System administrators, rejoice! Cfengine, an open source project, synchronizes systems across platforms (even Windows), corrects errors as they occur, reports on security vulnerabilities, collects statistics, and finds "strange" behavior! Changes can be made on a server and automatically rolled out to each client.
cfengine is made of a few programs:
Mark Burgess, a professor at Oslo University, has presented several papers based on his development of cfengine: Cfengine: a system configuration engine, Cfengine: a site configuration engine, Strategies for distributed resource administration using cfengine, Adaptive locks for frequently scheduled tasks with unpredictable runtimes, Automated system administration with feedback regulation, Cfengine as a component of computer immune-systems, Computer immunology, Evaluating cfengine's immunity model, Scalability of peer configuration management in partially reliable and ad hoc networks, On the theory of system administration, Configurable immunity for evolving human-computer systems, Predictable configuration management in a randomized scheduling framework, Recent Developments in Cfengine, Two dimensional time-series for anomaly detection and regulation in adaptive systems, Probabilistic anomaly detection in distributed computer networks, and Principle components and importance ranking of distributed anomalies.
This guy's not playing around. Cfengine uses some advanced computer science techniques, like "SplayTime" to randomize when clients run so that they don't all overload the server, locking to guarantee that processes don't run too often, and cryptography. Because Mark Burgess has made cfengine a critical part of his research, cfengine has a lot of flexibility and power.
Syntax
You tell cfengine what you want, and cfengine makes it happen. The difficult part about setting up cfengine is learning the extensive vocabulary and reading confusing documentation. In general terms, cfengine statements look like this:
action-name:
action-specific-commands
class-name::
action-specific-commands
class-name.class-name::
action-specific-commands
class-name|class-name::
action-specific-commands
Your program won't do anything unless it has the "control" action, with an "actionsequence" variable. A cfengine program with every action defined would have an actionsequence like so:
control:
actionsequence = (
mountall mountinfo
checktimezone netconfig resolve
unmount packages shellcommands
editfiles addmounts
directories links
mailcheck mountall required
tidy disable files
copy processes
)
Basically, each action listed in the actionsequence needs its own section, defining what to do for that action. Each action's syntax is defined in the cfengine Reference guide; see <http://www.cfengine.org/docs/cfengine-Reference.html>.
Cfengine defines some "classes" for you to describe the current state of the system. Here's a sample of the defined classes on a FreeBSD 5.1 machine:
% cfagent -v | grep Classes
Defined Classes = ( any cfengine_2_1_5 cfengine_2_1 cfengine_2 Sunday Hr01 Min44 Min40_45 Q3
Hr01_Q3 Day15 August Yr2004 freebsd jedi_starwars_example_com starwars_example_com jedi 32_bit
freebsd_5_2_1_RELEASE_p9 i386 freebsd_i386 freebsd_i386_5_2_1_RELEASE_p9
compiled_on_freebsd5_2_1 net_iface_fxp0 net_iface_ )
cfenvd will give you access to some crazy standard deviation metrics about how the machine's operating currently compared to the past. Pulled from Burgess's Anomaly detection with cfenvd and cfenvgraph webpage, here are some example classes:
RootProcs_low_dev2
netbiosssn_in_low_dev2
smtp_out_high_anomalous
www_in_high_dev3
ftp_in_high_microanomaly
You can also define your own classes in the "groups" action.
Here's a sample file, for you learn-by-example people:
control:
any::
actionsequence = ( resolve editfiles )
EmptyResolvConf = ( true )
groups:
any::
private_network = ( jedi saber )
resolve:
# any:: is assumed if not stated
10.1.1.1 # primary nameserver
10.1.1.2 # secondary nameserver
10.1.1.3 # tertiary nameserver
editfiles:
linux::
{ /etc/hosts
AppendIfNoSuchLine '127.0.0.1 localhost.localdomain localhost'
}
private_network::
{ /etc/hosts
AppendIfNoSuchLine '192.168.1.1 secret-server'
}
All cfengine's files are stored in /var/cfengine. There are two important subdirectories:
A typical cfagent/cfenvd session will first read /var/cfengine/inputs/update.conf and then read /var/cfengine/inputs/cfagent.conf. update.conf is supposed to stay stable, so that if you screw up cfagent.conf you can still download changes from your server and do the necessary initializations to get cfagent.conf to work. The "import" class lets you further divide your configuration files.
When you run cfagent, you may be frustrated to find that your configuration files aren't actually being run. cfagent is designed to work without overloading your system even if cfagent were running constantly, so it has locks. Run it as so to make sure everything's executed:
cfagent -Kq
-K ignores locks; -q turns off "splay time." Even better, add the verbose option: cfagent -Kvq.
More Information
Luke Kanies's introduction to cfengine, as seen on O'Reilly's OnLamp.com, is an excellent starting point. Find a link to his introduction and the official cfengine documentation at <http://www.cfengine.org>.
Sources
http://www.cfengine.org
Personal experience.
| 
