This of course led to the idea of coding up a driver for a dishwasher. clusto do-my-dishes FTW!

Inside was nothing but six machine-cut blank white sticky labels on a yellow backing:

Does anybody have any clue what this is all about?

There are some heavier-weight options we could use to accomplish this sort of thing, but we aren’t yet ready to move to a more complicated tool chain for this sort of thing. I was pretty sure we could accomplish this with git hooks. I was right:

#!/usr/bin/env python
 
import os
import re
 
from sys import argv, exit
from subprocess import Popen, PIPE
 
 
def blank(line):
    regex = re.compile('^\s*$')
    if regex.search(line):
        return True
    else:
        return False
 
 
def uncomment(line):
    return line.partition('#')[0]
 
 
def cleanup(lines):
    # Remove full-line comments.
    lines = [line for line in lines if not line.startswith('#')]
    # Remove blank lines.
    lines = [line for line in lines if not blank(line)]
    # Remove comments from line ends.
    lines = [uncomment(line) for line in lines]
 
    return lines
 
def parse_acl():
    try:
        fh = open('acl')
    except IOError:
        print "Could not open ACL file. Exiting."
        exit(1)
 
    # Read and close ACL file.
    lines = fh.readlines()
    fh.close()
    lines = cleanup(lines)
 
    # The ACL lines are whitespace separated. The first field is the
    # username, the second field is a regex describing the refs the
    # user is allowed to update.
    access = {}
    for line in lines:
        record = line.split()
        r_user = record[0]
        r_ref = record[1]
        if r_user in access:
            access[r_user] = access[r_user] + [r_ref]
        else:
            access[r_user] = [r_ref]
 
    return access
 
 
def authorize(refname='', user='', access={}):
    if not user in access:
        return False
 
    allowed_refs = access[user]
    for a_ref in allowed_refs:
        regex = re.compile("^%s$" % a_ref)
        if regex.search(refname):
            return True
 
    return False
 
 
def parse_git_config(config_entry):
    output = Popen(["git", "config", "--bool", config_entry], stdout=PIPE).communicate()[0]
    if output.strip() == 'true':
        return True
    else:
        return False
 
 
def parse_branch_tracking():
    try:
        fh = open('branch_tracking')
    except IOError:
        print "Could not open branch tracking file. Exiting."
        exit(1)
 
    # Read and close branch tracking file.
    lines = fh.readlines()
    fh.close()
    lines = cleanup(lines)
 
    # Branch tracking lines are whitespace separated. The first field
    # is the branch that must track the branch specified in the second
    # field.
    tracking = {}
    for line in lines:
        record = line.split()
        r_branch = record[0]
        r_track = record[1]
        tracking[r_branch] = r_track
 
    return tracking
 
 
def get_tracked_branch(refname):
    track = parse_branch_tracking()
    try:
        return track[refname]
    except KeyError:
        return None
 
 
def get_missing_refs(ref, base_ref):
    # git rev-list gives us the commits reachable from base_ref that
    # are NOT reachable from ref.
    output = Popen(["git", "rev-list", '%s..%s' % (ref, base_ref)], stdout=PIPE).communicate()[0]
    return output.splitlines()
 
 
def main():
    # The args are passed in by git.
    refname = argv[1]
    old_rev = argv[2]
    new_rev = argv[3]
    user = os.environ['USER']
 
    # Check if 'push acl' is enabled.
    push_acl = parse_git_config('hooks.pushacl')
 
    if push_acl:
        # Check the user's authorization to update these git refs.
        access = parse_acl()
        if not authorize(refname=refname, user=user, access=access):
            print "Could not update %s, permission denied by ACL." % refname
            exit(1)
 
    # Check if 'forced branch tracking' is enabled.
    force_tracking = parse_git_config('hooks.forcebranchtracking')
 
    if force_tracking:
        tbranch = get_tracked_branch(refname)
        if tbranch:
            # Get the refs that are reachable from our tracked branch
            # but NOT reachable from our new revision.
            missed_refs = get_missing_refs(new_rev, tbranch)
 
            if len(missed_refs) > 0:
                print "Could not update %s, you need to merge %s." % (refname, tbranch)
                exit(1)
 
 
if __name__ == '__main__':
    main()

This implements two git config options:

