One important assumption is that NONE of your servers share any DASD through VM's read-only minidisk mechanism. This would work well for a penguin colony that has lots of DASD, but can it work for colonies that are short on DASD and already sold management on the idea of read-only DASD sharing?
/Thomas Kern /301-903-2211 > -----Original Message----- > From: David Boyes [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 30, 2003 10:55 > To: [EMAIL PROTECTED] > Subject: Re: maintenance strategy > > > > 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 >
