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: [EMAIL PROTECTED]
http://www.webalive.biz/
"Your Business, Your Web, Your Control"
_______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
