I hope this is the right place to post this. The bug tracking system on
SourceForge did not look like it was in use.
I work for the IT Department on NTNU, Trondheim. We have some rather
complicated setups in our cfengine here, and need a way to generate config
files based on the classes defined on a client. It is a bit too
complicated for using EditFiles, I'm afraid.
What we use now is wrappers for a number of macro languages, M4 being the
most commonly used. Our wrappers read the $CFALLCLASSES environment
variable set by cfagent -u, and parse the file based on this information.
Right now, we solve this problem like in this somewhat simplified example:
control:
AddInstallable = ( generate_sshd_config )
groups:
all::
# Check if we need to regenerate the file
generate_sshd_config = (
!ChangedBefore(/etc/sshd/sshd_config.m5,/etc/sshd/sshd_config) )
copy:
all::
/path/to/sshd_config.m4
dest=/etc/sshd/sshd_config.m4
define=generate_sshd_config
shellcommands:
generate_sshd_config.generate::
"/local/admin/bin/m4wrap /etc/ssh/sshd_config.m4 /etc/ssh/sshd_config"
This approach has a number of disadvantages:
* It is cumbersome and error-prone to do all this writing for each file
* We re-implement a lot of cfengine functionality when testing if the
file should be regenerated
* A lot of M4 files have to lie around
What we would like to see, is an option in copy for using a custom parser,
like so:
copy:
all::
/path/to/sshd_config.m4
dest=/etc/ssh/sshd_config
parsecmd=/local/admin/bin/m4wrap
This approach would eliminate all the problems stated above, plus it would
be an extremely flexible and powerful feature. I also think it looks
pretty easy to implement.
I can think of the following requirements to make such a feature useful:
* Either pipe the file though the parser or give source and dest as
arguments to it, depending on what is the easiest to implement
* The $CFALLCLASSES variable must be defined (at least when using -u), so
the wrapper has info about the classes defined on the machine
Checksumming might be a problem. Checksumming the output of the parser
would naturally work, but an ignorant solution causing the checking to
always fail when a parsecmd is defined would be good enough for me. It
probably just depends on how much one wants to put into it.
Does this look like a feature worth implementing? I would be eternally
grateful if it was :-)
--
Knut Auvor Grythe
ITEA Systemdrift
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
