Barking Iguana

Creating a new Subversion branch from an existing local Git branch

2010-03-03T17:31:02Z

When I'm coding I frequently have to work with Subversion repositories. I'm a Git user, so I use git-svn for this. Usually I do my work in local branches, using a fairly regular Git workflow, then checkout the integration branch, merge in my changes and git svn dcommit to push the code to Subversion.

Sometimes however I need to share changes that I've made on an existing local branch in my Git repository with a Subversion user before they're ready to integrate back into the mainline. It takes me a while to hunt down and work out exactly what to do whenever I want to do this, so here are the instructions for my future reference. Hopefully they help you too.

git checkout master
git svn branch <new_svn_branch_name>
git svn fetch
git branch -r # make sure <new_svn_branch_name> exists
git checkout -b tmp/svn-rebase-target <new_svn_branch_name>
git rebase --onto tmp/svn-rebase-target master <existing_git_branch_name>
# That should have checked out <existing_git_branch_name>.
git svn dcommit -n # This should say it'll commit to <new_svn_branch_name>.
git branch -D tmp/svn-rebase-target # clean up the temporary branch.
git svn dcommit

This time mainly I used comments on a blog post that asked how to do this. Thanks Björn Steinbrink and Cameron.

Installing the MySQL gem on OSX 10.6 (Snow Leopard) with MacPorts MySQL5

2010-03-02T11:04:21Z

Took a while to work this command out. Hopefully it can save someone else some time.

sudo port install mysql5-server
sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql--config=/opt/local/bin/mysql_config5

London Tech Meetups

2010-02-23T12:20:11Z

It can be quite hard to find groups in your area that share your interest, and even if you find out that they exist it can be pretty hard to work out when the next meetup is. Some of the meetup groups have frankly mental scheduling rules.

John Sutherland has solved this problem for Edinburgh tech community meetups by listing when various groups meet and who they'd be of interest to. After asking and receiving permission I've duplicated this idea for London tech community meetups.

If your meetup isn't listed and you'd like it to be, email me at craig@barkingiguana.com and let me know.

Decoupling Nagios Host and Service check events for fun and profit

2010-02-17T17:49:37Z

Nagios does a pretty good job of watching over my services and hosts, but I want to do a little more with the events it creates – when it checks a service and something is wrong, or when something recovers. In particular I want to give my clients the ability to select at an incredibly high resolution what sort of notifications they get, for what services, how often, and at what level of technical detail. Coupled with this I want to up-sell the services that Xeriom offers – if the disk is getting full or the transfer quota is being consumed so fast that it wont last until the end of the month I want to make it easy to upgrade plans. I’d also like to be able to try out some fun things – iPhone push notifications, SMS gateways, audible alarms, whatever – without worrying that I might destroy Nagios and bring my monitoring setup to its knees.

Message queues are a great way of decoupling systems, moving risk and complexity elsewhere. Nagios shouldn’t have to worry about all of the stuff I want to build around the monitoring system, it should focus just on the core features that I like it for: monitoring my hosts and services.

Luckily, I already have ActiveMQ running for other tasks, writing a STOMP client using SMQueue is pretty trivial, and Nagios has several ways to execute external commands when events happen including the global host and service event handlers. All I need is a command to have Nagios run that’ll accept a bunch of information from Nagios and stick it on the message queue.

Here’s what I came up with:

require 'rubygems'
require 'smqueue'
require 'json'

message = {
  :hostname => ARGV[2],
  :service => ARGV[3],
  :state => ARGV[4],
  :state_type => ARGV[5],
  :state_time => ARGV[6].to_i,
  :attempt => ARGV[7].to_i,
  :max_attempts => ARGV[8].to_i,
  :time_t => Time.now.to_i
}

configuration = {
  :host => ARGV[0],
  :name => ARGV[1],
  :adapter => :StompAdapter
}

