Enterprise installs of GNU/Linux promise well-supported and rock-solid combinations of software packages.The problem with upgrading the software on an Enterprise install is that the built-in program management system only lets you upgrade and install the limited selection of packages and versions that make up that particular distro.*
In exchange for support and reliability, then, one gets a system that remains significantly behind the current state of the art. This can become a problem when, like many of our customers, you run a web application (such as Drupal or CiviCRM) which is actively developed and depends on fairly current versions of major software packages.
New versions = good
We recently had call to install Drupal on a Red Hat Enterprise Linux (RHEL) 3.8 system, which comes with MySQL 3.23 and PHP 4.3.2. These are very old versions of this software. I prefer to use MySQL 4.1 at the oldest (it offers some major advantages over 4.0, not the least of which is much better character set support), and for Drupal 4.7 it's necessary to use at least PHP 4.3.3 (but it's a better idea still to use the most recent 4.4.X version). The restrictions of the Enterprise Linux model mean that this can't just be handled by up2date (the RHEL software updater).
One option would be to download source tarballs and manually "configure; make; make install." Unfortunately, that means you have key system elements installed completely outside the provenance of the RPM package management system, which is decidedly inconvenient. Luckily, RHEL has a wide enough install base that there are unofficial RPMs available that allow us to install "rogue" versions of these software packages, have them integrate with the existing RHEL3 setup, and remain managed by RPM.
For MySQL, look on the mysql.org site for RPMs compatible with your RHEL version. They have packages available for versions 3 and 4 at the moment. You will need to install the following packages:
(Note that you need mysql-shared-compat NOT the plain mysql-shared RPM; the compatibility library ensures that apps expecting to find the old version of MySQL won't break when they use the new one.)
PHP is a little more complicated, as php.net doesn't provide helpful RPMs. The folks at CheetaWeb have put together a bunch of useful packages, however, that seem to be widely and successfully used. They are available from http://mirror.cheetaweb.com/redhat/3ES/i386/, and you will need to grab all the packages that are relevant to your web applications. Take a look at the results of 'rpm -qa | grep php' to see what's currently installed. For our drupal purposes, I used these ones:
Use RPM to remove php, mysql, and all their dependencies. 'rpm -e php mysql-server' will produce a list of dependant packages: add each to the list of packages to remove, and take note of ones that you will need to replace (php-mysql for instance). Then, using your freshly downloaded RPMs, install your new version of MySQL and PHP, in that order.
In our case, this (and restarting apache) was all that was necessary to get php 5 up and running. You may need to install additional RPMs from CheetaWeb to satisfy dependencies. Note that they provide an updated version of libxml2-devl here, in case you need it.
I had the luxury of doing this setup on a sever that was being put into service. Attempting these upgrades will be considerably more complicated on a server with live data to be moved over. My advice for MySQL is to follow the guidelines in the docs, which suggest upgrading in version-by-version steps. Even moving from MySQL 4.0 to 5.0 can be troublesome without a stop at 4.1 en route. Fortunately, PHP is easier to upgrade ... assuming your application is compatible with 5.x.
* I find this all a bit amazing, BTW, having cut my Linux teeth on Debian, which allows upgrading or downgrading of the entire system with relative ease, and with tremendous freedom to choose repositories, etc. To my mind, Enterprise Linux distros such as RHEL and SUSE EE take a lot of the good out of GNU/Linux. But I digress.