git config --bool hooks.pushacl
git config --bool hooks.forcebranchtracking

They are both meant to be set on a bare git repository (git init --bare). The first option causes the update hook to look for a file called ‘acl’ in the root of the bare repo. Here is the ACL file I’m using for our puppet configs right now:

plathrop refs/.*/.*
ron refs/.*/.*
synack refs/.*/.*
wfrancis refs/.*/.*
kad refs/.*/.*
mike refs/.*/.*
rcoli refs/heads/(development|(rcoli/.*)){1}
goffinet refs/heads/experimental
rich refs/heads/experimental
kelvin refs/heads/experimental

The entries are regular expressions matching git “refs”. So, I have full access, rcoli can push to the development branch or any branch starting with “rcoli/” (but cannot create tags), and goffinet and his fellow developers can push to the experimental branch (but cannot create tags).

The second option is probably badly named. It looks for a file called branch_tracking in the root of the bare repo. That file looks like this:

refs/heads/experimental refs/heads/development

When hooks.forcebranchtracking is set, the hook will enforce that the branch on the left contain all the commits from the branch on the right before it will accept any updates. Essentially this forces the experimental branch to track the development branch, and requires
regular runs of git pull to stay in sync.

The packaging process was relatively easy. Check out the results on GitHub.

Enjoy!

Never has that been more clear to me than the last couple weeks. Aly has started work again, which means Connor needs to learn to take milk from a bottle, so that I can feed him while mom is seeing patients. We’ve got plenty of milk stored up from Connor’s NICU days, and he’s fed from a bottle before; in fact, they wouldn’t release him from the NICU until he could take all of his feedings from a bottle. My feelings on this policy aside, the hope was that his familiarity with it would make things easier for us.

Maybe it would have, if we had kept it up. But in the four months since he’s been home from the hospital, he hasn’t touched a bottle (or a pacifier even, except to spit it out). So last week when we started trying bottle feeding, Connor let me know in no uncertain terms: “Boobs only, dad!”

This has been one of the singularly most frustrating things I’ve encountered so far. Every session ends with a cranky baby covered in milk and a frazzled dad who feels like a complete failure. I know he knows what to do, he makes all the right motions and signals like he does when breastfeeding, but he’s not interested in actually sucking on the damn bottle. Tonight we tried again, and I came away defeated, with a pounding headache to boot (from the screaming).

If at first you don’t succeed…

Thing is, I kept meaning to write more, and life kept getting in the way. After thinking about it more, it seems that the solution is to not restrict myself to just writing about work, and allow myself to write about life as it happens.

Let’s give it a go…

(UPDATE): Permalinks finally fixed.

I used to believe this was an easy problem. Pick a theme, like Star Wars Characters or Constellations, and then name machines based on that theme: “chewbacca.tertiusfamily.net” for example. Use DNS CNAMEs to point your “functional” names (webapp1, or db1 or whatever) at the theme name and you’re off. Then I started working for Digg.

Digg’s infrastructure is massively horizontally-scaled. That means clusters, which means *lots* of individual nodes. No matter what “theme” you choose, you run out of names awfully fast. Not only that, but when you start building out a service-oriented architecture, you stop wanting to deal with individual nodes and start thinking in terms of clusters which provide services instead.

At the Puppet training I went to in Portland, we discussed the issue and I found out that there are two camps (well, as many camps as there are sysadmins, but it can be broken down into two camps). On the one side are those who want to put meta-data into their hostnames. On the other are those who think that hostnames should be as arbitrary as possible. There are strong arguments either way.

I think I come down firmly on the side of arbitrary hostnames. I’m coming to believe that, since IP addresses are necessarily unique, they should be the only unique identifier for an individual node. But I can’t come up with a solid argument as to why that is the best way.

What do you do about naming?

If you are like me and prefer to use the libraries that are already installed, just do this:

1. If you haven’t already, install XCode.
2. Download python-ldap

and extract it.

3. Edit setup.cfg. The relevant lines are below:

   library_dirs = /Developer/SDKs/MacOSX10.5.sdk/usr/lib/
   include_dirs = /Developer/SDKs/MacOSX10.5.sdk/usr/include/ /Developer/SDKs/MacOSX10.5.sdk/usr/include/sasl

4. sudo python setup.py install

