Re: Package management with cfengine

[Chip Seraphine]

Luke A. Kanies wrote:
> I've basically got everything covered except the first item.  Is anyone
> specifying within cfengine itself exactly which packages to install?  The
> closest thing I can think of is something like the following:
>
> control:
>    host_type1::  pkgs = ( "${pkgs} cfengine--2.1.0 openssh--3.7.1p1" )
>    host_type::   pkgs = ( "{pkgs} openssl--0.9.9.9.9.9.9.9.9f" )
>
>    actionsequence = ( "module:packages ${pkgs}" )
>
> And then have the packages module dynamically build the exact sequence of
> stuff to do, based on template cfengine scripts and such.

That's similar to what I have, except that I have some more abstractions 
in the package listing mechanism (see below).

> This kind of works, but it's got some serious problems.  First and
> foremost, because the module functions as an abstraction layer between the
> main cfengine process and the package installation process, the subprocess
> doesn't really know anything that the parent process does (e.g., classes,
> variables).

The classes are easy enough; just pass 'em along via argv or command line. 
 Variables are a bit tricky; wish we had a $(cfallvars) supervariable 
that looked like "var1=foo:var2=bar" or something.  As it is, if I need a 
variable in the module I either explicitly set it on the module's 
commandline or have the module determine it from the same way the cfengine 
script does.  [For example, have the value live in a config file and have 
both cfengine and the module read the same file.]

> There are a couple other problems with this model, too, but that's the
> main one.
>
> Is anyone doing something like this right now?  I specifically, definitely
> want to specify the packages to be installed within cfengine; I don't want
> an external file that does it or whatever.

If by 'within cfengine' you include modules, then yes.  I wrote a module 
called 'apsht' for updating and installing Solaris packages.  It's a perl 
script that is passed the $(cfallclasses) variable on the command line. 
Using those classes, it consults a directory full of package-list files 
and reads the contents of the appropriate files (the files have names that 
are cfengine-y expressions like "sunos.i386.workstation.!developerws"), 
which are lists of Sun packages.  It then looks in the appropriate depot 
area for its architecture and installs/updates these packages if they need it.

I was actually talking to Mark about creating a page where I can post a 
few of my modules, but probably won't get that done for a few days.  If 
anybody wants, I'll be happy to post the relevant module now.