LinuxWebLog.com

Below is a clean method of updating, instead of doing a straight `yum update` which I have often done in the past and broken OS.

I was caught by this when upgrading CentOS servers from 5.2 to 5.3. Should make it a habit to atleast read the release notes!!

When upgrading from an earlier version of Red Hat
Enterprise Linux to 5.3, you may encounter the following
error:

Updating : mypackage ################### [
472/1655]rpmdb: unable to lock mutex: Invalid argument

The cause of the locking issue is that the shared futex
locking in glibc was enhanced with per-process futexes
between 5.2 and 5.3. As a result, programs running against
the 5.2 glibc can not properly perform shared futex locking
against programs running with the 5.3 glibc.

This particular error message is a side effect of a package
calling rpm as part of its install scripts. The rpm
instance performing the upgrade is using the prior glibc
throughout the upgrade, but the rpm instance launched from
within the script is using the new glibc.

To avoid this error, upgrade glibc first in a separate run,
ie

# yum update glibc
# yum update

You will also see this error if you downgrade glibc to an
earlier version on an installed 5.3 system.

Since Drupal has been coming out with rapid updates, mainly due to security fixes, it's quite cumbersome to have to keep it up to date. However, with the below setup and the script to help with the maintenance, it was a breeze with the last update. The script has been used to upgrade from 5.5 to 5.6 release.

Note: The script does not currently have any checks (extreme alpha stage) and my Drupal installation is not a standard install so usage may vary. Make sure you understand the script prior to running it. Usual disclaimer applies. You will also need root level access to shell to run the script as it is set to change ownership of files and folders using the "chown" command.

My current Drupal install are based on symbolic links for easy maintenance and upgrades. The layout is as below:

/var/www/html, /var/www/html/site_files, /var/www/html/sites are all symbolically linked to the /var/www/drupal-5.x, /var/www/drupal_files, /var/www/drupal_sites respectively where /var/www/html is the web root.

Document Root = /var/www/html            -> /var/www/drupal-5.x
Files Folder  = /var/www/html/site_files -> /var/www/drupal_files
Sites Folder  = /var/www/html/sites      -> /var/www/drupal_sites

Also, any customization to the .htaccess is on top of the default Drupal code. So the script will automatically prepend the data to the upgraded .htaccess file. Since, I also have the gallery module, the .htaccess file is also set to be writable by apache.

Don't forget to set your site in "maintenance mode" with the default theme, and disable all modules prior to the upgrade. Although, I've done some updates with all modules available without any issues. Also, my custom theme resides in the sites folder and stays untouched with the update.

Place the script in "/var/www" (just outside your document root) and run the update via:

Once completed, run update.php to update any changes to the database. Set site back to production mode, re-applying any customization as necessary.