That’s all!

]]> http://plathrop.tertiusfamily.net/blog/2008/07/07/getting-python-ldap-installed-on-os-x/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/06/23/my-first-conference/ http://plathrop.tertiusfamily.net/blog/2008/06/23/my-first-conference/#comments Mon, 23 Jun 2008 19:58:52 +0000 plathrop http://plathrop.tertiusfamily.net/blog/?p=28 I’m at Velocity 2008 right now. So far I’ve learned several things:
1. Twitter can’t handle a conference.
2. Sun might succeed in its attempt to restore its relevance.
3. SSDs are going to be abother layer in server memory, between disks and RAM.
4. Whenever a member of the Ops team is unavailable, something breaks.
5. Con food isn’t remarkable, in either positive or negative ways.
6. Arrive early to talks so you can snag a spot on the power strip.
7. I FAIL at socialization.

At least I managed to score some Puppet schwag (whoever made these shirts has a different definition of XXL than me…) and managed to track down Luke Kanies and Andrew Shafer of Reductive Labs to say “Hi.” Haven’t socialized much with them; they look like they’re working.

About to watch a talk on measuring performance; a topic I’ve always had big questions about; hopefully I’ll learn something good. I’m kinda regretting my decision to sit towards the front, though.

]]> http://plathrop.tertiusfamily.net/blog/2008/06/23/my-first-conference/feed/ 1 http://plathrop.tertiusfamily.net/blog/2008/06/18/crickets/ http://plathrop.tertiusfamily.net/blog/2008/06/18/crickets/#comments Wed, 18 Jun 2008 17:17:17 +0000 plathrop http://plathrop.tertiusfamily.net/blog/?p=27 It’s quiet in here. Life has been hectic and I’m somewhat confused as to what I’m allowed to say without getting in trouble at work.

Hopefully I’ll have some more Puppet content soon.

]]> http://plathrop.tertiusfamily.net/blog/2008/06/18/crickets/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/04/18/creating-puppet-modules/ http://plathrop.tertiusfamily.net/blog/2008/04/18/creating-puppet-modules/#comments Fri, 18 Apr 2008 23:56:09 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/04/18/creating-puppet-modules/ In Puppet parlance, a module is a collection of manifests (including classes and definitions), templates, and files which, taken together, describe a recipe for configuring something via Puppet. Puppet has a number of facilities which make modules incredibly useful and labor-saving.

Modules have a standard internal organization which is described in detail on the ModuleOrganisation wiki page. A trivial module can be as simple as a manifests directory containing only a single manifest: init.pp. However, as modules grow more complex, you’ll want to break up your manifests and add templates in a templates directory, files in a files directory, and a README file which explains how to make use of your module.

I’m in the process of polishing up several modules, including LDAP, Kerberos, memcached, and ntp modules. In some ways, I’m duplicating work; several implementations of these modules are available. However, Puppet modules are still evolving, and I wanted to try my hand at module writing. Also, the existing modules did not work quite right for us. Some of them fail to properly isolate site-specific information from the recipe, for example. Others had complex interdependencies that I didn’t like.

There are several techniques that I think will evolve as “best practices” for Puppet module design. These are:

1. Keep site-specific customization out of your modules.
2. Your module should implement a minimal working configuration “out of the box”.
3. Use variables to make it easier to patch your module for use on other platforms.
4. Break a module up into sensible classes and defined types to make it easy to customize via inheritance.
5. Use init.pp for module-wide variables and/or common functionality, but break all other classes/defines into separate files.

Let’s take a look at each of these in detail:

Keep site-specific customization out of your modules.

Modules are, at heart, meant to be shared with others. Try to write your modules so they are as site-neutral as they can be. Use variables that can be set in a higher-level scope like site.pp to control how the module works, instead of baking your site’s settings into the module. For example, in my LDAP module I do this:

class ldap::common {
  case $ldap_base_dn {
    "": { $ldap_base_dn = "dc=example,dc=com"
      warning("ldap_base_dn not set, using default $ldap_base_dn")
    }
  }
 
  case $ldap_admin_dn {
    "": { $ldap_admin_dn = "cn=admin,$ldap_base_dn"
      warning("ldap_admin_dn not set, using default $ldap_admin_dn")
    }
  }
 
