Thanks for bringing up this important area, Kevin. This is a relatively new and growing field and there is definitely lots of room for improvement.

I was surprised you found "severe incompatibilities" between point releases of CFEngine 3 -- I've been using 3 since 3.0.2 and have not seen severe incompatibilities. What did you run into?

Regarding CFEngine being barren by default -- I know what you mean. CFEngine is a configuration management FRAMEWORK. The CFEngine standard library is an example of using that framework. It does take a bit of work to use all this, but once you do, the benefits are enormous (labor and sanity saving, increased efficiency as a sysadmin, more power over the systems, infrastructure as code, etc. -- all the usual benefits of configuration management, plus the added benefits peculiar to CFEngine - support for over thirty operating systems, small memory and power footprint, very few dependencies and the resulting ability to run on a very wide range of hardware, from embedded to supercomputer).

Is there something you want to do with CFEngine that is not in the standard library? (Please give some concrete examples.) Maybe I could help with that.

I do have over 150 practical examples of using CFEngine 3 at http://www.verticalsysadmin.com/cfengine/cfengine_examples.t... and they are all RHEL/CentOS based.

FYI, CFEngine, Inc. grew this year from 4 to 30 staff and are still hiring. I think you're going to be seeing a lot from CFEngine the company in the near future.

Incidentally, I'm looking for CFEngine professional service engineers to help with CFEngine 3 deployments. Details at http://www.verticalsysadmin.com/pse.htm

I'll be training on CFEngine 3 in Palo Alto on January 25-27 (http://cfengine3.eventbrite.com), and in Los Angeles on Feb 20-22 (http://cfengine.eventbrite.com). Email me for a 10% off coupon.

I also run a free 2 hour webinar "Getting Started with CFEngine 3" - email me and I'll let notify you of the next one. aleksey at verticalsysadmin dot com

Configuration Management is an actively growing field right now, all the major players are doing a lot to improve their products. It's going to get better, stick with it.

I believe I started using a 3.x.1 distro package and on the other end a 3.x.5 package if memory serves (this was in April). The minor versions contained tons additional new features. If there's something 3.x.y can't do that 3.x.y+1 can't do, the middle number NEEDS to be incremented to signify this change. The promises from the later tail number would not work on the older one.

Some things I think would be useful to ease Cfenfgine adoption:

* .conf.example files that can be jockeyed around quickly to produce useful working samples within 15 minutes.

Specific areas for the above include: installing a file from cfmaster to a host, installing packages using the native package manager, starting services using the native service manager

* Reading about promise theory and Cfengine lingo is neat and all but if I'm not convinced of the benefits and have it running in 15 minutes, the install process/doc is flawed. Fixing this will get you much more market share.

* All of the above doesn't mean Cfengine can't handle n-th order complexity and diversity. Instead what I am suggesting is to make it very easy to try on in the simplest cases, and wear well with experience and age in tougher environments.

* Some simple config enumerator scripts. Run yum, dpkg, etc and get a list of all packages. Output this into a config file that the user can edit and put into use right away.

I'll dig through your Cfengine examples some time and see how it's going.

Thanks for your thoughtful reply, Kevin. I agree with you on the version numbering, on incrementing the middle number for bigger changes.

I'll talk to the CFEngine, Inc. guys about bundling my example config files into the package, having simple practical workable examples (that one can adopt to ones own use) would go a long way in helping people get started.

Agreed we need to improve the whole "up and off the runway" process.

Thanks again for your constructive feedback.

If you have any suggestions on my Cfengine example collection, drop me a line - aleksey at verticalsysadmin dot com

Best, Aleksey

To be "that guy" this is not at all a new area. CFengine is almost 20 years old and certainly wasn't the first bit of software to try and solve the problem. There is definitely a lot of room for improvement.

Well, shaggy, from my talking to sysadmins at large, most are not using any kind of automated configuration management at all. They are using ssh for loops, and that's their automation. Pushing changes.

So when I say configuration management is a new field, I mean the ideas are just starting to go from niche to wider adoption.

This year was the first year at LISA (Unix sys admin conference) where most people had some kind of configuration management solution -- and LISA is to a large extent early adopters.

So now the early adopters have adopted the technology -- it will take years for the rest of the field to catch up.

Just out of curiosity, I'm not aware of any configuration management software preceeding CFEngine - kindly share?

I agree there is a lot of room for improvement, and I see improvement happening, in all the modern tools, this is great.

There is probably a need for a more targeted promise lib for EL/Debian that does some of the simple stuff out of the box. However, it's a slippery slope because part of the problem with the configuration management domain is the mindset you exhibit. Windows and other Unix operating systems are not niches. Excluding operating systems because you don't see them being used or deployed will result in an ever growing list of small point solutions that don't solve very many problems. Then as soon as you outgrow that solution you have a larger problem on your hands.

It's no harder to manage, say, Solaris using CFengine than it is to manage EL/Debian. You're right that CFengine isn't mentioned here very often and that's most likely because it's not new web 2.0 startup-o-fied ruby fanboi cool. It's been around since 1993. So in almost 20 years the problem of configuration management hasn't been solved in a satisfactory manner. It's a very difficult problem to solve.