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

[Tim Nelson]

On Thu, 24 Feb 2005, Knut Auvor Grythe wrote:

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

        Great!  That tells me what order to put the actionsequence :).

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

	By this, do you mean that the groups section duplicates something 
that you think "copy" should be doing?

> > 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 ;-)

	Typo, based on pasting examples from the doco and modifying them 
:).  Here's another try.

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

	Either that, or my subconscious thought I should be tarred and 
feathered :).

> > 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 :-)

	Yes.  I guess that I'm coding for my needs here :), and I just 
have a skeleton filesystem which I want cfengine to overlay on the target 
:).

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

	Yeah, that's what I thought too.  Unless I can figure out some way 
to get it to guess, based on:
1.      #! lines
2.      The extension (<-- evil Windows-type thinking here) +
        /etc/mime.types

        For now, though, I'll settle for passing it in.

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

	Yeah, I guess my assumption was that wrappers would be made for 
the non-conforming group, and I figured that the stdin/stdout group was 
larger than the command-line-with-no-switches group.

> > > * 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 ;-)

	Yeah :).  I guess I wanted to send this e-mail before Mark felt he 
had to start duplicating my work, so I sent it before I had finished 
everything :).

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