[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature request: Ability to parse files with a custom parser
From: |
Tim Nelson |
Subject: |
Re: Feature request: Ability to parse files with a custom parser |
Date: |
Fri, 18 Feb 2005 13:37:26 +1100 (EST) |
On Wed, 16 Feb 2005, Knut Auvor Grythe wrote:
I hope this is the right place to post this. The bug tracking system on
SourceForge did not look like it was in use.
This is probably as good a place as any.
What we use now is wrappers for a number of macro languages, M4 being the
most commonly used. Our wrappers read the $CFALLCLASSES environment
I've done similar things (but all Perl).
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) )
Why do you need this if you set it on copy, below? Just a
double-check?
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 :-)
I'd vote in favour too, unless the list comes up with a better way
of solving the problem, which I guess is the need to generate config files
based on both cfengine classes and information only available on the
local machine.
Of course, you could generate the required cfengine config on the
server, which does all the copying and everything else :).
:)
--
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne,
Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/
"Your Business, Your Web, Your Control"