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: Thu, 24 Feb 2005 12:25:25 +1100 (EST)

Mark Burgess wrote:

I am so sorry to be slow at answering this -- I was going to make a
little example solution for you, but I am really swamped and have not
had time.

I think you could do this with a "method". i.e. import and then
editfiles. That would do the trick. I shall try to find time for this
soon, before this falls over my mailbox horizon again.

I started working on a method for this yesterday morning, since it's a problem I have too.


On Wed, 16 Feb 2005, Knut Auvor Grythe wrote:

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

Is there a reason you define "generate_sshd_config" twice? As a more general question, which condition do you want the class defined on?

This approach has a number of disadvantages:
* It is cumbersome and error-prone to do all this writing for each file

        A cfengine method will eliminate this.

* We re-implement a lot of cfengine functionality when testing if the
  file should be regenerated

        Sorry, I don't understand this.

* A lot of M4 files have to lie around

A method would also need a "tidy" clause to fix this. I'm not intending to implement it straight off, but would hope to make it an option later.

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

        Instead, you'd use:

method:
        all::
                InstallTar(/etc/ssh/sshd_config,/local/admin/bin/m4wrap,m4)
                        action=deploy.cfa
                        returnvars=null
                        returnclasses=null
                        server=localhost

The third parameter (m4) is the extension on the file. It'll basically copy from a local root to the dest. So you'd have /path/to/ turned into /path/to/etc/ssh, and you'd customise the module to define localroot = /path/to/

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

Both about the same for methods. I'd be in favour of the stdin/stdout method, because a lot of the things that take them as command line options need switches for both, and that makes things trickier. It'd probably be possible to make this an option, though.

* The $CFALLCLASSES variable must be defined (at least when using -u), so
  the wrapper has info about the classes defined on the machine

This is the only real difficulty here. I can't determine clearly from the documentation how many classes are defined when the method is started. My expectation from other languages (Perl :) ) is that all the same classes are defined, and any classes defined in the method are discarded at the end of the method (unless returned). If this isn't what happens, I'd like someone to let me know.

        :)

--
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: address@hidden
http://www.webalive.biz/

"Your Business, Your Web, Your Control"




reply via email to

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