{"id":427,"date":"2008-04-17T11:36:06","date_gmt":"2008-04-17T10:36:06","guid":{"rendered":"http:\/\/wp.devco.net\/?p=427"},"modified":"2009-10-09T14:01:07","modified_gmt":"2009-10-09T13:01:07","slug":"easy_per-machine_custom_facts_for_puppet","status":"publish","type":"post","link":"https:\/\/www.devco.net\/archives\/2008\/04\/17\/easy_per-machine_custom_facts_for_puppet.php","title":{"rendered":"Easy per-machine custom facts for Puppet"},"content":{"rendered":"
UPDATED<\/b>: The code below is a bit crap – first ever ruby code – try this instead<\/a><\/p>\n As this is the first time I am posting about Puppet<\/a>, maybe a few words about it first. Puppet is a configuration management system that helps you manage large infrastructures. There are ofcourse many similar things, cfengine<\/a> and lcfg<\/a> to name just two. I like Puppet as it has a big and active community but it is also a modern approach to the problem being that it has some properties of Object Orientation and so forth.<\/p>\n I’ve used cfengine – actually chose it over Puppet when it was still young – but that is over a year ago now and I if you have many or even 2 of the same nodes to maintain I urge you to check out Puppet.<\/p>\n So the rest is only really useful if you already know Puppet, sorry if this will bore many people \ud83d\ude42<\/p>\n On a site I worked we used to have a file on each machine that defines a few Facter facts, this was very handy and I wanted to do something similar because I define variables like $country=”uk”<\/i> and so forth in my nodes which then helps my manifests builds correct ntp configs for example. Now doing it with a global variable in the node is ok and all, but not nearly as sexy as letting each node know where they are in via facts.<\/p>\n In the old days hacking in new facts was a right pain and you possibly even needed to maintain your own package of facter, not so anymore, it’s in fact really nice now.<\/p>\n