[Top][All Lists]

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

Re: Package management with cfengine

From: Chip Seraphine
Subject: Re: Package management with cfengine
Date: Fri, 07 Nov 2003 12:51:22 -0600
User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030121

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:

   host_type1::  pkgs = ( "${pkgs} cfengine--2.1.0 openssh--3.7.1p1" )
   host_type::   pkgs = ( "{pkgs} openssl--" )

   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,

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.

reply via email to

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