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