  case $ldap_admin_password {
    "": { fail("ldap_admin_password not set!")
    }
  }

Then, in site.pp, I set the variables appropriately:

# Site Variables
$ldap_server           = "ash001.example.com"
$ldap_admin_password   = "testing"
$ldap_base_dn          = "dc=example,dc=com"

Your module should implement a minimal working configuration “out of the box”.

This principle is also tied in with the fact that modules were meant to be shared. When someone is looking for a module, they are going to want something that works with little-to-no configuration, because this will give them confidence that the module will work once it is fully configured. Just like full-blown pieces of software, if a module doesn’t have an easy initial setup, people will get confused as to whether or not it even works. My LDAP module provides a ldap::master class which implements a very basic configuration: the slapd package is installed, a working configuration file is set up (without SSL or any of the other goodies), and the service is started. If the user sets just one variable, $ldap_admin_password in their init.pp and includes ldap::master on a node, they will be able to verify that LDAP is up and running with an example configuration. Even better, if they set the other variables, this configuration will be customized to their site with little effort on their part. It might be better to add in all the bells and whistles (SSL at a minimum), but I’m not sure yet where I stand on that.

Use variables to make it easier to patch your module for use on other platforms.

Currently, in the init.pp of my LDAP module, I set variables like this:

  $ldappackage       = "slapd"
  $ldapservice       = "slapd"
  $ldapdir           = "/etc/ldap"
  $ldaputilpackage   = "ldap-utils"
  $ldapclientpackage = "libnss-ldap"

and use them like this:

  package {
    $ldappackage:     ensure => installed;
  }
 
  file { "$ldapdir/slapd.conf":
    content => template("ldap/slapd.conf.erb"),
    require => Package[$ldappackage],
    notify  => Service["$ldapservice"],
  }
 
  service { $ldapservice:
    require   => [ Package[$ldappackage], File["$ldapdir/slapd.conf"] ],
    ensure    => running,
    enable    => true,
  }

These variables are set up for Debian now, because that is the distribution I’ve standardized on. If later I (or someone I’ve shared the module with) wants to add support for another distribution, they can set up case statements, and not have to modify the rest of the module!

  case $operatingsystem {
    debian: {
      $ldappackage       = "slapd"
      $ldapservice       = "slapd"
      $ldapdir           = "/etc/ldap"
      $ldaputilpackage   = "ldap-utils"
      $ldapclientpackage = "libnss-ldap"
    }
    centos: {
      $ldappackage       = "openldap"
      $ldapservice       = "slapd"
      $ldapdir           = "/etc/openldap"
      $ldaputilpackage   = "openldap-utils"
      $ldapclientpackage = "libnss-ldap"
    }
  }

I have not tested this, as I don’t use CentOS, so don’t use these!

Break a module up into sensible classes and defined types to make it easy to customize via inheritance.

Since you’ve pulled all the site-specific customization out of your package, and you are providing a minimal working configuration, people are going to want to do other things with your module that are appropriate to their site. If you have everything lumped into one big “ldap” class, this is going to be difficult for them. I break thinks up into ldap::common for things common to all the other classes, ldap::client for things needed to query the LDAP servers, ldap::master for the primary LDAP server, and later I’ll provide ldap::slave for replication slaves.

Use init.pp for module-wide variables and/or common functionality, but break all other classes/defines into separate files.

This is for your sanity as well as the sanity of those who might want to modify your module. I started with everything in one big init.pp file and it rapidly went out of control. Puppet does some awesome automagical lookups that you can take advantage of. For example, my ldap::master class is defined in a file called master.pp; when someone tries to load ldap::master, Puppet automatically searches for a .pp file named “master” in the “ldap” module!

So far, this is all the wisdom I have to impart on the subject. I’ll be sure to post links here when these modules are ready for prime-time.

]]> http://plathrop.tertiusfamily.net/blog/2008/04/18/creating-puppet-modules/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/03/24/ssh-tab-completion/ http://plathrop.tertiusfamily.net/blog/2008/03/24/ssh-tab-completion/#comments Mon, 24 Mar 2008 17:57:08 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/03/24/ssh-tab-completion/ This is awesome. Put the following into your ~/.bash_profile file:

