|
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: 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.
[Prev in Thread] | Current Thread | [Next in Thread] |