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

[Knut Auvor Grythe]

On Thu, Feb 24, 2005 at 12:25:25PM +1100, Tim Nelson wrote:
>       Is there a reason you define "generate_sshd_config" twice?  As a 
> more general question, which condition do you want the class defined on?

Yes, as I wrote in an earlier post, if something goes wrong parsing the
file (for instance a bug in the parser or the run is interrupted for
some reason) then the file should be generated on the next run. That's
what the test is for. It should also be regenerated if the defined
classes on the client changes (since that might change the content of
the output file), but that was not implemented in my example.

>> * We re-implement a lot of cfengine functionality when testing if the
>>  file should be regenerated
> 
>       Sorry, I don't understand this.

Since cfengine is doing all comparisons etc on the m4 file, while we
really are interested in keeping the output file up to date, we need to
do all the checks cfengine normally would have done on the output file
manully.

> 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. 

I could definately live with that syntax :-)
I'm not sure why it is called InstallTar, but I suppose there is either
a good reason or a typo ;-)

> So you'd have /path/to/ turned into /path/to/etc/ssh, and you'd
> customise the module to define localroot = /path/to/

I think it would be more flexible to just have two arguments, so the
repos isn't forced to have the same directory structure as the client,
but I presume taht would be easy for me to hack into the method :-)

A mapping from file extension to wrapper would save some typing, but I
guess specifying it every time is more flexible.

>   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.

One would probably make custom site-specific wrappers anyway, so I think
one would manage to make all the wrappers use one of the two (for
instance stdin/stdout).

>> * 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.

I suppose that is pretty easy to test. If you make the method write the
class definitions to disk, add a 
    "/bin/echo $CFALLCLASSES > /tmp/cfclasses"
shellcommand somewhere, run cfagent -u and compare the two outputs.
All this assuming I didn't misunderstand what you meant ;-)

-- 
Knut Auvor Grythe
ITEA Systemdrift