I use revision control systems for almost all of my software development, deployment, and server configuration. When using Subversion there is, technically, no difference between a working copy on my personal or development machines vs. a working copy on a production server. (Yes, you need a working copy on the production server, because exports cannot be updated that easily.) However, modifications of the checked out code or config files on a production server can cause problems with the next round of updates. Sometimes you just don’t notice that there are conflicts that need to be resolved.

To make sure I notice when a colleague or I have fallen back into the bad habit of changing things on a production server directly, rather than checking in changes to the repository, I have created a Nagios Plugin: it’s called “check_svnstatus”

You can download, clone, or fork the plugin from my GitHub repository for Nagios plugins. (I know it’s a bit ironic to host this here.) If you’re unfamiliar with GitHub: here’s a .zip version, and here’s a .tar.gz version.

Installation and Configuration

Copy check_svnstatus.sh to your Nagios plugins directory. Usually this will be /usr/lib/nagios/plugins or /usr/local/nagios/libexec but your environment may be different. The plugin needs to be copied to the same server as your working copy, i.e. if you’re watching working copies on different servers you need the plugin on all of those servers.

Make check_svnstatus.sh executable:

chmod +x check_svnstatus.sh

You can test the plugin now by manually invoking it:

/path/to/check_svnstatus.sh -d /your/working-copy

You should see “OK: working copy at /your/working-copy is unmodified”, but “CRITICAL: working copy at /your/working-copy contains modifications” would also be OK for the moment; you can clean up later.

Now we need this to be run from Nagios… Things will be slightly different depending on whether your working copy resides on the same server as Nagios or on a different server. Lets start with a local working copy, i.e. one that’s on the same server as your Nagios install.

First you need a Nagios command. If you’re still using a modified version of the sample configuration files (nothing wrong with that!) append this to commands.cfg:

define command{
  command_name check_local_svnstatus
  command_line $USER1$/check_svnstatus.sh -d $ARG1$
}

Then you can add a service definition, e.g. append these lines to localhost.cfg:

define service{
  use                 local-service
  host_name           localhost
  service_description SVN ST /your/working-copy
  check_command       check_local_svnstatus!/your/working-copy
}

Reload the Nagios configuration (or, if you get the hint: check in the config changes to your Subversion repository, then run svn update on the config directory on your Nagios server, then run something like service nagios reload) and Nagios will schedule the first check of your working copy… Things will be very straightforward and self-explaining from here.

Now if your working copy is on a different server than your Nagios install, you need a method to invoke the plugin remotely. There are various methods for doing so, and there tend to be lengthier discussions about the pros and cons, but please keep in mind that this post is not about remote invocation methods. For this example I’ll be using check_by_ssh but NRPE or other methods will work as well. If you’re unfamiliar with remote invocation and/or you’ve never run “check_by_ssh” before you should get this sorted out first, e.g. by reading this post on TechRepublic.

Again you need a Nagios command. Append this to commands.cfg:

define command{
  command_name check_ssh_svnstatus
  command_line $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/path/to/check_svnstatus.sh -d $ARG1$"
}

Note: /path/to/check_svnstatus.sh should be the location on the remote server. This path may be a different than the location of your plugins on the Nagios server itself.

Then you can add a service definition the server’s .cfg file:

define service{
  use                 generic-service
  host_name           servername
  service_description SVN ST /your/working-copy
  check_command       check_ssh_svnstatus!/your/working-copy
}

Once again: reload the Nagios configuration and Nagios will schedule the first check of your working copy… Things will be as straightforward and self-explaining as they were for a local working copy.

By the way: You can also call this a poor-man’s IDS as it will trigger alerts when someone exploits your website and drops or alters PHP or other files in your htdocs directory (if you’re using Subversion to deploy).

Oh, and think about this: It might be good idea to put your Nagios configuration in a Subversion repository. Whether or not you end up monitoring the working copy on the Nagios server.

Additional reading

If you’ve been scratching your head over the “deployment” remark in my opening sentence you might want to follow these links:

• Joseph Scott: Installing WordPress As A Subversion Checkout (Or External) In A Subdirectory
• WordPress Codex: Installing WordPress With Clean Subversion Repositories