* Michael Lockhart <[EMAIL PROTECTED]> [2006-11-02 18:33]:
> All,
Wrap your bloody lines!
>
> 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
>
> 2. Command and Control. What projects or capabilities are available for
> performing remote command and control over services, packages, and system
> health? Currently, all push/pull is done with perl/sh scripts to bring files
> over, sanity check, install, update, etc. I've been leaning towards creating
> a daemon that runs on each system and has a secure connection back to a
> centralized location for determining if updates are available. My proof of
> concept works, but thoughts on how to do this right are GREATLY appreciated.
>
ssh gives me pretty much everything I need. for remote console most
of my systems use serial tty's to cisco console servers and the ilk - all of
which hide behind a console server box hooked to a private net running
conserver from ports. conserver gives me remote console logging and shareing.
>
> 3. Remote upgrading. Going from 3.2 -> 3.8 or 4.0 is going to be very
> difficult, and the approach that I am taking right now is creating a bsd.rd
> based kernel/image that will boot fully into memory, and contain the
> appropriate scripts to re-initialized the disks, rsync/scp/ftp/get/whatever
> the new base image and kernel over, then reboot, and go into the new image,
> and perform the rest of the upgrade from there. Has anyone done something
> similar to this or know of any projects along these lines?
>
I do a couple of things for this, depending on what it is.
To clone systems outright I use a bsd.rd and a variant of the
usual dump | restore ;; installboot, take the master client dump each
filesystem. make a shell script that then sets up filesystems, mounts
them, grabs the aforementioned dumps, feeds them to restore, and then
does an installboot and adjusts /etc/hostname.* and myname.
The other approach I often do is a siteXX.tgz file. The standard
openbsd installer will look for these and use them. if the tarball contains
an executable site_install script it will also run it. My typical approach
to a site customized distribution is to put a site_install script inside
the siteXX.tgz file as well as any files I want to override from the
distribution, and
then do pkg_adds in the site_install script.
Having said that, I'll often do remote upgrading from X.Y to A.B where
the difference between A.B and X.Y isn't a lot. 3.2 to anything modern is
huge. that's not an upgrade, it's a reinstall. I would be testing a sample
on a modern client and deploying new installs based on that.
-Bob
> Anyway, just wanted to get some feedback from the community and see what
> everyone had to say on this stuff. Thanks in advance everyone.
>
> Regards,
> Mike Lockhart
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Mike Lockhart [Systems Engineering & Operations]
> StayOnline, Inc
> http://www.stayonline.net/
> mailto: [EMAIL PROTECTED]
> GPG: 8714 6F73 3FC8 E0A4 0663 3AFF 9F5C 888D 0767 1550
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
--
#!/usr/bin/perl
if ((not 0 && not 1) != (! 0 && ! 1)) {
print "Larry and Tom must smoke some really primo stuff...\n";
}
