« Odds and Sods .... | Main | Return of the architects »
January 20, 2004
Cfengine
The posting has been a little light yesterday and today because I have been flat out migrating essential administrative services from one work system to another. Most of the pain comes from in-dah-viduals who are all convinced that their particular requirements are so unique they need to be treated separately. The deal is that we use an amazing product called 'cfengine' to manage a large number of Unix servers. Each server runs a different mix of applications in possibly different modes (production, test, development, etc). To maintain some semblance of order, cfengine has a set of 'standard' files for a given operating system version. In some cases the files are intended for a particular OS and in other cases they are more widely applicable. Take for example the /etc/inet/hosts (sometimes called /etc/hosts). This contains a basic list of host names and addresses, which is fairly common. Most servers on the network need to know similar things like:
- what is my address (when I know my name)
- what is the address of the log server
- what is the address of the DNS server
and so on. This can be accomplished by storing the names (and addresses) of all the managed hosts in a common host file. Cfengine then takes this file and makes sure that everybody gets a copy. More particularly it insists that everyone gets a copy of it. You edit your local host file and cfengine overwrites it. How can you make changes? Well there are two types of changes - global and local. If your change is one that everyone needs to know about (e.g. a new host) then it can go in the master file and everyone will get a copy of it. If your change is local (e.g. an alias or name specific to an application on your box) then it goes in the cfengine edit rules. These rules specify what makes a particular box different. The edit rules can comment out an existing line and insert a new one or just append some alternate information. Why bother? Well this means that the configuration of a host - the things that make it 'different' to 'normal' and now recorded. This record is normally stored in some form of version control so that changes can be tracked. If tomorrow this server dies with some major hardware failure, we can rock in a new vanilla box, jumpstart it (install the operating system) and then run cfengine to get exactly the same configuration that was there before the failure. More importantly when there are problems there is a central repository of the differences that matter for a particular server. There are two problems with this approach, the first is that the some rigour is required when setting the system up. Each variation must be recorded and entered to start the system and this can be time consuming (hence what I have been doing). The second (and far larger) problem is the users who can no longer make changes willy-nilly to configuration files. They are now forced to follow a change mechanism (to which they all give lip service but ignore when it comes to doing things for their own servers).
The biggest hassle is those users who are determined to remain outside the system because they are "exceptions". They do not want to follow change procedures. They do not want someone "managing" "their" servers. They do not want the benefits of automation. And sometimes they can pressure line managers into agreeing with silly propositions. The list of exceptions last time correspond 100% with the list of problems this time (as we migrate to larger servers and newer versions of the software). Hopefully this time senior management will maintain their current support for automation (= reduction in support personnel - which has already happened) and central ownership (= servers owned by operations, not users). My fingers are firmly crossed because I refuse to fight the political battles again (how did you think I got a reputation for being obstructionist?). At the first sign of capitulation on the part of management, I will wash my hands of the entire project (that is the benefit of being a consultant).
Posted by Ozguru at January 20, 2004 09:01 PM
Comments
Posted by: Skipjack at January 20, 2004 09:01 PM
