[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfengine-develop] ExecResult results interpreted as a list

From: Mark . Burgess
Subject: Re: [Cfengine-develop] ExecResult results interpreted as a list
Date: Fri, 9 Jan 2004 20:00:19 +0100 (MET)

I agree with this patch and am applying it, subject to a note in
the manual.

On  2 Dec, Luke A. Kanies wrote:
> Hi Mark,
> This is the third time I've encountered this, so I'm going to bring it up
> this time.
> As I mentioned in my previous email, I'm calling an external script within
> cfservd.conf and trying to use the results of that script to decide whom
> I'm going to allow to connect to cfservd.
> For a little background, the reason I'm doing this is to reduce the number
> of manual steps involved in building a server.  I already am putting all
> of my servers in LDAP, so if I can have cfservd retrieve all IP addresses
> from LDAP, that would be very easy.  Otherwise I'm going to have to
> dynamically generate a cfengine file with all of the IP addresses and then
> import that file.  I can do this, but I've already got a bunch of these
> and they're really, really annoying.
> So, I want to retrieve a list from LDAP.  Well, call an external script
> using ExecResult.  Okay, that's easy.  Problem is, only certain variables
> support returning lists, vs. strings.  For instance, if you call
> ExecResult within AddClasses, then the result is split based on the '.'
> character.  If you call it from within AddInstallables, the result is
> split based on '%'.  A very interesting point about both AddInstallables
> and AddClasses is that you can use ExecResult to set completely invalid
> classes, including classes containing spaces.  Go ahead, try it.  It's
> fun.
> There are probably a couple other variables that support lists, but these
> are sufficient.  We have completely inconsistent behaviour here.  Given
> three variables, two of them split based on separate characters and the
> third doesn't split at all.
> Just getting this far and understanding where everything happens is
> relatively complicated, and I'm apparently one of the few people who
> encounter this problem.  My guess is actually that many people encounter
> it but most just give up.  I guess I'm stubborn.
> So, my question is:  Is there any way we can bring some consistency here?
> I'm pretty convinced that this inconsistency is a result of how the parser
> is built, and making function call behaviour truly consistent would
> involve a lot of rewriting, but am I wrong?  Does someone see a good,
> simple solution?  Yes, I know that I could just add a wrapper function for
> every variable, like AddClasses has, but that's a hack and doesn't solve
> the deeper problem.  The section of cfengine (specifically in install.c)
> dealing with variables is already in dire need of abstraction.
> Frankly, I'd like to solve this problem by making the "variable" settings
> in cfengine into what the really are: function calls.
> Take the following snippet:
> control:
>   actionsequence = ( files )
>   actionsequence = ( shellcommands )
>   variable = ( files )
>   variable = ( shellcommands )
> The settings for variable result in a warning, but the setting for
> actionsequence result in actions being added to a stack.  Nearly all of
> cfengine's builtin variables would be better off as functions, from what I
> can tell.  I'm seeing if I could somewhat easily modify the parser et al
> to allow this, but as I mentioned, I don't think it will be terribly
> straightforward.
> My main point, though, is:
> Do you have any idea how we can relatively easily support using ExecResult
> to consistently gather more than one piece of data?  I need to allow every
> machine in LDAP access to cfengine, and I don't want to keep that list
> manually, and I don't want to have to generate a file that gets imported
> by cfservd.  That's a hack, and I hate it.
> Luke

Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :

reply via email to

[Prev in Thread] Current Thread [Next in Thread]