urandom Mangot ideas

Tuesday August 04, 2009

A Trade Show Booth: Part 2 - The Puppet Config After writing the blog post about running a trade show booth with OpenBSD and PF, a few people asked about the puppet configuration. The configuration is actually dead simple. The idea is to configure the machines with the base configuration they need, as well as provide for future management. Because this is such a simple environment, we are able to keep the flexibility of both configuration management coupled with instantaneous change. The best way to understand this is just to have a look at the site.pp.

import "classes/*.pp"

node default {
        include rootssh
        include tchomedir
        include postfix
        include mysql
}

Let's look at each file in turn

rootssh

class rootssh {
  file { "/root/.ssh":
        owner => root,
        group => root,
        mode => 700,
        ensure => directory
        }
  file { "/root/.ssh/authorized_keys":
        owner => root,
        group => root,
        mode => 700,
        content => "ssh-dss AAAAB...truncated...N==",
        require => File["/root/.ssh"]
        }
}

I know there is a puppet directive to handle ssh keys but it doesn't work, at least it didn't in my setup. Using 'content' to the 'file' type works well. This enables the puppetmaster (OpenBSD box) to control all the puppet hosts as root. Turns out we didn't need to use this very much but it's handy to have nonetheless.

tchomedir

class tchomedir {
  file { "/home/terracotta/terracotta":
        owner => terracotta,
        group => terracotta,
        ensure => "./terracotta-3.1.0-beta.jun2",
        }
  file { "/home/terracotta/examinator":
        owner => terracotta,
        group => terracotta,
        ensure => "./examinator-cache-1.2.0-SNAPSHOT.jun2",
        }
  file { "/home/terracotta/Destkop/Demo.Deck.Simple.2.2.pdf ":
        owner => terracotta,
        group => terracotta,
        mode => 755,
        name => "/home/terracotta/Desktop/Demo.Deck.Simple.2.2.pdf",
        source => "puppet:///dist/Demo.Deck.Simple.2.2.pdf"
        }
  file { "/home/terracotta/.bashrc":
        owner => terracotta,
        group => terracotta,
        ensure => present,
        source => "puppet:///dist/bashrc"
        }
}

We already had the terracotta user and group created, though this could have been easily done in puppet, maybe next year. Here we make sure that the "terracotta" and "examinator" symlinks are always pointing to the right kits. We distribute a PDF file used for the demos, and make sure everyone has the same centrally configured .bashrc

postfix

class postfix {
  package { "postfix":
        name => postfix,
        provider => apt,
        ensure => present
        }
  file { "/etc/postfix/main.cf":
        owner => root,
        group => root,
        source => "puppet:///dist/main.cf"
        }
  service { "postfix-svc":
        ensure => running,
        subscribe => File["/etc/postfix/main.cf"],
        require => Package["postfix"],
        name => postfix
        }
}

Pretty simple and demonstrates what is pretty awesome about puppet. This definition retrieves and installs postfix, gets the postfix configuration from the puppetmaster and makes sure postfix is running. It will even reload the postfix configuration if the main.cf on the puppetmaster changes.

mysql

class mysql {
  file { "/etc/init.d/mysql":
        owner => root,
        group => root,
        source => "puppet:///dist/mysql"
        }
  service { "mysql-svc":
        ensure => running,
        subscribe => File["/etc/init.d/mysql"],
        name => mysql
        }
}

Here we could have used puppet to install mysql just like we did for postfix, but it is already on there from the machine build. We replace the init script for mysql with our own with some custom arguements and then make sure the service is running.

Distributing the Terracotta kits

To distribute the Examinator and Terracotta kits we used prsync in the PSSH kit by Brent Chun. It can run a command, sync over rsync, etc. to 32 machines over ssh in parallel by default, and more if configured that way. With this we ran a single prsync command that distributed out each directory to all the machines at the same time whenever we needed to update the kit.

Questions

Why aren't you using puppet to distribute the kits?

Prior to the new Puppet 0.25 RC just released with the beginnings of a move toward REST from XML-RPC, puppet has been terrible at recursively copying large directory trees. We tried to distribute the Terracotta kit with all its directories and jars and it blew up running out of file descriptors. The is reportedly fixed in the RC mentioned above.

Why are you using prsync instead of puppetrun?

Because we couldn't use puppet to distribute the kits so triggering the run can only be used to shift the symlink. We could have used an exec directive in the puppet config to pull the file from somewhere and untar it but that seems no less hackish.

Summary

Using puppet definitely makes our lives easier when setting up a trade show booth. This is the first year we've used puppet and I've already learned a lot about the tool and will be using it even more extensively next year to separate the OS install, from the booth dependencies (e.g. mysql). See you at JavaOne!