complete -W "$(echo `cat ~/.ssh/known_hosts | cut -f 1 -d ' ' \
| sed -e s/,.*//g | uniq | grep -v "\["`;)" ssh

Open a new shell and type ssh tab tab. I love tab completion, don’t you?

]]> http://plathrop.tertiusfamily.net/blog/2008/03/24/ssh-tab-completion/feed/ 1 http://plathrop.tertiusfamily.net/blog/2008/03/17/freebsd-update/ http://plathrop.tertiusfamily.net/blog/2008/03/17/freebsd-update/#comments Mon, 17 Mar 2008 18:32:13 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/03/17/freebsd-update/ I just followed these instructions to update my server from FreeBSD 6.2-RELEASE to FreeBSD 7.0-RELEASE.

Aside from taking almost a day, it went flawlessly. I’m extremely impressed!

]]> http://plathrop.tertiusfamily.net/blog/2008/03/17/freebsd-update/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/03/12/virtualization-article/ http://plathrop.tertiusfamily.net/blog/2008/03/12/virtualization-article/#comments Wed, 12 Mar 2008 18:41:13 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/03/12/virtualization-article/ This article might be interesting to some of you.
]]> http://plathrop.tertiusfamily.net/blog/2008/03/12/virtualization-article/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/03/12/bash-history/ http://plathrop.tertiusfamily.net/blog/2008/03/12/bash-history/#comments Wed, 12 Mar 2008 18:35:54 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/03/12/bash-history/ Here are a couple of tips for more effective use of your Bash command history. I think the Ctrl-R trick will save me a lot of typing.

I have some articles planned, but have been busy starting my new job. Those few of you who actually read this, don’t worry – I’ll be back.

]]> http://plathrop.tertiusfamily.net/blog/2008/03/12/bash-history/feed/ 1 http://plathrop.tertiusfamily.net/blog/2008/02/23/useful-ssh-isms/ http://plathrop.tertiusfamily.net/blog/2008/02/23/useful-ssh-isms/#comments Sat, 23 Feb 2008 22:53:07 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/02/23/useful-ssh-isms/ Two useful SSH-isms
]]> http://plathrop.tertiusfamily.net/blog/2008/02/23/useful-ssh-isms/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/02/14/simple-ssh-speed-up/ http://plathrop.tertiusfamily.net/blog/2008/02/14/simple-ssh-speed-up/#comments Fri, 15 Feb 2008 00:00:35 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/02/14/simple-ssh-speed-up/ I just discovered something that is very simple but saves a significant amount of time. Specifically, the SSH ControlMaster feature, which allows you to re-use an existing SSH connection whenever you connect to a host you are already connected to.

In your ~/.ssh/config file, add:

Host *
        ControlMaster auto
        ControlPath /tmp/%r@%h:%p

Whenever you connect to server.example.com as user joeuser, SSH will create a named pipe at /tmp/joeuser@server.example.com:22. If you open another connection to the same server (as the same user), instead of creating a new TCP/IP connection, SSH will automatically multiplex the new session with the existing connection (through the named pipe)! This reduces time spent setting up new connections. Although this usual only saves a couple of seconds per connection, I’m constantly opening several simultaneous sessions; this will definitely add up to a significant savings over the long term!

]]> http://plathrop.tertiusfamily.net/blog/2008/02/14/simple-ssh-speed-up/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/02/11/is-it-quiet-in-here/ http://plathrop.tertiusfamily.net/blog/2008/02/11/is-it-quiet-in-here/#comments Mon, 11 Feb 2008 19:37:10 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/02/11/is-it-quiet-in-here/ The lack of posts is due to a general lull in my work lately. I’ve got a couple of posts in the queue, but they need more development. Stay tuned!
]]> http://plathrop.tertiusfamily.net/blog/2008/02/11/is-it-quiet-in-here/feed/ 0 http://plathrop.tertiusfamily.net/blog/2008/02/03/capistrano/ http://plathrop.tertiusfamily.net/blog/2008/02/03/capistrano/#comments Sun, 03 Feb 2008 22:51:58 +0000 plathrop http://plathrop.tertiusfamily.net/blog/2008/02/03/capistrano/ One of the things you quickly learn as you become a more sophisticated systems administrator is that performing the same task on several servers is both tedious and error-prone. Of course, if your infrastructure has been deployed in an ad-hoc manner, sometimes you don’t have a choice; the task is unique on each machine simply because each machine has a unique configuration. However, once you have made the transition to stock configurations on multiple machines, you gain the ability to use new tools to perform tasks in parallel on a number of systems at once. The tendency for many admins is to set up public-key authentication and hand-roll a script. This isn’t necessarily a bad approach; sometimes a quick-and-dirty script is all you really need to get the job done. On the other hand, there are tools which can make the process more elegant, consistent, and professional. The two I know of are ClusterSSH and Capistrano.

