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

Some of my clients are using their WordPress installs with pages only, i.e. without any posts, and with comments turned off completely. This is often referred to as “WordPress as a CMS”. To free the screen from clutter I like to remove the comments link from the new/revised WordPress 3.3 Admin Bar. I also usually change the “+ New” link to default to creating a new page instead of creating a new post.

To accomplish this you can drop the following lines into your theme’s functions.php file:

<?php
function my_admin_bar_menu( $wp_admin_bar )
{
  $wp_admin_bar->remove_node( 'comments' );
  $newpage = $wp_admin_bar->get_node( 'new-page' );
  $wp_admin_bar->add_node( array( 'id' => 'new-content', 'href' => $newpage->href, ) );
}
add_action( 'admin_bar_menu', 'my_admin_bar_menu', 100 );

To find out more about the Admin Bar API you should check out this post by Andrew Nacin on the official WordPress Development Blog.

Peter Westwood and some other WordPress core developers have written a great plugin for WordPress plugin and theme developers: the Debug Bar. It plugs into the Admin Bar that was introduced with WordPress 3.1 and outputs various details about the current page, but to (super) admins only.

Thanks to the consequent usage of WordPress Plugin API functions there is a fairly easy and straightforward way of outputting your own debug information into the Debug Bar.

You should create a separate file for your Debug Bar tab, let’s call it my-debug-bar-panel.php, and place it in the same directory as your plugin file or your theme’s functions.php file. In this file you create a child class of Debug_Bar_Panel, e.g. my_Debug_Bar_Panel, with at least one method render() in which you can output everything that should be on your tab.

<?php
class my_Debug_Bar_Panel extends Debug_Bar_Panel
{
  function render()
  {
    echo '<div id="my-debug-par-panel">';
    echo '<h3>Some header</h3>';
    echo '<p>Some debug output</p>';
    echo '</div>';
  }
}

Now back to your main plugin file or functions.php: You need a function that hooks into debug_bar_panels. I put a double check in my example to make sure the base class Debug_Bar_Panel exists (since you never know whether they drop this in a future release which would cause fatal runtime errors). Then you create a new instance of my_Debug_Bar_Panel with the title, which you would like to see on your tab, passed to the constructor:

function my_debug_bar_panels($a)
{
  if (class_exists('Debug_Bar_Panel'))
  {
    require_once dirname(__FILE__).'/my-debug-bar-panel.php';
    $a[]=new my_Debug_Bar_Panel('My tab title');
  }
  return $a;
}
add_filter('debug_bar_panels', 'my_debug_bar_panels');

Believe it or not, you’re done!

I have just released my newest WordPress plugin to the public:

Open Graph Pro automagically adds Open Graph Protocol metadata to your WordPress powered blog/website. Through the Open Graph Protocol you can control how your posts and pages appear on Facebook when someone shares a link or likes your stuff.

The plugin does not add any “Like” buttons to your site just yet, but that’s on my to-do-list.

It does however give for a great deal of customization already by allowing you to change the object type of your entire site as well as the object type of individual pages, e.g. when you have a single page for each album or song of your band, or for each product of your company, etc. If you go to the settings page in the admin section of your site you can enter your Facebook user ID and give your site/blog the full potential of a Facebook page.

And just in case you’re wondering: I’m not using this plugin on this site at the moment, because liking or sharing stuff on Facebook only looks good with images, or it actually looks really crappy without them, and as you may have noticed I have very little eye-candy on my site at the moment. Now that the majority of all the coding is done I will focus next on the visual aspects of this blog, and then install the plugin when things have become more graphical around here…

I had always been a bit reluctant to enable the XML-RPC publishing feature on my blogs because this can be just an extra attack vector to a site. It is, however, required when you want to manage a WordPress blog using WordPress for BlackBerry. When your BlackBerry is connected to a corporate network using BlackBerry Enterprise Server, and your organization’s admins are OK with you using your mobile device and the corporate server to manage your blog (or if it’s a company website anyway), you can add the following lines to your .htaccess file to block any XML-RPC access to your blog which is not coming from your corporate server:

<Files xmlrpc.php>
Order allow,deny
allow from 198.51.100.27
</Files>

You will have to replace 198.51.100.27 with the IP address of your BlackBerry Enterprise Server.

Now you will also need to setup the WordPress app on your mobile device to use the BlackBerry Enterprise Server to connect to your blogs. In the app hit the BlackBerry key and click on “Setup”:

In the setup screen disable all other Connection Options and enable only “BlackBerry Enterprise Server” (this appears to be off by default):

Now Apache will allow only your BlackBerry (well, and any other BlackBerry in the same organization) to connect to your blog.

Nils asked me whether I knew about a WordPress plugin that would verify a comment author’s e-mail address. I didn’t, so I wrote one myself.

The plugin is in its early stages, the current version number is 0.1 – you are welcome to test-drive it and watch it grow, or watch me procrastinate and forget about it over my day-job :/ if I do, go ahead and nag!

Download the latest version (ZIP).

If you have a question about the plugin please go to the plugin’s homepage.

This release has been internationalized. I have created a German language file myself. If you would like to create a language file in your language you are more than welcome to do so (POT file is included with the plugin). Please contact me by posting a comment on this post (and be sure to provide the correct e-mail address so I can write back) to have it included in the next release.

I have written a WordPress Plugin: Top Spammers displays a list of your top spammers’ IP addresses, based on all comments in your database that are marked as spam. It also generates a blacklist for your .htaccess file to block those spammers from your website entirely, thus taking load off the server. You will need another plugin (like Akismet) to identify the spam.

Download the latest version (ZIP).

If you have a question about the plugin please go to the plugin’s homepage.