On Fri, 2006-11-03 at 08:45 -0700, Bob Beck wrote:
> * Michael Lockhart <[EMAIL PROTECTED]> [2006-11-02 18:33]:
> > All,
> 
>       Wrap your bloody lines!

I agree

> > 
> > Here's a question that I wanted to pose to the OpenBSD community about 
> > managing and maintaining a large number of OpenBSD systems in the field.  
> > To provide some background, we currently have 650+ OpenBSD 3.2 systems in 
> > the field, and I've been dealing with a fair share of headaches bringing 
> > our software to a baseline across the board on all these systems.  Keep in 
> > mind most of what I'm working on is independent from the OS install itself. 
> >  Here's the things that I've got solutions in place for, but would like 
> > some input on projects available, or good feedback from other's who have 
> > maintained a large number of disparate systems:
> > 
> > 1. Reliable package building system to auto-generate OpenBSD packages that 
> > are compliant as much as possible with the standards enforced by OpenBSD.  
> > I've got scripts to do this right now, but I'm not happy with them.
> >
> 
>       I use the built packages from openbsd.org
> > 

Maybe use a standard install as base and pull the config from a CVS
server. There are ways to separate each client's specifics inside a
single CVS module, if you're not too fussy about hacks, and if the
clients are more or less identical except for simple config issues like
IP adresses etc. If some clients differ greatly, maybe put them into
separate module groups. In my opinion OpenBSD is extremely easy when it
comes to separating different configs.

About packages: don't try to re-do what others have already done for you
(tell me about it!!). Use the standard base and place your own layers on
top of it, whether in the form of a CVS checkout or a site.tgz (which
you're probably going to put under some kind of revision control anyway)
or whatever. If the same things are done twice that's too bad, but you
will be safer than when trying to maintain your own basXX.tgz etc., and
keeping it in sync with the main dist.

Upgrades are an automation nightmare, Linux distros claim they can do it
but they can't (goes wrong more often than not - I've stopped installing
updates on my Ubuntu-driven desktop, which saves me lots of reinstalls).
I would simply reinstall, after having distilled a working config from a
test system.

Bill Maas

Reply via email to