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

Tim Nelson Wed, 23 Feb 2005 21:16:06 -0800

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

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

Reply via email to