Yes. Configuration Management Software Sucks. Horribly.
The main problem is that n-th order tweakability is preferred over convention. It’s just stupid. There are a core set of things that just about everybody needs to do. Those should be dead simple. Ready to uncomment and run. The set operating systems used in the enterprise is fairly small: RHEL5, RHEL6, Debian 6, Ubuntu LTS. A configuration system should be opinionated and have complete out of the box support for these platforms. Simple rulesets for the basics that nearly everyone uses should be ready to go.. package management, process initialization, file management, ssh, sudo, DNS, Apache, PAM, PostgreSQL, MySQL, OpenLDAP, etc. Keep it simple. Keep it simple. Keep it simple. Resist all urges to add complexity.
That’s not the case.
You’d think after 30 years of Unix, BSD and Linux network deployments this would be pretty well trodden ground. Wrong. It’s a complete crapshoot and everybody does things differently. Pick your poisons and reinvent the stack ad infinitum.
This is one of the few areas I’m green with envy of the Microsoft side of the fence. Between Active Directory, Group Policy, and maybe a third party tool or two for cloning and installs and such, Microsoft environments can easily be set up and managed well by complete morons (and often are).
Puppet
Puppet seems to have potential. Of course, out of the box you’re pissing in the wind with a blank slate and most books and sites will have you following tutorials to rewrite rulesets that thousands of other people before you have similarly cobbled poorly together. As a Ruby project, it unsurprisingly has vocal hipster fanboys. Unfortunately, they forgot to parrot their DRY principle to each other.
It centers around a domain specific convention which isn’t so bad.. but in no time flat you’ll start seeing full blown Ruby programs intermingled. Ugh. But it’s not so bad if you stick to the basics.
If you look around you can find reasonably complete module sets, i.e. http://www.example42.com/. It’s not all gravy as these are heavily interdependent and kludgy. If you want a clean, simple solution you’re back to rolling your own with some healthy copy and paste.
Since it’s a Ruby project, aside from the annoying fanboys, you’re also going to run into scalability problems past a few hundred nodes. There are mitigation strategies, but it’s a joke compared to something like Cfengine.
Due to hype, you’ll find decent versions in the Debian and Ubuntu backports repos. RHEL 5 and 6 are covered by a Puppet Labs repo. 2.6 and 2.7 are therefore readily available and as long as your master is running the later version you shouldn’t have interop problems.
All things considered, Puppet is probably the best choice at the moment. It sucks, but it’s got a lot of momentum behind it. There are mountains of docs, books, and tutorials to get you going and nothing is too foreign or hard to grasp.
Cfengine 3
I really want to like Cfengine. It’s incredibly light weight and hardcore ROFLscale. It’s got serious theory behind it and older versions have been used in massive deployments. But it’s not just a blank slate. It’s even lower level and incomplete compared to the others.
You really need to add a promise library to get features that should be included by default. These are all stagnate though, and still leave much to be desired.
There’s a company behind it doing something or another, but the open source version is raw. If you have more than one Linux distribution, I’ll pretty much guarantee the packages are incompatible.
The repo choices aren’t great either. Uncle Bob’s PPA on Ubuntu, out of luck on Debian. RPMs in the EL repos look out of date. You can of course get source and binaries from the Cfengine company, but it’s not my preferred way to install things and makes bootstrapping harder than it needs to be.
I haven’t tried the latest release, but quickly gave this one up when I found severe incompatibilities between point releases. Madness. You’d think people inventing something like promise theory could handle something as simple as version stability.
Ping me when a corporation backs Cfengine with a good promise library, some standard tasks, and repos for the common operating systems.
Bcfg2
Bcfg2 made the most sense to me out of the box. XML is yucky and out of fashion these days, but Bcfg2 manages to use it acceptably. Consequently, most things are declarative, easily read, and overall easy to mimic. Beyond that, you can tap into some Python template and generator stuff. But yes, these guys finally didn’t put n-th order above the common cases! Installing packages and ensuring services are on is a snap.
They’ve got their own repos for many distros so installation isn’t bad.
The client and server are Python so you’ll have similar scaling problems to Puppet in large environments.
My biggest grievance with Bcfg2 is that the server needs intimate knowledge of each operating system version’s package repos. You’ll fumble around writing a good bit of XML definitions for this in a heterogeneous environment.
The main thing Bcfg2 is lacking right now is community momentum. Including repo definitions by default and some more doc work.. I think this would be a great system for small to medium deployments.
Conclusions
The lot of this stuff is really terrible. End to end system management under *nix is a major pain point. On top of this, you’ll need a fairly free form monitoring framework (these also all suck) and directory service. Mix and match an impossible array of projects and eventually you’ll find your own recipe that sort of works. Except everyone does it differently so you’ll constantly be learning and redoing the same things over and over anyway.
It’s not fun. What we need is end to end integrated thinking. This area is still ripe for picking. Oh RedHat, where art thou?
