Server-less Configuration Management

Introduction

Configuration Management Systems (CMS) are most often setup using a central server to distribution the management policies. Installing a central server is a non-trival task and adds to the server management load of the technical staff.

This document describes an alternate configuration without a central CMS server. Policies are distributed to the hosts by some method other method than the services provided by a central server. The policies are applied using the locally installed CMS software. The method described here assumes that the policies are publically accessible which means they cannot contain any secrets, e.g. passwords, secure tokens, or keytabs.

The example here is Linux based and uses the Puppet CMS. The general method should work for Chef Solo as well. In theory, Windows and Macintosh systems can be supported using this method, but that is completely untested.

The basic requirement for a serverless CMS deployment is that the CMS policies be available locally on every host under management. The delivery method is not critical to the operation of the CMS. The policies can be copied to the managed hosts or accessed using a networked file system. The method described here uses AFS to publish CMS policies.


Puppet Policy Structure

There are many ways to structure policies in Puppet. A simple structure is:

    BASE_DIR
        bin
            puppet-apply
            puppet-setbasepath
        code
            modules
                <module 1>
                <module 2>
                ...
        <manifest id 1>
        <manifest id 2>
        ...
  • BASE_DIR is the base for Puppet policies and supporting scripts. An example BASE_DIR is:

      /afs/mycell.org/public/software/puppet-apply
    
  • bin is a directory that holds the shell scripts to setup the Puppet and to execute puppet apply.

  • manifest id is used to form the file path to the manifest which is passed to puppet apply. While Manifest IDs can take any form, the examples here use the format:

      ${BASE_DIR}/${MANIFEST_ID}.pp
    
  • code is the directory that holds the Pupppet manifests.


CMS Policy Access Methods

The access methods described here rely on using either kafs or an Auristor client.

Simple Authenticated Access

Simple authenticated access can use either kafs or an Auristor client. The basic requirements are:

  • Create a Kerberos keytab to be used on the managed system that will be used to obtain AFS credentials.
  • Create an AFS ID for the Kerberos principal.
  • Grant the AFS ID access to the CMS policies.

It makes sense to create a PTS group, add the managed hosts to the group, and use the group to grant access to the CMS policies. Once the PTS group and ACLs are set then adding a host is a matter of creating a user for the new host and adding the host ID to the pts group.

The simplest way to apply the Puppet policy is to create a shell script that obtains AFS credentials and executes puppet apply.

Auristor Combined Authenticated Access

On managed systems where the Auristor client is installed then combined authentication ACLs and cache manger maintained AFS credentials can be used to simplify access to the CMS policies. The requirements are:

  • Create a Kerberos keytab and make it available to the cache manager.
  • Create an AFS ID for the Kerberos principal.
  • Configure the cache manager to maintain the AFS credentials.
  • Set a combined identity access control entry on the directories in the CMS policy directory tree.

Then to apply the Puppet policy someservice the command is simply:

  puppet apply /afs/@cell/service/puppet/someservice.pp

Anonymous Access

For closed environments where who has access to the CMS policies is not a concern then anonymous to the policies simplifies the application of the policies. For these environments only the AFS ACL be set to allow anonymous access. For example:

  fs sa /afs/mycell.org/service/puppet anonymous read

Then applying the CMS policy is simply:

  puppet apply /afs/@cell/service/puppet/someservice.pp

Examples

Setup Common to kafs and Auristor

Install puppet on the managed host and configure the base module path.

  1. Install puppet.

  2. Set the Puppet base path. Using bash directly the base path can be set with the following commands:

     BASE_DIR='/afs/mycell.org/public/software/puppet-apply'
     ppath="${BASE_DIR}/code/modules"
     ppath+=':/etc/puppet/code/modules'
     ppath+=':/usr/share/puppet/modules'
     echo "basemodulepath = $ppath" > /etc/puppet/puppet.conf
    
  3. On a host with pts installed, create the PTS group whose members will have access to the CMS policies.

     pts creategroup -name puppet-hosts
    
  4. Create a puppet manifest. For example:

     # file: /afs/mycell.org/service/puppet/someservice.pp
     include util_base,
             sys_someservice
    

kafs Setup and Execution

All steps that use pts and fs commands need to be performed on a host that has Auristor or AFS installed. The fs command that set ACLs will likely need to be perform recursively. Recursive fs is available as the fsr script found in the afs-admin-tools package.

  1. On a host with pts installed, create the PTS user for the host somehost and add the user to the PTS Group.

     pts createuser -name rcmd.somehost -type machine
     pts adduser -group puppet-hosts -user rcmd.somehost
    
  2. On a host with fs installed, set the ACL on the Puppet base directory. (Note: this ACL needs to be set on all directories in the base directory tree.)

     fs sa /afs/mycell.org/service/puppet puppet-hosts read
    
  3. Execute puppet-apply. The following script is sufficient:

     #!/bin/bash
     export AKLOG=/usr/bin/aklog-kafs
     /usr/bin/k5start -k /tmp/puppet.tgt -f /etc/krb5.keytab -U -t
     puppet apply /afs/mycell.org/service/puppet/host_service.pp
    

Auristor Setup and Execution

This example uses the cache manager maintained AFS credentials to access the Puppet policies. The fs command that set ACLs will likely need to be perform recursively. Recursive fs is available as the fsr script found in the afs-admin-tools package.

  1. Configure the cache manager to maintain AFS credentials. Assuming the use of the host keytab, then in the [afsd] block of the /etc/yfs/yfs-client.conf file include the following line.

     keytab = /etc/krb5.keytab
    
  2. Restart the cache manager.

  3. Create the PTS user for the host somehost and add the user to the PTS Group.

     pts createuser -name host.somehost.mycell.org -type machine
     pts adduser -group puppet-hosts -user host.somehost.mycell.org
    
  4. Set a combined identity ACL on the Puppet policies directories. (Note: this ACL needs to be set on all directories in the base directory tree.)

     fs sa /afs/mycell.org/service/puppet anonymous,puppet-hosts read
    
  5. Execute puppet-apply. The following script is sufficient:

     puppet apply /afs/mycell.org/service/puppet/host_service.pp