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).