On configuring CfEngine

On configuring CfEngine
	Part XIII. (Mass) Installations, also dual-boot

Jurjen Bokma

July 2007

Table of Contents

In a freshly installed Debian Etch, the package cfengine2 comes with

/var/lib/cfengine2/inputs a symlink to /etc/cfengine, and

/etc/default/cfengine2 looking like

RUN_CFSERVD=0
RUN_CFEXECD=0
RUN_CFENVD=0

CFSERVD_ARGS=""

The server part

First of all, the server needs to run. Modify /etc/default/cfengine2:

RUN_CFSERVD=1  
RUN_CFEXECD=0  
RUN_CFENVD=0

CFSERVD_ARGS=""

	The server must run
	If the server isn't a client of another server, best leave this off. Circular dependencies don't seem like a good idea at this time.

Then, we need configuration files in /etc/cfengine. CfEngine looks for them in /var/lib/cfengine2/inputs, but that is a symlink to /etc/cfengine. To get started, we need at least the following:

server:/etc/cfengine# find /etc/cfengine/ -type f /etc/cfengine/cfrun.hosts /etc/cfengine/cfservd.conf /etc/cfengine/masterfiles/update.conf /etc/cfengine/masterfiles/cfagent.conf

	Note
	In my case, these files are generated using `iserv` ^[39]. Whenever iserv-update is run, the templates in `/etc/inserv/templates/etc/cfengine/` are used to generate instances in `/var/lib/iserv/generated/etc/cfengine/`, which are then copied to `/etc/cfengine/`. The Makefile (`/etc/iserv/Makefile`, and its inclusion `/etc/iserv/copy-targets`) direct this behaviour.

	Note
	`/etc/cfengine/cfrun.hosts` should be created by `iserv`, but isn't. This is on the ToDo-list for iserv.

/etc/cfengine/cfrun.hosts should simply contain the FQDNs of all hosts this server is ever going to service, one per line. List them all and be done with it.
/etc/cfengine/cfservd.conf can be fairly simple: see Conference under Docker

/etc/cfengine/masterfiles/update.conf should be tampered with as little as possible. Its sole responsibility is to keep the configuration files for CfEngine on the client identical to those on the server. If the master copy /etc/cfengine/masterfiles/update.conf becomes incorrect, the client copies also become incorrect at the next run of cfagent, and this cannot be repaired, as this is the file that should do the repair, and it has become incorrect.

	Warning
	Do not mess with `/etc/cfengine/masterfiles/update.conf` unless you know exactly what you are doing, and you have redundant mechanisms in place to assure that a newer version does not depend on CfEngine to spread, and you are wearing clean underwear.

That being said, take a look at Conference under Docker

All the previous configuration just serves to get /etc/cfengine/masterfiles/cfagent.conf into place. This is the file that does all the work. We present a minimal version in Conference under Docker, but it should greatly be elaborated upon. For help, please refer to the cfagent reference.

We are now ready to restart the cfservd daemon: /etc/init.d.cfengine2 restart

	Note
	In order to make the `update.conf` and `cfagent.conf` available fro clients which don't have a configured `cfagent` yet, `iserv` also makes them available through `ftp`, by placing a copy in e.g. `/srv/ftp/pub/local/os/linux/distributions/sl/installer/scripts/` ^[40]

^[39] iserv Is a suite I made. It consists of a couple of scripts that generate configuration files for various services using a central stash of known variables like network addresses of interfaces, serviced domains, etc. There is no use in looking for it on the Web, as it is not past the kludge phase, and I haven't open-sourced it yet. If anyone who reads this knows of an existing system that can do this, I would be grateful for a quick notification.

^[40] This location is not the only one that carries a copy, and subject to rapid change over time.


Can we safely use ZENworks imaging on machines with multiple disks?		The client part