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

[Wheeler, John]

> -----Original Message-----
> From: Chris Edillon [mailto:jce@zot.com]
> Sent: Wednesday, November 06, 2002 11:04 AM
> To: Wheeler, John
> Cc: help-cfengine@gnu.org
> Subject: Re: RE: Réf. : RE: activating a class from shellcommands
>
>
> 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).

I thought the environment variable was only available using cfagent -u? Honestly I didn't test this, but It would make it easier if the environment variable is available.

>
> > 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
correct. out of inittab using cfexecd -F.

 
> 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.

yea, my plan may be overly aggressive, but there is one more goal I'm trying to satisfy, storage.
If I copy all the software on some of our legacy machines, I fill the partition and /var is not a good partition to fill.

>   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

Thanks for all your advice, and help. As for perl, I wanted to program in the least common denominator for all my hosts (mostly solaris 2.6 and 2.8) which is ksh.

Some of the other design considerations were that based on this 'pkgs' file I would copy software from a common directory on a master host. The directory contains ~ 30 packages so I can't copy all of them to all the hosts. I also did not want to code a new cfagent file every time I need a new package installed.

So from an operation perspective, all one needs to do to install software on any host ( similar to what you stated above) is edit the pkgs file on the master host add a line containing the class you want the package installed to, the pkg name , an action (currently ignored but in the future will allow me to delete packages), a package version, and finally the package file name. After the edit, you simply place the file in the "software" dir and smile because in ~ 1 hour you are done.

At this point cfagent will see that the pkg file has been updated and, check if he has to install any new. If so the chechsw script creates a new script for this purpose and waits for the next run. On the next invocation the files will be copied and installed. Finally the tidy action will remove my copy script and the new package files copyed over.

Sounds really cool. Lets hope it works.

wheeler
>