broadcast = SMQueue(configuration)
broadcast.put message.to_json, "content-type" => "application/json"

You’ll need Ruby and RubyGems installed. Once you have those, install the script like this:

sudo su -
gem sources -a http://gems.github.com/
gem install seanohalpin-smqueue json --no-ri --no-rdoc
cd /usr/bin
wget http://gist.github.com/raw/306765/2a3e9cbade88b4c6dd430e108bc8a28f95047462/notify-service-by-stomp.rb
chmod +x notify-service-by-stomp.rb

Once it's installed tell Nagios to use it by adding this to your Nagios configuration:

define command {
  command_name notify-service-by-stomp
  command_line /usr/bin/notify-service-by-stomp.rb mq.example.com /topic/foo.bar.baz.quux $HOSTADDRESS$ "$SERVICEDESC$" $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEDURATIONSEC$ $SERVICEATTEMPT$ $MAXSERVICEATTEMPTS$
}

global_service_event_handler=notify-service-by-stomp

Change mq.example.com to be the hostname of your message broker, and /topic/foo.bar.baz.quux to be the topic or queue that you’d like notifications to be sent to. Restart Nagios and you should start receiving notifications on that queue or topic.

If you don’t receive notifications form Nagios very often then a simple way to test that this is working is to attach stompcat – a cat type tool that uses STOMP as a source – to the topic or queue, then send a few test notifications to the same queue by manually running the same command that Nagios would.

Here’s a simple stompcat tool in case you don’t have one handy:

#! /usr/bin/env ruby

# Run me like this:
#
#   ./stompcat.rb mq.example.com /topic/foo.bar.baz.quux
#

require 'rubygems'
require 'smqueue'

configuration = {
  :host => ARGV[0],
  :name => ARGV[1],
  :adapter => :StompAdapter
}

source = SMQueue(configuration)
source.get do |m|
  payload = m.body
  puts ">>> #{payload}"
end

Here’s how to send notifications to the queue or topic:

/usr/bin/notify-service-by-stomp.rb mq.example.com \
  /topic/foo.bar.baz.quux service-host.example.com "SERVICE NAME" \
  WARNING HARD 86492 6 6

If it’s working you should get an entry like this showing up where you’re running the stompcat:

{
  "time_t":1266427384,
  "state":"WARNING",
  "state_type":"HARD",
  "state_time":86492,
  "attempt":6,
  "hostname":"service-host.example.com",
  "max_attempts":6,
  "service":"SERVICE NAME"
}

You should be able to change the stompcat example to perform more complex and interesting actions – looking up clients in a database, sending text messages if an account has enough credit, whatever you fancy. If you come up with something fun, please let me know!

Keeping the software on your Ubuntu server up-to-date

2010-02-11T23:15:49Z

New exploits are found just about every day in software both old and new. To combat this, software vendors release security updates which the Ubuntu team package up and use to release new, more secure packages of the software that you install.

It’s very hard to provide software updates for all versions of all software packages ever built for a platform like Ubuntu so the Ubuntu team produce releases of Ubuntu Linux which they offer to support for a known period of time. These support periods are currently one of two lengths depending on the release of Ubuntu you use. Long Term Support (usually noted by including “LTS” in the name) releases for the server are supported for 5 years after the release date. Regular releases are supported for 18 months. Beyond these windows support for the release is dropped and you won’t be able to upgrade or update any packages without a lot of work, so it’s important to upgrade before support for your release is stopped.

The current commonly used releases, their release date, and their end of support window are as follows:

