Keeping Up With The Jones’s.. err.. The Fedora Release Cycle

March 24, 2008 | Categories: Linux, Technical No Comments ↓

We have a number of systems that run the bleeding-edge RPM based distribution Fedora. Because of the rather quick Fedora release cycle, people are forced to either keep up with the curve, or be left behind in the dust. Typically, only the current and last most recent version are supported, and this support comes in the form of updated packages and/or security fixes. If you aren’t updating your systems regularly, it can become quite easy to fall way behind the curve, especially if you have even the slightest touch of the “If it ain’t broke, don’t fix it” mentality.

Although it is usually ill-advised, following the instructions at the YumUpdateFaq for performing live OS level updates via Yum has proved to be something that is both rather simple and extremely effective. Personally, I have seen a lot of success with it.

Recently, however, there was a need to upgrade a system from the i386 architecture to the x86_64 architecture, primarily to reduce the number of repositories that were being rsync’ed nightly, but also to utilize the full resources of the system. This type of upgrade is commonly referred to as a ‘cross-grade’. The first instinct with any upgrade is to perform a clean install and just move over the configuration files, and that method is truly the Best Practice ™.

Unfortunately, in this particular situation, a scorched-earth mentality did not seem to fly. This system runs a large amount of services (clustered, thankfully), and when trying to configure up the clean install, something (still not sure what) was not making it across. User account lookups (via nss_ldap) were hanging after an hour (or more) of system up time. It got to the point where we had to back out and go back to the old i386 install.

After several failed attempts with a test copy of the system within a VM (do yourself a favor and get yourself a copy of VMware-server!), the upgrade was performed against the anaconda portion of the DVD installer (selecting “upgrade”). This worked well.. sort of. It was a little more ‘brute force’-ish for our liking as a lot of services were not functioning as a result of the upgrade.

Again, using the VM image, we tried out the method found on Linux.com, which had a nice feature article (http://www.linux.com/feature/123800) on this very topic, and, while the article was a little fluffy in some areas, it was extremely accurate. This can be said because we were very very happy with the results. After proving that this method worked within our test environment, we backed up our production environment and went through the exact same steps.

Once the Yum upgrade was complete, we did have to fiddle with a few of the configuration files of some of the applications (samba, cups, etc) to get them working the way we wanted, we were back up and running live in very short order. Now that the system has been upgraded, we could address the numerous packages that we hand rolled (and yum did not know how to update) and the duplication in i386 and x86_64 packages while the server was still providing services to end users.

All in all, our downtime was minimal. The prep work and repeated attempts to make sure the process was nailed down.. well, that took days. The negative end user impact was nominal (the system was off-line for about 30 minutes), and the response has been positive (new packages, new features, better performance, etc).

You must be logged in to post a comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Leave a Reply