[BlueOnyx:20126] Re: 5209R PHP-FPM implementation overhauled

[Darren Wolfe]

Hi,


I'm afraid that since those changes were implemented, there has been another issue that has cropped up.

The proxypassmatch rule worked with urls in the form "/index.php/foo" (where index.php is a file, not a directory and foo foes not exist - used in Magento and vbulletin), but not "/foo/index.php" (where foo was not a real directory - used by Wordpress multisite).

The rewritecond -f rule fixed this by checking if the file in the url existed before passing it to phpfpm. This fixed /foo/index.php by allowing the wordpress htaccess to rewrite this to /index.php but, it turns out that it broke /index.php/foo - but in a weird way.

The rewritecond in the vhost config checks if the full url exists, which /index.php/foo does not. And so it goes through into the htaccess as you would expect. 

In the case of vbulletin (which doesn't use an htaccess), because index.php/foo doesn't exist, you get a 404.

In the magento htaccess, there is a rewrite that should rewrite any url to /index.php but only if the file does not exist. But when httpd checks it THIS time, for some reason it strips away everything after index.php, and determines the file exists, so this final rewrite is never done! And then we get to the end of htaccess, and because /index.php/foo doesn't actually exist, it throws a 404.


So - how do we fix this?

RewriteCond /home/.sites/75/site8/web/%{REQUEST_FILENAME} -f
RewriteRule ^/(.+\.php(/.*)?)$ fcgi://127.0.0.1:9059/home/.sites/75/site8/web/$1 [L,P]

RewriteCond /home/.sites/75/site8/web/%{REQUEST_FILENAME} "\.php/"
RewriteRule ^/(.+\.php(/.*)?)$ fcgi://127.0.0.1:9059/home/.sites/75/site8/web/$1 [L,P]

The first rule and condition is the same as before. We check if the file exists, if it does then we pass the url to phpfpm and let it carry on.
The second rule and condition specifically checks for a url in the form index.php/foo (is there a / immediately after .php) - if there is, we pass that to phpfpm too.

I've tested these new rules with wordpress multisite, magento and vbulletin - hopefully this is the last change that should be made.

It's weird and inconsistent that proxypassmatch worked with /index.php/foo and not /foo/index.php when neither exist. I suspect that it's not actually httpd that cause it, but phpfpm. It must have some sort of kludge buried within its code to handle the former url. All we've actually done here is allow that kludge to do its job again.
You can actually see there is something like this happening if you examine the http vars passed to php.


If we use the old proxypassmatch rule, we get these:
    [REQUEST_URI] => /index.php/foo
    [SCRIPT_NAME] => /index.php
    [ORIG_SCRIPT_NAME] => /index.php/foo
    [PATH_INFO] => /foo
    [ORIG_SCRIPT_FILENAME] => /home/.sites/90/site11/web//index.php/foo
    [PATH_TRANSLATED] => /home/.sites/90/site11/web/foo
    [PHP_SELF] => /index.php/foo

If we make a new rule that just passes the actual script to phpfpm - as you might expect it should need:

RewriteCond /home/.sites/90/site11/web/%{REQUEST_FILENAME} "\.php/" 
RewriteRule ^/(.+\.php) fcgi://127.0.0.1:9061/home/.sites/90/site11/web/$1 [L,P]

You get this:

    [REQUEST_URI] => /index.php/foo
    [SCRIPT_NAME] => /index.php/foo
    [PHP_SELF] => /index.php/foo

Note that the script_name is the full url! Weird! This does actually work, but...

If we use our new rule as above we get:

    [REQUEST_URI] => /index.php/foo
    [SCRIPT_NAME] => /index.php
    [ORIG_SCRIPT_NAME] => /index.php/foo
    [PATH_INFO] => /foo
    [ORIG_SCRIPT_FILENAME] => /home/.sites/90/site11/web/index.php/foo
    [PATH_TRANSLATED] => /home/.sites/90/site11/web/foo
    [PHP_SELF] => /index.php/foo

The same as with proxypassmatch!
This suggests that we're activating the same code within phpfpm with our new rule, so we should be done with this problem from now on.

-----Original Message-----
From: Blueonyx [mailto:blueonyx-bounces at mail.blueonyx.it] On Behalf Of Michael Stauber
Sent: 02 October 2016 01:06
To: BlueOnyx General Mailing List <blueonyx at mail.blueonyx.it>
Subject: [BlueOnyx:20121] 5209R PHP-FPM implementation overhauled

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
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx