help-cfengine
[Top][All Lists]
Advanced

[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"




reply via email to

[Prev in Thread] Current Thread [Next in Thread]