Re: unable to execute php-fpm properly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 12 April 2017 22:24:03 Frank wrote:
> On 12/04/17 08:36 PM, John Iliffe wrote:
> > See below.
> > 
> > On Wednesday 12 April 2017 20:02:10 Frank wrote:
> >> On 12/04/17 05:34 PM, John Iliffe wrote:
> >>> I am converting my web pages from mod_php to php-fpm, following the
> >>> directions found at:   https://wiki.apache.org/httpd/PHP-FPM  
> >>> Testing to date indicates that on this server all scripts work
> >>> properly under mod_php.
> >>> 
> >>> Both of the following were tried within a <VirtualHost> container
> >>> for the default virtual host.
> >>> 
> >>> If I use the "simple" approach from the Wiki:
> >>>  ProxyPass "/*.php/" "fcgi://127.0.0.1:9000" enablereuse=on
> >>> 
> >>> then the page SOURCE is displayed, PHP never executes.  Adding a
> >>> first line of      #! /path-to-php-executable   doesn't accomplish
> >>> anything.  Neither way leads to any errors showing in the php-fpm
> >>> log.
> >>> 
> >>> 
> >>> Using the "more flexible" approach:
> >>> 
> >>> ProxyPassMatch ^/(.*\.php(/.*)?)$
> >>> fcgi://127.0.0.1:9000/httpd/iliffe/$1
> >>> 
> >>>    enablereuse=on
> >>> 
> >>> Gives me a "No Input File Specified" error.  This line was cribbed
> >>> from the Wiki example and the path /httpd/iliffe/  is precisely
> >>> where the php script lives, based on the server root and not the
> >>> document root as noted in the Wiki article.
> >>> 
> >>> There is no php-fpm error message issued in either case and the
> >>> Apache error entry for the ProxyPassMatch case is:
> >>> 
> >>> [Wed Apr 12 16:50:28.688837 2017] [proxy_fcgi:error] [pid 13574:tid
> >>> 140145512003328] [client 192.168.1.10:45240] AH01071: Got error
> >>> 'Unable to open primary script: /httpd/iliffe/testfcgi.php (No such
> >>> file or directory)\n'
> >>> 
> >>> I am using mostly the defaults in the php-fpm config and pool config
> >>> files. The default path to the php executable has been updated to
> >>> point to where it really is.
> >>> 
> >>> Can anybody see what I might have missed?
> >>> 
> >>> Thanks in advance.
> >>> 
> >>> John
> >>> =========================================
> >>> 
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> >>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
> >> 
> >> 1) ProxyPass doesn't use PCRE (the wiki does not use PCRE with
> >> ProxyPass, either). You need to use ProxyPassMatch to parse PCRE.
> > 
> > I'm not sure what you are saying here.  When I used only ProxyPass
> > using the default configuration in the Wiki, the correct page was
> > displayed, it just didn't execute the PHP script and adding the
> > bang-path didn't change anything.  The source code was displayed as
> > the page.
> > 
> > While it is possible that the ProxyPath directive didn't match
> > anything and Apache tried to handle the script file as a static page,
> > I have been unable to prove that conjecture.  The page IS in Apache's
> > document root for this virtual host, so I suppose that is possible. 
> > There is no SetHandler directive to handle the .php extension, and my
> > understanding of the documentation is that one should not be required
> > since Apache is not actually running the script.
> > 
> >> 2) /httpd/iliffe/testfcgi.php would need to exist on your filesystem
> >> or php-fpm chroot. The requested URI is literally appended to the
> >> path in the ProxyPassMatch directive.
> > 
> > Yes, that's what I had expected to happen.  php-fpm does not chroot;
> > the true path /httpd/iliffe/testfcgi.php exists in the file system
> > and is visible to php-fpm, based on the simpler configuration. 
> > That's what's so weird, the same path gets completely different
> > results, depending on the way the script is called.   In this case
> > the $1 amounts to a null since there is no passed data in the URL.
> > 
> > Before you ask, I expect SELinux problems with these files because of
> > the tagging, but at the moment SELinux is in permissive mode.
> > 
> > John
> > 
> 
> ProxyPass *cannot* understand PCRE. ProxyPassMatch *can*. Hence, do
> *not* use PCRE with ProxyPass. That is all.
> 
> Step 1) Make sure that mod_proxy_fcgi is loaded. See apachectl -M
> 
[root@prod04 John]# /usr/apache-2.4.25/bin/apachectl -M
Loaded Modules:
 core_module (static)
 so_module (static)
.......whole lot of modules skipped here.....

 version_module (shared)
 proxy_module (shared)
 proxy_connect_module (shared)
 proxy_ftp_module (shared)
 proxy_http_module (shared)
 proxy_fcgi_module (shared)    <------
 http2_module (shared)                                                                                                                
 proxy_http2_module (shared)

The necesary support modules for mod_proxy_fcgi (mod_proxy and 
mod_proxy_http2) are also verified as being loaded.

> As for the "Primary Script Unknown" error, it always means that you
> mapped the request to a non-existent resource on the file system /
> chroot. Verify again.
Here is the process root info for php-fpm

[root@prod04 John]# ps -ef | grep php-
root     15368     1  0 Apr12 ?        00:00:00 php-fpm: master process 
(/usr/php-7.1.3/etc/php-fpm.conf)
phpfpm   15369 15368  0 Apr12 ?        00:00:00 php-fpm: pool www
phpfpm   15370 15368  0 Apr12 ?        00:00:00 php-fpm: pool www

[root@prod04 John]# ls -al /proc/15368/root
lrwxrwxrwx. 1 root root 0 Apr 13 10:34 /proc/15368/root -> /

Here is the directory for the document root and also the absolute path that 
was passed to php-fpm 

[root@prod04 John]# ls -al /httpd/iliffe/t*
-rw-rw-r--. 1 John John 5740 Apr 12 16:40 /httpd/iliffe/testfcgi.php

I had already done all of these checks before I asked for help on this 
list.    The commands used to invoke both ProxyPass and ProxyPassMatch were 
cut and pasted from the Wiki.  The only change I made was to put in the 
correct base directory path.

Also, I did verify that the TCP port (9000) for php-fpm was present and 
listening:

[root@prod04 John]# ss -a -n | grep 9000
tcp    LISTEN     0      128    127.0.0.1:9000                  *:*                  
tcp    LISTEN     0      0      127.0.0.1:9000                  *:*   

While I don't think it is necessary, since the TCP port is on the loopback 
interface, I also opened port 9000 on the internal firewall:

root@prod04 John]# firewall-cmd --list-ports
     ----other open ports not shown--------
 9000/tcp

> 
> The various methods listed on the wiki allow httpd to pass the request
> to a fcgi backend, which will process the php file, and return the
> output. You can use the SetHandler approach instead of ProxyPassMatch -
> it's up to you.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux