Date: 18 Apr 2002 12:24:31 -0700 From: Ken McGlothlen <mcglk@artlogix.com> To: Brett Glass <brett@lariat.org> Cc: nate@yogotech.com (Nate Williams), Christopher Schulte <schulte+freebsd@nospam.schulte.org>, security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip Message-ID: <87it6oajyo.fsf@ralf.artlogix.com> In-Reply-To: <4.3.2.7.2.20020418114304.00dccf00@nospam.lariat.org> References: <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <4.3.2.7.2.20020417230144.032ad390@nospam.lariat.org> <200204171923.g3HJNga58899@freefall.freebsd.org> <4.3.2.7.2.20020418095356.024354c0@nospam.lariat.org> <4.3.2.7.2.20020418114304.00dccf00@nospam.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass <brett@lariat.org> writes: | Many people are suggesting that one CVSup every night. Which isn't an onerous thing to do, provided you're only doing it on one reference machine. I suspect most people only do the cvsup on demand, or weekly, or monthly, or whatever else. | How does one know that there isn't a system-crashing bug in some other part | of the tree for the same date? Well, that's certainly a possibility. However, patches made to -STABLE are tested pretty well prior to inclusion (which is why it's called -STABLE). In -CURRENT, you're kind of on your own, but a production shop shouldn't be running -CURRENT. Even well-funded organizations such as Microsoft can't possibly test all combinations of hardware; Microsoft has occasionally released system updates that have caused widespread problems. The same can conceivably happen with FreeBSD, or any other operating system, for that matter. The absolute best way to head off potential problems is this: * Have all your machines running absolutely identical hardware. * Designate one machine to be the FreeBSD -STABLE source reference. * CVSup that one daily, nightly, weekly, whatever you like. * Designate another machine to be the test box. * Before installing a new version of FreeBSD or any kernels on a production machine, test it on your test box until you're reasonably sure that it will work on the production machine. Now, this gets kind of expensive, because you have to make hardware upgrades across the entire range of machines at once (say, if a part croaks and it turns out they don't make that model anymore). But it's the only sure-fire way. A more reasonable approach is to be aware that changes to the -STABLE branch are properly and reasonably pretested, widely installed, and any potential problems will be squished as soon as humanly possible. Pay attention to and evaluate all the security advisories on an individual basis, and try to run the same build across all the machines. I should point out that I've been running FreeBSD since . . . uh . . . 1994 or 1995, and I've *never* had -STABLE produce a non-running system. Ever. I've developed a lot of faith in the -STABLE tree, and in the people in charge of it. You might want to relax a little. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87it6oajyo.fsf>