> If > not, then things get quite a bit harder. It does take some planning.
One approach I've used is to set up local APT repositories for different classes of applications, ie: local-<arch>-stable == things that every server should have; security patches, common applications like system management packages, configuration files for DNS and Kerberos, etc. Each processor architecture has it's own repository set (using the standard architecture identifiers to identify the repository name). local-<arch>-apps == add-on applications packages such as databases, web servers etc local-<arch>-dbapps == tools specific to databases and so forth, depending on what classes of servers you want to maintain. Part of the standard build template is a crontab entry that does a "apt-get local-<arch>-stable" every night at a scheduled time, to allow distribution of fixes that should go everywhere. If a server is customized for a specific purpose, the crontab gets modified as part of the application install to add a "apt-get <repository>" command for the appropriate local repository. The various servers then pick up updates as they are committed to the repositories w/o having to do individual updates. With a little creativity, this works well for both .deb and .rpm based systems, and it lets you carefully control the commit of service to the environment w/o having to trust YOU or up2date everywhere. Some assumptions of this approach are that you want all your servers to pick up upgrades at the same time and that you're confident enough in your knowledge of RPM and friends to ensure that the packaging of the upgrade corresponds with your configuration, but I'd argue that it's a workable situation. It seems to be fairly scalable and produces a parseable update log from the APT server that can be massaged into useful reports on configuration status. I should put together a short talk on this for the next WAVV or zExpo. It might be useful to somebody. -- db
