-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There has been a lot of discussion on these two mailing lists about the upcoming EoL of FreeBSD 4.x which I mentioned in my email entitled "HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon". Now that everybody (hopefully) has had their say, I'd like to offer some background and explanation. The concept of "security branches" in the FreeBSD CVS tree was introduced with FreeBSD 4.3, about five years ago. At the time, support was only guaranteed for the most recent FreeBSD release and one -STABLE branch (either the latest stable branch, if two or more releases were based on it, or the previous stable branch). Under this original policy, the only supported branches would now be the security branch for FreeBSD 6.1 and 6-STABLE. Three and a half years ago, the Security Officer decided to increase the length of time for which releases would be supported, and the policy was changed to promise that releases would be supported until 12 months after their release dates, and any stable branch containing a supported release would also be supported. Under this policy, the only supported branches would now be the security branches for FreeBSD 5.5, 6.0, and 6.1, and 5-STABLE and 6-STABLE. A year later, support was once again extended. Security branches became "Errata branches", open to both security fixes and critical stability fixes (as jointly defined by the security and release engineering teams); in addition, some releases were designated as "extended support" releases, to be supported for 24 months after their respective release dates. FreeBSD 4.8 was the first such release, and FreeBSD 4.10, 4.11, 5.3, 5.5, and 6.1 have also been designated as such. It was agreed that the last release from any stable branch (which, since FreeBSD 2.2.x, has always come after the first release from the next stable branch) would always be designated for extended support, in order to provide a minimum of two years for users to upgrade to the new stable branch before their systems became unsupported. When FreeBSD 4.11 was released on January 25th 2005, the release announcement stated that "this is expected to be the last release from the RELENG_4 branch. Most of the Developers are now focused on the RELENG_5 branch, or on the cutting edge development in HEAD", and on that same day the EoL date of January 31st 2007 was documented on the Security webpage at http://www.freebsd.org/security/. The upcoming end of support for FreeBSD 4.x should therefore not be a surprise. While it might be convenient for some if FreeBSD releases were supported for far longer, it must be remembered that FreeBSD is a volunteer project which issues new releases every 4-6 months. Whereas a company like Microsoft has funds to hire people to support Windows 200[03] and XP, the FreeBSD Security Team is now supporting six releases -- 4.11, 5.3, 5.4, 5.5, 6.0, and 6.1 -- as volunteers. Each supported release increases the workload on the Security Team, by adding to the number of releases on which patches must be tested, by increasing the time required to investigate security issues, and by often requiring that patches be "back-ported" to apply to older releases. Based on my experience as a member of the Security Team since early 2004, I simply do not think that it is practical to support more than six releases concurrently. FreeBSD 4.x also poses some challenges due to its age. FreeBSD 4.11 contains OpenSSH 3.5, Sendmail 8.13.1, and BIND 8.3.7; these all act as Internet-facing servers, and are consequently particularly likely to suffer from security issues, but they are all maintained by their respective projects. The FreeBSD Security Team is largely dependent upon receiving security advisories and patches from the "upstream" maintainers of this code and/or from other projects (e.g., Linux vendors) who use the same versions as we do; FreeBSD is now one of the last projects still supporting these versions, and as time passes it will become increasingly difficulty to continue to do so. Even with code written and maintained within the FreeBSD project it would be far from trivial to continue to support FreeBSD 4.x. FreeBSD 4.x has not been the target of new development in FreeBSD since March 2000; FreeBSD, like all free software projects, has constant turnover in its pool of developers, and it is often very difficult to find developers familiar with code in FreeBSD 4.x which has been replaced in newer FreeBSD releases. The FreeBSD project is reaching the point where it lacks the "institutional memory" needed to continue to support FreeBSD 4.x. In short: * FreeBSD is a volunteer project, and we don't want to volunteer to support FreeBSD 4.x beyond the scheduled EoL date of January 31st, 2007; * Even if we did want to support FreeBSD 4.x beyond that date, I'm not certain that we would be able to do so, given that both FreeBSD and the rest of the world has moved on; and * You've had lots of warning that this was going to happen, so it's a bit late to start complaining now. Colin Percival FreeBSD Security Officer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFFNTHJFdaIBMps37IRAnPVAJ4yeeE+yFq8B2cJJJnMBHzInA7vtgCfXjOa x4J/fxk3XMgPrGw3In+mSAk=no9w -----END PGP SIGNATURE-----
FreeBSD Security Officer wrote:> In short: > * FreeBSD is a volunteer project, and we don't want to volunteer to support > FreeBSD 4.x beyond the scheduled EoL date of January 31st, 2007; > * Even if we did want to support FreeBSD 4.x beyond that date, I'm not certain > that we would be able to do so, given that both FreeBSD and the rest of the > world has moved on; and > * You've had lots of warning that this was going to happen, so it's a bit late > to start complaining now. > > Colin Percival > FreeBSD Security Officer >To no one in particular: "The hood's not welded on" (Eric Raymond?). You'll have the sources. If you're using 4.11 in a business, you need to decide if it's more cost effective to move on to 6 or hire someone to keep 4.11 running. There's compat_4 to keep most userland apps happy. I'm sure you could argue the various design issues to your hearts content on the news groups, but practically speaking, I don't have an issue with this. Nor is it all that different from your typical paid for support model for a proprietary OS. It's not like the poor folks that got stuck with a business app that was locked to win95 or 98 with bizarre undocumented API's jim
Colin, Thanks for the verbose and reasoned explanation. Since the email last week, I have taken the opportunity to upgrade two machines, one here and one remote (both with serial console) from 4.9->5.5->6.2PRE, and while I can't say that I did it blindfolded, it wasn't too painful. The upgrade instructions at... http://www.freebsd.org/releases/5.3R/migration-guide.html ...were as close to perfect as could be (and for those who might ask me for a step-by-step howto, look to the above URL). A few things that I should mention to others trying this are... 0. Backup, and then check your backups! 1. Be prepared to spend a lot of time in single-user mode, especially for the 4->5 step, because there is a LOT for mergemaster to do. The step from 5->6 is not nearly as painful. I didn't try to do the installworld and mergemaster in multiuser, and if you do then have a bigger set than I do. 2. Trust the migration guide when it says to use a default kernel configuration file unless you are 100% prepared to reap what you sow. 3. Be prepared to spend a lot of time (depending on the speed of your machines) rebuilding all of your ports. Don't skimp on this step. 4. On one of my machines (the local one, thank God!), I started getting weird pauses and bus errors when trying to rebuild my ports, and then noticed that the acpi.ko wasn't being loaded at boot. Turns out that I had disabled ACPI in the BIOS back when the machine was originally built for v4. Since switching on ACPI in the BIOS, those issues have totally cleared. All in all, it has been a good experience. I do sympathize with the folks who clamor for the death of v5 before v4, because v4 continues to be rock-solid stable for UP machines. Time will tell if v6 answers the shortcomings of v5 when compared to v4. Either way, the benefits of using FreeBSD far outweigh the costs, so I thank you and the rest of the development community. -- Mike Oliver, KI4OFU [see complete headers for contact information] ------------------------------------------------------------------------ If your email to me is rejected, it is likely a problem with the MTA on your end, so please send the error report to me at mwoliver at gmail dot com and I will investigate the issue. Thanks. ------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061017/4da6c6de/attachment.pgp
Michael, Nice job with this, I'm sure that many people will find it very helpful. I would like to offer a few suggestions if I may. Michael W. Oliver wrote:> Colin, > > Thanks for the verbose and reasoned explanation. Since the email last > week, I have taken the opportunity to upgrade two machines, one here and > one remote (both with serial console) from 4.9->5.5->6.2PRE, and while I > can't say that I did it blindfolded, it wasn't too painful.That's great news! :)> The upgrade instructions at... > > http://www.freebsd.org/releases/5.3R/migration-guide.html > > ...were as close to perfect as could be (and for those who might ask me > for a step-by-step howto, look to the above URL). A few things that I > should mention to others trying this are... > > 0. Backup, and then check your backups!Amen brother, especially to the bit about checking the backups before committing yourself.> 1. Be prepared to spend a lot of time in single-user mode, especially > for the 4->5 step, because there is a LOT for mergemaster to do. The > step from 5->6 is not nearly as painful.One technique that I have used successfully in the past is to get an up to date src tree, run mergemaster -v up to the point where it has built the temproot and says "The following files ...", then ^C out of that and run the following: diff -ur /var/tmp/temproot/etc /etc > etc.diff That way you will know what you've changed and rather than have to suffer through running mergemaster you can just blow away /etc, install the new one using 'mergemaster -i', and then apply the bits of your diff that are still relevant.> 3. Be prepared to spend a lot of time (depending on the speed of your > machines) rebuilding all of your ports. Don't skimp on this step.One small clarification, it's not necessary to do this after installing RELENG_5, only after you've arrived at R6. In addition to the excellent suggestion that Kris offered of using portupgrade, I would also like to suggest that you give portmaster a try. Particularly, _before_ upgrading you can install portmaster and run 'portmaster -l > installed-ports-list'. Then when you're ready to start over, you can install each of the ports on the root and leaf lists and portmaster will sort out the dependencies for you. hth, Doug -- This .signature sanitized for your protection
On Tue, 17 Oct 2006, Michael W. Oliver wrote:> 1. Be prepared to spend a lot of time in single-user mode, especially > for the 4->5 step, because there is a LOT for mergemaster to do. The > step from 5->6 is not nearly as painful. I didn't try to do the > installworld and mergemaster in multiuser, and if you do then have a > bigger set than I do.If you're setting up machines that you're going to be upgrading like this in the future, I think it's _really_ worthwhile hacking out a couple of "root slices" - that is, space for a second / and /usr - to facilitate this. You can run mergemaster on a secondary copy of your /etc (this, of course, requries that the contents of /etc are relatively quiescent for this step) and tidy up by hand. You can perform a dump & restore followed by a source upgrade, a fresh source install or a binary upgrade ad lib; just reboot (with nextboot) when done. This also means you can keep the previous OS around for a while in case there are problems with the new one. For setups that aren't amenable to automated deployments this works pretty well and gives you a safety-net for upgrades. Cheers, jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ We thought time travel was impossible. But that was now and this is then.