Use of editfile to support templated configuration files

[wbmccarty]

Hi all,

I'm trying to determine the appropriate architecture for managing
certain configuration files. As a newcomer, I'd welcome any
suggestions, particularly from those who've been there <g>.

I've identified three broad architectural options: (1) use editfiles to
revise whatever configuration file contents currently exist; (2) fetch
a standard configuration file if the current file's MD5 differs from
that of the standard file; or (3) fetch a template, use editfiles to
instantiate it, and replace the current configuration file with the
instantiated template if the two files have different MD5 values.

In my case, I don't favor option #1 because I'd prefer to have the
ability to reconstruct the configuration from centrally managed data.
Tweaking the current file's contents won't provide me with a full
record of the configuration. Of course, I could use copy to upload the
current configuration file to a server. But, I also prefer that
cfengine read files from, but not write files to, the policy server.

I can't see how to acccomplish option #2 very concisely. In general,
there will be several versions of a configuration file: a standard
version applicable to multiple hosts and one or more additional
versions peculiar to specific hosts or groups of hosts. I might
simplify matters by having a distinct copy of the file for each host.
But, the benefit in reduced cfengine script size is offset by the
proliferation of files.

Alternatively, I'd like to somehow be able to specify a hierarchy of
host groups, and have cfengine choose the file at the lowest level for
which a  version of the file exists. This would be pretty easily done
using an external module. But, I'd prefer to avoid external modules for
now and I don't see how to manage such a hierarchy concisely using
cfengine scripts.

It looks to me like I'd need a set of file actions for each
configuration file, having one action for each level of the hierarchy.
And, I'd have to ensuure that (1) the actions are tested in order from
the bottom to the top of the hierarchy, and (2) only one action fires.
I'm not certain how cfengine decides the order of operations, but I
presume that the ordering of actions dictates the order in which
they're tried. At least, it's easy to ensure that only one action
fires, since a firing action can set a define that prevents actions at
higher levels from inappropriately firing.

Option #3 appears to me to be the cleanest. But, I don't see how to
implement it. To do so without sacrificing convergence, I seem to need
a way to instantiate a template without altering the template itself.
But, I don't find a way to cause editfiles to read one file and write
another.

Perhaps my model of the template process is faulty. I imagine a
three-step process: (1) a file action pulls a configuration template
from a central repository if the local copy has a different MD5, (2)
editfiles instantiates the template and places the result in a staging
directory, (3) a file action compares the staged configuration file
with the actual configuration file and replaces the configuration file
if the MD5s differ.

Thoughts, anyone?

Cheers,