You are browsing the documentation for iTop 2.6 which is not the current version.

Consider browsing to iTop 3.2 documentation

PHP and MySQL settings

iTop needs write access to the temp dir (this path is retrieved using the PHP function sys_get_temp_dir()). Check rights and also the openbase_dir PHP parameter !

When editing objects with many relations, iTop creates one big form containing all the relations. Therefore in some cases the number of variables passed to the PHP server may exceed 1000. A configuration setting protects PHP against such a situation. This behavior is configurable using the parameter max_input_vars in php.ini, which default value is 1000.

Make sure that the parameter max_input_vars (in php.ini) is set to a large enough value (for example 5000)
This very same behavior may happen when Suhosin is installed. Refer to iTop and Suhosin for more information

iTop is capable of uploading and storing documents (i.e files) as attachments to various objects (Tickets, CIs…). These documents are stored as binary blobs in the iTop database. In order to to safely upload and store documents, several settings must be adjusted consistently across PHP and MySQL.

In PHP, several variables govern the upload of files:

file_uploads Set to 1 to allow file upload, to zero to prevent all file uploads.
upload_tmp_dir The temporary location (on the server) were the uploaded files will be stored. Make sure that this parameter points to a location that is accessible (and writable) by the process running the web server (or by the end users in case of IIS with the Windows built-in authentication) and that there is enough space left.
upload_max_filesize The maximum size allowed for an uploaded file. The value is expressed in bytes. You can use units like K for kilobytes (=1024 bytes), M for megabytes and G for gigabytes. Example: 4M stands for 4 megabytes.
max_file_uploads The maximum number of files that can be uploaded simultaneously in a single web page. iTop should normally upload only one file at a time. You can safely use the default value, which is 20.
post_max_size The maximum amount of data that can be sent to the server via a POST request. This value MUST BE bigger than upload_max_filesize, since the same request will contain some more information (the title of the document, an operation code…). So it’s better to put a bigger value here. For example, if upload_max_filesize is 4M, then put 5M for post_max_size.
memory_limit After being uploaded on the server, the file will be read in memory before being stored in the database. Therefore make sure that memory_limit (if enabled) is far bigger than upload_max_filesize.
max_input_time This value defines the maximum time allowed for the server to read its input. This includes the time spent uploading the files. The default of 60 seconds may be exceeded for uploading big files over slow connections.

The uploaded files are stored into the MySQL database, each file in one query. Therefore the maximum size allowed for a query MUST BE BIGGER than the maximum size of the uploaded file. This is configured via the variable max_allowed_packet in the my.cnf configuration file (on the MySQL server).

It is good practice to have the following relation between the various settings:
upload_max_filesize < post_max_size < max_allowed_packet < memory_limit
php.ini php.ini my.cnf php.ini
If you ever have an issue linked with mysqldump, there is another parameter max_allowed_packet you can act on, in the same file my.cnf but under [mysqldump] section

As of iTop 2.5, the charset used is utf8mb4 with utf8mb4_general_ci collation. To allow iTop to correctly handle strings, the following requirements must be met :

  • MySQL version 5.5.3 or newer
  • innodb_default_row_format variable set to DYNAMIC (default value) or COMPRESSED
  • innodb_large_prefix set to true

MySQL recommandations

my.cnf
  innodb_buffer_pool_size = 512M
  query_cache_size = 32M
  query_cache_limit = 1M

PHP recommandations

php.ini
  memory_limit = 256M
2_6_0/install/php_and_mysql_configuration.txt · Last modified: 2020/02/05 11:42 (external edit)
Back to top
Contact us