Re: Feature request: Ability to parse files with a custom parser

[Tim Nelson]

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

"Your Business, Your Web, Your Control"