Version	Name	Release Date	Support Ends
10.04 [LTS]	Lucid Lynx	April 2010	April 2015
9.10	Karmic Koala	October 29 2009	April 2011
9.04	Jaunty Jackalope	April 23 2009	October 2010
8.10	Intrepid Ibex	October 30 2008	April 2010
8.04.4 [LTS]	Hardy Heron	January 28 2010	April 2013
8.04.3 [LTS]	“	July 16 2009	April 2013
8.04.2 [LTS]	“	January 22 2009	April 2013
8.04.1 [LTS]	“	July 3 2008	April 2013
8.04 [LTS]	“	April 24 2008	April 2013
7.10	Gutsy Gibbon	October 18 2007	April 2009
7.04	Feisty Fawn	April 19 2007	October 2008
6.10	Edgy Eft	October 26 2006	April 2008
6.06.2 [LTS]	Dapper Drake	January 21 2008	June 2011
6.06.1 [LTS]	“	August 10 2006	June 2011
6.06 [LTS]	“	June 1 2006	June 2011
5.10	Breezy Badger	October 12 2005	April 2007
5.04	Hoary Hedgehog	April 8 2005	October 2006
4.10	Warty Warthog	October 26 2004	April 2006

Currently supported are 6.06, 8.04, 8.10, 9.04 and 9.10. Ubuntu 10.04 will be released in April.

Your responsibilities

There are two things that you as a server operator need to know how to do to stay up-to-date with the software on your server and make sure that it’s always supported. One is upgrading installed packages, and one is upgrading to the next release of Ubuntu. I’ll cover them both one at a time, but first we’ll do a little setup to make sure that both operations are nice and fast.

Using a package mirror

A very time consuming part of the update and upgrade process is downloading a large quantity of files from the servers that host the latest software packages. To make this faster Xeriom Networks provide a mirror of the software packages for 8.04, 8.10, 9.04 and 9.10. If you’re not hosted on Xeriom Networks (why not?) you should ask your current provider if they supply a package mirror for your release. If they don’t you should skip this section and hope that your connection is fast enough to cope.

Using the package mirror is simple and requires you to edit just one file. A nice simple editor is nano. Install it by connecting to your server by SSH and using sudo and apt-get to install it:

sudo apt-get install nano --yes

The contents of the file is determined by which release of Ubuntu you are running. Find out which release you run by typing this:

cat /etc/lsb-release

You should then match your release up with the appropriate box on this Wiki page: http://wiki.xeriom.net/w/XeriomUbuntuPackagesService

Copy the text from within only the box that’s matched with your release. Now we can edit the file to add the local package server:

sudo nano -w /etc/apt/sources.list

Delete all the existing lines in that file and replace them with the text you copied from the Wiki page. Now press CTRL and X and say that you do want to save the file.

Now we tell Ubuntu to refresh the list of software packages so it knows what’s available on the local package mirror:

sudo apt-get update

Congratulations, you’re now using the Xeriom Ubuntu package mirror.

Upgrading installed software

Keeping your software up-to-date is an important part of keeping your server secure but since these new packages may break existing functionality it’s best not to install them automatically. You should sit down and do this yourself, only applying the updates if they’re appropriate and necessary.

To update the software installed on your server you use a set of tools called apt – and specifically you use apt-get.

To make sure you get the latest updates you should first update your servers package database:

sudo apt-get update

Then you should ask it to upgrade your existing packages:

sudo apt-get upgrade

This will calculate everything that needs upgrading, show you a list of those packages and ask you if you want to continue. Most of the time this command will run smoothly and you’ll get the latest version of the software on your server, but you should check the list of packages that it will upgrade and be sure that you know what’s going to change before you let it complete.

Upgrading to the next release

Upgrading Ubuntu is a slightly more time consuming process with a small increase in risk because of the huge number of packages that will be upgraded. It will usually also require you to reboot your server since the kernel is likely to be upgraded so you should plan for a little downtime.

To upgrade you should use a package called update-manager-core. If this is your first time upgrading your Ubuntu release you may need to install it:

sudo apt-get install update-manager-core

Next configure it to target releases based on your preferred strategy. This is either lts, normal or never.

sudo nano -w /etc/update-manager/release-upgrades

