4.3. Upgrading

At some point, you will likely want to upgrade your OpenBSD or FreeBSD server. If you followed the guidelines set forth in Chapter 3 for your operating system installation, you have already performed a trivial upgrade. As you allow your system to remain in operation from a few months to a year or more, upgrades become more challenging. Consider putting in place regular upgrade procedures that ensure you are capturing all security and reliability related updates. In some cases, your regular upgrade schedule may be accelerated by a released security advisory. This section of the chapter covers the steps you take to keep your system secure by patching and upgrading.

4.3.1. Patching Only

One school of thought for upgrading systems can be summarized by "if it ain't broke, don't fix it." Many system administrators adhere to this paradigm and upgrade or configure workarounds only when they run into a problem. Strictly adhering to this approach may have a variety of negative consequences:

• Systems are often in an unknown state, especially if you have been intermittently patching individual binaries as security advisories have been released without documenting all changes.

• It can be tempting to put off the installation of less-critical locally exploitable vulnerabilities when the affected host only provides shell accounts to administrators. These omissions may linger longer than desired.

• Increased care is required in performing an upgrade on an older system the more workarounds that have been configured, the more painstaking it will be to account for them all during a full system upgrade.

The OpenBSD and FreeBSD security teams release security advisories with source code patches to address issues on a regular basis. As discussed previously, installing patches to mitigate the risks presented by security vulnerabilities is a key component to secure systems administration. However, following a patch-only philosophy, a few months or years down the road you or another administrator may find it difficult to conclusively determine if your system is free of all known vulnerabilities. While patching is vital for rapid response and risk mitigation, regular upgrades are necessary, too.

4.3.2. Tracking Branches

Both operating systems provide a patch branch, which includes only security and critical reliability fixes to a given release of the operating system. This branch offers the highest level of stability by introducing only the most critical security and reliability fixes. The administrator can expect that while tracking this branch, the fewest number of changes have been introduced into her system and only the most significant issues have been addressed.

Despite how few changes are made to these production-quality branches, always perform system upgrades in a test environment before upgrading production systems.

Tracking this branch accommodates the "if it ain't broke, don't fix it" philosophy, while at the same time updating the system's configuration to reflect a certain patched state. This allows other administrators to determine whether the system is up to date in an instant.

Release Engineering

There is one important difference when comparing the way OpenBSD and FreeBSD count releases and manage branches. OpenBSD releases are denoted x.y where both x and y are equally significant. This means upgrading from 3.3 release to 3.4 release should (in general) be considered as significant a step as upgrading from 3.9 to 4.0. OpenBSD systems maintain a stable branch at every release. These branches are usually maintained for two releases.

FreeBSD releases also have x.y notations, but in this case x is the traditional "major" version number, and y is the traditional "minor" version number. A change in the major version number indicates significant and substantial changes are being introduced to the system. Upgrading from 4.4 to 4.5, 4.8, or even 4.9 is not a major undertaking (though certainly the more increments are skipped the more careful you must be). An upgrade from 4.9 to 5.0, even though the two versions appear close, includes extensive changes in the code base.

Be sure to read the mailing lists and learn about what is happening on the major release before you blithely upgrade. Ideally, you should set up a test system where you can install the new version and become familiar with it before upgrading critical servers. Note also that some major versions are more significant than others. The switch from FreeBSD 2 to FreeBSD 3 was a rocky one, and there were some significant bugs in 3.0. As an exception to the rule, the transition from 3.0 to 3.1 included a switch from a.out to elf binaries another troublesome change. The transition from 3.0 to 4.0 was much smoother. FreeBSD 5.0 was released with an explicit warning that there were still some instabilities. By Version 5.3, however, the 5.x branch had reached production quality stability for most purposes.

For more information about OpenBSD releases, see Chapter 5 of the FAQ. For details about FreeBSD's release engineering, see http://www.freebsd.org/releng/.

Determining when to upgrade your BSD system can be tricky. Several factors will play into your chosen paradigm for longer term system maintenance. In more structured environments, your organization's security policy should describe the exact schedule for system patching and upgrades based on your security and availability requirements. The considerations for upgrading your system will depend on the operating system, so we must consider each in turn.

4.3.2.1 Tracking OpenBSD branches

OpenBSD calls their production-quality branch the stable branch or the patch branch. This is the appropriate choice for most, if not all, of your systems infrastructure. These stable branches are created at every OpenBSD release and are maintained for two releases. Because new versions of OpenBSD are released approximately every six months, you can avoid upgrading for about a year but you had better not wait any longer than that. Note also that the official upgrade path with OpenBSD does not allow skipping versions. Do not attempt to install 3.6 over 3.4. Upgrade to 3.5 first. Upgrades are most safely accomplished through the construction of a parallel system and subsequent data and configuration migration.

If you do not have the resources and time to dedicate to this process, a binary upgrade is your best bet. That is, you are less likely to run into problems while performing a binary upgrade than while performing a source upgrade. This was especially true between Versions 3.3 and 3.4, which included a change in the format of system binaries from a.out to elf. Bear in mind you may need to rebuild applications installed from ports (after updating your ports tree) when you perform a binary upgrade of your system.

On infrastructure systems with very specific purposes like firewalls, nameservers, mail relays, etc., you may find there are few security advisories that expose exploitable conditions for your system. In these cases, frequent operating system upgrades may be overkill. In all other cases, updating your system to the latest stable on a monthly or bi-monthly basis is recommended.

4.3.2.2 Tracking FreeBSD branches

FreeBSD calls their production-quality branch the security or release branch. This is an ideal choice for most, if not all of your critical production systems. This branch is typically officially maintained for a little over a year.

New minor releases of FreeBSD are shipped every four months or so. The -STABLE branch will track through various changes in the source tree, eventually culminating in a code freeze. During this period of time, release candidates are tested and the only changes made to the -STABLE branch are critical fixes much like in the security branch. At the end of the code freeze is the next FreeBSD release. Directly tracking -STABLE is only recommended for less important systems, and ideally in a test environment first.

To keep up to date, FreeBSD administrators will generally want to track the security branch for one or two releases. Once a later release has reached maturity (after the release candidates, and perhaps even a month or two after that), it is appropriate to upgrade to this later release and track this new release's security branch. This is a fairly straightforward process described as a post-installation hardening task in Chapter 3.

Finally, new major revisions of FreeBSD come around every few years. Migration to these platforms should never be done for critical systems until the x.2 or x.3 release and the introduction of a -STABLE branch for that version. If possible, building parallel systems and performing a data and configuration migration is the way to go.

You need not go through an entire make world process on all of your FreeBSD systems. Pick an internal host and build binaries there. You may then burn the contents of /usr/obj to a CD and subsequently mount this CD on /usr/obj on other systems and perform the install.

Although you may be thinking that the -STABLE branch is production-quality, FreeBSD includes performance enhancements, noncritical bug fixes, and sometimes even small features into this branch of code. This is generally more change than you look for on critical systems infrastructure. While these have been carefully tested and should work in most environments, traffic on the freebsd-stable mailing lists provides evidence that users do experience problems tracking this branch from time to time. Nevertheless, if you are able to test upgrades to the latest -STABLE system to ensure compatibility with your hardware and software, this may be a viable option for all but the most vital of your infrastructure servers.