Hi, Here's an idea I had - it involved a combination of binpatches and release packages.
What you would do is have a central server with the required binpatches and packages to install and set up scripts to run on shutdown, then when you want to update a server, simply reboot, and the changes will be made prior to reboot. I haven't yet tested this method on moving from one release to another as yet, though it would be relatively straightforward assuming you don't hit any speed humps trying to reboot. Another suggestion would be to modify the boot scripts for a copy of the ramdisk so that when it boots, it gets the network config from the host, connects to the update server and applies the updates, resets the system to boot off the normal kernel, then reboot. For the server you'd need nothing special, just running apache and storing the patches in the /var/www/html directory will suffice. If you were to compile the binpatches whenever they came out, however, you'd need a bit of hard disk (probably no more than about 4-6 gigabytes for the full system, add another 5-20gb depending on how much of the ports repo you plan to use). The only other thing to consider is changes in configuration files. The update scripts would need to consider that config files could change from release to release, and that there may be changes that you have made. HTH On Wed, Jun 24, 2009 at 6:46 AM, Rogier Krieger<[email protected]> wrote: > On Tue, Jun 23, 2009 at 22:27, Urban Hillebrand<[email protected]> wrote: >> My aploogies for being unclear. Those hosts are all on different >> locations and nets, even belong to different companies. > > You could try using tools such as cfengine and/or puppet (both are in > ports) to have them pull in their configuration form a master host. > Preparing the configuration, scripts, install tools and keeping them > under version control might work for your purposes. > > Whether it's worth your effort is up to you. I'd recommend to start > simple, to see if you like it. If so, it should free your hands a bit > to improve on the system. > > Perhaps a look at infrastructures.org [1] proves helpful; it was for > me. How you want to deploy such a thing with multiple companies etc. > may take some thought/checking their policies. > > Hope this helps, > > Rogier > > References: > 1. Infrastructures.org - Best practices in automated systems > administration [...] > http://www.infrastructures.org/ > > -- Aaron Mason - Programmer, open source addict - Oh, why does everything I whip leave me?
