Instead of having more talks, I was invited to join the workshop from Mark Burgess around CFengine3. As someone who plays with puppet and have set that up on my VM’s and colocated machines ( a good 10 machines, some servicing similar functions, some doing totally different things), I have some experience in configuration management, eventhough I am mainly a networking and security consultant
What happend is difficult to describe, Mark is excellent in giving such a tutorial or workshop, and his motivation and energy is a real lot to cope with in little time.
The workshop itself was great, and that does not actually cover it as I mentioned but well this is the best word I can find about it. Comparing puppet and CFEngine is not actually fair, both do things in their own ways and have their way of doing it. Puppet has it’s advantages but clearly CFEngine has as well. As Security consultant I found that you are able to remotely tripwire a system, which means that in a group of machines, every other machine can check another machine for file changes and report to the hub (if you want) if there are differences. CFengine will try to fix these differences so that the system is again in the state you want it to have, still alerting you something was fishy and might need investigation. This all happends by default every 5 minutes. So basically you are most likely 2.5 minutes away from having a fix applied to your system automatically and still get the alert.
The concept of CFengine is that will only work on things that it is able to fix or repair for itself. “Self healing”. If that is not an option then you are most likely not using CFengine.
The syntax is a bit odd though, it’s something you really need to get used to since it is not as clear (for me) as a programming language where you have logic defined. Certain keywords describe the function of a variable and you can assign and request them depending on the keyword something will happen. That might get kinda ugly if you have $(variable[$(nested_variable)]), which is still pretty easy, but gets unreadable if you do complex things with it. Or at least that is my understanding.
Another thing that I miss is the standard library path. CFengine does some odd assumptions (my opinion) on where files are located. If you for example call out cf-agent -f $fileinyourdirectory it will lookup the $fileinyourdirectory in /var/cfengine/inputs/ instead of the directory you are in. You need to specify ./ in front of the filename to have it look in your current working directory (cwd). In addition some functions require the cfengine_stdlib file, which is fine but unless you are in the /var/cfengine/inputs/libraries directory, you need to either specify that it is in that directory, or a subdirectory instead of having it looking for that content in the default directories.
That said, since I am starting to learn puppet I will most likely stick around with it for a little while longer. CFengine surely has it’s potentials and I also had a little chat with Glen Barber from the FreeBSD Foundation yesterday, and he goes beserk on CFengine, things he showed me puzzled me.. but then again he gets puzzled by puppet stuff.
Many thanks to Snow and CFengine/Mark Burgess that I was able to be there, it was a hard three hours workshop, frying my brain entirely (I needed to go away immediatly after, because I couldn’t get more information in :-)) but it was well worth it. For me personally that was the best thing at the SUE2014!