In case you’ve ever wondered what the monthly traffic allowance in your web hosting plan means in bandwidth, here’s an easy-to-remember number:

3.19 (month kbit) / (sec GB) – I shall call this the Brian Adkins number

Under the assumption that traffic from a web server only flows in one direction it means that for every GB (gigabyte) of monthly traffic included in your plan you could consume 3.19 kbit/s constantly. Or for every TB (terabyte) of traffic allowed per month you can transmit data at a constant rate of 3.19 Mbit/s.

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

Smart Quotes should appeal to the international audience. E.g. if you’re a German writer and would like to use German book style quotation marks (»…«) even when you type so-called "dumb" quotes or use the <q> element: This plugin is for you!

Right now the plugin comes with shortcuts for Croatian/Hungarian/Polish/Romanian style quotation marks („…”), Czech or German style („…“), Danish (or German books) style (»…«), Finnish or Swedish style (”…”), French style (« … » – with spaces), Greek/Italian/Norwegian/Portuguese/Russian/Spanish/Swiss style («…» – without spaces), Japanese or Traditional Chinese style (「⋯」), but you’re free to manually enter/paste any arbitrary characters or character combinations.

Download “Smart Quotes” (.zip) now

After you’ve installed the plugin go to your Wrting Settings screen where you will find this:

Right now the plugin comes in English and with a German translation, but for “Smart Quotes” I’d be particularly interested in adding more languages. Contact me if you think you can help! The .POT file for this one is really small, so I’m thinking it could be a quick fix. – If you have never translated software before: this thread on Lester Chan’s Forums is a good start and it’s specific to WordPress plugins.

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

I’m using the post-commit hook to send out E-mail notifications when changes are committed to Subversion repositories.

If you search the web you’ll find a ton of scripts in various languages for this purpose. They all do more or less the same thing: create an E-mail message for the commit, including such details as the revision author, number, timestamp, a list of the paths that were changed, and a diff of the changes.

For one particular project I wanted the diff as an attachment, though, rather than inline in the message text. So I ended up writing my own script. It’s a Shell script that should work on most Unix/Linux based systems.

Source code

Installation instructions

To install this for your repository:

1. Copy commit-report.sh to the server hosting your repository, for instance to /usr/local/bin, and make sure it’s executable (run chmod +x commit-report.sh)
2. Check line #2 of commit-report.sh – you may need to change that address depending on your individual circumstances I removed this item later: see this comment
3. Edit line #2 of the file post-commit: change /path/to to the correct path for your server, e.g. /usr/local/bin
4. Edit line #2 of the file post-commit: you probably don’t want to send reports to foo and bar at foo.local but to some other address(es)
5. If you want a fancy name in the subject line, instead of “SVN: `basename-of-your-repository`” append -name "Your fancy name here" to line #2 in post-commit
6. If you haven’t used the post-commit hook yet, copy the file post-commit to the hooks directory in your repository – Note: Don’t check it in, but copy it to the respository itself, e.g. in /srv/svn/repositories/myrepo/hooks
7. If you’ve already used the post-commit hook, and it’s a Shell script, append line #2 of the file post-commit to your script. If it’s not a Shell script you’ll have to figure out a way to call commit-report.sh with the correct parameters in your language

You can always test commit-report.sh by invoking it manually.

Troubleshooting

Update: Pointers for troubleshooting have been added later, based on your feedback…

• If the script runs without any errors on the console, but you never receive a commit report, change line #2 of commit-report.sh: put something like FROMADDRESS="youremail@yourdomain" in here

Webduino, the web server library for Arduino, now supports HTTP Basic access authentication. You can download a .zip file of the latest version from GitHub. (Note: The download link does not point to a specific version, but always to the very latest version of Webduino including features and/or bugs that were added/fixed after I wrote this post. Here’s the front page of the GitHub repository.)

Authentication means that you can now protect the web-enabled functions of your Arduino with a username and password.

There is at least one other version of Webduino supporting authentication, written by Claudio Baldazzi. It’s in this post on the original Google Project site of Webduino, with an example here. When I started working on improvements of the Webduino, plus new features for my own use, I considered using Claudio’s version but decided against it for the following reason:

With the Claudio’s version all pages of the Arduino would be protected by the same username and password. However I wanted a way to distinguish different user levels. E.g. Person A should be allowed to see on the web whether the lights are on or off, but only Person B is allowed to flick the switch.

Here’s how I did it.

The WebServer class now has two new methods: httpUnauthorized() sends error 401 back to the client, which in the case of a regular web browser causes the user to see a prompt for username and password. checkCredentials() checks whether a username and password have been sent with the request and whether they are valid, i.e. they have certain values. In a Webduino command function you should first run checkCredentials() and depending on the return value either run your “protected” code, like turning on the lights, or fire httpUnauthorized(). See the methods’ subpages of the API documentation for example code.

