Managing the network with Cfengine

Get the Keys

Before you can test the system, you need to generate public key cryptography keypairs for each node. As root, run cf-key on both the PolicyServer and the client. This command will create identities in /var/cfengine/ppkeys. Because of how cf-serverd is configured in

trustkeysfrom => { "", "" };

and cf-agent is configured in,

trustkey => "true";

the behavior of the machines will be to accept the key of a remote node on trust the first time, but from then on only accept clients coming from that same IP address on trust if they can prove these clients have the same key. This stance is rather permissive, but you can tighten up your production systems if you deem it worth the effort. However, then you need to deal with key distribution through an external channel. (One common way to improve this is to distribute the server's public key with the use of your OS install system but to allow the server to accept new clients on trust. Only you can decide what an appropriate level of security is for your site.)

Getting Started

To start, manually, copy cf-serverd's configuration files into place:

cd /srv/cf-serverd/inputs
cp /var/cfengine/inputs

Note that the server is also getting copies of and all the other files; during normal functioning, any changes you make to in the central repository will be picked up automatically. With the configuration files in place, start up cf-serverd. The following command starts cf-serverd verbosely and in the shell foreground. If you leave these options off, cf-serverd will silently go into the background.

cf-serverd --verbose --no-fork

Now, bootstrap the client by copying and manually to /var/cfengine/inputs on the client (remember, in a production environment, this is something that could be taken care of automatically), then run cf-agent to execute the code in from the directory that contains

cf-agent --bootstrap

If you switch back to the server console, you should see many messages about what is going on from the server end. If you didn't configure your access control correctly, diagnostics explain why the connection or copy was denied. Once you have verified that the network copy was successful, you can kill the foreground cf-serverd process (Ctrl+C) and start it up as a daemon by running it with no arguments.


The last bit of Cfengine infrastructure is the periodic scheduler. cf-execd is a scheduler daemon similar to cron. Perhaps you wonder why Cfengine doesn't just use cron. In fact, many people run Cfengine out of cron as well for an added level of reliability, and they configure cf-agent to restart either crond or cf-execd if necessary. The use of cf-execd has a number of benefits, though, including the power to control the execution schedule within the central Cfengine policy, as well as the ability to format and send email reports about any actions. If you do decide to run cf-agent with cron as well, I recommend having cron execute cf-agent via the foreground version of cf-execd; that way, you will get the same email settings in both systems, and cf-execd will log any output in /var/cfengine/outputs. In this case, however, I assume you are only running cf-agent out of cf-execd and not cron.

First, create a new file that controls the functionality of cf-execd ( and add it to the inputs list (Listing 4). Listing 4 states that cf-execd will run twice per hour (that is the "schedule" line, and the two members of the list are called Cfengine time classes) and that it will send mail to with as a relay. If you have a usable email address and relay, I recommend using them to get a feel for how the whole system produces feedback for the admin.

Listing 4


The item most in need of explanation is splaytime. If a splaytime is set, cf-execd effectively waits a pseudo-random number of minutes before attempting to connect to the server, with the splaytime number as a ceiling. So, in Listing 4, cf-execd waits up to 1 minute. The point is to avoid resource contention.

In this case, I have set it to the artificially low value of 1 so that the user will not need to wait long to see activity from cf-execd. In a production environment, it would probably be better to set this to something on the order of 15 or 20 minutes for the schedule given in Listing 4.

Remember to add the executor bundle that you just created to a bundlesequence in Now, go back to the client and run cf-agent again. This should update the policy from the server and execute it.

Afterwards, check a process listing and you should see that cf-execd was started. From the client's point of view, the process is now truly "hands-off": Any modifications you make to the central policy repository will be picked up automatically. Once the scheduled time comes, cf-execd will wake up, run cf-agent, and deposit any output in /var/cfengine/outputs.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Hyperic HQ

    Monitor a Java application server with Hyperic HQ.

  • Network Management Intro

    Professional admins with tightening IT budgets are always looking for new tools that will help them do more with less. This month we feature some popular open source applications for deploying, configuring, updating, and monitoring software and systems on the network.

  • FAI

    FAI helps you automate the process of installing and configuring new Debian systems.

  • Intrusion Detection

    The Prelude security information management system receives both host- and network-based IDS messages and displays them in an easy web interface. We show you how to set it up.

  • Day One at LinuxCON: Open Cloud Mini-Summit - and Cannoli
comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More