Tue, 02 Jan 2007
PkgWatcher - Initial Release
When it comes to servers, some packages should be everywhere, some should
be
banned and there are always the edge cases - be it a build host that
requires GCC or a webserver that needs a full complement of packaged perl
modules. While a decent system imaging or ad-hoc change system will help
keep the discrepancies down nothing beats a system level check that
verifies your assumptions. And PgkWatcher is that
check.
The script's easy to use, copy it to the machine, install
Parse::Debian::Packages (via CPAN or apt-get) if you're on a
Debian system and then populate any (or all of) a required packages,
prohibited packages and local packages list. And then run the command with
the files, each line of which should contain a single package name, passed
as options (pkgwatcher -h will show you some examples) and see
what it outputs. The script will tell you about anything that should be
installed and isn't, shouldn't be installed and is, and any packages that
are listed in both files. Which I consider a configuration error. And now to
an added feature, the local package list. This is the last list checked and
allows you to do host specific overrides. If, for example, you banned GCC
on all your servers you'd add it to the prohibited package list. And if you
had a build host that required GCC you'd have to either leave the check off
or customise the file for that one machine. By adding GCC to a local
packages file you can override that one package on that single host.
PkgWatcher was designed to run under Nagios but works just as well as an ad-hoc command line tool. Although without centralised management, keeping the required and prohibited lists up-to-date and in sync could become a hassle. And now some notes, it understands the RPM and DPKG packaging systems (and it's pretty easy to add additional ones), it's written in pure-perl (so it's easy to move around) and it's quite forgiving. If a package isn't on its required or prohibited lists then it does nothing about it. This is both because I'm pragmatic (a good deployment strategy is a better solution to keeping hundreds of machines in check) and because the environment I've written it for has a lot of legacy systems. And being overly strict means you never gain any ground.
What's next for it? It'll soon be plugged in to the configuration templating system we use to get automatic package checking based upon the services defined for that type of host (with package list generation based on the declared OS type).
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2007/01/02 22:42 | /tools/commandline | Permanent link to this entry | This entry + same date
Copyright © 2000-2005 Dean Wilson
