Simplifying File Permissions in Puppet Manifests

Wed, 23 Sep 2009 22:16:00 GMT

I've been a user of Puppet for about three years now and while on a recent dig in to some of my older classes it was a little embarrassing to see lots of file types used like this:


  file { "/srv/whi/maps":
    ensure => present,
    source => "puppet://$servername/whi/maps.conf"
    owner  => whi,
    group  => whi,
    mode   => 644
  }
  file { "/srv/whi/elocs":
    ensure => present,
    source => "puppet://$servername/whi/eloc.conf"
    owner  => whi,
    group  => whi,
    mode   => 644
  }

Luckily as we get more experienced with a tool we can often go back and improve on the first steps. By using an explicit File { settings } inside a class you can assign a sensible set of defaults to all the instances of the same type that lack overriding settings. So we can shorten the previous example to -


File {
  owner => whi,
  group => whi,
  mode  => 644
}

file { "/srv/whi/maps":
  ensure => present,
  source => "puppet://$servername/whi/maps.conf"
}

file { "/srv/whi/elocs":
  ensure => present,
  source => "puppet://$servername/whi/eloc.conf"
}

While this isn't a huge win in raw characters typed (although in longer manifests they start to mount up) it does move all the common settings in to a single location (keeping us clear of DRY violations) and it leaves only the differences between file type definitions.

You can also apply those kind of settings (such as Exec { path => "path:list" } at the server level by including them in a top level file and then overriding them as needed in each module. If you do this then you need to be aware that any declared type that doesn't override it gets the global setting, which can lead to the odd action from afar head scratching.

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Stand Alone Puppet

Thu, 17 Sep 2009 21:33:00 GMT

While Puppet can be used to manage large, complex environments it's also a useful tool at the lower end of the spectrum. Using just the puppet executable and a small inline class or two you can write very useful manifests in only a handful of lines.


class build-host {
  package { "build-essential": ensure => installed }
  package { "subversion":      ensure => installed }

  file { "/home/dwilson/repos/":
    ensure => directory,
    owner  => dwilson,
    group  => dwilson,
  }
}

node default {
  include build-host
}

To invoke the class you just run puppet -v build-host.pp. It's also worth pointing out the node name of default. This saves you manually changing the manifest whenever you move to another machine. While it wouldn't be hard to replace the above example with a shell script, by using puppet you can easily access the built-in abstractions (which package manager to use, how should you add users) and remove a lot of scaffolding code. And then when you're done you can promote the class to your managed infrastructure.

I've used this to bootstrap provisioning servers (why should the provisioning host be the only machine that wasn't provisioned?), test small but annoying new classes on scratch servers and I'm currently working on integrating it with a small subversion backup testing project in my spare time at work (so very slowly).

Like this post? - Digg Me! | Add to del.icio.us! | reddit this!

Dean Wilson@UnixDaemon: In search of (a) life

Simplifying File Permissions in Puppet Manifests

Stand Alone Puppet