Change the line that starts “Prompt=” to be whichever strategy you choose. For example, if I choose the lts strategy which should give me 5 years of support for each release I update to I’d enter “Prompt=lts” here. Now press CTRL and X and tell it that you want to save the file if it asks.

Now, before you upgrade, read the release notes for the version of Ubuntu that you’re going to upgrade to and make sure you understand all the current issues and caveats surrounding it.

Once you’re happy that you understand what you’re doing and you’ve scheduled a time to upgrade your server you can start the upgrade:

sudo do-release-upgrade

This will calculate all the packages that will be upgraded and ask you if you want to continue. Don’t just say yes – read the list of packages and make sure you understand what upgrading them means to your setup.

If it all goes pear-shaped

Sometimes things get messed up. Maybe the release wasn’t tested enough (rare these days) or perhaps the new release doesn’t support the same software as the one you upgraded from and you need that to run. If this ever happens we can create you a brand new image of the release you need as long as it’s still supported. Of course, your data won’t be on the new release so make sure your backups are up-to-date!

The correct OID for system uptime

2010-02-11T13:54:07Z

I use SNMP to track system uptime so I know when my hosts have recently rebooted, but I keep making a mistake when picking which OID to monitor and using sysUpTime.0 which is wrong I should be using hrSystem.hrSystemUptime.0.

sysUpTime.0: Timeticks (0.01s) since the snmpd started.
hrSystem.hrSystemUptime.0: Timeticks since the hardware started.

Getting started with node.js

2010-01-21T19:15:00Z

Tonight I'm giving a talk to the London Javascript User Group where I'm introducing node.js.

My slides are available here: http://barkingiguana.com/~craig/talks/2010/javascript-london/getting-started-with-node-js. There's a script if you print it out or there's a video on Vimeo if you'd like to watch it.

If you have any feedback please feel free to leave a comment.

Telnet 101

2009-12-10T18:13:21Z

Telnet has been around since before the dawn of (Unix) time but surprisingly few people know how to use this extremely useful tool to track down problems with many popular services. A few seconds with Telnet can save hours of frustrating searching, trial and error, and screaming at the computer.

Telnet can be used to simulate many plain-text protocols. I've used it to talk to MySQL, Memcached and Postfix. Here I'll show how to use it to test that an HTTP daemon can serve content over HTTP/1.1.

What is HTTP?

Before we can use telnet to simulate HTTP we need to know more about HTTP - what is it and how it works.

HTTP/1.1 - HyperText Transfer Protocol - is a plain-text protocol defined in RFC2616. It's used for a great many things, but the most visible one for most people is as a transport mechanism for web pages.

When you request a webpage a few special operations are performed (which I'll gloss over because they're beyond the scope of this article). After those have completed your web browser connects to the web server and sends it a requests for a page. A typical request for a web page looks something like this:

GET / HTTP/1.1
Host: example.com

The format of the request is:

[HTTPMETHOD] [PATH TO WEBPAGE] HTTP/1.1
Host: [SERVERNAME]
[BLANK LINE]

The server responds with something similar except after the blank line there's usually the page you requested.

HTTP/1.1 200 OK
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
ETag: "b300b4-1b6-4059a80bfd280"
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Connection: close     
Date: Thu, 10 Dec 2009 10:37:33 GMT
Age: 7114   
Content-Length: 438

<HTML>
<HEAD>
  <TITLE>Example Web Page</TITLE>
</HEAD> 
<body>  
<p>You have reached this web page by typing "example.com",
"example.net",
  or "example.org" into your web browser.</p>
<p>These domain names are reserved for use in documentation and are not available 
  for registration. See <a href="http://www.rfc-editor.org/rfc/rfc2606.txt">RFC 
  2606</a>, Section 3.</p>
</BODY>
</HTML>

The format of the response is:

HTTP/1.1 [RESPONSE STATUS]
[RESPONSE HEADERS]
[BLANK LINE]
[REQUESTED WEBPAGE]

