After updating our server to Debian Jessie (8.3), I switched Apache 2.4.10 from mpm_worker/mod_php to mpm_event/proxy_fcgi/php-fpm. I have the handoff configured for all virtual hosts as such:
# cat conf-enabled/php5-fpm.conf
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost/"
</FilesMatch>
I have also disabled mod_php. Because of that, apache will not let me have php_admin_value/php_value/php_flag directives in the VirtualHosts files.
Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration
I've read a bit about .user.ini files, but it doesn't sound like the directives I need to set will are supported in there, and I just successfully removed all the .htaccess files from my site for performance reasons, so this seems like a backward (and incompatible) approach.
The other common suggestion is to make a unique pool for each VirtualHost, but this concerns me for two reasons:
- Complexity of setup - right now, the configuration is super-simple
- Switching from socket to TCP? Am I correct in that that I need a unique TCP port per pool? Would I alternatively need a unique socket per pool?
- Memory allocation! This server doesn't have as much RAM as I'd like. It seems wasteful to have a bunch of php-fpm instances spun-up for the lesser-visited sites on the server.
You can pass environment variables to the CGI pool from Apache configuration files:
mod_env
must be enabled, and you must disable.htaccess
file handling, if third party users can upload, or modify them (AllowOverride None
). If you need to pass more than one variable, you must concatenate them with a newline char (\n
).A malicious user can change
open_basedir
or other important PHP configuration variables (ie.:disable_functions
) with a simple.htaccess
. I don't know if it's possible to prevent this behavior.Reference: https://bugs.php.net/bug.php?id=51595
In the end, I just defined some [HOST=] sections in my /etc/php5/fpm/php.ini configuration.
http://php.net/manual/en/ini.sections.php
This felt more secure than using mod_env or .user.ini.