2

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:

  1. Complexity of setup - right now, the configuration is super-simple
  2. 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?
  3. 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.
4

You can pass environment variables to the CGI pool from Apache configuration files:

    SetEnv PHP_ADMIN_VALUE "open_basedir=/path-to-your-doc-root"
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost/"
    </FilesMatch>

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

4

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.

3
  • This worked well for me and meant that I didn't have to spin up multiple pools just to segregate error logs. Thanks for the answer!
    – e_i_pi
    Jun 15 '17 at 11:17
  • It's probably worth adding that these sections must be in the standard config files (php.ini and conf.d/*) and not the fpm config files (php-fpm.conf and pool.d/*). The fpm config files are specifically for configuring pools so any [HOST=] sections will be creating a new pool not just adding some config.
    – George
    Aug 23 '17 at 9:07
  • can't get this to work. I'm trying to use a [PATH=...] section in my custom php.ini in conf.d. It is successfully being parsed but settings are not activated when using [PATH=...]. Any idea on this?
    – Hokascha
    Mar 1 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.