There's a lot more to the HTTP protocol, but it's all document in rather a lot of (rather dry) detail in RFC2616. Mostly you can just skim the RFC for the parts you're interested in.

Simulated Awesome

Okay, so now we've got an idea how HTTP can be used to request a webpage. How do we go from that to using telnet to show it works?

The telnet manpage says that the telnet command can take arguments for host and port. In the above example we were requesting a page from example.com so that's the host we'll use. Typically HTTP is served on port 80, and this is true of example.com so we'll use that as the port.

telnet example.com 80

With that we're connected to the HTTP service - the web server - on example.com. You'll see output something like this as connects:

Trying 192.0.32.10...
Connected to example.com.
Escape character is '^]'.

Once connected you'll be left with your cursor on a blank line. This is where you can start pretending to be a web browser.

Type in the GET request shown in the "What is HTTP?" section above (including the blank line at the end). After a short delay you should get back the example.com webpage.

How is this useful?

Requesting a webpage by hand can quickly expose several common problems.

Misconfigured firewalls mean telnet won't connect.
The status code returned can tell you a lot about what the server did with your request. RFC2616 contains a list of HTTP status codes and their meaning.
You avoid problems which may be caused by your browser caching the old version of files you request.
You can easily check all the headers that the server sends back.
By adding headers such as Accept-Encoding you can check that your assets are being served gzipped when it is requested.

Telnet isn't limited to checking just HTTP either. SMTP, IMAP, POP and many others can be simulated using telnet. It's not a silver bullet, but it's a very useful tool.

Simulating slow or laggy network connections in OS X

2009-12-04T17:55:11Z

A client recently said that their site was loading slowly from remote sites. We got the specification of the network connection used, but I always forget how to do bandwidth limiting and latency simulation on OS X. This is a note for myself so I don't have to go searching again.

Configure a pipe that has the appropriate bandwidth limit and delay.

sudo ipfw pipe 1 config bw 16Kbit/s delay 350ms

Attach it to all traffic going to or from port 80.

sudo ipfw add 1 pipe 1 src-port 80
sudo ipfw add 2 pipe 1 dst-port 80

Now traffic coming from or going to port 80 anywhere is limited by the pipe that you specified. Do your testing and once you get frustrated with slow access to the web remove the rules like so:

sudo ipfw delete 1
sudo ipfw delete 2

Returning explicitly is slower

2009-11-11T08:32:17Z

My main concern about returning explicitly is readability. It's a very subjective thing, but in general whenever I see an unnecessary return statement my internal WTF counter increments.

Less subjective though, it has been pointed out that returning explicitly is slower.

Benchmarking in Ruby is easy. Here's how:

require 'benchmark'

def explicit
  return "TEST"
end

def implicit
  "TEST"
end

n = 100_000_000
Benchmark.bmbm do |x|
  x.report("Explicit return") { n.times { explicit } }
  x.report("Implicit return") { n.times { implicit } }
end

And here are the results of this particular benchmark:

Rehearsal ---------------------------------------------------
Explicit return  50.380000   0.210000  50.590000 ( 51.000510)
Implicit return  36.200000   0.100000  36.300000 ( 36.454038)
----------------------------------------- total: 86.890000sec

                      user     system      total        real
Explicit return  47.650000   0.070000  47.720000 ( 47.744167)
Implicit return  35.900000   0.070000  35.970000 ( 35.985493)

This shows that while returning explicitly is slower, like the to_proc hack it's not slow enough to matter. You need to return a huge number of times to see any significant difference.

Does this change my mind? No. Returning explicitly is still ugly.

Update: The above benchmark was run on Ruby 1.8.6. Tom Ward has provided similar benchmarks for Ruby 1.8.7, 1.9 and jRuby 1.1.6 (using n = 10,000,000) which show that the cost of explicitly returning on these platforms in negligible. Still ugly though.