I’m fairly new to Capistrano, but I’ve been using it to perform some simple tasks for a couple of months, and I’m really pleased with the results. I first encountered Capistrano when I was looking for a simple way to remove the SNMP agent from a group of about 20 machines. I knew I could whip up a script, but I had remembered reading a blog post somewhere (sorry, I don’t remember where) about ClusterSSH; several Google searches later I had found both ClusterSSH and Capistrano. At the time, I was learning Ruby (in order to get involved in Puppet development), so Capistrano seemed the natural choice.

According to the website, Capistrano was originally written to help deploy Ruby on Rails applications. Like many tools, it has grown beyond its initial mission, and is now a powerful tool for systems administration. Capistrano makes some assumptions about your infrastructure. First, you must be using SSH to access your systems, because Capistrano does not support older methods such as telnet (and if you are still using telnet, shame on you!) Second, your systems must have a POSIX shell in the default system path. For most *nix systems these days, this is a given. Finally, to *really* utilize Capistrano correctly, you should be using public-key authentication to access your servers. You don’t necessarily need to use password-less keys (in fact, I suggest you resist that temptation in general). Just use ssh-agent to keep your passphrase in memory. All of these assumptions are true for my environment, so I got started.

Installation was trivial using RubyGems. Next I needed to create a “capfile” – the Capistrano equivalent of a “Makefile”. The “capfile” gives Capistrano information about your environment and defines “roles” and “tasks”. “Roles” describe groups of systems, “webservers” or “firewalls” for example. “Tasks” are the actions you wish to perform. After reading through the Basics on the Capistrano website, it was fairly simple to define a task to do what I wanted:

task :remove_snmp do
  run "sudo aptitude -y purge snmp"
end

One complication of my environment is that most of the systems are not directly accessible from outside. We have an SSH “bastion host” which acts as a gateway to the internal network. Luckily, Capistrano is ready for this. I added the following to the beginning of my capfile:

set :gateway, "ssh-gateway.example.com"

This tells Capistrano to first establish an SSH connection to ssh-gateway.example.com, and connect from that machine to the systems we want to run commands on. “But how does Capistrano know what systems to run commands on?” you ask. Good question! That is what we need a “role” for:

role :de_snmp, "server1.example.com", "server2.example.com", "server3.example.com", "server4.example.com", "server5.example.com", "server6.example.com"

Before you run a task on all of your systems at once, you probably want to test it first. I usually try the task by hand on one or two systems. Once I am happy with the procedure and the results, I pick several less-critical (or easy to rollback) hosts to do a second pass on. Finally, after all is well with those hosts, I run the task on the full group. Here is our completed “capfile” for the second pass:

1 2 3 4 5 6 7

set :gateway, "ssh-gateway.example.com"   role :de_snmp, "server1.example.com", "server2.example.com", "server3.example.com", "server4.example.com", "server5.example.com", "server6.example.com"   task :remove_snmp, :roles => :de_snmp do run "sudo aptitude -y purge snmp" end

As you can see, we’ve modified our “task” definition to apply to the “role” we created. All we have to do now is run cap remove_snmp and Capistrano will do its job! There is plenty of output, so it is fairly easy to review what is happening (though it can be challenging to follow the events on a single server unless you know your way around grep; you do, right?)

This is just the tip of the iceberg. Capistrano is very sophisticated, allowing your tasks to be self-documenting, divided into namespaces, use variables, and more! Perhaps the most powerful feature is the ability to define “transactions” and “rollback” functions. Although you still have to manually define what a “rollback” means, Capistrano allows you to do that once, and use the capability as often as necessary. In addition, you have the full power of Ruby at your command in Capistrano scripts. I haven’t had the need to explore these features but as I do I’ll be sure to share my experiences here!

]]> http://plathrop.tertiusfamily.net/blog/2008/02/03/capistrano/feed/ 1