Puppet Camp San Francisco 2010
Posted Mon, 11 Oct 2010
The conference was the same format as last year. The morning was single-track presentations from various puppet users, and the afternoon was openspace/barcamp-style break out sessions. It was good to see some old faces and also to finally put faces to IRC and twitter names.
One of the bigger announcements was that mcollective would join the Puppet project. Other announcements included new employees and other good news. Beyond that, I picked up a few tricks and learned more about the puppet roadmap.
In no particular order - some thoughts and notes.
Facter 2.0 will be good. Take lessons learned from Facter 1.x and improve things - Make the DSL for making facts simpler, add structured data, add caching, etc.
Puppet supports a "config_version" option that specifies a script that will override how the version of a given catalog is determined. Useful for tagging based on revision control or deployment versions.
Scoped defaults such as 'File { owner => root }' apply
downwards in all cases, something I hadn't considered before. That is, if you
are class 'foo' and define a default and also include class 'bar', the default
in foo will apply to bar as well. This was new to me, and I will be cleaning
up some of my manifests as a result (I use defaults in some classes but not
others). Best practice here is to either use no class-specific defaults or use
class-specific defaults in every class.
Twitter operations (John Adams) gave a talk covering their automation/puppet stuff.
John talked about problems with sysadmins trying to hack around puppet by using
chattr +i to prevent puppet from modifying certain files - a
practice they heavily discouraged. He also mentioned problems with poor cron
scheduling and presented the usual sleep $(($RANDOM % 600))-style
solution. I didn't get around to sharing my cron
practices (sysadvent) with John before the end of the con. He also
mentioned having problems with home directory syncing using puppet, which was
another solution I'd covered that here and better solved previously on sysadvent.
During some downtime at the conference, I started working on an ssh key authorization module for mcollective. The ruby ssh key code is here and the mcollective fork with the sshkey security plugin is here. It works pretty well:
snack(~) % sudo grep security /etc/mcollective/{server,client}.cfg
/etc/mcollective/server.cfg:securityprovider = sshkey
/etc/mcollective/client.cfg:securityprovider = sshkey
snack(~) % mc-ping
snack.home time=97.81 ms
The gist of the key signing pieces is that your ssh agent signing authenticates
you as a user for requests, and for responses the server signs messages with
its own ssh host key (like /etc/ssh/ssh_host_rsa_key). Validation of you as a
user is done through your authorized_keys file, and validation for the reply
uses your known_hosts file to verify the host signature.
It was a good conference, though I would've enjoyed a more hackathon-style atmosphere. We tried to do a facter hackathon, but there wasn't enough time, so instead we code reviewed some of the sillier parts of facter and talked about the future.