[Penguin Logo]

Linux for Newbies, Pt. 25:
Upgrading Your System

by Gene Wilburn

(The Computer Paper, August 2001. Copyright © Wilburn Communications Ltd. All rights reserved)

Operating systems are a work in progress. They are never finished and never will be. New hardware, new software, new standards and new concepts continually create fresh demands and drive up expectations, while fixes and improvements to existing OS code need to be incorporated back into the code base.

From time to time the collection of software that constitutes a distribution--whether it be Linux, FreeBSD, Solaris, or Windows--is deemed ready and is released to the user base. OS releases create a dilemma for users: upgrade or stay put?

This Newbies series began with Red Hat 6.0 Linux. Since then Red Hat has released 6.1, 6.2, 7.0 and 7.1. Other distributions such as Mandrake, SuSE and Caldera have followed a similar evolution. Linux releases tend to follow two patterns: "large jump" major releases, often based on the release of a new Linux kernel series or the GNU C/C++ compiler and libraries, and "small jump" minor releases that incorporate new drivers, kernel and application updates, new admin tools, and bug and security fixes.

Red Hat 7.1 Linux (reviewed elsewhere in this issue of the Computer Paper) is a "large jump" release. Based on the new Linux 2.4 kernel, it addresses things like support for multiple CPUs, USB devices, Firewire devices and extremely large amounts of RAM (e.g. 64GB). It incorporates the next generation (4.X series) of the XFree86 X Window System and can detect a much larger range of video and sound cards. Support for laptops has improved significantly.

All in all, it's an important release. The question is, should you upgrade? There is no single, or simple, answer to this question. It depends in part on what you use Linux for. You need to weigh the inevitable risk and work effort of an upgrade against the benefits of upgrading. Let's see how the options play out.

Staying Put

One valid option is to do nothing. Just as you can still run Windows 95 on your home workstation, you can run any version of Linux you choose. The reasons for sticking with a release, such as Red Hat 6.2, may be related to stability. If your server is stable, and in production, you introduce risk by upgrading, especially if you have heavily customized your system and your kernel. Chances are that you're not running a multiple CPU box anyway so the 2.4 kernel may not buy you much.

At the very least, an upgrade is going to cost you time. You can be certain that some parts of your existing system will require re-work, even if it's only an adjustment to a configuration file.

Samba, for instance, has incorporated new features. When you upgrade your system and want to use the new features, you need to spend some time taking the new default configuration file and adjusting it in accordance with the configuration file from your earlier release of Samba. With luck everything will work correctly the first time you throw the switch. If not, you will have some troubleshooting time introduced into your schedule.

The same applies to other services. Sendmail has been made more secure. You need to reconfigure it before you use it. Ditto for telnet, ftp and ssh. The changes are good changes from a security point of view, but they're not transparent changes. There's additional work needed before your system is ready to go again.

For this reason, it may be better to keep a Red Hat 6.2 web server in production, as is, adding only security fixes until such time as you build a replacement server on new hardware, adding the 7.X series at that time. There is no compelling reason to upgrade a busy production server that is performing well and reliably.

The downside of staying put is that the leading edge of the Linux industry begins to recede in the distance, leaving you behind. Support materials, such as books, magazine articles and website support tend to follow what's current. Within a surprisingly short period of time it becomes challenging to find support for older versions of software.

You can mitigate against obsolescence by keeping certain key individual components, such as Apache, Samba, Sendmail and Bind up to date. Less risk to your production server, but you still obtain the benefits of the latest software. As long as you keep up with all security fixes, staying put is a highly viable option.

Moving Forward

At a workstation level, and especially if you own a laptop, the prospect of upgrading to new releases is more appealing. How often you upgrade is another question. Some users prefer to skip "small jump" releases or wait until the minor releases have received some good reviews.

A case in point is Red Hat 7.0 Linux--a minor release beyond 6.2. The reviews have been consistently mixed and commentary on 7.0 on Linux newsgroups among Linux users has frequently been unflattering. A visit to the Red Hat site reveals a larger than normal number of bug fixes for 7.0.

Many users, myself included, simply avoided 7.0, preferring to stick with the rock-solid 6.2 until Red Hat had a better release available. With 7.1, Red Hat put additional effort into beta testing and the preliminary reviews have been favorable. Feedback from the Linux user community has also been positive. Given that 6.2, as stable as it is, is looking a bit "long in the tooth", 7.1 presents an attractive opportunity for upgrading.

Before deciding to upgrade, however, do a reality check. Will your hardware support the new release? 7.1 is bigger and more demanding of swap space. At a minimum, it wants a 128MB swap partition. If you have an older system, do you have this to spare?

The software cornucopia of a Linux distribution increases with each release, and the packages get bigger. A typical Red Hat 6.2 install might occupy between 600-900MB or more. Red Hat 7.1 looks better starting at 1.5GB. You can trim back, to be sure, but make sure you have the space you need before you attempt the upgrade.

