Hi, On Wed, Jun 24, 2009 at 10:13:21AM +0200, Joachim Schipper wrote: [...] > If you want to go the whole hog, cfengine/puppet may be useful. But > you're likely content to just keep a single configuration up to date, > in > which case simpler measures may suffice.
I plan to look into cfengine (didn4t know about puppet, thx) - however, I think configuration files are not a problem. Changes there are always documented and everything is backed up on a central location, so it will be easy to do this manually. > You can use release(8) to construct updated tarballs for the base > system. Create these on a secure system, sftp them to anywhere you > need, > and unpack. Binary patches are possible, but probably more effort than > they're worth for a comparatively small setup like yours. Ok. > I'd be inclined to go with snapshots, but you'll need to follow the > process at least a little and test at least a little. On the other > hand, > if you go with -stable, you should make sure your ports are kept up to > date, which isn't guaranteed. This is the reason why I plan to look into snapshots at all. I got into quite a mess with my mixture between stable OS, and newer versions of programs (like ClamAV, which needs frequent updates). I guess snapshots will keep everything in sync. > Remote upgrades should be possible in either case. > > You can use sysmerge to check for and resolve differences between the > installed files and the etcXY.tgz and xetcXY.tgz files. This is very > useful when upgrading systems. > As for keeping the configuration in sync, you may want to consider > your > favourite version control system. You will, obviously, need some > per-host customizations: these may be best represented as branches. Or > not. > > You should create ports from your personalized postfix and clamav > installations, which will make it a lot easier to install them and > ensure you can easily keep all your hosts on an updated version. This is good advice, didn4t think about creating my own ports for this. > Otherwise, it seems pretty sensible. You might be better off if you > could convince those organizations to trust in a single mailhost run > by > you, though. This is not an option unfortunatly, however, the different mail configurations were never a problem. Thanks for your advice, really appreciated! Urban
