The example is that of a very, very basic sudoers policy but the principles are easily extended to create much more complex policy. The general idea here is that we want cfengine to ensure that specific rules are always in place. Instructed properly, cfengine accomplishes this very well.

Warning: I don’t know anything. I’m just someone learning cfengine 3 and posting about it. If I’m wrong about something, let me know! If you find this at all useful, be my guest. That is all.

################################################################################
##
## FILE: sudo.cf
## DESC: Control /etc/sudoers file on various servers
##
################################################################################

bundle agent sudo
{

vars:

  "sudoers" string => "/etc/sudoers";

  "sudo"     slist => {
                      "%admin ALL = ALL",
                      "%sysadmin ALL = /sbin/mount",
                      "%devel ALL = /sbin/mount"
                      };

packages:

  Night::

  "sudo" -> "Security policy"
    comment               => "Ensure sudo is up to date every 24 hours (and only at night)",
    package_policy        => "update",
    package_method        => yum,
    package_architectures => { "$(sys.arch)" },
    action                => if_elapsed("1440");

files:

  "$(sudoers)" -> "Security Policy"
    comment      => "Append common configuration to sudoers",
    edit_line    => append_if_no_lines("$(sudo)");

}

As with last snippet I posted, the above does not even resemble a complete cfengine policy/configuration, just a small portion that can be contained in it’s own bundle. It can be put in a separate .cf file, imported by promises.cf and added to the bundle sequence, inheriting variables and classes! Also, just like last time I’m using cfengine’s built in interface for package management systems to ensure “sudo” is always installed via yum at night, every 24 hours.

What’s new here is file editing with edit_line and the use of iteration which proves to be very powerful in cfengine 3.

Editing Files

Editing files with cfengine is supposed to be easy but initially it seemed a bit awkward to me.

First you have the promise file promise:

files:

  "$(sudoers)" -> "Security Policy"
    comment      => "Append common configuration to sudoers",
    edit_line    => append_if_no_lines("$(sudo)");

Which makes some reference to the edit_line facility and what looks like a function name with append_if_no_lines(…).

Then you have the edit_line bundle defined elsewhere:

bundle edit_line append_if_no_lines(list)
{
insert_lines:

 "$(list)";
}

Which describes what “append_if_no_lines” actually does.

Of course I’m just learning cfengine and new things can often seem strange and scary but I am finally warming up to editing files with cfengine… I think. What I seemed to have initial trouble with was with the bundles necessary for edit_lines, as described above. The bundle within a bundle concept. The append_if_no_lines and append_if_no_line bundles I’m using are implemented in the cfengine std library, which is highly recommended so that you may avoid re-inventing the wheel a little bit.

For basic promises, to add or remove, comment or uncomments lines and the such there are good edit_lines bundles available in the stdlib. For other more complex or customized file editing, writing your own bundles will be necessary. Either way, understanding what a bundle is and how to create your own is key to fully grasping file editing and getting the most out of it. This seems obvious in retrospect but something I didn’t pickup instantly.

See the cfengine documentation for more about editing files, check the cfengine documentation. There’s waaaaay more good information over there and it’s from the cfengine team, not some random newb.

Iteration

Iteration is powerful mechanism within cfengine that harnesses the power of lists to express a large possible number of actions/operations with very little amount of code. When lists are used, single actions can be made to repeat for every item in a list by using the $(varname) syntax to refer to the list… which as it turns out is the same for scalar values! Funny that!

So cfengine allows us to define X different lines of code to ensure are in a file using only a single file: promise all with the same simple syntax as scalar variables? Brilliant!

A demonstration of iteration can be seen with the $(sudo) slist and the “Append common configuration to sudoers” file: promise. With this single promise definition, up to 6 actual promises are made because the $(sudo) variable is an slist. Each element or item in the list is iterated over in sequence and the promise is evaluated and acted upon, if necessary. The reason that up to 6 promises will be evaluated is the ifvarclass property of promise, ensuring the promise will only be kept if we’re in the context of the class… and looking at the promise to find out which class, we see another example of iteration using the $(sudo) list and the canonify function that turns a string into a class. Thusly, if the host currently running this policy defines all the classes that are tested by the ifvarclass iteration, 6 promises will be made. If the host defines 3 of the classes, then 3 promises will be made and so on, and so forth.