How about RAM? If you're running under 64MB you're not a serious candidate for GNOME or KDE, two of the more compelling reasons to move to 7.1. Even 64MB is minimal for the latest releases of these heavyweight desktop environments. If you're happy with substituting a lightweight windows manager, such as Icewm, this may be a non-factor.

If you're attracted to the new features of Red Hat 7.1 but your hardware is too far behind, you may decide it's time to upgrade your entire system. Windows and Mac users face the same dilemma as the OS layer evolves. New computers are cheaper all the time.

Update or Upgrade?

For various reasons let's say you would like to move from Red Hat 6.2 to Red Hat 7.1. The reasons don't have to be immediate technical ones. Simple curiosity is a perfectly good reason, as long as you are aware of the potential challenges and are mentally prepared to deal with issues that may arise from an upgrade.

During the installation phase of Red Hat 7.1, there is an option to "update" your current Red Hat system to 7.1. Sounds nice. Minimal fuss, and easy to do. Just click the checkbox.

My advice: never update to a "large-jump" release. Because of mixed libraries and other issues, an update can destabilize your system in ways that are difficult to troubleshoot afterward.

Instead, follow the time-honoured principle of upgrading Unix systems: do a fresh, "clean" install and add back your data. Yes, we're talking about reformatting your partitions and installing 7.1 from scratch.

If you already have a separate /home partition, that's one partition you can leave as is (the other, if you have it separated, is /usr/local). If your /home partition is large enough, you can also use it to temporarily store other files you will want to access after the new installation.

When I upgraded to 7.1, I created a directory called /home/backup and in this directory I copied my entire 6.2 /etc directory with all its subdirectories with these commands:

Because I run a DNS server on my home network, I also preserved /var/named:

My development website was located in /usr/local/apache/httpd (and I do not have a separate /usr/local partition). To make my website easily accessible after the install, I entered the following commands:

You can repeat variations of this process for any files you want to put back after upgrading. If you don't have a separate /home partition, you will need to preserve all the files you want to keep to external media such as tape, CD-R or another computer system. Later you can restore these files into temporary directories and move them into their final locations.

Post-Upgrade Tasks

Once you've done a fresh install of Red Hat 7.1, you have some additional tasks to perform. To re-integrate your older setup, you need to reconfigure all your services.

One of the first things you want to reconfigure are your user and group settings. You can try to do this by moving your previous password and group and shadow files back to /etc. However, for various reasons this might not work. For starters, the authentication schemes must match exactly. Even if they do, the password generator may be using a different seed and the old passwords may not be understood.

I prefer to open my old passwd and group files in a pager program such as less or more, and using these as a guide, re-create users and groups from scratch, assigning new passwords as I proceed. This is the cleanest, surest approach. When you re-create your user base you sometimes need to re-assign ownership of the files in your /home directory. It's not difficult. On my system I would reassign ownership in the following way:

Simply repeat this for every user who has a home directory.

Restoring services

The biggest job after upgrading is restoring services. For instance, if you were running Samba and you selected Samba as part of the Red Hat 7.1 install, you now have a new, generic configuration file: /etc/samba/smb.conf. It's guaranteed not to work with your existing network as is.

In addition, there are likely newer features in Samba that were not present in your old configuration unless you were continuously upgrading Samba itself. Merely copying back your old configuration might work, but it's not the best way to proceed.

As before, work cautiously. Be sure you have untouched copies of both old and new that you keep safe. Here's one way to proceed:

Now you have a ".71org" original copy put aside for safety, and two working conf files that end in ".71" and ".62" to help you keep them straight. In the editor of your choice, load the .71 and the .62 files and compare them line by line, copying and pasting the good bits from .62 to .71. A split-screen editor like Emacs is useful for this, though I often read both files into vi and simply move back and forth between the files.

Once you think the .71 file is correct, copy it to smb.conf and start Samba. Check /var/log/messages for any error messages. Check your Win machines to see if they're now seeing network shares as before. You may need to recreate the smbpasswd file before your Windows users can authenticate. After everything works you can delete the .62 and .71 working files.

Continue re-configuring and testing services until all your services are working to your satisfaction. Yup, it can be a lot of work. But on the positive side, you're configuring a pristine new system that won't turn around and bite you because of some old files or libraries hanging around to get things confused. Troubleshooting a messy "updated" system is often more work, and more frustrating, than re-configuring a new, clean system, so play the odds.

Re-learning Linux

Despite the effort involved, I enjoy upgrades. As with any knowledge, I forget things I once knew if I don't get "hands on" every so often. Doing an upgrade forces me to re-examine each of my services and refresh myself on how they work.

There are also new things to learn. For instance, Red Hat 7.1 has a more secure way of installing services such as ssh, telnet and ftp. As you learn the new way of activating these services, you begin to absorb the new security model.

Linux is fun. It's fun to learn and it's fun to re-learn. A successful upgrade is really a twofold accomplishment: upgrading your system and upgrading your Linux skill set.

Gene Wilburn (gene@wilburn.ca) is a Toronto-based IT specialist, musician and writer who operates a small farm of Linux servers.

-30-