About a year ago, I wrote a small python script to automate installing and bootstrapping CFEngine on virtual machines in AWS. It had some hard coded IP addresses that I needed to update when I spawned new hosts, but other than that, it worked well. During manual testing, it saved me a lot of time instead of having to do things manually.

cf-runagent is a component for triggering remote agent runs using the CFEngine network protocol. It does not allow for arbitrary commands to be executed, but rather asks the remote host to run the policy it already has. To trigger cf-runagent from other systems or web interfaces, you want to be able to run it as non-root.

CFEngine is very simple to set up and use, especially if all of the clients and the hub are going to be using the same promises. But what if there are certain things you want to enforce on a hub and not a client? What if there are certain things you want to enforce on a client but not on a hub?

The CFEngine policy analyzer is an awesome new service introduced in CFEngine 3.13. The policy analyzer allows you to quickly debug policies and inspect what is going on under hood of CFEngine. A known challenge with CFEngine, and most DSL based automation tools, relates to understanding what is actually going on during live operations. Many users view it as “black-box magic”. Unfortunately, the amount of magic and the size of the black box increases with the level of automation.