Chapter 6: Upgrading FreeBSD

Overview

Upgrading Internet servers can be quite a pain. While you can probably deal with a bit of unexplained behavior in your desktop computer after an upgrade, you don't want anything to go wrong when you have a whole company or hundreds of customers depending on one system.

There have been many times when I've attempted to upgrade a Windows server from NT to 2000, or 2000 to XP, and found that some portion of the server no longer worked as expected. Linux upgrades can also inflict gray hair, and other UNIXes can be even worse. Quite a few experienced UNIX system administrators habitually reinstall their operating systems rather than suffer through an upgrade. And, though a few UNIX versions have straightforward upgrade procedures, they require several hours to complete and a certain amount of luck. (The last time I upgraded an HP/UX machine and the Informix database that it held, I showed up on Friday night with a sleeping bag, an alarm clock, and a box of meal bars, and I left Monday at noon. I would run a command and set the alarm clock for an hour or two later, when the command would be finished and I could start the next step.)

One of FreeBSD's greatest strengths is its upgrade procedure. For example, I have a few servers that were installed when FreeBSD 2.2.5 was the latest and greatest. They've been successively upgraded to 2.2.8, past 3.0 to the last version 3, and are now at version 4. The only inconvenience I've suffered was when jumping major version numbers—that is, from FreeBSD 3 to 4. I spent a couple of hours making those jumps. Just try that with Solaris or HP/UX, or with Windows.

FreeBSD Versions

Why is upgrading FreeBSD a relatively simple matter? The key lies in FreeBSD's development method. FreeBSD is a continually evolving operating system. If you download certain versions of FreeBSD in the afternoon, they're a little different than the morning's version. Developers from around the world continually add changes and improvements, which makes the traditional release numbering used by less open software impractical. At any given moment, you can get several different versions of FreeBSD: releases, −current, −stable, and snapshots.

Release

A FreeBSD release has a conventional version number, like you'd see on any other software: 2.2.7, 3.3, 4.4, 5.0. If you buy FreeBSD in a store, it's a release.

A release is simply a copy of the state of the most stable version of FreeBSD at a particular moment in time. Three or four times a year, the Release Engineer asks the developers to hold off on making any major changes and resolves outstanding problems. After thorough testing, the resulting code is given a release number, after which development returns to full speed, while the BSD department of your release provider rushes the release to the CD factory.

Always install the release version in a production environment.

116

FreeBSD−current

FreeBSD−current is the bleeding−edge, latest version of FreeBSD and contains code that is just making its first public appearance. FreeBSD−current is where much initial peer review takes place and, at times, −current sees radical changes of the sort that give experienced systems administrators headaches.

FreeBSD−current is made available to developers, testers, and interested parties, but is not intended for general use. Support for user questions about −current is very slim because the developers simply don't have time to help a user get a Web browser working when a thousand more critical issues are begging for attention. Users are expected to help fix these problems, or to patiently endure until someone else fixes them.

If you can't read C, shell, and Perl, or don't feel like debugging your OS, or don't like computer functions failing in a seemingly random manner, or just don't like being left hanging until someone gets around to fixing your problem, −current is not for you.

The brave are certainly welcome to try −current. So is anyone who is willing to devote a large amount of time to learning and debugging FreeBSD, or who just needs a lesson in humility. This isn't so much a matter of "you're not allowed to" as "you're on your own."

People running −current must read the FreeBSD−current@FreeBSD.org and cvs−all@FreeBSD.org mailing lists. These are high−traffic lists, with as many as a couple hundred warnings, alerts, and comments a day. Read them, especially the warnings. If someone else discovers the latest Bug of Slow Hideous Death, you might have time to benefit from his experience.

Code Freeze

Every 12 to 18 months or so, FreeBSD−current goes through a month of "code freeze" during which no non critical changes are allowed, and all remaining problems are fixed. At the end of the code freeze (or shortly after), −current becomes the new .0 release of FreeBSD−stable.

For a short time during code freeze, −current is treated like an early release of FreeBSD−stable. This focuses developers on stability and bug fixes for problems exposed by early adopters. After a release or two, a new −current is branched off the new, mainstream −stable. For example, at this writing 5−current is expected to become 5.0−release. The −current version will remain 5.0 until some point after 5.1−release, to help focus developer attention on the new release. At some point after 5.1−release, a copy of the source code will be labeled 6.0−current and another copy will be marked 5.1−stable.

FreeBSD−stable

FreeBSD−stable is bleeding edge for the average user—it contains some of the most recent peer−reviewed code. FreeBSD−stable is expected to be calm and reliable, requiring little user attention. Once a piece of code is thoroughly tested in −current, it might be merged into −stable in a process called MFC, or merge from current. The −stable version is the one that is mostly safe to upgrade to at almost any time; you might think of it as FreeBSD−beta.

As −stable ages, the differences between −stable and −current become greater and greater, to the point where it becomes necessary to branch a new −stable off of −current. The older −stable is actively maintained for several months while the new −stable is beaten into shape.

117

Some users will want to upgrade to this new −stable immediately, while others are more cautious. After a release or two of the new −stable, the older −stable is made obsolete and users are encouraged to upgrade to the new −stable. Finally, the older −stable receives only critical bug fixes.

Figure 6.1: FreeBSD development branches

Every so often −stable is polished and tested; developers stop MFCing features and focus on testing. When everyone's happy with the quality, it's released and generally given a "point" after the main branch. (For example, the fourth release of FreeBSD 4 is FreeBSD 4.4, and you'll see references to both 4−stable and 4.4−stable–the name 4−stable includes all of the 4.x releases and −stable branches.)

The word stable describes the code base, not the OS itself. It doesn't guarantee that the operating system is completely stable and reliable, but that the underlying code won't suffer a radical change. For example, many people considered FreeBSD 3.5−stable more reliable than FreeBSD 4.0−stable.

Note FreeBSD may be one of the most reliable operating systems available, but beware of any .0 release, from any company. Remember the poor folks who implemented Windows 2000 the month it came out?

Users of FreeBSD−stable should read the FreeBSD−stable mailing list, a moderate−traffic mailing list. Important messages from developers generally have a subject beginning with "HEADS UP". Look for those messages, and take whatever action they recommend.

Snapshots

Every so often, the FreeBSD development team releases a snapshot of −current (available via FTP, and through some vendors on CD−ROM). The snapshot does not receive the same attention to quality that −release does, but is intended as a good starting point for people interested in investigating or testing −current. Generally speaking, developers avoid adding major new features for a week or so before the snapshot is released, but the snapshot does not undergo quality analysis. Bugs exist, and while most are known, many aren't. New features are incomplete. You might call it a bleeding−edge release.

Security Updates

With the advent of FreeBSD 4.3, the project began supporting security−update−only branches. Previously, a FreeBSD user had to upgrade to the latest −stable to get the security patches, but this caused problems, as the OS changed between releases. Why upgrade a whole server, and go through the headaches it can cause, just to get a patch for one small security problem? (Anyone who's worked through a Windows 2000 Service Pack upgrade can attest to the problems this sort of upgrade can cause.) Only actual security issues and system−damaging bugs are fixed; new features are not brought onto these branches, nor are performance enhancements. This might be considered a very timid −stable version.

118