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 cf-serverd.cf

trustkeysfrom => { "192.168.1.62", "192.168.1.61" };

and cf-agent is configured in update.cf,

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 promises.cf update.cf cf-serverd.cf /var/cfengine/inputs

Note that the server is also getting copies of update.cf and all the other files; during normal functioning, any changes you make to cf-serverd.cf 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 failsafe.cf and update.cf 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 failsafe.cf from the directory that contains failsafe.cf:

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.

Scheduler

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 (cf-execd.cf) 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 root@example.com with 92.168.1.61 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

cf-execd.cf

01     body executor control {
02         splaytime => "1";
03         mailto => "root@example.com";
04         smtpserver => "192.168.1.61";
05         mailmaxlines => "1000";
06         schedule => { "Min00_05", "Min30_35" };
07         executorfacility => "LOG_DAEMON";
08     }
09     bundle agent executor {
10     processes:
11         any::
12             "cf-execd"
13                 restart_class => "start_cfexecd";
14     commands:
15         start_cfexecd::
16             "/usr/local/sbin/cf-execd";
17     }

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 promises.cf. 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.

Read full article as PDF:

Cfengine.pdf (463.98 kB)

Related content

Comments

  • reply to pghpete

    There is no package named flex-devel in RHEL/CentOS 5.4, although there should be. Instead, libfl.a is part of the flex package, so you cannot crosscompile. I found this attempting to compile the latest setkey (ipsec-tools) for i386 on an x86_64 host.
  • Can't believe the trouble...

    I can't believe the trouble I was having getting ver 3.0.3 of cfengine installed on either RHEL 5.4 or CentOS 5.4... as it turns out, it's still a personal problem. Argh. What an inept bum I am today... forgot cardinal rule number 1, read the INSTALL file and install all dependencies it asks for. Which, were surprisingly extensive...

    'yum install openssl openssl-devel db4 db4-deve flex flex-devel bison bison-devel pcre pcre-devel'

    Then your './configure && make && make install' should run without issues on either distro.
  • Many issues while trying to follow your article

    I read your article and enjoyed it. Thank you. I ran into a few problems so I figured I would comment for the benefit of others who may encounter the same issues. ** Long story short: compile and install from source if you want to follow this articles instructions... for details keep reading **

    I decided to use a package utility instead of compiling the source.

    RHEL 5.4:

    'yum install cfengine' worked without incident

    CentOS 5.4

    'yum install cfengine' reports package not found, nothing to do.

    I thought this was quite strange since CentOS, from my knowledge, is near identical to RHEL 5.4 ( including their repository content)

    Apparently, you have to install rpmforge just to get the package for CentOS 5.4. Here is what I did to accomplish that...

    'wget http://packages.sw.be/rpmfo...elease-0.5.1-1.e15.rf.i386.rpm'
    'rpm -Uvh rpmforge-release-0.5.1-1.e15.rf.i386.rpm'
    (as rpmrepo.net/RPMforge instructs)

    After that a 'yum install cfengine' worked without incident. At this point I figured my troubles where over,... nope!

    While trying to follow your "Hello, World" instructions, I couldn't figure out why there was no command cf-key, or cf-agent on my systems... a quick 'man cfengine' showed me why... ah... it's cfkey and cfagent. I figured it was just the authors typo(s). Then, the files and directories that I was directed to create/alter were not on my systems either. Hum... strange. I was about to give up but then I ran 'rpm -q cfengine' on both systems and had my "Ah ha" moment... both of my test distros are Enterprise OS systems and therefore, their package versions are way behind the most recent versions of anything. I totally missed the first sentence of paragraph two in which Mr. Strejcek states clearly, "To show what is possible with Cfengine 3,..."

    I can't believe I missed that! I had ton of problems, but they were all self-inflicted wounds. Had I just caught that line... aw well.
comments powered by Disqus

Direct Download

Read full article as PDF:

Cfengine.pdf (463.98 kB)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia