Musings of an Open Source BOFH

So kernel.org has gotten up to the point where it's 10 some machines in size and scope with general plans to grow that number of machines as needed. Now at 10 machines copying around configuration files, directories, etc is a little unwieldy but it isn't so cumbersome as to really make me want to change things. Generally speaking our configurations are very static, we don't add new machines very often and our configurations don't change much over time.

That said we recently started work on deploying an 11th machine for a specific project, we are still feeling out the project so I can't say much about it yet, but I figured it was time to start trying to centralize the configuration for kernel.org into something a bit more centrally managed and controlled.

Why? Well designating certain machines as 'masters' of a configuration is fine, but it still means machines could diverge in ways I'm not expecting. It's also hard to explain to everyone else who has to work on these machines, and ultimately it's not really a good thing for long term sustainability. Plus I wanted to play with puppet on a larger scale.

So as of today I've got now 2 machines hooked up to puppet, our backend machine that deals with our dynamic web content (demeter) and our mystery project box (nott*). I've got the following things ported over:

• smtp / mail
  • sendmail
  • greylisting
  • clamav
• ntp
• puppet (itself)
• rsync
• sudo
• yum-updatesd

While I recognize this is not a particularly impressive list, this is what I've gotten through in only a couple of days worth of work, and our mail setup - is *NOT* simple (there's over 1M of configuration data to deal with that alone). I'm at the stage where I'm just taking our existing configuration files and copying them around, in a lot of cases this is likely how it will just be, but I can see where there would be some much more interesting setups using their templates and such. The example that immediately floats to mind is our configuration files for vsftpd - which don't allow us to store all the possible ports to listen on in the configuration file. It sucks, most everything else doesn't care, but vsftpd does.

That said I have been pondering something that I would genuinely love: the ability to include reported information from the clients in templates.

Lets say I have a list of machines that are connected to puppet:

• machineA
• machineB
• machineC
• machineD
• machineE

Lets also say that I've applied the class 'greylist' to all of these machines. Now in a puppet template I can include information about that specific machine in the configuration file, say the IP address of the machine. This is very useful indeed, I can trivially tell them which interface to listen on and they are good to go. However what if I want to have all of the machines (nodes) that belong to class 'greylist' (or that have imported it) listed in the configuration file?

So far I can't find a way to do this, but it would be extremely useful and it might be something that I implement outside of puppet and do some more basic queries on my own, it's just annoying that this doesn't already exist inside puppet. That said I'll happily admit to being a n00b when it comes to puppet, and I fully expect to re-write the rules that I've already written in the near future (in fact I think one of the rules has already gone through 3 revisions). I'll likely post some more commentary on this as I get further, come up with something novel, etc.

---

* For those interested this is the Goddess of Night from Norse Mythology http://www.godchecker.com/pantheon/norse-mythology.php?deity=NOTT