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

[Chris Edillon]

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

> > 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.
> 
  according to the docs you're right.  i think this is something
new in cfengine 2.x, since i don't remember it from 1.6.3 (not
that i haven't been wrong before...).

> 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.
> 
  i do software updates on clients using the native cfengine
copy command and a central server which contains the software
in a set of directories which mirror the client from the root
down.  for example, on the central server i might have a directory
called /opt/cfengine/copytree/arch/i686_linux under which is a
hierarchy that mirrors the root filesystem on my linux boxes.
so, there will be an i686_linux/usr/local/bin which contains all
of the binaries i want to put there, or i686_linux/usr/local/sbin
for files that go there, i686_linux/usr/local/lib for libraries,
etc.  whenever i want to have linux clients pull new binaries,
i just put them in the i686_linux tree and the next time cfagent
runs on the clients it pulls the data into the appropriate spot
on the client:

  copy:
    linux::
      /opt/cfengine/copytree/arch/i686_linux  dest=/  recurse=inf

    sunos_5_8::
      /opt/cfengine/copytree/arch/sparc_sol8  dest=/  recurse=inf

i set up multiple trees under arch for all of my architectures,
and i also set up trees for files common to all machines or
common to a given operating system.  so on the server the
directory /opt/cfengine/copytree/common might contain an etc
directory which contains files i want to go into /etc on all
of my clients, or a usr/local/etc for all files that go in
the equivalent spot on the clients:

  copy:
    all:
      /opt/cfengine/copytree/common  dest=/ recurse=inf

so if i want to install a new version of a particular software
package, i'll compile it on all of my target platforms and put
the resultant binaries in the approprate arch tree (and config
files go in the common tree).  it doesn't use the native package
management scheme on the client, but since i'm controlling
configuration management myself at this point i find it doesn't
matter.  once the files are in place they get copied down by
each client when cfagent next runs.
  this is a simplification, but i have a similar scheme set up
for a few thousand machines running five different flavors of
unix/linux and various versions of each.  i use replicated
software repositories so a single machine isn't burdened, do
filtering of common files which may look slightly different
depending on the operating system (/etc/nsswitch.conf between
solaris 7 and solaris 8, or automount files which use different
flags depending on the OS).  common files such as centrally
managed config files (all text and small) get copied out every
half-hour, and  binaries get updated once nightly when no one is
logged in (and i can set the splaytime longer for that particular
run).
  this is a different way of approaching the software management
problem, but hopefully you'll find something useful in it.