I think that the session for WAVV or zEXPO would be a great idea and very helpful to a great number of people.
Loren Charnley, Jr. Tech Support Administrator Family Dollar Stores, Inc. (704) 847-6961 Ext. 2000 > -----Original Message----- > From: David Boyes [SMTP:[EMAIL PROTECTED] > Sent: Tuesday, September 30, 2003 10:55 AM > 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
