What do you do if you have a large infrastructure that you must ensure is configured correctly, each and every day? The answer is Cfengine.
If you consider large computing infrastructures from an architectural point of view, they rarely resemble tidy planned communities; rather, they resemble cities with lax planning processes. Just as the latter tend to grow haphazardly, so too does the average computing infrastructure.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
This causes problems for system administrators, as existing scripts and monitoring mechanisms are hacked and then installed on new machines. It doesn't take long for a dozen slightly different versions of admin tools to be running throughout the environment. This can cause significant problems on an ongoing basis, as the administrative tools are brittle (prone to breaking when something changes in the environment, e.g., OS upgrades). The headache of bringing new personnel up to speed on the glue-and-baling-wire administrative tools is significant (and expensive) as well.
Cfengine was developed to address this problem. Rather than have a set of slightly different tools residing on may different machines, it uses a centralized approach that declaratively defines how machines should be configured and then ensures each machine implements that definition.
The advantages of this approach are obvious. First, the definition for each machine only needs to be kept in one place; this avoids the problem of each machine having its own set of administrative tools that must be worked on at that machine. Second, it enables easy updating of administrative settings since the change is made once and then pushed out to the rest of the infrastructure. Finally, due to cfengine's declarative, object-oriented approach, it is able to administrate differing machines (e.g., Solaris and Linux) all from one set of administrative files.
However, this power comes at a cost. One of the reasons the topsy-turvy administrative mechanisms are so common is that the marginal effort of adding another machine is relatively low; it's only when considering the overall administrative burden that it becomes clear how much work it is to keep up a fragmented infrastructure.
Implementing Cfengine requires setting aside time to familiarize oneself with the product and to plan its implementation across the infrastructure. Once this initial effort is concluded, the day-to-day work of administration is much reduced.
Cfengine works as a client/server system. A central server defines the system configuration and then each machine implements whatever portions of the configuration apply to it. Cfengine's meta-configuration can be set to allow the client machines to poll the central server or to have the central server push the config file out to the clients.
Cfengine runs off of a main configuration file called cfengine.conf. A very simple example file is listed below in bold:
# Comment... control: actionsequence = ( links ) links: sun4:: /bin -> /usr/bin # other links osf:: # other links
Essentially, the control section lists meta-information about the system and what actions Cfengine should take. In this case, the "links" action is to be performed. The specifics of the action itself are defined in the "links" section of the config file.
In the links section you will see two entries, one for "sun4::" and one for "osf::". The double colon indicates what Cfengine calls a class, which is its terminology for a set of machines that share a set of characteristics. In this case, the characteristic is type of operating system. So, rather than having to list each machine in the config file, the class is listed. When the client machine executes the configuration file, it will determine which of the actions it should execute based on whether it fits into a listed class. The determination of class can be far richer than OS type; things like day of week and month can also be define a class, which makes Cfengine convenient for regular maintenance or update tasks.
Our example file contained only one action: links. Cfengine is capable of a much richer set of actions, though. Here is a list of possible actions: groups, control, homeservers, binservers, mailserver, mountables, import, broadcast, resolve, defaultroute, directories, miscmounts, files, ignore, tidy, required, links, disable, shellcommands, editfiles, processes
With such a broad array of actions, Cfengine provides a very powerful administration tool. Because it knows about so many actions, system administration takes on much more of declarative aspect: you merely define what characteristics you want the infrastructure to have, and Cfengine implements them.
If you read my previous article on Nagios, another very flexible centralized system administration tool, you might wonder which is the right choice: Cfengine or Nagios. It probably doesn't have to be an either/or choice. Cfengine is very good at implementing standard system administration tasks, but doesn't provide a lot of extensibility (although the shellcommands action does offer the ability to add new commands), while Nagios is focused on raising alerts when something has gone wrong. There is overlap between the tools, but they could be configured to complement one another and make administering the infrastructure hyper-efficient.
This article has barely touched on the capability of Cfengine or given the barest hint of the flexibility its declarative configuration offers. Because it's so comprehensive and complex, here are some guidelines about how to move forward with it:
- Get acquainted with Cfengine at www.cfengine.org. Take advantage of the excellent resources and tutorials available on the site.
- Start small and simple. The "links" example above offers a good way to get going. Find one important system administration task that takes up a lot of time but isn't too complicated. Start by automating that task on a couple of machines. Then incrementally build on the initial implementation.
- Spread the work out over several weeks. It will take time to understand the system, and it will also require some experimentation. Don't try to do too much too quickly.
- Continue in a dual-mode after you get the initial implementation up and running. Check the machines that Cfengine is managing to be sure that what you think has happened actual happened.
Cfengine may seem like a lot of work to get up and running, but consider the effort in light of endlessly checking machines manually to be sure they're configured properly. With that in mind, cfengine may not seem like so much work, after all.
>> Find out more about the GNU cfengine.