As reported earlier I had been given an Arduino Uno. I subsequently received my Ethernet Shield to hook the board up to the network. I’m clearly heading towards the Internet of things… Although I am still not 100% certain about what I’m going to do with the board (or how many additional ones I am going to have to buy) one things is pretty clear: It will have to be controllable and/or configurable over a web interface.

I found the Webserver example that ships with the Arduino IDE to be rather dull and unflexible. It wasn’t long before I stumbled upon Webduino, a very flexible generic Web Server library originally written by Ben Combee. The Webduino project homepage on Google Project Hosting points to this GitHub page. I downloaded the version adapted to Arduino 1.0 and started hacking away. Let me say this now: Webduino does meet my expectations.

However after a short while I ran into problems. None of them were to blame on the library, but rather on myself, but that’s actually not the point of this post… When I ran Wireshark to look at the data going over the network I noticed that for every page loaded Firefox also tries to download favicon.ico from the web server. Since Webduino sends a 400 error back on any requests for resources that have not been defined Firefox just keeps retrying forever.

At around the same time I discovered that, to avoid excess traffic from robots, there is a default robots.txt built into Webduino. So I decided to add a default favicon.ico, based on the icon used in the “Web_Image” example that ships with Webduino. Now when the first page is requested, Firefox loads the icon file, which actually eats more resources than one 400 error, but it pays off down the road when Firefox caches the icon and does not request it again, saving the Arduino from having to generate many 400 errors…

Webduino "Hello World!" page with favicon.ico; this is the default favicon.ico in my version of Webduino

And since I see projects hosted on GitHub as an open invitation to fork I ended up with my own Webduino project on GitHub. Feel free to look at the code, to fork, clone, whatever (MIT license), and to let me know what you think! (Oh, and I gave the readme some TLC and also added a keywords.txt file for syntax highlighting.)

Update: I started to write a “beautiful” API documentation

I found an Arduino Uno under the X-mas tree:

I’m still waiting for my Ethernet Shield to ship. In the meantime I wanted to get started with some of the “simple” stuff like controlling single LEDs, triggering events using pushbuttons etc. It came in handy I still had my 1980′s “Kosmos electronic X3000″ workshop kit around, which I used to experiment with when I was a teenage nerd:

I guess I’m still a nerd: My heart jumped a bit when I found out they seem to still sell these things.

Here’s what they look like in combination:

You and I know that talking about new ideas prematurely is the best way to kill them. Anyhow you should expect some Arduino related posts over the next year or so…

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.

Since the upgrade to version 3.2.2 Nagios does not update the host alias macro when the configuration is reloaded. Macros are the variables used in commands, such as notification commands, i.e. the information you receive via E-mail when there is a problem with your hosts or services.

As long as you don’t change your host alias information you will never notice. I did change it and I found myself scratching my head for some time, especially since the same information does get updated in the web interface.

I found a greater number of forum discussions relating to this, but none seemed to offer a practical solution for larger scale environments.

After some pondering I came up with these lines:

service nagios stop
cp /usr/local/nagios/var/retention.dat /usr/local/nagios/var/retention.bak
grep -v ^alias /usr/local/nagios/var/retention.bak > /usr/local/nagios/var/retention.dat
service nagios start

They do the trick in my installations.

Update: Here’s a brief summary of the error and what the script does to work around it.

When Nagios parses the configuration and finds a new host it loads the alias field into memory. When Nagios reloads the configuration, the alias information that is already in memory does not get updated. When Nagios stops (or before reloading the configuration) the alias information in memory is dumped to the retention.dat file. When Nagios isn’t running and you start the service, it doesn’t load the alias information from the configuration files but from retention.dat, unless that information is not present in the file. So my solution does the following:

1. Stop Nagios
2. Make a backup copy of the retention.dat file (Note: I’m copying the file instead of renaming it to make sure that it will still have the same owner/group and permissions when I write to the original file in the next step)
3. Strip all lines starting with “alias” from the backup file and overwrite the original retention.dat file with this data
4. Start Nagios

You may have to tweak the file location for the retention.dat and backup files. You may also need to change the commands that stop and start the Nagios deamon.

The next version 1.1 of my Open Graph Pro WordPress Plugin will feature an API (a public method and two filter hooks) that can be utilized by theme and plugin developers who would like to add “Like” buttons to their blogs. The API also allows you to add Custom Object Types.

If you want to test-run the API go to the Open Graph Pro download page and grab the Development Version. The API is not going to change anymore. The code is also pretty much final. I’m merely working on some final UI touches and i18n/L10n of the plugin.

Code snippets for adding “Like” buttons or using Custom Object Types are part of the API documentation.