RE: php(5)-cgi + Apache2 + fastcgiexternalserver =lost hair

[Paul Blondé <jpb@xxxxxxxx>]

I have seen PHP run as an Apache module plenty of times, but not remotely.
It makes sense to run it as a module if you have a busy server and many, if
not most, of your pages are written in PHP. In addition to my other post, I
can also see where it would make great sense to run a database server with
Apache+PHP that would respond to, for instance, includes from multiple other
servers to provide data from the database without having to run PHP and
MySQL on each web server, but you still have to have an httpd on the PHP
machine I think.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Blondé


-----Original Message-----
From: Keith Roberts [mailto:keith@xxxxxxxxxxxx] 
Sent: Tuesday, July 24, 2007 1:30 PM
To: php-install@xxxxxxxxxxxxx
Subject: Re:  php(5)-cgi + Apache2 + fastcgiexternalserver
=lost hair


That's interesting Tony. Didn't know you could do that. Are 
you saying you want to run PHP as an Apache module, and the 
CLI version remotely?

If so, why would you want to do that?

Regards

Keith

On Tue, 24 Jul 2007, Tony Shadwick wrote:

> To: Keith Roberts <keith@xxxxxxxxxxxx>
> From: Tony Shadwick <tshadwick@xxxxxxxxxxxxxxxxx>
> Subject: Re:  php(5)-cgi + Apache2 + fastcgiexternalserver =
lost
>      hair
> 
> Yup.  Build php as a cgi binary, and then start it with -b flag.  You can 
> choose the port you want to run it on.  Then use fastcgiexternalserver 
> (or equivalent) to connect to it.
>
> Keith Roberts wrote:
>> AFAIR I have never heard of hosting apache and php on seperate 
>> machines. I don't even know if you can connect to php remotely, say 
>> like MySQL on a specified port?
>> 
>> Kind Regards
>> 
>> Keith Roberts
>> 
>> On Tue, 24 Jul 2007, Paul Blondé wrote:
>> 
>>> To: php-install@xxxxxxxxxxxxx
>>> From: Paul Blondé <jpb@xxxxxxxx>
>>> Subject: RE:  php(5)-cgi + Apache2 + 
>>> fastcgiexternalserver = lost
>>>      hair
>>> 
>>> wait...are you saying that you are hosting your PHP on one machine, 
>>> and your
>>> Apache on another?
>>> 
>>> Does Apache+PHP support remoting like that?
>>> 
>>> 
>>> 
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Paul Blondé
>>> 
>>> 
>>> -----Original Message-----
>>> From: Tony Shadwick [mailto:tshadwick+php.net@xxxxxxxxxxxxxxxxx]
>>> Sent: Tuesday, July 24, 2007 11:02 AM
>>> To: php-install@xxxxxxxxxxxxx
>>> Subject:  php(5)-cgi + Apache2 + fastcgiexternalserver = 
>>> lost
>>> hair
>>> 
>>> 
>>> Okie.  I've been googling for days on this now, and I've come across
>>> several PHP bug reports that basically say this is a configuration
>>> error, and not a php bug.  If that's true, I seriously need help.
>>> 
>>> On my web server box, I'm running Apache2.1, and in my httpd.conf file 
>>> I
>>> have this:
>>> 
>>> FastCGIExternalServer  /path/to/stub/fcgi-bin/php -host php-host:9000
>>> 
>>> Then in my Includes/site.conf (individual sites each have their own
>>> config file), I have this:
>>> 
>>> AddHandler php-cgi .php
>>> Action php-cgi /fcgi-bin/php
>>> ScriptAlias /fcgi-bin/php ScriptAlias /fcgi-bin/php
>>> /path/to/stub/fcgi-bin/php
>>> 
>>> Then I have a directive that adds +ExecCGI to the user's directory. 
>>> So
>>> far so good.  Restart apache.
>>> 
>>> On the php-host box, I've compiled:
>>> 
>>> php5-5.2.3          PHP Scripting Language (Apache Module and CLI)
>>> 
>>> I start it using php-cgi -b 9000.  The port accepts connections just
>>> fine.  When I go to browse to a simple script on my web host that has:
>>> 
>>> <?
>>> 
>>> phpinfo();
>>> 
>>> ?>
>>> 
>>> I get "No input file specified." on screen, and in the logs I get what
>>> oddly appears to be a 404 message:
>>> 
>>> 172.16.12.2 - - [23/Jul/2007:22:27:12 -0500] "GET /phpinfo.php 
>>> HTTP/1.1"
>>> 404 25 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
>>> AppleWebKit/419.2.1 (KHTML, like Gecko) Safari/419.3"
>>> 
>>> Except it's really not a 404.  If I get rid of the php handler, it
>>> returns the text of the script just fine.
>>> 
>>> I've googled this mess forwards and backwards, and what I come across 
>>> is
>>> that there appears to be some sort of a tiff between PHP and web
>>> servers, where web servers usually pass along the environment variable
>>> SCRIPT_NAME, whereas PHP wants SCRIPT_FILENAME in order to determine
>>> that it is running in cgi mode (I think?).  I've done everything I can
>>> think of to facilitate that.  I've adjusted the relavent setting in
>>> php.ini on the php host
>>> 
>>> cgi.fix_pathinfo=1
>>> 
>>> Restart the php-cgi binary, does no good.  I've tried making 
>>> mod-rewrite
>>> changes on apache2 to force SCRIPT_FILENAME to be assigned, that 
>>> doesn't
>>> work.  I've tried manually assigning a SCRIPT_FILENAME environment
>>> variable on the shell that I'm executing php-cgi from.  That too 
>>> fails.
>>> 
>>> Out of desperation, I finally ran tcpdump -w ~/phpdump.txt -i em0 port
>>> 9000 on the php-cgi host.  I won't bore you with everything that
>>> wireshark says about it, rather, the most relevant part gets revealed 
>>> by
>>> strings I think:
>>> 
>>> # strings ~/phpdump.txt
>>> REDI
>>> SCRIPT_NAME/fcgi-bin/
>>> Status: 404
>>> X-Powered
>>> 
>>> 
>>> A few things stand out to me here:  number one, SCRIPT_NAME appears to
>>> be getting sent, 2 it looks like php-cgi is the one returning 404, not
>>> the web server, and finally....this is getting a bit truncated, isn't
>>> it?  I'd fully expect to find the full X-Powered header there, and if
>>> it's going to say /fcgi-bin/, I'd expect to find /fcgi-bin/php.  and
>>> REDI....?
>>> 
>>> Anyone have an idea what I can do to fix this up?  The file DOES 
>>> exist.
>>>  It'd currently chmod 777 to make sure it's not a permissions thing
>>> (it's just phpinfo at this point anyway....).  The traffic *is* being
>>> sent to port 9000 on the php-cgi host.  What else can I do?
>>> 
>>> Tony Shadwick
>>> OSS Solutions
>>> 
>> 
>

-- 
------------------------------------------------------------
http://www.karsites.net
http://www.raised-from-the-dead.org.uk

This email address is challenge-response protected with
http://www.tmda.net
------------------------------------------------------------