[BlueOnyx:20121] 5209R PHP-FPM implementation overhauled

[Michael Stauber]

Hi all,

As you might have seen, Darren Wolfe reported to the list that our
PHP-FPM implementation on 5209R could use an improvement:

[BlueOnyx:20116] PHP-FPM and .php in url - file not found

If PHP-FPM was enabled for a Vsite, .htaccess didn't work correctly, as
we piped all file accesses on a PHP-FPM enabled Vsite through FCGI via a
ProxyPassMatch.

The solution he recommended involves a rewrite rule, that checks if the
file exists and ends with *.php. Only if that's the case, the FCGI call
is made. Any other content is still served directly by Apache.

That solves a couple of issues, such as the automatic Let's Encrypt
renewal not working if a Vsite was using PHP-FPM. Or the inability to
use files and folders with a leading dot in the name.

I just published two updates to the YUM repositories that bring new
base-apache and base-vsite RPM's that implement this fix.

To push out the new Apache configuration that uses the new PHP-FPM
implementation the YUM update will execute a new script:

/usr/sausalito/sbin/phptoggle.pl -h
Command line options for re-appliyng PHP settings to Vsites:
 -all    All Vsites with any form of PHP enabled.
 -dso    Only Vsites which use PHP as DSO without mod_ruid2.
 -ruid   Only Vsites which use PHP as DSO *with* mod_ruid2.
 -suphp  Only Vsites which use suPHP.
 -fpm    Only Vsites which use PHP-FPM.

In our case it will run this:

/usr/sausalito/sbin/phptoggle.pl -fpm

So if you have Vsites that use PHP-FPM, it will turn it off and back on
again to apply the new config lines to the Vsites Apache config files.

To make sure Apache comes up again after the YUM update this script also
runs Swatch, which will test if Apache responds and (if need be)
restarts it.

-- 
With best regards

Michael Stauber