I recently switched from puppet daemon to mcollective commander : it kicks the “stuck in outer space puppet daemon” feature out of the way and brings me nice features (as load control). To do so I deployed the puppetd agent over my boxes.

Most people that work with puppet use a VCS : subversion, git, CVS, mercurial… Pick yours. My company uses subversion and each cmmit to the repository needs to be pulled by the master. Since I have two masters, I also want them to be synchronized. Once again it’s mcollective that comes to the rescue. I wrote a very simple agent (a 5 minutes work, to be improved) that can update a specified path. Grab it here. Once it is deployed you can use a post commit hook that calls it.

On my Solaris machines at $WORK I use iMil‘s pkgin to install additional software. But until today, I add to do it by hand, on every machine… Not really what I like to do after a little more than a year using puppet. So I wrote a provider to manage packages with pkgin. It was very informative on puppet internals and I learned more about my favorite config management system.

At $WORK I started using Nginx a while ago, first as a front end to my mongrel instances for puppet. Recently I began to use it for one of its most know features : reverse proxy (and caching too). Of course this work had to be puppetized !

Today I started installing a reverse proxy at $WORK. I choose to follow this way, and all my DNS data is stored in my CMDB. Once again, the solution came from #puppet ! You can embed some “pure” ruby code in ERB templates. And, yes, you can query your database !

Disclaimer : this work is mostly based upon DavidS work, available on his git repo. In the scope of my work I needed to have munin support for freeBSD & Solaris. I also wrote a class for snmp_plugins & custom plugins. Some things are quite dependant from my infrastructure, like munin.conf generation script but it can easily be adapted to yours, by extracting data from your CMDB.

-Post en anglais, pour une fois-

Everyone using puppet knows DavidS awesome git repository : git.black.co.at. Unfornately for me, his puppet infrastructure seems to be almost only linux based. I have different OS in mine, including FreeBSD & OpenSolaris. Looking at his module-munin I decided to reuse it (and not recreate the wheel) but he used a custom fact that needed some little work. So this is a FreeBSD & (Open)Solaris capable version, to know what network interfaces have link up

Il y a des trucs, ça relève du bon sens mais on y pense pas toujours. Dans le monde des sysadmins, il y en a qui militent pour ce qu’on appelle “l’agilité”. C’est en fait appliquer certaines techniques à la base mises en place pour le développement au monde de l’administration système. Personnellement, je trouve que ce sont essentiellement des conseils de bon sens, l’expérience qui parle en somme.

J’en avais parlé il y a quelques temps avec des lutins donc le voici, mon /etc/puppet. Ne vous attendez pas à quelque chose d’exceptionnel puisque ça ne suis pas les best practices, notamment le découpage en modules. Accessoirement certaines classes ont besoin d’être réécrites (souvent les premières que j’ai conçues).

Petite suite à mon précédent billet sur l’utilisation d’un LB devant puppet. En 0.24.5, il existe un bug gênant si vous utilisez les external nodes : personnellement la conf des nodes est stockées dans une base mysql et c’est un script qui me sort le YAML correspond à la config.

Mon puppetmaster au boulot a toujours été le bon vieux webrick fourni avec puppet. J’ai récemment atteint un nombre de machines qui ne permet plus de l’utiliser, il ne scale pas. Qu’à cela ne tienne, après avoir parcouru le wiki de puppet je me suis lancé : petit résumé et condensé orienté debian.