Cfengine: Distributing configuration across the cluster

From GridPP Wiki
Revision as of 10:24, 22 November 2006 by Graeme stewart (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Distributing your cfengine configuration across the cluster can be done in two ways:

  1. Telling cfengine to use a shared file space area, e.g. an nfs mount area.
  2. Using cfengine's update.conf to copy configuration files automatically to each host.

The second method is preferred as it's more robust (not relying upon nfs being available) and allows clients to continue to run agianst their local cfengine configuration if the master host is unavailable.

In fact, the second method is built into the way that cfagent runs. In the Cfengine: Getting started page cfagent looked for the update.conf file and tried to use it to update the configuration before running.

Client Configuration

To start this process try something like the following update.conf file:

#######################################################################
#
# This script distributes the configuration, a simple file so that,
# if there are syntax errors in the main config, we can still
# distribute a correct configuration to the machines afterwards, even
# though the main config won't parse. It is read and run just before the
# main configuration is parsed.
#
#######################################################################

control:
   actionsequence  = ( copy tidy )  # Keep this simple and constant

   domain          = ( my.tier2.ac.uk )  # Needed for remote copy

   #
   # Which host/dir is the master for configuration roll-outs?
   #

   policyhost      = ( master.my.tier2.ac.uk )
   master_cfinput  = ( /var/cfengine/inputs ) 

   #
   # Some convenient variables
   #

   workdir         = ( /var/cfengine )


############################################################################
 #
 # Make sure there is a local copy of the configuration and
 # the most important binaries in case we have no connectivity
 # e.g. for mobile stations or during DOS attacks
 #

copy:

     $(master_cfinput)            dest=$(workdir)/inputs
                                  r=inf
                                  mode=700
                                  type=binary
                                  exclude=*.lst
                                  exclude=*~
                                  exclude=#*
                                  server=$(policyhost)
                                  trustkey=true


#####################################################################

tidy:

     #
     # Cfexecd stores output in this directory.
     # Make sure we don't build up files and choke on our own words!
     #

     $(workdir)/outputs pattern=* age=7

#####################################################################

###
#
# END cf.update
#
###

Server Configuration

Of course, the server needs to listen for these copy requests, and this is done using the cfservd process. So configure this using /var/cfengine/inputs/cfservd.conf on the master server:

######################################################### 
# 
# This is a cfservd config file - it is used for the server 
# part of cfengine, for remote file transfers and control 
# over cfengine using the cfrun program. 
# 
######################################################### 

control: 
        domain = ( my.teir2.ac.uk ) 
        cfrunCommand = ( "/var/cfengine/bin/cfagent" ) 
        TrustKeysFrom = ( 192.168.0.0/255.255.0.0 )

any:: 
        IfElapsed = ( 1 ) 
        ExpireAfter = ( 15 ) 
        MaxConnections = ( 50 ) 
        MultipleConnections = ( true ) 

######################################################### 

grant: 
        # Grant access to all hosts with an internal domain address
        # Files should be world readable 

        /var/cfengine/inputs *.my.tier2.ac.uk

        # Make sure there is permission to execute by cfrun
        /var/cfengine/bin/cfagent master.my.tier2.ac.uk

######## 
# 
# END cfservd.conf 
# 
######## 

Obviously you'll need to change the IP address range and the domain to be appropriate to your site. The start cfservd on the master server.

If everything has been configured correctly then when cfagent runs on the client it will now grab a copy of master:/var/cfengine/inputs and put it into its local directory. Then cfagent can continue its run using this local configuration copy.

Trust

One concern about this process is how the cfengine server trusts the clients. This is discussed here, but in essence cfengine will encrypt (3DES) connections between the server and the client. The first time that the server and client connect they exchange keys (storing these in /var/cfengine/ppkeys). After this the same keys must be presented or the connection is refused.

The keys are stored as root-xxx.yyy.zzz.www.pub for remote hosts, where xxx.yyy.zzz.www is the host's IP address and root is the user, who should always be root! The keys owned by a client itself are localhost.pub and localhost.priv.

If you have a secure mechanism for distributing secrects across the cluster then the "trustkey" stanzas can be set to false, in which case you have to have the correct keys stored in ppkeys.