Things to Consider Before Choosing a make world Upgrade
Things to Consider Before Choosing a make world UpgradeThe risks of building your system from scratch are not insignificant. On a high-profile production server, you may deem them too great for make world to be a viable upgrade method. It's a simple matter to wait for each full release on CD, and you may prefer to go that route insteadeither doing a binary upgrade through Sysinstall, or (as many administrators do today) backing up the data, performing a fresh install complete with a reformat of the hard disks, and reinstalling the data. To make an informed decision, though, you need to fully understand the risks involved in building a system from interim sources. First, and most obviously, make world involves at least one reboot, and it takes a long time to completeduring which time many of your system utilities might not work properly. If you're concerned about your uptime, or if your system absolutely must be online at all times (as with a high-profile network server), you would probably be best served by upgrading to each successive RELEASE version and applying the necessary patches in between releases. Second, make world isn't a guaranteed process. The FreeBSD Group makes no claims that make world will not completely destroy your system (though the same is true for any upgrade path, really). The real issue is that frequently rebuilding the operating system gives it that many more chances to blow up. Using make world is absolutely the best way to keep on top of all the latest bug fixes, but it's also an excellent way to find yourself running a system with untested new features or code changesor even to find that your sources won't build because, by pure bad luck, you synchronized your sources just when some unstable code was being checked in. Remember, the STABLE and CURRENT code branches are living, breathing creaturesthey're not "release" quality, nor are they intended to be. Any interim code that's not on a specific release branch should be regarded as beta quality at best. Rebuilding the entire system between releases is really something you should do only if you're using your FreeBSD machine as a workstation or a small, noncritical server, or if there is absolutely no other way for you to get a critical bug fix or new feature. Note In production environments, it is a common configuration to have two identical machines: the "real" server and a clone of it used for backup and testing purposes. If you have this kind of setup, you can test the results of a make world process on the backup system before performing the same procedure on the production server. Because the purpose of the production environment with the mirrored test server is to provide two identical platforms where if something works on the test machine you know it will work on the live one, you need to make sure that the sources from which you build your system are identical on both systems. It's imperative that you synchronize both systems to the exact same source tree and errata fix point, and don't perform any more source sync processes between the test system's make world and the real one. If you do track either STABLE or CURRENT, it's absolutely essential that you subscribe to the freebsd-stable@freebsd.org or freebsd-current@freebsd.org mailing list (as appropriate). These lists serve as forums for anyone tracking the branch to discuss problems, new bug fixes or features, and possible pitfalls for anyone choosing to synchronize sources at a particular time. A committer might post to freebsd-stable@freebsd.org, for instance, warning everyone not to use make world for at least the next couple of days until he has had a chance to test a risky new feature that has just been checked in. If you're not on the mailing list and the feature turns out to be less than rock-solid, you could end up with an unstable or insecure system, which is exactly what you're trying to avoid by tracking the sources. Note Both mailing lists are standard Majordomo lists. You can subscribe to either one by sending an email to majordomo@freebsd.org, with the message body as follows: subscribe freebsd-stableDo not send the subscription request itself to freebsd-stable or freebsd-current! This is one of the Internet's most common mistakes! These addresses are for the actual list traffic, not for control commands. That's all there is to it. When you receive a confirmation message, reply to it as directed to be added to the mailing list. To unsubscribe, do the same thing, except replace the word subscribe with unsubscribe. It's important to note that even though you might choose not to run the make world process regularly, it's still an excellent idea, in almost all circumstances, to track the sources. Tracking sources in and of itself merely synchronizes the source code tree on your system (everything within /usr/src) to the current state of either the STABLE or CURRENT code branch; it doesn't upgrade any binaries or affect the operation of your system at all. You can then choose to use make world, compiling all those sources into a completely new system, at your discretion. Alternatively, because the build process is as hierarchical as the filesystem in which it resides, you can simply go to any point within /usr/src and build that component individuallyfor example, go to /usr/src/lib/libkvm to rebuild just the libkvm library. This is how you typically patch your system in response to a security advisory (learn more about these in the section "FreeBSD Security Advisories," in Chapter 30). Above all, remember that upgrading a FreeBSD system is not a reversible process. You can't deinstall a newer version and have the older version still work as it used to. The best safeguard is to take as many precautions as you can.
|
