My colleagues and I have combined our resources and formed a new company, Evolve Thinking. We are stronger together. Cfengine is one of the corner stones of Evolve. To show what we are about we are releasing our own promise library, the Evolve Thinking free Cfengine library. Most of my future blogging will be on Evolve's site. You can still follow me on Twitter.
Recently in the cfengine Category
Giving a presentation and demo of Cfengine at the Toronto Linux User's Group August 14, 2012.
In the spirit of collaboration with my Cfengine colleagues I've moved my Cfengine 3 VIM files to Github. I hope that others will help grow this small body of work.
Cfengine’s time based classes and promise theory make it an attractive alternative to venerable crond.
You want to have your bundlesequence change based on class.
This question comes up regularly on the Cfengine mailing list. The secret is to build a string list based on class. The alternative is to use methods.
You want to monitor free disk space.
Cfengine has storage promises that can mount file systems and monitor disk space.
You want to ensure that a process is running.
This promise searches the process table for the regular expression “snmpd”. If this is not found the class “start_snmpd” is set. This class being set causes the command “/etc/init.d/snmpd start” command to be run.
You want to prevent certain processes from running.
In formal Cfengine parlance this promise ensures that there are zero instances of processes running that match the regular expression “snmpd”. If such processes are found a term signal is sent. If that signal is ignored a kill signal is sent.
Sometimes a file’s contents depends upon the class of host that the file resides on. This makes file copy promises impractical. Who wants to copy a different file for so many hosts? Sysadmins are a lazy lot.
Template files consist of two promises. One promise copies a base file whilst the second promise edits the base file. The key is the contents of the base file. It contains the names of Cfengine variables. These variables are expanded during the edit.
You want Cfengine to manage crontables.
The recipe we used edit authorized_keys can also be used for crontables.
You want to distribute public SSH keys.
There are two possible methods for distributing SSH public keys. The first involves a simple copy.
You Cfengine binaries are in /var/cfengine/bin but you want them in the PATH.
Symbolic linking the binaries is a good approach. The most simple method follows. Please note that you should look at the introduction entry to this series to better understand the setup.
In 2008 I wrote the original Cfengine cookbook. That edition covered Cfengine version 2. With the release of Cfengine 3 and its growing popularity it is time for a rewrite. This new edition takes the same approach as the first but it will be published one recipe at a time on this site. You’ll find practical examples of how Cfengine is used. You’ll be able to expand on these examples to create your own Cfengine policies.
To maintain the large quantity of servers typically found in enterprise organizations, systems administration must move beyond manual and custom scripts toward a centralized configuration management service. This move can save an organization considerable time and money.
It’s vicious cycle. Resources are spent auditing hosts. Many more are spent fixing all of the audit’s deficiencies. Then it’s back to business as usual. Time passes and hosts slowly degrade until the next audit. Repeat.
It might take an hour to plan, schedule and fix each host. That’s 100 hours for 100 hosts. Audit twice a year and you’ve spent 200 hours. What if you have a 1000 hosts? Using Cfengine you can audit your hosts and fix deficiencies automatically every day! Consider these typical policies.
- Disable services that are not required.
- No world writable files.
- Limited guid and suid files.
- Tighten file permissions in selected areas.
- Harden services by applying custom configurations.
- Ensure certain applications are not installed.
This can be a lot of manual work. Typically I see these policies applied at build time using services like Jumpstart and Kickstart. But what happens after hosts are built? Over time hosts will diverge from the ideal state set at build time. Cfengine can manage all of these requirements automatically and continuously. As Cfengine makes corrections and reports you’ll build a log of information that the auditors will love. It will show compliance.
Go above and beyond with more advanced policies.
- Monitor any file for content changes (e.g. Tripwire).
- Monitor host performance for statistical anomalies.
- Kill unwanted processes.
- Change all local root passwords.
- Disable local accounts and ssh keys.
- Change any of these policies and all hosts are updated automatically!
Before you finish your next 300 page audit report defeat this cycle. Find out how you turn audits from headaches into business as usual with Cfengine.
I and few others have been recognized by the creators of Cfengine for our contribution to Cfengine and its users.