Patching procedures

[Guy Van Sanden]

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