cfengine

Whenever I think of cfengine, I think of the line from Neal Stephenson's "Unix - Hole Hawg"

"Unix has always lurked provocatively in the background of the operating system wars, like the Russian Army. Most people know it only by reputation, and its reputation, as the Dilbert cartoon suggests, is mixed. But everyone seems to agree that if it could only get its act together and stop surrendering vast tracts of rich agricultural land and hundreds of thousands of prisoners of war to the onrushing invaders, it could stomp them (and all other opposition) flat. "

It is impossible to have a discussion about configuration management among Unix admins without someone mentioning that "so and so uses it" or "I've seen it". People who have set it up from scratch are extremely rare. There's a reason for that...it aint easy.

Cfengine's goal is the convergence of systems to a standard. Essentially this means that the practice of individual admins editing config files on servers is NEVER DONE. Think about that. No, really, think about it. Do you understand your infrastructure well enough to describe it, classifying every machine and function accurately? Accurately enough to let a program control them? Yeah, thought so.

gulp

So here we go with a simple cfengine setup. Our goal is to

1. setup a cfengine master
2. setup a cfengine client and have it register with the master
3. distribute a trivial file from the master to the client

After that, the rest is gravy. Amazingly enough, I can not find a tutorial that tells you how to do that. They usually fall apart at the "distribute a trivial file" step and diverge into the wonders and glories of cfengine's promise language, or syntax, or something.

Things I've learned in the 6 months

I wrote everything above this header on Oct 25. It is now April. So what have I been doing (besides Thanksgiving, etc)....trying to get my head around how it works in 20 minute segments. Some things I think I know now

1. cf-agent runs against the local server by default
2. You don't define the "master server" as a setting in a file somewhere.
3. There are 2 types of updates. Updating the local masterfiles from the remote "master" masterfiles. Updating the local inputs from the local masterfiles
4. Updating from the "master" masterfiles is done by running cf-agent with a specific config file from cron
5. Updating the local inputs from the local masterfiles can be done via cf-execd, or as part of the pull from remote, or manually
6. It is really hard to figure out how not to edit files by hand.

Common pieces

• cf-promises - reads the config files in /var/cfengine/inputs (starting with promises.cf) and validates syntax, etc.
• cf-agent - the work horse. Analyzes the promises and executes those which apply to this host. When called with an appropriate promise, will copy files from the master to the client.
• cf-execd - the cron engine. Runs cf-agent on a given schedule. Since promises can include date and time restrictions, the agent may not do anything when it is run

Overview of the server

The 'master' server is both a master and a client (of itself and probably of whatever you are storing the real configs in). It has 3 cfengine daemons running on it

• cf-serverd (started by the cfservd script)
  • gets its configuration from /var/cfengine/inputs/cf-serverd.cf
  • acts as the file server for the agents to pull from
  • is configured to allow or deny access based on subnet or ip
  • stores copies of the public keys of the clients that it has seen
  • 'serves' files from /var/cfengine/masterfiles/inputs unless configured otherwise
• cf-execd (started by the cfexecd script)
  • gets its configuration from /var/cfengine/inputs/cf-execd.cf
  • is a cfengine specific cron engine
  • runs cf-agent on a periodic basis
• cf-monitord (started by cf-monitord script)
  • gets its configuration from /var/cfengine/inputs/cf-monitord.cf
  • I'm not sure yet FIX ME

Overview of the clients

I've created rpms that will install the mentioned files and run an initial update. They are described here