[TriLUG] Apache2 / PHP / MySQL Help?

[Justis Peters]

Brian McCullough wrote:
> As it happens, Justis, rPath is my home these days too, and has been for
> a couple of years.
>   
Congratulations!  It seems like a good home, from what I can tell.  I 
apologize that I didn't already know you worked there.  I met Matt 
Wilson after the last TriLUG meeting and greatly enjoyed picking his 
brain.  I also attended a lecture on marketing by Keith Boswell (back 
when he still worked there).  I've even read Billy's blog a few times.  
Most of all, though, I've been curious since I first heard of your 
offerings.  You guys have built a great system there and I hope that you 
gain the market traction you deserve.  Virtualization has so much 
promise to simplify our world and rPath is helping to speed the delivery 
of that promise.
> Unfortunately, it is a client machine, in a rack in San Jose, installed
> with Debian Sarge.  The VMware idea is intriguing -- I really don't
> think it should be necessary to go that far, but maybe it is a way of
> avoiding the problem, instead of trying to fix it.  The system has a
> pile ( technical term! ) of Virtual Hosts defined in Apache, and we were
> just trying to add another which needs to use PHP and MySQL ( Drupal
> site ).
>   
Well, my suggestion to avoid the problem and use virtualization was 
before I knew that it was for an existing client on an existing server.  
If this had been just for a personal webserver so that you could fiddle 
with PHP, then the virtualization idea would be a faster route to the 
fun part.  I still think that it could be a useful trick to keep in your 
back pocket, in case you need to show the client results ASAP or just 
like the flexibility you gain with virtualization.

Based on the current machine setup, though, you're not going to be happy 
with virtualization as the solution, unless you move all the virtual 
hosts into one or two VMs.  You generally don't want to give each 
website its own virtual machine, unless there are compelling security or 
scalability reasons to do so.  The overhead for a VM is way higher than 
the overhead for a virtual host in Apache.  The overhead for Apache is 
almost trivial.  So, if you do virtualize, you probably want to still 
use virtual hosting in Apache.  You could probably move your whole 
"pile" of virtual hosts, along with the PHP one, into a single virtual 
machine.  For the technology stack you're using (LAMP), you'll get the 
biggest bang for your buck with a Xen kernel, paravirtualized.  The 
performance hit is very small and you gain a lot of benefits, like the 
potential for easy backup and disaster recovery, the ability to clone a 
production environment precisely, and the ability to do easy 
deploy/rollback of new software versions.

The VMware tools are way easier to work with, though, and you mentioned 
them directly.  You probably don't want to buy ESX server for a simple 
PHP hosting client and the performance on GSX server (the free version) 
just doesn't compare to Xen paravirt.  GSX server is really easy to 
install and deploy, though.
> For some reason I seem to be able to add other modules successfully, 
> ( GD for example ), but can't seem to make MySQL work with PHP.  The
> system administrator tells me that PHP has nothing to do with MySQL,
> it's just a language, and besides it should have had the MySQL module
> compiled in to PHP.  We don't seem to talk the same language!
>   
It's always a frustrating experience when two engineers don't understand 
each other.  He's partly right in what he's stated, but he's assuming 
too much.  In the Linux world, you have to remember that there are 
129,234,832 ways to skin a cat (and counting).  I don't know how a 
standard Debian system gets setup, but I know that many distros have 
modularized popular packages like Apache and PHP in order to make 
package management easier.  I just dropped in on a Fedora server that 
has PHP/MySQL installed and inspected its setup, using "rpm -qil php" 
and "rpm -qil php-mysql" to find the relevant *.so files and "ldd" to 
inspect the list of libraries already linked into those.  There's no 
trace of MySQL in the "php" package (I'll spare you the long ldd output 
for what is actually linked into the core PHP).  The "php-mysql" package 
includes these files:

    /etc/php.d/mysql.ini
    /etc/php.d/mysqli.ini
    /usr/lib/php/modules/mysql.so
    /usr/lib/php/modules/mysqli.so

