Barking Iguana

My Dot Files: Dot Aliases

2010-07-07T11:14:24Z

This is the first part of a series in which I'll document the various dotfiles I use to support my work, making it easier and more enjoyable.

I use Git and Rails every day at work. To stop my fingers wearing down I've created short aliases for the most common tasks I need to do.

Stick these in ~/.aliases.

# ~/.aliases
# Record how much I've used various Git commands:
#   http://github.com/icefox/git-achievements
alias git="git-achievements"

# Working with Git
alias g='git'
alias gs='git status'
alias gc='git commit'
alias gca='git commit -a'
alias ga='git add'
alias gco='git checkout'
alias gb='git branch'
alias gm='git merge'
alias gd="git diff"

# Working with Rails
alias s='script/server'
alias c='script/console'
alias m='rake db:migrate'
alias r='rake'

# Open the current directory in TextMate
alias e='mate .'

# Serve the contents of the current directory over HTTP
alias serve="ruby -rwebrick -e\"s = WEBrick::HTTPServer.new(:Port => 3000, :DocumentRoot => Dir.pwd); trap('INT') { s.shutdown }; s.start\""

Now source the aliases file from your ~/.profile to use them.

# ~/.profile
for I in aliases; do
  [ -f ~/.$I ] && . ~/.$I
done

An updated command prompt

2010-04-12T09:16:50Z

It's been a while since I added the current Git branch to my command prompt to better aid my development efforts. Since then I've started working with several versions of Ruby and find myself working more frequently in situations where the exit status of the last command is a useful thing to know. I've updated my prompt to look like this:

To get this I declare $PS1 like this:

# Show the exit code of the last command.
# Idea stolen from @mathie.
function last_exit_code() {
  local code=$?
  if [ $code = 0 ]; then
    printf "$1" $code
  else
    printf "$2" $code
  fi
  return $code
}

# I only want to see the interpreter in the output if I'm not using MRI.
function ruby_version() {
  local i=$(/Users/craig/.rvm/bin/rvm-prompt i)
  case $i in
    ruby) printf "$1" $(/Users/craig/.rvm/bin/rvm-prompt $2) ;;
    *)    printf "$1" $(/Users/craig/.rvm/bin/rvm-prompt $3) ;;
  esac
}

# Show lots of info in the __git_ps1 output.
# Thanks for the info @mathie.
export GIT_PS1_SHOWDIRTYSTATE="true"
export GIT_PS1_SHOWSTASHSTATE="true"
export GIT_PS1_SHOWUNTRACKEDFILES="true"

export PS1='\[\033[01;32m\]\u@\h\[\033[00m\] $(last_exit_code "\[\033[1;32m\]%s\[\033[00m\]" "\[\033[01;31m\]%s\[\033[00m\]") $(ruby_version "\[\033[01;36m\]%s\[\033[00m\]" "v p" "i v p") \[\033[01;34m\]\W\[\033[00m\]$(__git_ps1 "\[\033[01;33m\](%s)\[\033[00m\]")\$ '

A one-line web server in Ruby

2010-04-11T16:58:56Z

Prodded by a tweet, here's how to serve a directory in one line of Ruby:

ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port => 3000, :DocumentRoot => Dir.pwd).start'

Handy for sharing files at a conference, for example.

Command-line EC2 with ec2-api-tools

2010-03-21T11:00:00Z

A company I've been working with hosts some of their applications on EC2. Being a software developer who has worked extensively with Linux and Unix based servers and desktops I find it quite frustrating to work with the EC2 console webpage. Here's how I set things up to work with the EC2 API from my laptop (currently a MacBook Pro).

mkdir ~/.ec2
cd ~/Downloads
curl -O -L "http://www.amazon.com/gp/redirect.html/ref=aws_rc_ec2tools?location=http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip&token=A80325AA4DAB186C80828ED5138633E3F49160D9"
unzip ec2-api-tools.zip*
cd ec2-api-tools
mv bin lib ~/.ec2/
echo 'export EC2_HOME=~/.ec2
export PATH=$PATH:$EC2_HOME/bin
export EC2_PRIVATE_KEY=`ls $EC2_HOME/pk-*.pem`
export EC2_CERT=`ls $EC2_HOME/cert-*.pem`
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home/
# I use the eu-west-1 - you may want to change this
EC2_REGION="eu-west-1"
export EC2_URL="https://${EC2_REGION}.ec2.amazonaws.com/"
export EC2_KEYPAIR_NAME="aws-`whoami`"' > ~/.ec2/env
echo '[ -f ~/.ec2/env ] && . ~/.ec2/env' >> ~/.profile
ec2-add-keypair aws-`whoami` > ~/.ec2/aws-`whoami`
chmod 0600 ~/.ec2/aws-`whoami`

Now download the X.509 private key and certificate from the Security Identifiers page of your AWS account and save them to ~/.ec2/ - leave the names as they are with the big messy jumble of letters in them.

That should be it. You're setup. Try asking for a description of all the machine images owned by Amazon to see if it worked:

ec2-describe-images -o amazon

The output should be a huge list that looks something like this:

IMAGE	ami-13042f67	amazon/fedora-8-i386-v1.14-std	amazon	available	public		i386	machine	aki-61022915	ari-63022917		ebs
BLOCKDEVICEMAPPING	/dev/sda1		snap-34739d5d	15	
IMAGE	ami-1d042f69	amazon/fedora-8-x86_64-v1.14-std	amazon	available	public		x86_64	machine	aki-6d022919	ari-37022943		ebs
BLOCKDEVICEMAPPING	/dev/sda1		snap-08739d61	15

All the ec2 commands start with 'ec2-'. To see them all you can do this: ls ~/.ec2/ec2-*

If you get deprecation notices from Xalan don't worry about it, everything will still work.

[Deprecated] Xalan: org.apache.xml.res.XMLErrorResources_en_US

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.

I've turned this into a bash shell script. Download it and make it executable. It takes one argument, the name of the local branch you want to push to Subversion:

./svn-push development/avoid-the-wombat-widgets

This assumes that when you cloned your repository from Subversion you told Git where to find our Subversion branches. I'm not sure what'll happen if you didn't do that. Caveat emptor and all that.

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.