From owner-freebsd-questions@FreeBSD.ORG Wed Sep 13 15:27:19 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 987DB16A4EE for ; Wed, 13 Sep 2006 15:27:19 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3364643D7E for ; Wed, 13 Sep 2006 15:27:15 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1GNWdu-0004ma-M6; Wed, 13 Sep 2006 16:27:14 +0100 Received: from [82.41.35.166] (helo=[192.168.0.2]) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1GNWdq-0003rb-9T; Wed, 13 Sep 2006 16:27:10 +0100 Message-ID: <4508234D.4080408@dial.pipex.com> Date: Wed, 13 Sep 2006 16:27:09 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.13) Gecko/20060515 X-Accept-Language: en MIME-Version: 1.0 To: Chris References: <1DCE50F2-FFCA-479D-9E68-11936F0076DB@cbpratt.prohosting.com> <450730C9.4070309@dial.pipex.com> <4507E59B.9000109@dial.pipex.com> <6A634D83-491F-4837-A919-43050523DCB4@cbpratt.prohosting.com> In-Reply-To: <6A634D83-491F-4837-A919-43050523DCB4@cbpratt.prohosting.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freeBSD Subject: Re: NIC Questions for 6.1 Release - Obtaining changes not in RELEASE X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2006 15:27:19 -0000 Chris wrote: > Excellent and detailed information. I read the handbook and Complete > FreeBSD but couldn't grasp the relationship between CURRENT, STABLE, > and RELEASE and the cvsup tags definitively. This is important when > buying new hardware running ahead of RELEASE changes (e.g. the > Broadcom 5704). Last time (a then leading edge server with a U320 > Adaptec controller), I manually updated the driver source just to get > it to production and made my source out of sync and then feared > cvsuping further. I think you've given me, in a nutshell, how to do > this more responsibly. Let me take a shot at it for posterity. RELENG = The official release versions; as well tested as things come. Only get security patches. CURRENT = The very bleeding edge. Updated often. Not recommended for any critical machine. STABLE = Changes that have run well in CURRENT, fix problems or improve performance etc, and are things which will form part of the next RELEASE. Bugs and other issues much less likely than CURRENT. So developed software generally goes from CURRENT (when tested) -> STABLE -> next RELENG. But, not all software in CURRENT automatically goes to STABLE. CURRENT (right now) is what will be RELENG_7_0, and not all changes there will be suitable for 6. > > 1. Take the machine to STABLE via RELENG_6, if it tests reliably, go > production and freeze > 2. security patch through the .asc file patches until RELEASE 6.2 > 3. cvsup to RELEASE 6.2 aka RELENG_6_2 (when available and if needed > hardware changes were indeed incorporated) > 4. given no hardware additions, continue to cvsup on RELENG_6_2_0 for > Security Patches for server life-cycle This should work fine. In step 4, you can consider upgrading from RELENG_6_2 to RELENG_6_3 etc etc, obviously testing. The more critical a machine, however, the less likely you are to want to do that. If you have any kind of farm, then keeping identical hardware and using one machine as a test bed for any upgrades is also a possible scenario. The farm can be as small as two machines - one a backup for the other, but also usable for testing upgrades. I think it would be technically possible (if unlikely), that a security patch for STABLE might not apply cleanly if you are not running the latest STABLE. In such a case, you might again have to bite the bullet and update to the latest STABLE and test again. This is only likely to happen if the bug is some kind of kernel internal, and even then only if some other code for it in STABLE has changed since you did your upgrade. As I say, I think this would be unlikely. Depending on what the machine in question actually does, how it is firewalled etc, it might be that you don't even bother to apply a security patch. (No doubt some will shout when I say that), but you have to analyse what risk the security whole actually poses to *your machine*. You could always seek advice here if such an issue arises, > > I think a light is clicking on. > > Thanks VERY much, You're welcome. --Alex