As a beginner, using lists and iteration effectively and creatively seems fairly important to getting the most out of cfengine 3.

Editing Files vs. Copying Files

In my previous snippet, I demonstrated how to promise to copy a file from a secure remote server if the local file does not match the server’s file in order to manage a configuration with cfengine. This time, I’m promising to add lines to a configuration file if they do not already exist exactly as provided.

This represents two rather different takes on policy. The first says: “The configuration must always be exactly like this file, byte per byte!” the second says “These lines must exist but I don’t care about anything else in the file”. The file copy method is what I would call hard policy and the second is soft policy. In the cfengine community solutions, they recommend managing sudo by copying an /etc/sudoers from a remote server. That way is great (just like my DenyHosts example) but this is just another way if you have a use case for cfengine not owning every byte of your configuration file.

Conclusion

Yeah, that’s about it. Enjoy.

Related posts:

1. Cfengine 3 Snippets Part 1: DenyHosts
2. Nanorcs: Ultrasimplistic Configuration File Revision Control
3. RHEL/CentOS, NFS and Firewalls

What is nanorcs? It’s a very simple bash script wrapper around the nano, the cute GNU version of pico and RCS, a basic but functional revision control software package. The script is used in place of a call to ‘nano’ when editing a file and it automates the tasks related to change management of configuration files including tasks such as check in/out, and prompting the user when a discrepancy between the current file version and the RCS version exist.

Basic Prerequisites

While few prerequisites exist for nanorcs, most of them should be quite simple to satisfy on any Linux system:

Nanorcs also makes some assumptions regarding the path to certain executables: it assumes the required executables are in your path!. I know I could have made it “cleaner” by providing a variable in which to set the paths, but this script was 99% written for me, on my systems… where the RCS and nano commands are in my path… and besides, if you’re reading this you can probably figure out how to edit it to suit you anyways! This is just an example of how this might be done, not necessarily a working solution for your systems.

Functionality

Using nanorcs

Using nanorcs is easy, but you always have to remember the key point that it must be invoked against a file that is in your current working directory! The basic calling convention is (assing the script is in your path!):

root@box:/etc/ssh
# nanorcs sshd_config

The Script

And finally, the script itself:

#!/bin/bash
#
# Name: 	nanorcs
# Desc: 	RCS wrapper around nano for editing config files
#

# Check if file exists in RCS
#
if [ ! -e $1,v ]; then
  echo "First time editing, checking file into RCS..."
  ci -l $1,v $1
else
  # Check if RCS version is different from local version
  rcsdiff $1,v $1 &> /dev/null
  if [ "$?" -eq 1 ]; then
    echo -n "File $1 is not the same as RCS version, clobber it (y/n)? "
    read clobber
    if [ "$clobber" = "y" ]; then
      co -l $1,v $1
    else
      echo -n "Commit current version to RCS (y/n)? "
      read commitfirst
      if [ "$commitfirst" = "y" ]; then
        rcs -l $1,v
        ci -l $1,v $1
      else
        echo "Nothing left to do, exiting..."
        exit
      fi
    fi
  else
    co -l $1,v $1
  fi
fi

nano $1

echo -n "Commit changes to RCS (y/n)? "
read commitfinal
if [ "$commitfinal" = "y" ]; then
  echo "Committing changes..."
  ci -u $1,v $1
else
  rcsdiff $1,v $1 &> /dev/null
  if [ "$?" ]; then
    echo -n "Do you want to revert to RCS version of $1 (y/n)? "
    read revert
    if [ "$revert" = "y" ]; then
      echo "Reverting to RCS version..."
      co -u $1,v $1
    else
      echo "Changes made have NOT been committed!"
    fi
  else
    echo "File unchanged from RCS version, BYE!"
  fi
fi

#
# END
#

That is all. Nanorcs is my ultra-simplistic solution to the minor hassle of managing configuration file revision. For more advanced users and admins, things like cfengine and pikt are certainly light years ahead of this in every way imaginable, but for those of you who don’t necessarily need or want a configuration engine, this type of solution seems to be suitable enough.

Related posts:

1. Time Navigator HA Cluster Agent Configuration
2. l2c.pl – Lines to Columns