RE: processing order, preprocessing, etc.

[Luke A. Kanies]

On Sun, 22 Dec 2002, Wheeler, John wrote:

> My requirements were as follow:
> 1) scripts are restricted to sh/ksh
> 2) must not leave any package archives on host after install
> 3) must use solaris based package administration
> 4) must be able to push out software on demand
> 
> Its not quite the "cfengine way" but as close as I could get. it goes a
> little like this:
> 
> I have a file based database like this:
> 
> # more pkgs
> sunos_5_8 add SMCzlib 1.1.4 zlib-1.1.4-sol8-sparc-local
> sunos_5_8 add EBopenssl 0.9.6g openssl-0.9.6g-sol8-sparc
> sunos_5_8 add EBopenssh 3.4p1 openssh-3.4p1-sol8-sparc
> sunos_5_6 add SMCzlib 1.1.4 zlib-1.1.4-sol26-sparc-local
> sunos_5_6 add EBopenssl 0.9.6g-eb1 openssl-0.9.6g-eb1-sol6-sparc
> sunos_5_6 add EBopenssh 3.4p1_0.9.6g openssh-3.4p1-sol6-sparc
> dev add EBxvfb X11R6.6 xvfb-6.6-sol6-sparc
> cessna add EBcronolog 1.6.2 cronolog-1.6.2-sol8-sparc
> web001prod add EBcronolog 1.6.2 cronolog-1.6.2-sol8-sparc
> web002prod add EBcronolog 1.6.2 cronolog-1.6.2-sol8-sparc

I found at least one optimization you could make here:

Because cfengine allows you to iterate over a list in shellcommands, you
could actually store the associations between classes and packages in
cfengine.  I'm nearly positive that I'm breaking unwritten rules, but
anyway...

For instance:

control:

        ftpserver::
                pkgs = ( "${pkgs}:newpkg:otherpkg" )

shellcommands:
        install::
                "${pkginstall} ${pkgs}"

Basically, you go through your config building up your list of packages.
You might have a packages.cf file or something; however you're storing
host-specific or class-specific information, you just include this as one
of the specific pieces of information.

Then, once you've got all of the packages defined, you just run the
package install (or probably initially the package check) script, and
cfengine will actually iteratively call your script with each packge in
turn.

In fact, using a module, you could have a checksw module which checked the
list of installed software against the list of ready-to-install software
and returned what's left to do.  I don't know enough about modules to know
exactly how you'd do this, but my guess is you could set it up so that the
module accepted a list of all packages and then returned just the packages
that are left to install.  Then you let cfengine iterate over the package
installation stuff.

I actually did the following in a test and it worked:

control:
        pkgs = ( "my:pkg:list" )
        actionsequence = ( shellcommands )

shellcommands:
        "/usr/local/sbin/cfagent -f ${INPUTS}/${pkgs}.cf"

This allows me to store all of my per-package configuration information in
a per-package cfengine config file.  Or, and I just thought of this, you
could store all of your package info in a single config file:

shellcommands:
        install::
                "/usr/local/sbin/cfagent -f ${INPUTS}/packages.cf -D ${pkgs}"

This will actually iterate over the package list defining each package as
a class in turn.  Then you could have a packages.cf like the following:

control:
        mysql::
                version = ( 3.5 )
                requires = ( "openssl:ncurses" )
                package = ( "mysql" )
        .
        .
        .

Of course, this concept could be extended a bit.  You'd probably want to
have a step that followed all of the package prerequisites, then checked
the installed software, then installed the final list.

Either way, this method of embedded cfengine call, which I've checked and
does work, seems to be the only way to correctly iterate over my entire
package list, setting package-specific variables and then doing the right
thing.

If anyone has another way of doing this, preferably without calling
cfagent again, I would love to hear it.  I also can't think of a way,
using this method, to let one host override the default package version.

Anyway, so this is kind of what I am thinking about.  I don't know enough
about the installsequence and classing to know all the details about how
to set it all up to do the right thing.  I'll be messing with it, though,
and seeing where I end up.

Anybody else trying something like this?

--
    The Washington Bullets are changing their name.  The owners no
    longer want their team's name to be associated with crime.  So from
    now on the team will be known as The Bullets.
                -- Paul Harvey, quoting Argus Hamilton