The php.ini file contains this

    ; Directory in which the loadable extensions (modules) reside.
    extension_dir = "/usr/lib/php/modules"

There is also a comment in there that mentions that you should load 
individual modules by putting the settings in /etc/php.d/*.ini.  That's 
where this machine loads its mysql.so and mysqli.so, but it has all the 
default settings for those listed in the php.ini itself.  I don't know 
why it bothers setting them there, except for convenience to a lost 
sysadmin, but the MySQL extensions should work whether those defaults 
are set or not.  So, this is the part that really matters:

    [foo at www ~]# cat /etc/php.d/mysql.ini
    ; Enable mysql extension module
    extension=mysql.so

To find that shared object, it probably goes and looks in the directory 
set for "extension_dir".  If it doesn't find it there, it might go 
searching through LD_LIBRARY_PATH (but I don't know that for sure).  You 
might want to output that from PHP to find out what its value is in that 
environment and make sure it includes the path to your mysql.so.  You 
should also be making sure you've got mysqli.so.

Hopefully, that brief dissection helps lead you to a solution.  If not, 
be sure to give us similar details about how the box is setup.
> Going back to the VMware idea, can we talk design?  The existing Apache2
> listens to one address:port pair, and redirects queries to a couple of
> dozen sites.  MySQL is listening on both a UNIX socket and on TCP
> localhost.
>   
Well, there are quite a few ways to do this.  First, there's my advice 
from above that virtualization is more trouble than its worth unless you 
are after the flexibility.  If you want the flexibility, then you want 
to move all the virtual hosts off the primary host and into a VM.  To 
gain further flexibility, though, you might consider a reverse-proxy 
that allows you to handle virtual hosting.  I'm pretty fond of "pound" 
(http://www.apsis.ch/pound/), which is a lightning fast SSL engine, load 
balancer, and reverse-proxy.  The author argues that it's not *supposed* 
to be used to do virtual hosting, but admits that it can be used that 
way.  You can then use this to still have all your hosts appear to be 
one IP address to the outside world, but can be sent to different 
addresses behind the scenes.  Then, you can number your internal network 
however you want.  This would allow you to move just a few virtual hosts 
at a time, on your own schedule.

If you do go down this virtualization path, don't forget to consider 
where your heavy disk I/O will take place.  Any partition that will get 
heavy disk usage, such as the database or the log files, should not go 
on the "sparse disk" filesystem that many virtual appliances use out of 
the box.  You will want to move those to an LVM partition on the dom0, 
to a disk with a dedicated PCI controller that gets exported to the 
domU, or to a SAN.

Also don't forget to keep good documentation.  Virtualization looks nice 
and clean on the outside, but all those virtual wires can become a 
confusing tangle, just like physical wires.  If you're the visual type, 
draw diagrams and keep them near at hand.
> If I install a VMware child, it would then have a new IP address within
> the local network, and its Apache would be listening on that IP address.
> I suppose that I could put a redirect in a placeholder in the original
> Apache for the new site, bouncing connections to the new location. (
> Code 302, I think )  Otherwise, we would have to publish a completely
> new public IP address for the VMware Apache, correct?  The VMware
> Apache, PHP and MySQL would work as we expect, I'm only concerned about
> the outside access, unless you can see other issues.
>   
Don't bother with the HTTP redirect.  For the record, you would probably 
want "301 Moved Permanently". The 302 code has been deprecated and 
replaced with "307 Moved Temporarily".  If you wanted to change the IP 
address as it appears to the outside world, you should do it with DNS.  
You would want to reduce the TTL (time to live) on the DNS entry a few 
days in advance, so that each ISP knows they'll need to flush the cached 
value soon.  Then, you could change the DNS once the new server is in place.
> Thank you for the suggestions
>   
You're quite welcome.  Best of luck.  I hope you find the solution quickly.

Kind regards,
Justis Peters