FreeBSD

Tracking Stable

by Rick Leir
<rleir@igs.net>

Rick Leir is in charge of a Linux firewall but spends most of his time developing Java applets.





Thanks to Bob Gray for his excellent ;login: series on "Source Code UNIX." Bob explains why you will be wanting to use FreeBSD, how to use it best, and what hardware to run it on. Thanks to reviewers Rik Farrow, Bob Gray, and Alfred Perlstein. Thanks to all the contributors in the FreeBSD world. — RL

This article, a practical guide to using and updating FreeBSD on your production systems, should help a newcomer to FreeBSD get productive quickly.

Let's quickly present the advocacy, and be done with it: I think that FreeBSD is the best *nix system and that it is particularly suitable as a server. Developers like it because of the skill level in the development group and because of the permissive licensing terms. FreeBSD is reliable under heavy load, more so than many commercial systems, and impressively secure against attacks across the Net.

And FreeBSD's reliability is more amazing, considering that the latest OS research is going into it. The Berkeley Fast File System keeps getting faster. There are several development projects under way. See more at <http://www.freebsd.org/projects/>.

FreeBSD is not to be confused with NetBSD, which has been ported to many processor types; or with OpenBSD, which focuses on security; or with Linux, which is . . . Linux.

Choose a Version

Running FreeBSD in a production environment requires a bit of care in deciding which version to run and when to update. Unlike the Linux world, with its many competing distributors (Red Hat, Debian, Caldera, and others), FreeBSD is released from a single organization. Versions have in the past been released quarterly, but that has changed to three per year. The instructions for getting and installing them are at <http://www.freebsd.org/handbook/install.html>.

If you want the most stability, run the 2.2.8 version. It has been frozen for months, with the only changes being careful bug fixes. This is fine unless you have the latest hardware and some new card is not supported, or you really need some new feature.

The 3.0 version had a new framework for driver integration (CAM) and support for many new device types.

The 3.1-Stable version was much improved. The boot loader changed to ELF format, and if you followed the instructions, you did not get stranded at the boot prompt!

The 3.2-Stable version, released in time to be distributed to all Monterey USENIX attendees, promises to be very stable. It comes with a nice default user desktop to save you configuration effort.

Versions are announced on the FreeBSD Web site and on the Announce mailing list, <freebsd-announce@FreeBSD.ORG>.

FreeBSD source is kept in CVS, available on the Net, and it is possible to update your system between versions. There are two CVS "development branches." The Current branch contains the latest bleeding-edge developments and is recommended to the adventurous user or open-source developer. The Current branch is associated with versions 4.n.

The Stable branch contains development that has been proven by months of use by Current-branch developers and is stable enough for general use. The only changes accepted into the Stable branch are bug fixes, entirely new programs, and new drivers. No major overhauls of proven programs and subsystems are done in this branch. Also, Stable offers binary compatibility with previous versions of the C library and core operating-system functionality.

Most users will want the Stable branch. The Stable branch includes the above-mentioned 2.2.8 and 3.n versions.

Version Updating

As ever in software development, new features often cause bugs in existing features, and bug fixes often cause or expose other bugs. You want to use the new features, but you are afraid of sorting out the new version's bugs.

A bug is only a problem if it bothers you. There is a Web-based bug-tracking system at <http://www.freebsd.org/support.html#gnats>, and you will find that most reported bugs simply don't affect you. Maybe they are related to a certain brand of disk controller card or maybe to a feature that you don't use.

