Date: Fri, 29 Aug 2003 14:25:12 +0200 From: Guy Van Sanden <n.b@myrealbox.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: Patching procedures Message-ID: <1062159912.2800.34.camel@cronos.home.vsb> In-Reply-To: <20030828112912.GC6697@happy-idiot-talk.infracaninophile.co.uk> References: <1062058175.9153.14.camel@cronos.home.vsb> <20030828112912.GC6697@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Matthew Thank you for your very complete answer. I'm going to be experimenting with this for a while, and I'll do a lot of reading. Kind regards Guy On Thu, 2003-08-28 at 13:29, Matthew Seaman wrote: > On Thu, Aug 28, 2003 at 10:09:35AM +0200, Guy Van Sanden wrote: > > ** message didn't make it to the list - sending again ** > > > > > > I'm still relatively new to FreeBSD, and I was wondering what most of > > you use as a patching procedure for FreeBSD (not the ports) > > > > Up to now, I have always folowed the instructions in '2) To patch your > > present system:'. > > Yet somehow this seems like the long way to do it. > > > > Therefor, I'm wondering how most of you keep your systems up to date. > > > > For the moment, I'm only managing my home server (which is still > > critical), but I would also like to know how to manage this in a > > professional deployment (I used to manage Solaris networks, and we had > > these patch-clusters which were rahter nice). > > Unlike Solaris, FreeBSD generally operates by supplying patches to the > system source code. Colin Percival has a binary patch system under > development, but it's not an official FreeBSD thing yet -- see > http://www.daemonology.org/ for details. > > The standard way to keep a system up to date is to maintain an up to > date copy of the system sources -- either which ever one of the > release branches you've chosen, or 4-STABLE or 5-CURRENT -- and > compile and install from there. > > For the release branches you can achieve that by starting with the > sources as distributed on the CD Roms, and applying the patches as > shown in any security advisories -- any changes to a release branche > will be accompanied by an advisory notice, which is almost always a > security advisory. Technically it may be possible for a really > crucial but not security related patch to be applied to a release > branch, but it doesn't seem to happen much in practice. The > non-release branches (4-STABLE, 5-CURRENT) are under continuous > development, so there's not going to be any specific points at which > everyone will update, other than when large chunks of particularly > awaited new functionality or big bugfixes go into the tree. Or when > (like now) a new release is in the offing. Most private users > tracking STABLE or CURRENT will just update every week or month or so, > or when they get around to it. > > Whatever the release branch you've chosen, and particularly if you're > running 4-STABLE of 5-CURRENT, it's much more convenient to use > cvsup(1) to keep your sources up to date, rather than by applying > patches. There are a few other mechanisms around -- see Appendix A of > the handbook -- > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors.html > > but cvsup(1) is what the vast majority of the users use. > > If you're using FreeBSD in a commercial setting, then you should > certainly be tracking one of the release branches and be implementing > a testing regime on a spare server before pushing out updates to your > production servers. Whilst the FreeBSD project generally does > extremely well at keeping 4-STABLE and the RELEASE branches stable, > they do rely on bug reports from users and developers rather than > having the sort of comprehensive QC test cycles that Sun performs. > > The test box function can be combined quite neatly with being a build > server -- you can either make your own releases and cut them to CD-ROM > for installation on your production machines, or just NFS mount the > /usr/obj and /usr/src trees from the build box in order to install the > upgrade. With practice you can get an installkernel - reboot to > single user - installworld - mergemaster - reboot cycle down to under > 15mins downtime, which is a lot quicker than it takes to install some > Solaris patches. > > One other major difference between Solaris patches and FreeBSD updates > is that FreeBSD doesn't offer you a specific mechanism to back out any > changes you make. Always make sure you have good backups from > immediately before you start an upgrade cycle. > > Cheers, > > Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1062159912.2800.34.camel>