[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 15:45:01 +1100 (EST) |
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"
- Re: Feature request: Ability to parse files with a custom parser, (continued)