PHP-FPM

PHP FastCGI Process Manager (FPM) is a PHP implementation of the FastCGI, an enhancement of the earlier Common Gateway Interface (CGI).

PHP-FPM works especially well with NGINX.

Installation

To install PHP-FPM on a system, use your local package to manager to grab all of the following: php, php-fpm, fcgiwrap, and nginx.

Often apache2-utils (a.k.a. apache-tools, httpd-utils, etc... consult your package manager!) is also necessary, for creating .htpasswd files.

Upstream manages a Docker file with frequent security patching, as bitnami/php-fpm:latest. This will expose PHP-FPM on port 9000 and generally work out of the box.

PHP

A working installation of PHP is required. See here for help in configuring PHP.

PHP-FPM

For the most part, distributed configuration for PHP-FPM works out of the box.

; Pid file
pid = /run/php-fpm/php-fpm.pid

; Error log
error_log = /var/log/php-fpm.log

FCGIWrap

FCGIWrap is, as the name implies, a wrapper script. It manages the configuration of FastCGI through PHP-FPM so that all you need to do is point NGINX at /run/fcgiwrap.sock.

NGINX

NGINX is a modern and lightweight web server, which works well with PHP-FPM. For more details on NGINX configuration, see here.

A basic configuration is:

user www-data www-data;

http {
  server {
    listen 80;
    server_name example.com;
    root /var/www;

    location ~ \.php(/|$) {
      fastcgi_split_path_info ^(.+\.php)(/.+)$;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      fastcgi_param PATH_INFO       $fastcgi_path_info;

      try_files $uri =404;

      fastcgi_pass unix:/run/fcgiwrap.sock;
      include fastcgi_params;
    }
  }
}

As stated above, /run/fcgiwrap.sock can be used through FCGIWrap. If you are not using that package, or if you are using the upstream Docker image, you will need to set this differently. In particular, if you are redirecting to a PHP environment on another server, you will need to set this to an address and port.

fastcgi_pass 127.0.0.1:9000

Test Script

A minimal test script to validate the PHP installation.

<?php phpinfo(); ?>

Remote Files, chroots, and Work Directories

PHP applications can be placed anywhere on the web root and they will work as expected. This is because PHP-FPM defaults to working in the current work directory.

However, it is recommended to isolate PHP-FPM by running it in a different work directory. This is accomplished by configuring PHP-FPM on a pool level, which you can read more about here. What needs to be addressed up-front is how a web server will interact with an isolated FastCGI environment.

The NGINX try_files command, as shown below, checks for existence of files. This will cause issues if PHP applications are actually living in a different directory (or a different server). However, without checking for the existence of an executable, you can run into difficult-to-debug errors and security issues regarding embedded PHP in ordinary files.

The workaround is to set the key FastCGI parameters for the target server and check the URI against local null files. Furthermore, note the specific ordering in this configuration.

location ~ \.php(/|$) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    fastcgi_param SCRIPT_FILENAME /remote/path/to/work/directory/$fastcgi_script_name;
    fastcgi_param PATH_INFO       $fastcgi_path_info;

    try_files $uri =404;

    fastcgi_pass 127.0.0.1:9000;
    include fastcgi_params;
}

Note that try_files is called strictly after path info has been pulled out. Try files will, on success, overwrite $uri with the matched local URI. To avoid this, set the value of parameters before validating file existence.

CategoryRicottone