Tracking the FreeBSD Sources
However, new features that come with new major releases aren't the only reasons you might want to upgrade. Suppose, for example, that a major security flaw has been found in the kernel, or in a key system component such as BIND or Sendmail. This situation requires an immediate response, a real-time solution to a real-time problem. There's really only one way to achieve this end: You have to track the sources.
The source tree for FreeBSD is kept in a central Concurrent Versions System (CVS) repository, mirrored across a number of redundant servers, and
Thus, when a security flaw has been patched or a critical bug fix has been checked into the source repository, you as a FreeBSD user have the ability to synchronize your sources with the most recent version and then build and install a new component to address your system's vulnerabilityor build an entirely new operating system from the ground up.
The STABLE and CURRENT Source Branches Explained
Between full operating system releases, the FreeBSD code is in a state of constant flux.
Figure 19.1. The FreeBSD code branches, showing the relationship of the CURRENT and STABLE branches.
This code development model is fairly common in the software world; it enables developers to freeze a certain feature set within a version and avoid the instability of ongoing minor tweaks and additions. Following this model, developers add new features in blocks, introducing each new feature set or restructuring with each new branch.
The thing to remember here is that CURRENT is
the branch you want to use for a production server! CURRENT refers to the very most cutting-edge branch of the codethe one where
At some point during development on a CURRENT branchusually after the first release, for example 6.0-RELEASEthe CURRENT version feature set is deemed STABLE, and the CURRENT and STABLE designations each move up one branch on the tree. CURRENT becomes the tag for the newly created topmost branch, and the newly designated STABLE (formerly CURRENT) version feature set is now recommended for use on production servers. New releases are announced on both branches every few months, until the feature set in CURRENT has matured and the STABLE branch no longer meets the needs of the community. The tree then branches again, starting the cycle over.
Of course, this model is an idealization of actual reality. FreeBSD 6.0 was released after a longer period between full releases than was characteristic of earlier version schedules, and it was a much less
Selecting Your Upgrade Target
You can upgrade your system at any time, no matter how far along the development in the source tree is. You have three choices for making the upgrade:
The remaining sections of this chapter discuss how to synchronize your source tree to a
See http://www.freebsd.org/releng/ for a current list of FreeBSD releases and their maintenance status.
Upgrading to a Release Version
To upgrade your FreeBSD system to a release version, you insert a release version tag into your CVSup configuration, which we will discuss a little later. The release version tags all have three digits, separated by underscores rather than periods, and have a suffix of
. Table 19.1 shows how release tags map to version numbers. This is an incomplete example; there are many more available release version
Table 19.1. Mappings Between Release Tags and Version Numbers
Upgrading to an Interim Build on an Errata Fix Branch
Interim versions for specific releases are maintained so you can apply security patches and critical code fixes to an
Interim releases on a so-called "errata fix branch" (or, earlier, "security fix branch") such as
are numbered with a
suffix, as in
, which signifies a system built from the third revision that was checked into the
branch. From this you can see that code checkins in the errata fix branches are
Security vulnerability announcements (such as those sent to the
mailing list) usually contain two suggested paths for fixing the bug in question: the point on each errata fix branch to which you need to upgrade your sources and then rebuild a component or the entire system, or a link to a "patch" file that you can apply to your existing sources without synchronizing the entire system. The instructions for downloading and applying the patch are given in the security
Errata fixes occur usually about once a month. Each such code change is
# uname -a FreeBSD simba 5.4-RELEASE-p3 FreeBSD 5.4-RELEASE-p3 #1: Wed Jun 29 18: 06:56PDT 2005 root@simba:/usr/obj/usr/src/sys/GENERIC i386
To upgrade to an interim build of FreeBSD, you specify in your CVSup configuration an errata fix branch that's in development. To switch from a RELEASE version (such as your original installation) to its corresponding errata fix branch, create your release target by leaving off the RELEASE suffix and the third digit from the initial release's tag, as shown in Table 19.2.
Table 19.2. Branch Tags and Version Designations for Interim Versions
Note that Table 19.2 is current as of early 2006. Due to the dynamic nature of development branches, this information will become obsolete with time. Refer to http://www.freebsd.org/handbook/cvs-tags.html for a definitive and current table of the appropriate branch tags.
Upgrading to an Active Line of Development (CURRENT or STABLE)
Tracking STABLE or CURRENT branches in this way means you specify a branch tag with only the first digit of the release branch. For instance, specifying RELENG_6 gives you the current state of the FreeBSD 6.x source tree, including code changes checked in by independent developers hours or minutes ago; it isn't tied to the official "frozen" states of FreeBSD 6.0, 6.1, or any other designated release. And that's just for the STABLE branches. You can get even more adventuresome by specifying the HEAD of the code tree, which gives you the CURRENT branchas you'll recall, CURRENT is where the newest, most experimental features are being actively developed, and they may not be stable or even complete. There's no guarantee that the code will be "safe" at any particular time, as it is with the interim p releases on an errata fix branch. If you choose to track a CURRENT or STABLE code branch, be prepared to wrestle with a system that may be unstable or even unusable if you happen to sync your sources to it at just the wrong time!
See Table 19.3 for the branch tags you'll use to sync to a CURRENT or STABLE branch.
Table 19.3. Branch Tags for Active Development Branches