Here at Normation, we use CFEngine 3 extensively for configuration management across Linux and Windows servers.
CFEngine 3 is a very secure tool, that relies on keys to identify hosts and authorize connections. To set up a secure CFEngine infrastructure, you ought to exchange keys between hosts (note that if you don’t have confidential data on your promises, you can skip the security offered by the public key system).
Cfengine 3 est un logiciel de gestion de configuration open source très puissant, permettant de gérer efficacement des parcs informatiques de toutes tailles. Comme la plupart des outils complexe, un temps d’apprentissage est nécessaire pour l’utiliser au mieux.
Nous organisons des sessions de formation à Paris, les 15, 16 et 17 juin, et à Bruxelles les 4, 5 et 6 juillet.
Trois formules sont disponibles :
Le détail du programme et les tarifs sont disponibles sur notre site web.
L’inscription est ouverte, contactez-nous pour vous inscrire. Plus que quelques jours pour profiter du tarif early bird !
Normation est partenaire officiel de Cfengine AS, et réalise des formations Cfengine certifiées à travers le monde.
Here at Normation, we use Cfengine 3 extensively for configuration management across Linux and Windows servers. Cfengine 3 is an open source project, and as every good open source project, the trunk version is always available (but not always very reliable) and stable versions are released regularly. Prior to the release of a new version, a beta version is available, for the community to test and rule out any bugs in the stable version.
We’ve been testing this beta version, and we are quite thrilled about it. This post won’t go through every detail of the changelog (Eystein is much better at it that I would be) but will run over the changes that improve our ways of using Cfengine.
Here at Normation, we use Cfengine 3 extensively for configuration management across Linux and Windows servers. A question we get often is why Cfengine?
I’d like to focus this post on file editing. Since Configuration Management has a lot to do with configuration files, file editing (either from a template, or just setting parameters) is one of the most common tasks.
As good as your configuration management tool may be, it can only do it’s job if it’s running. Some tips on making sure this is the case, whatever happens.
With Cfengine, the “heavy lifting” is done by cf-agent, which is normally run on a regular interval by cf-execd (a daemon that runs all the time).
Frequently, servers will also run two other daemons: cf-monitord (keeps statistics on a system) and cf-serverd (allows local file sharing, and remote on-demand execution of cf-agent). Common practice is to include in cf-agent‘s configuration a promise that ensures that the desired daemons are running, and start them if not.
This makes sense, but what happens if cf-execd gets stopped, and then cf-agent is never run again? Well, this should never happen of course. But, out there in the real world, stuff happens:
Enough rambling, here is what we do:
The promise we use is derived from one provided with the Cfengine sources, as follows:
The above Cfengine example uses some interesting concepts:
Last, but not least, here is the line we add to /etc/crontab:
Of course, we wouldn’t add that line manually, but instead, use a Cfengine promise to add it if, and only if it’s not already in /etc/crontab… This is a subject for another post, but here’s a sneak preview:
Using the above promises, you will ensure that the Cfengine components you want will always be running (or at least restarted if they stop). Of course, it’s probably a good idea to monitor these promises, so that you don’t end up with a start/stop fight…
Here at Normation, we use Cfengine 3 extensively for configuration management across Linux and Windows servers. A question we get often is why Cfengine?
This is phrased either as What is so great about Cfengine? or What is the difference between Cfengine and Puppet or Chef? (as a reminder of how these 3 projects are related, check out Relative origin of Cfengine, Puppet and Chef).
I’d like to focus this post on memory consumption. Since Configuration Management software runs an agent on each server you want to manage, you want to be careful about the extra resources you’ll need to run it…
Before getting into the statistics, we need to know what processes we’re looking at.
The main Cfengine process that applies configuration to a managed node is named cf-agent. When this process is run, it reads it’s local configuration (called promises) and attempts to apply that to the local machine, by running various commands. Three daemons can be run to support this process:
With no further ado, here is the memory consumption we get on our servers for each component:
Cfengine daemons memory consumption
We couldn’t get graphs for the actual cf-agent process – it’s runtime is just too short for the monitoring probe to pick it up regularly. Running it manually we see it’s memory consumption peaking at 10 megabytes of RAM, with a total runtime of roughly 1.5 seconds.
I think the graphs speak for themselves – each Cfengine daemon uses around 3 megabytes of RAM, and doesn’t have any visible memory leak (valgrind does confirm this). The agent itself sees slightly higher peaks, at around 10 megabytes, for a few seconds every execution.
This is why we trust Cfengine to be run on nodes old and new alike, from physical machines with more gigabytes of RAM than you can use down to tiny virtual machines running on only 128 MB (I’m not sure why, but we have more of the latter… I’m told it’s a budget problem).
The CPU usage of Cfengine is also very lightweight – but much harder to graph. Various other optimizations allow it to be extremely non-intrusive… More on these topics soon!
Some details for the curious:
We were at FOSDEM in Brussels last weekend (OK, like every year, and like thousand of others – yes it’s that good an event!).
Alongside a huge number of interesting talks, events and people, of particular interest to us was the Configuration Management DevRoom, organized by James and Nigel from Puppet Labs. It hosted brilliant talks all day, ranging from introducing tools (Chef, Vagrant, Geppeto, FusionInventory, GLPI, OPSI, etc), best practives and real-world feedback from small companies up to the aviation industry.
We presented a session about Disaster Recovery, telling the tale of how things went massively wrong with our production systems, and how using configuration management saved us. The slides below include an introduction to Cfengine and some of the reasons why we chose it in 2009 and still love it.
A series of posts on this blog will go into more detail about these reasons in weeks to come – stay tuned!
Thank you to all those who could wake up early and attended the talk. The room was completely full, so for those who couldn’t get it because of the large attendance, apologies!
Two major wishlist items have come out of our experience:
On this last point, I must mention that Cfengine Nova (the commercial version of Cfengine) already ties into libvirt to define virtual machines and change their settings. This is awesome, but installing the operating systems by hand is still a pain!
Any ideas or suggestions out there?
In December 2009, Mark Burgess, the author of Cfengine, was in France. This was a great opportunity to arrange a talk with members of the French Cfengine community.
Cfengine[0] is a policy-based configuration management system written by Mark Burgess at Oslo University College. Its primary function is to provide automated configuration and maintenance of computers, from a policy specification.[1]