As soon as you have more than one system to manage, it's time to start thinking about configuration and system management. Cfengine can take the complexity out of systems management.
As soon as you have more than one system to manage, it’s time to start thinking about configuration and system management. Plenty of open source configuration management tools exist, but two stand out from the pack — Cfengine and relatively newcomer Puppet. (See also Master of Puppet: System Management Made Easy.) While the two tools take different approaches, they both perform extremely well. We covered Puppet in the July 2007 issue of Linux Magazine, so I’ll cover Cfengine here.
Cfengine is a policy-based configuration management system written by Mark Burgess. It’s licensed under the GNU General Public License (GPL) and available for download from the Cfengine Web site. Cfengine uses a declarative language to define the desired end state of a system, as opposed to some other configuration management tools that define what should be done to a system.
Cfengine actions are carried out in a convergent manner, meaning it can be run any number of times on a system in almost any state, and end up with the desired end state. You can use Cfengine to automate a variety of tasks including checking and setting file permissions, creating and deleting files, maintaining configuration files, executing scripts and commands, reverting unauthorized changes, monitoring md5 checksums, restarting daemons, and warning you about system anomalies or aberrant behavior. Best of all, it can do all this in a heterogeneous operating system environment, so it’s OK if you’re running a mixture of Linux distros or a combination of Linux and other operating systems.
That list is only a small sampling of what can be accomplished with a solid configuration management tool. With that flexibility, however, comes complexity. Setting up Cfengine is not trivial and is extremely custom tailored to your individual requirements and environment. Due to those facts, this article is simply meant to be a brief introduction to Cfengine. I recommend that you initially implement Cfengine (or any configuration management tool) with a very simple configuration that manages a small amount of files. As you become comfortable with the setup you can slowly add complexity and take advantage of more advanced features. This gradual roll out will help you avoid frustration and mistakes. While the deployment of your more advanced configuration may take some time and involve a fairly steep learning curve, the end result will not only save you time but also provide a stable and solid infrastructure that lets you focus on more interesting tasks.
Installation of Cfengine in the standard
./configure && make && make install, if your distro doesn’t already have Cfengine packages available. Once installed, Cfengine provides of the following components:
cfagent An autonomous configuration agent (required).
cfservd A file server and remote activation service (optional).
cfexecd A scheduling and report service (recommended).
cfenvd An anomaly detection service (strongly recommended).
cfrun A way of activating cfagent remotely (use this as you need to).
cfshow A way of examining the contents of helper databases (helper).
cfenvgraph Ancillary tool for cfenvd (helper).
cfkey Key generation tool (run once on every host).
With Cfengine installed, let’s move on to configuration. As previously mentioned, while learning Cfengine your initial setup should be minimal. For instance, You can start out simply checking file permissions and then move on to centrally managing configuration files. I strongly recommend that you use a revision control system, such as Subversion, to manage those configuration files but it’s not strictly required by Cfengine.
Cfengine configuration is broken into actions, with functional actions that perform work and meta actions that control how Cfengine operates. The files action, which I’ll show you in a moment, is one of the many powerful actions built into Cfengine. Once you get into more advanced configurations, you can logically separate distinct functionality into separate files and use includes to bring them into Cfengine. Proper Cfengine configuration involves multiple configuration files. The first, cfagent.conf, defines the actions you’d like Cfengine to perform. A simple cfagent.conf that checks and fixes the permissions of /etc/passwd would look much like this:
actionsequence = ( files )
domain = ( yourdomain.com )
smtpserver = ( smtp.yourdomain.com )
sysadm = ( email@example.com )
/etc/passwd mode=644 owner=root action=fixall
You can now run
cfagent-v from a command line to verify that everything works as expected. While that will run Cfengine on your local machine, where Cfengine becomes useful is using it on distributed hosts. To enable remote execution you’ll need to configure public/private key pairs using
cfkey and properly configure update.conf, which controls updating the Cfengine configuration. There’s an example update.conf on the Cfengine site that you can use as a base. Once everything is working as expected you can add
cfexecd to cron.
0 * * * * /usr/local/sbin/cfexecd -F
We’ve barely scratched the surface of what you can accomplish with Cfengine. You’ll want to read up further on the various actions and implementation options available. When configured properly, Cfengine can be used to remotely management almost anything, including Cfengine itself. You can deploy new servers in a matter of minutes and ensure your infrastructure operates exactly how you’d like it to.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62