[Top][All Lists]

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

Re: processing order, preprocessing, etc.

From: Luke A. Kanies
Subject: Re: processing order, preprocessing, etc.
Date: Sun, 22 Dec 2002 12:22:54 -0600 (CST)

On Sun, 22 Dec 2002, Kai Großjohann wrote:

> "Luke A. Kanies" <address@hidden> writes:
> > I have 70 servers, 100 or so packages, and multiple versions of each
> > package.  I want to define some way to configure the correct version of
> > the correct packags on every host.  I'd prefer to do it based on some kind
> > of classing; I always want the most recent version of ssh, but I can't
> > always just upgrade Oracle or whatever.
> >
> > I am trying to figure out a way to store all of the information I am
> > working with (default package versions, package installation methods, and
> > which hosts have which packages) in cfengine configs, and let cfengine do
> > the installing.
> It seems to me it would be quite simple to store a list of
> package/version pairs in a file and to write a shell script to
> iterate over that list and invoke an installer.
> So why not use that approach?

Because then cfengine isn't in charge of making sure everything looks the
way it's supposed to.  My goal is to keep all of the configuration data in
the cfengine configs, and as much as possible of the methods in there also
(the installation method might be as simple as setting a set of files to
be pulled down).

I can obviously write a script to do all of the installation, and to
figure out what needs to be done, but then I'm not using my configuration
management tool to do anything involving packages, and if there's a
problem, I basically have to fix it manually, rather than letting cfengine
just do it for me.

I have thought about writing a cfengine code generator, kind of like
TemplateTree.  Then I store all of my configuration data in meta-files,
and use those files to generate my configs.  I can't take advantage of
cfengine's configuration language, but at least I can take advantage of
its other capabilities.  Until cfengine supports multiple namespaces,
which Mark says will happen sometime (early?) next year, and maybe
supports a couple more features, I will probably go with this approach.
The resulting cfengine configs will use all application-specific variables
(e.g., mysql-version, instead of a version variable for each package), so
it'll be a bit ugly, and will be a much larger config, but, oh well.


Millions long for immortality who do not know what to do with
themselves on a rainy Sunday afternoon.         -- Susan Ertz

reply via email to

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