[thelist] [long] PHP and Apache, each in a box. Possible?

[Steve Lewis]

M.G. Noriega wrote:

>It's a fair large company, whose intranet was built by us. Right now,
>it's two twin servers and a load balancer. Today they phoned me asking
>about wanting to set up a third server, which would be accesible from
>internet (maybe for a public show of the intranet or something) but they
>wished to install only Apache and let the already existing php do the
>magic.
>  
>
Given that PHP is not network-aware service by itself, I do not see how 
you can have Apache on one machine talk to PHP directly on another 
machine.  Not knowing more about your environment, I will try to cover 
as many details as I can.  If anyone else sees options I missed or 
errors in my thinking please do share. :)  I am somewhat confused by the 
premise of the question, however.  You do not mention a MySQL or other 
database engine and usually PHP is used with dynamic content from a 
database as well as for the scripting power available to interpret 
dynamic incoming requests.  Are you storing dynamic content on the file 
system?  Are you using PHP to rewrite other PHP scripts? If you say yes 
to either of these cases than there are special concerns we find below.

The model, as I see it.
1) Apache passes requests to PHP (either as a CGI or as a module 
compiled into Apache)
2) The PHP scripts interpret the request and generate a response.  This 
could involve the following steps.

2a) The PHP scripts may query a database.
2b) The database responds to the queries from PHP.
2c) PHP would then integrate the query results into the response.

3) PHP passes the response to Apache.
4) Apache transmits the response over the network,

Apache must be able to hand off the request to PHP at step 1 above.  PHP 
is not a socket-aware server daemon, it is either a module to Apache, or 
it is a stand-alone application that is executed by Apache with each 
request (CGI mode).  Apache must be able to "run" PHP so Apache must be 
able to see the filesystem that PHP and your script files are sitting 
on.  If you are in the *nix world, this can be achieved with a shared 
file system (read up on NFS or Network File System) to share the PHP 
executable and the scripts that PHP will read.  In the Windows world, 
you could create a shared folder, map that folder as a networked drive 
on the other server, and access it normally.  Using NFS or a shared 
folder would mean that there was only one copy of the PHP scripts to 
maintain.  If you are storing dynamic content on the file system or 
using PHP to rewrite other PHP scripts, this is your optimal solution.  
You would likely want to be careful of security issues, of course.

Another option, if you do not like the NFS/shared folder scenario would 
be to create an automated scripted process which would copy files from 
one server to the other.  Look at using cron to execute a CVS update as 
an option in the *nix world.  I don't know what to recommend for the 
Windows world.  You could potentially script 'backups' to be made from 
the first server, and restored on the other.  This option is better 
suited to an as-needed batch process and not well suited for dealing 
with dynamic content on the file system.

A third option, which defeats the purpose of load balancing, would be to 
have the second Apache server send a request to the first Apache server, 
and then forward that response (making sure to strip the headers 
returned by the first Apache server).  There may be other options that I 
am missing.

If you have a database system like MySQL storing dynamic content than 
you have more options.  Relational database management systems /are/ 
network-aware applications.  Any number of Apache + PHP systems can send 
database requests to a single database server, or different database 
servers as needed, in the process of generating their responses.  This 
option allows you to run, for instance, two Apache + PHP servers 
connecting to one MySQL server which uses your 'live' database.  Then 
you could have a third Apache + PHP server connecting to the /same/ 
MySQL server, using your 'demo' database (and using a different MySQL 
username/password for security), or maybe even using your 'live' 
database.  Another twist would be to put the MySQL server daemon on one 
of the first two Apache servers.  This would make no significant impacts 
on how the model works.

HTH,
Steve