Re: RE: Réf. : RE: activating a class from shellcommands

[Chris Edillon]

On Wed, 6 Nov 2002, Wheeler, John wrote:

> good stuff. I'm amazed at how creative people are when adapting this tool to
> there problem. I was unaware of this behavior, but it makes sense based on
> one of the examples I read about import and how action sequence is appended.
> It never dawned on me that you could "compile" an action sequence in the
> same file.
> 
> pretty cool. 
> 
  very cool.  :)  just make sure that any classes you use for decision
making are defined at the same level as your control sequence.  that is,
if you're defining the majority of your classes in an included file,
you can't use those classes in any config files like cfagent.conf which
read in the included file.

> I know this thread is long, but I just wanted to be clear on what exactly I
> was looking for. I wanted a shell command, that is enabled from a class set
> in a previous successful copy in the action sequence, that could set a class
> (and gets passed the  $allclasses variable). 

  i don't believe this is possible, as the only external programs which
can set arbitrary classes have to be modules.  however, as i said before
all of the scripts you run via shellcommands should have $CFALLCLASSES
defined in the environment for you to use as you see fit (that is, you
don't need to pass the classes in as cfagent does it for you).

> copy:
>       /cfengine/software/pkgs
>               dest=/var/cfenigne/scripts/pkgs
>               type=checksum
>               server=cessna
>               define=checksoftware
> 
> shellcommands:
>       checksoftware::
>               '/var/cfengine/scripts/checksw $(allclasses)'
>                       define=copysoftware
>       
>       copysoftware::
>               '/var/cfengine/scripts/copysoftware'
>                       define=installsoftware
>       installsoftware::
>               '/var/cfengine/scripts/installsoftware'
> 
> NOTE: The above define statements do not work for me.
> 
> I use the checksw script to read the pkgs file, which is a simple space
> delimited database:
> class#action#pkg#version#file
> ##############################3
> any add SMCzlib 1.1.4 zlib-1.1.4-sol26-sparc-local
> any add EBopenssl 0.9.6g-eb1 openssl-0.9.6g-eb1-sol6-sparc
> any add EBopenssh 3.4p1_0.9.6g openssh.pkg
> dev add EBxvfb X11R6.6 xvfb-6.6-sol6-sparc
> 
> If this file is updated I have each host check to see if it needs to install
> new software. If it does I use a trick I read about on this list from
> "ducky" that dynamically creates a cfagent script to copy files. This script
> is copysoftware. Finally, I'd like to enable the install software script if
> copy software succeeded.
> 
> I've gotten everything to work by enabling a class:
> 
>         copyfiles = ( FileExists(/var/cfengine/scripts/copyfiles) )
> 
> then having tidy clean this up for the next time. The only problem with this
> solution is that it requires two runs of cfagent. Not bad, but I'd like to
> push stuff out and have it updated all at once.
> 
  it seems to me that you're going out of your way to force a software
install immediately when it's probably not necessary.  you are running
cfagent periodically, right?  it would be easy to set up an infrastructure
whereby software updates were put in a central location, and each client
would pick up the software package the next time cfagent runs via the copy
command.  you have a module which looks for updates in the drop directory,
and sets a class called installsoftware when it detects new packages.
your install script would run the time after cfagent does the package
copy (the next half-hour or whatever your period is for running cfagent).
so from the time you drop a software package in the central location to
the time cfagent installs the package on the machine is at most an hour,
assuming you're running cfagent every half hour.  convergence.
  now, if you have an operational need for immediately forcing a software
install on all of your machines and they're all running cfexecd, you could
use cfrun and define a set of classes like copysoftware or installsoftware
as you're doing above, and ensure the order of your copy and install
scripts using actionsequence classes (shellcommands.install or whatever).
  and having said that, couldn't you write one script which does the
software check, copy, and install all at once instead of splitting it
up into multiple actions?  TMTOWTDI, as my perl programming friends say.

chris