Suppose that you have encountered a bug, and it really is a bug, not a misunderstanding, and maybe you have discussed it on the mailing list <freebsd-questions@FreeBSD.ORG>. (See <http://www.freebsd.org/support.html#mailing-list>.) You have found that there is now a fix in the CVS Stable branch, perhaps by monitoring the Stable mailing list <freebsd-stable@FreeBSD.ORG>. You decide to update, as described at <http://www.freebsd.org/handbook/stable.html>.

It is surprisingly simple to update your sources across the network using one CVSup command. CVSup is a software package for distributing and updating collections of files across a network. It displays its progress in an X window. CVSup's streaming communication protocol and multithreaded architecture make it most likely the fastest mirroring tool in existence today. When the CVSup is finished, the entire base operating system, including kernel, stock user-mode programs, and libraries can be rebuilt to a known configuration by typing a single make command.

The update will fix many other bugs that you might not care about, and possibly (unlikely) introduce a bug that you do care about. How anal do you need to be about updating your production server? You could run a test system, but it is hard to test with a real workload. At some stage, you have to get brave and put the updated system online. The FreeBSD team is devoted to helping fix any problems via the mailing lists. Usually a solution will be provided in under 24 hours, most often in two to three hours! The FreeBSD developers are worldwide, so at any hour of day or night the chances are good that someone knowledgeable is ready to help you.

The above-mentioned mailing lists are really useful (though the volume is bothersome, even with a threading MUA). Commercial system vendors don't give you as much visibility into the release decision-making, especially if you are a smaller customer. With FreeBSD, it is discussed openly on the Stable mailing list, and bugs are tracked on a Web page, so you can understand all the pros and cons of changes.

CVS versus Patching

Vendors like Sun often supply patches for specific bugs. Apply patch 1, then apply patch 2, and then bug 1 reappears. You end up applying a "jumbo" patch that includes fixes for both bugs. Sun provides extensive information on the patches, so you can plan your patching activities. Not even Sun recommends installing every fix. FreeBSD doesn't have any other practical option. To patch FreeBSD you would have to monitor the source changes going into CVS and pick just the ones you want. This might be practical for developers, but most of us will update to the latest CVS and take the small chance of encountering an unrelated bug. Most FreeBSD users prefer the CVS approach to patches. But, as I mentioned above, you are taking a finite risk.

The exception to the above is that FreeBSD supplies patches to fix problems identified by CERT advisories. FreeBSD generally is designed with security as a primary goal, so not many such problems arise. See <http://www.freebsd.org/security/>.

If you have your own private source changes, including patches, then you don't want them clobbered by a CVSup update. It is a bit tricky, but CVSup makes it easier than it could have been. The CVSup FAQ has help for this at <http://www.polstra.com/projects/freeware/CVSup/faq.html>.

Contribute!

Would you like to begin contributing to the open-source community? Find a significant bug (difficult!), determine that it really is a bug, and develop a simple test that demonstrates the bug. Mention it on the mailing list, and if nobody has a quick fix for it, then submit a problem report to the bugs Web page, <http://www.freebsd.org/send-pr.html>.

Testing is not as glamorous as new development, but it is challenging and it makes a very useful contribution to the FreeBSD world. Some people have a nightly update and build, so they are constantly testing the latest source.

Another way to ease into a contributing role is to help with documentation. See <http://www.freebsd.org/tutorials/docproj-primer/>.

Commercial Services (Plug)

Install from CD-ROMs! CD-ROMs from Walnut Creek are the fastest way to get installed initially. Thanks are due to Walnut Creek, <http://www.cdrom.com/titles/freebsd/>, for its generous ongoing support of FreeBSD development. After the CD-ROM installation, you can add prebuilt packages from the CD-ROMs or make ports from sources on the CD-ROMs. Disclaimer: I am just a satisfied customer of Walnut Creek.

If you would be more comfortable with commercial support, there are many consulting services listed at <http://www.freebsd.org/commercial/>. Or, if you want to deal with
a larger company, I recommend BSD/OS from Berkeley Software Design, Inc., at <http://www.bsdi.com/>.

Mini-Musings

I am not a communist. I believe that a person should be able to enjoy the proceeds of his/her labor. But I am not sure how this can happen in the software world. FreeBSD and the other open-source projects unfortunately compete with some well-respected commercial companies that deserve to stay in business and stay profitable (I am thinking of Sun, BSDI, and SCO, among others). Is it fair that some of the FreeBSD development is subsidized by government research grants and university funding, and ultimately the taxpayer? This means that the commercial companies are forced to support their competition to some degree. Fair or not, the software world is not going to change direction because of my musings. The affected commercial companies may need to shift the focus of their businesses toward integration, documentation, and support.