Wed Mar 26 11:17:48 EDT 2008
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.
> 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 ).
> 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
> 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,
More information about the TriLUG