Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Jan 2006 02:52:27 -0800
From:      Jo Rhett <jrhett@svcolo.com>
To:        Peter Jeremy <PeterJeremy@optushome.com.au>
Cc:        stable@freebsd.org, current <current@freebsd.org>
Subject:   Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
Message-ID:  <20060106105227.GE54324@svcolo.com>
In-Reply-To: <20060105114056.GN42228@cirb503493.alcatel.com.au>
References:  <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> <20051223045648.GH77268@cirb503493.alcatel.com.au> <20060105093727.GK1358@svcolo.com> <20060105114056.GN42228@cirb503493.alcatel.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 05, 2006 at 10:40:56PM +1100, Peter Jeremy wrote:
> >No.  I want a binary update mechanism.  Obviously if we have local
> >configuration options we'll have to compile our own binaries.  But doing
> >the work of tracking system updates currently requires us to build our own
> >patch tracking mechanism, and then re-write it for every new release.
 
> On Thu, 2006-Jan-05 01:37:27 -0800, Jo Rhett wrote:
> If you're willing to do your own compiles:
> 1) CVSup or cvs update to whatever branch you want
> 2) make build{world,kernel}
> 3) make DESTDIR=/updates install{world,kernel}
> 4) mergemaster -D /updates
> 5) rsync or similar
 
Hm.  So how do I know which systems need the upgrade?

So what occurs if the wrong version is rsynced to the wrong system?

What do I do if a kernel module upgrade fails?  How do I restore state?

This problem is solved fairly well in every other OS I can think of.  But
for FreeBSD we're currently solving it with very complex cfengine
management tied to lots of local databases and thousands of lines of our
own code.  It's all the long way around a problem that is very simple to
solve in the core.

> It seems fairly obvious that you are frustrated by FreeBSD's inability
> to meet your needs as far as updating is concerned.  I suspect I'm not
> alone in being uncertain exactly what your requirements are and what
> additional features FreeBSD needs to satisfy you.

Some implementation (any!) that versions the core.  Something you can query
to ask what is, update to say what you've done, and revert to restore a
previous state.

> How would you like
> to write a formal requirements specification and post it here (or in
> -arch).
 
This has been written many times, by people better at explaining the issues
than I am.  I'll find someone elses and forward it to you.

> Have you looked at tools like Bcfg2 ( http://www.mcs.anl.gov/cobalt/bcfg2/ )?

I haven't compared bcfg2 to what we're doing now (cfengine) but it would
likely have all of the same problems.  Namely, we'd have to build and
maintain a database of all possible software combinations, and what systems
are running which patches, and then write scripts that do the right updates 
to the right systems.

Again, thousands of lines of perl/ruby/shell to work around a very well 
known limitation in freebsd.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060106105227.GE54324>