[TriLUG] Apache2 / PHP / MySQL Help?

[Brian McCullough]

On Wed, Mar 26, 2008 at 02:23:46AM -0400, Justis Peters wrote:
> 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 

Sorry, wrong terminology.  I am a fan of theirs and have moved almost
all of my servers and desktop machines ( including laptops ) to rPath,
including Xen ( not para, "older" AMD CPUs -- what, six months? ) for
the servers.



> > Unfortunately, it is a client machine, in a rack in San Jose, installed
> > with Debian Sarge.  

> 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.  
> 
> 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.  

Which I don't.  I don't have much experience with VMware, having started
with Xen, and generally liking it.  However, it means completely
rebuilding the machine, which the client isn't too enthusiastic about,
since he is here on the right coast, with me, and the machine is on the
left.



> "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.

I completely agree.  When I retired my various servers, running multiple
versions of Linux ( I kept the OpenBSD firewall ), and built one big Xen
box with rPath and several rPath domU clients, it made life much easier.
>From the outside world, it looks like multiple machines, hardware-wise,
it's one, much more economical one.



> 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.

That's the impression that I get from its fans.  It's barely possible
that the performance hit would be acceptable, since it is a membership
site with a very limited membership ( members of a particular fraternity
at a particular university ).



> 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.  

Which Debian-based and Debian-like systems do, too.  I even have an old
machine here that has been ( mostly ) retired, running an early Ubuntu,
which seems very like the Fedora server that you described.  What was
very interesting about this Debian system is that it seems to be getting
information from somewhere else.  When I commented out the
"extension_dir" statement in the "official" php.ini file, a value showed
up in the phpinfo() output which was correct, but which I had not put
there!   Similarly, when I installed the "php4-gd" package, gd.so showed
up under /usr/lib/php4, "extension=gd.so" is NOT enabled, and there is 
no "gd.ini" file under /etc/php.d, but GD shows up in phpinfo()! In
fact, there is no php.d directory, like my Ubuntu system, which also
seems to magically get its information from somewhere else.  Neither
system seems to have an "/etc/sysconfig" directory, which Red Hat-like
systems do.  There is only /etc/php4, not /etc/php.d, and /etc/php4 only
contains apache2/php.ini, which is generally comments, not the commands
that we both expect.


> 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).  

No, it _appears_ to depend on the "extension_dir" directive, I just
don't know where that value is coming from.


> 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.

No mysqli.so, just mysql.so, which was installed automatically by
"apt-get install php4-mysql".  




> Hopefully, that brief dissection helps lead you to a solution.  

At some point here, I should thank you for the very detailed and
thoughtful help that you have given.  For some reason this machine is
resisting "proper configuration," although I am the first to admit that
it has been some time since I last adminstered a Debian system.



> > 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.  

The only reason that I would consider the virtualization option would be
because it would give me control over the environment in a way that is
more familiar and predictable ( perhaps better reversed ).



> 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.

This is an intriguing idea.



> 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.

Good point. That is how I built all of my servers, but a worthwhile
warning.


> 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.

!!!



> Don't bother with the HTTP redirect.  For the record, you would probably 
> want "301 Moved Permanently". The 302 code has been deprecated and 

Thanks for the correction.  I didn't have my chart in front of me, and
the wetware memory isn't necessarily the best solution.



> 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.

True.  I was just going for "stealth" mode, instead of the RIGHT Way.


> Kind regards,
> Justis Peters


Once again, thank you for the very detailed responses,
Brian