Nginx and PHP – configure php.ini file

We already have a configured a Nginx web server and PHP-FPM wrapper. It’s time to change PHP default settings now – default configuration files from Ubuntu or Debian repositories aren’t bad, but we can make them better for our needs. In this chapter we will change only one file, php.ini, which should be located on /etc/php/YOUR_VERSION/fpm/ directory. Of course, fell free to use other settings than proposed on this blog entry.

Nginx installation and first configuration

Nginx virtual host configuration

Use PHP-FPM with Nginx

Describe and change php.ini settings

PHP-FPM – config improvements

Use strong Nginx encryption settings

Nginx optimizations, tips and tricks (work in progress)

PHP.ini configuration file

It’s main PHP configuration file with global settings for all deamons that use this PHP version. We can overwrite some of this file values in wrapper configuration files, but it isn’t topic of this entry. Just open this file and find some values:

Performance settings

It’s memory limit for PHP process and very important setting. Some of our scripts can consume more memory, good example is images or text processing. Also some „standard” scripts may need high memory limit – Invision Power Board community software is good example with minimum 128 MB memory limit for installation. So, should we put there very big limit, half of our server memory capacity? No. It’s limit per process, so if you set 256 MB limit and there will be just 4 high memory usage processes, they may consume 1 GB. I think better option is to set low limit (32 MB) and increase this value on demand using ini_set function.

These settings are related to files uploading. We can limit the size of files that users will upload on our forms, AJAX requests etc. All depend of our needs – you should set maximum possible value. Remember, that big upload limit and slow connection will block your processes.

Maximum time (in second) for one PHP request – after this time, script will be automatically terminated by PHP engine. Of course it will display error message to user, but you should always use this setting and also set small values – big execution limit allows potential attackers block your PHP and overload server if there is any slow scripts.

It’s maximum time to get data from user request – it means, maximum time what PHP can wait for user input: file uploading, send (very) big form, and others. In this case, it’s similar to max_execution_time, but applies only to POST/GET processing, not whole script execution. Default value is -1 and it isn’t unlimited – that value means it will be the same as max_execution_time. And it’s good option.

Security settings

These three settings are related to user sessions and cookies handling. First forces session renegeration and strengthens security – if we don’t use this setting, should always regenerate session ID after each request. Use only cookies will prevent script to use URLs to store session ID. It isn’t secure, because potential attacker can steal ID from URL (or users can just copy such URLs to other people…). Cookie secure will force script to use secure connections to send cookies – it’s great option, but we must use encryption on our web server. It’s only proposed configuration.

Disable functions directive allows us to disable some of buil-in PHP functions. It’s great option if we just want limit our PHP wrappers and disallow to run for example shell commands. I can’t say what setting will be good for your websites, all depend on your needs.

 

Logs settings

 

It’s PHP error reporting level. I think is good option to log any reports and fix bad scripts, but sometimes „all” is too much. You can configure this option and increase or decrease logging level – disable notices, warnings or new PHP versions stricts standards information.

Errors logging is good, but you should not display any error to user – it isn’t necessary, it isn’t „prety” and also can reveal your website configuration. Better option is to log error to file and check it regularly. You can send errors to browser only on development environment.

Other settings

You can say: what? Timezone? It isn’t important! But it is important. Without that and without on demand set timezone, some script can send PHP notices about invalid timezone. Also, it should be used to handle all dates and properly without set timezone every time.

This small option is enabled on default and will fix some PHP variables (like PHP_SELF) on configuration with Nginx web server. It was security issue before 5.4 because allow attackers to run other files as PHP scripts using invalid requests, but now it isn’t problem because of changes in other PHP settings. If you use Nginx, you should enable this option.

This option will display (or not, as on example) PHP information on server headers. I think we should hide as much as possible – real users will not check our server headers, potential attackers or script kiddies will do. We know what PHP version we use, so… why should we reveal this to all visitors? It’s not necessary and should be disabled after PHP installation.