The issue:  You’ve got a nice web server that is serving the needs of lots of clients and everything’s great. Except that you made what turned out to be an ill-fated decision to choose Red Hat Enterprise Linux 4 as your Linux distro, and now you’re stuck with prehistoric versions of PHP and MySQL that Red Hat’s updater won’t update.

Now you can’t install a whole raft of newer apps, your clients are mad that you can’t provide the latest version of [insert one of a number of Web apps that require PHP5 here], the thought of moving everybody off of your perfectly good server just to get updated software makes your stomach hurt, and the thought of manually updating PHP and MySQL makes it hurt even worse.

Fear not, there’s hope …

Don’t get me wrong, RHEL4 is great stuff, and the up2date tool that comes with it does a fine job of keeping any security issues patched up.  However, Red Hat does not provide RPMs for versions of PHP or MySQL beyond either tool’s 4.x releases, leaving you in a box when it comes to installing Good New Stuff such as Magento (our new  favorite eCommerce tool, sorry X-Cart).  We recently had just this same beef and would like to relieve you of a little pain and suffering by sharing how we got around it, so here goes:

1. Back up everything you can think of.   Databases, files, everything.  I know, backing up is boring, but do it anyway. Hopefully you already have all that backed nightly … if so, just make sure the backups are all good.
2. Upgrade Plesk (and anything else that depends on older versions of PHP).  If you’re using a version of Plesk that’s lower than 8.3, upgrade that old beast, because it won’t work with newer versions of PHP.  You should be able to upgrade from within Plesk to the latest stable version.  Tip: Do the update after hours, because it results in some web server downtime while it’s working.
3. Setup some nice new yum repositories.  Huh?  Yum?  I thought RHEL4 used up2date?  Well, it does, but yum is a newer package management tool (you can learn more on how they differ by googling yum vs up2date), and it’s what the amazing folks at AtomicRocketTurtle use for … get ready for it … their repository of updated PHP and MySQL RPMs for RHEL4!  Here’s how to get setup (don’t worry, this won’t actually do any scary stuff, but will just set up new yum repositories … the scary part is next step). Fire up a command prompt, log in as root, and:

   wget -q -O - http://www.atomicorp.com/installers/atomic | sh

4. Upgrade! Ok, this is the scary part I mentioned earlier where you may wish to close your eyes while hitting the enter key.  We’re  going to tell yum to upgrade everything on the system that it can find updates for in the repository we just setup.  You might want to play around with yum for a bit, look at the man page, list updates it has available for the things you’ll be updating (yum list available php*) and so on.  You know, just to make you feel good before taking the plunge. When you’re ready, take a deep breath, perhaps indulge in a refreshing beverage and:

   yum update

   Once it works out all the things that it’ll update and the corresponding dependencies, you’ll be prompted to approve the list of changes above to be made.  Do that, and you’ll be off and running, no longer slave to the arcane ways of software releases that have been around longer than your favorite websites.

Of course no server administration challenge would be complete without a slew of gotchas that go well beyond the “here’s all you have to do” instructions you started with.  I’m sure you’ll find your own speed bumps, but hopefully our review of what slowed us down will eliminate most of them:

• php-domxml: I don’t know what this is, but I do know that gets in the way of upgrading things.  So we told yum to exclude that nasty thing (yum –exclude php-domxml upgrade) and never looked back (you can find some discussion on the topic here).
• PHP extension_dir:  PHP was looking in the wrong place for extensions, which caused lots of things to not work (we first noticed with a WordPress install, but I’m sure most PHP apps would complain).  It was looking in /usr/lib/php4, which is the old directory.  So, we just changed the “extension_dir” line in /etc/php.ini to “extension_dir=/usr/lib/php/modules/” and restarted httpd.
• Update MySQL tables: We upgraded tables in a way that is probably done better by following these instructions.
• Plesk / Horde:  Once we upgraded, the webmail options disappeared from Plesk.  Despite Plesk showing the psa-horde package as being installed, it also said that no webmail client software was available for use. We ended up manually uninstalling the Horde package (yum remove psa-horde) then reinstalling it from within Plesk’s upgrade screen. The install said there was one error, but it ended up working anyway and providing us with the Horde option inside Plesk again.  Well, it *almost* ended up working …
• Horde, Part II: Upon logging into a webmail account, we got an ugly error that looked like this:

  A fatal error has occuredDB

  Error: connect failed

  Details have been logged for the administrator.

  Turns out this is a common problem, so we followed these instructions. But, it turned out that everything was in perfect order according to the instructions.  After much hair pulling, cursing, and ghetto debugging with echo statements in Horde’s PHP files, we found that Horde was simply looking for a password file in the wrong place, and the following command took care of everything:

  cp .webmail.shadow webmail/horde/.horde.shadow

And there you have it.  Hopefully our trials and tribulations will eliminate some trials and add a few tribulations on your end.  Please speak up if we missed anything or let us know if this article helped you out.