help-cfengine
[Top][All Lists]
Advanced

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

Re: Getting $(allclasses) into a shellcommand


From: Ed Brown
Subject: Re: Getting $(allclasses) into a shellcommand
Date: Tue, 20 Jul 2004 15:18:24 -0600

To back up a little, and to try to understand this thread a little
better, it seems like it should be said that being able to pass
$(allclasses) to another script works just fine, except when it grows
very long.  

1. What are the limits we are talking about?  Buffer sizes in cfengine? 
Bash command line limits?  Without knowing what the problem is, it's
hard to weigh some of the solutions that have been offered.  

2. When do too-long $(allclasses) strings get created?  So far, I've
only seen it mentioned with respect to 'packages:'.  Defining classes is
the only action available in 'packages:'.  It would be great if you
could execute arbitrary commands, as in 'processes:'.  This could help
eliminate some of the need to rely on class definitions.  This
possibility was discussed in a thread several months ago,
http://lists.gnu.org/archive/html/help-cfengine/2003-11/msg00061.html
, and I wonder if the implementation might still be in the works?? 

thanks,
Ed


On Tue, 2004-07-20 at 13:52, Ted Zlatanov wrote:
> On Tue, 20 Jul 2004, borwicjh@wfu.edu wrote:
> 
> Mark.Burgess@iu.hio.no wrote:
> >> I am interested in finding a different solution to this problem.
> >> Any ideas would be welcome.
> >> M
> > 
> > Could you add a new option to shellcommands that sends all the class
> > variables to STDIN?  E.g.
> > 
> > shellcommands:
> >    "/path/to/program" stdin=allclasses
> 
> I'm divided about this proposal.  On the one hand, it's elegant and
> very much in the Unix spirit.  On the other, it means cfengine can't
> use STDOUT for any other communications with the client program.
> 
> I propose the following:
> 
> 1) providing a "classoutput" option which can be "stdout," "file," or
>    nil (the default).  With "stdout" the above happens.  With "file"
>    the user can expect the name of the file in the CFCLASSOUTPUT
>    environment variable; the file contents will be as in (2).
> 
> 2) Some communication protocol between cfengine and programs it
>    spawns.  This should be synchronous, so the cfengine feed to the
>    child could be:
> 
> CFALLCLASSES=a
> CFALLCLASSES=b
> CFALLCLASSES=c
> CFALLCLASSES=d
> ...
> 
> CFSECTION=shellcommands
> CFPID=$$
> CFINSTALLABLECLASSES=a
> CFINSTALLABLECLASSES=b
> CFINSTALLABLECLASSES=c
> ...
> 
> The advantage of the format above is that it's pretty much standard
> Unix lingo, so parsing it is trivial for apps like Perl or shells.
> 
> We already have the "cfengine-die\n" protocol for communication back
> from the spawned program to cfengine :)
> 
> Ted
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine





reply via email to

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