Re: [PHP] PHP-FPM fails to start scripts

On Wednesday 24 May 2017 03:40:54 Lester Caine wrote:
> On 24/05/17 02:05, John Iliffe wrote:
> > On Tuesday 23 May 2017 02:40:03 Lester Caine wrote:
> >> On 23/05/17 02:41, John Iliffe wrote:
> >>> The Apache directive invoking this script is:
> >>> 	ProxyPassMatch "^/.*\.php(/.*)?$"
> >>> 	fcgi://127.0.0.1:9015/httpd/iliffe/
> >> 
> >> ProxyPassMatch ^/(.*\.php(/.*)?)$
> >> fcgi://127.0.0.1:9015/httpd/iliffe/$1 was your original line, and
> >> this should have resulted in the right trimming of slashes while I
> >> think you are currently getting the double slash because of the
> >> trailing one in your current string.
> > 
> > Please ignore this following paragraph.  It was an attempt at a
> > minimalist ProxyPassMatch that would bypass any regex errors.  It
> > isn't useful in the real world so I dropped trying it.  I think you
> > got that info from the Apache mailing list.
> 
> I suggested it simply because it would bypass some errors ;)
> 
> >> ProxyPassMatch ^/info$
> >> fcgi://127.0.0.1:9015/httpd/iliffe/i_phpinfo.php and
> >> http://localhost/info should work ... but is /httpd REALLY a root
> >> folder? I'm getting /srv/www/htdocs as the default root, and I
> >> switch to /srv/website/test.com for each website ...
> > 
> > Some further info:
> > 
> > Yes, /httpd is the root directory for the web pages.  The production
> > server has a lot of named virtual hosts on it and each one has a
> > document root of /httpd/<server name>/  and the test server is set up
> > the same way.  The test server is www.iliffe.ca and its document root
> > thus becomes /httpd/iliffe plus a few subs below that where needed. 
> > In this case, there are no additional subs.
> 
> One of the major problems with Linux is the way each distribution
> modifies just where it installs key applications and how it manages
> them. I'm on SUSE myself and apart from a couple of attempts at other
> distros when the SUSE guys just totally lost the plot, I've been with
> that since version 6. My problem is installing later APACHE/PHP builds
> while maintaining the stable SUSE installs ... and getting paths right
> teds to be the problem.
> 
> > When I tried the $1 extension as you suggested it didn't work, see
> > previous memo; so I removed the $1 and also the last '/' in the
> > ProxyPassMatch directive and now php-fpm has the correct path and
> > file but without the double '//'.  So, this is one case where a
> > trailing / on a directory does not work/isn't required.  Here is the
> > strace record:
> > 
> > -------------------------------
> > 5254  20:14:55 lstat("/httpd/iliffe/i_phpinfo.php",
> > {st_mode=S_IFREG|0644, st_size=213, ...}) = 0
> > --------------------------------
> > 
> > php-fpm received a 0 from lstat (file exists), is a regular file
> > (S_IFREG) and is readable (0644).  So that makes no difference to the
> > result.  php-fpm still backs down the directory tree and then tries
> > to stat the wrong file name.  Just for completeness, here is the
> > php-fpm log entry:
> > 
> > ----------------------------------
> > [23-May-2017 20:14:55] WARNING: [pool www] child 5254 said into
> > stderr: "ERROR: Unable to open primary script:
> > /httpd/iliffe/i_phpinfo.php (No such file or directory)"
> > ---------------------------------
> 
> THAT is telling me that /httpd/iliffe/i_phpinfo.php is not the path to
> the file. Bit like one gets with windows where it hides the real
> physical location and only gives you a 'user' view of the path. My copy
> of Apache is using wwwrun:www user when it is running, so all of the
> /<server name> folders and files have that user name and group, but even
> with that php should be able still to read the file so I'm still
> thinking the path is wrong in some way. A quick search on Fedora give
> /var/www/html/ as the default where SUSE gives me /srv/www/htdocs ...
> 
> > I haven't been able to find out yet if the parameter data is picked up
> > when the Apache directive is coded this way.   (eg:  
> > i_phpinfo.php?a=b&c=d)
> > 
> > I seem to be getting a good argument here for backing off to PHP5!
> 
> If there was a good security reason for changing the PHP5.4 machines I'm
> still running then I'd move, and eaccelerator still provides all the
> speed improvement I need, so I'm not surprised three quarters the world
> has yet to even move to a higher version of PHP5 ... and less that 5%
> are using PHP7 front facing.