Re: possible to undefine hostname class?

[David Kewley]

Chip Seraphine wrote on Tuesday 27 April 2004 05:18:
> Taking the conversation in a sharp left turn....
> 
> On Tuesday 27 April 2004 02:06, David Kewley wrote
> 
> > What Eric is doing is pretty cool.  But I'm not going to use it, because
> > I don't want to split the intelligence between my cfagent scripts and
> > the cgi script.  I want all intelligence in the cfagent scripts for
> > simplicity.
> 
> FWIW, whenever I find myself in what I call "the authority problem", I
> usually just use the best tool for the job (in Eric's case, a cgi probably
> written in shell or perl) and then have *that* tool maintained by
> cfengine.    For example, the CGI could spit out results from a datafile
> that cfengine assembles.
> 
> I figure my goal is not to have the cfengine interpreter do all the work 
> itself so much as to have a centralized point of authority; in other
> words, a self-enforcing piece of documentation that I *know* is 100%
> right, because if it was wrong it would go out and change the environment
> until it *was* right.

I agree that's best practice.  For example, on my Red Hat boxes (RHL, RHEL, 
Fedora), I use yum to install and maintain the packages, not cfengine.  But 
cfengine runs yum and tells yum which package groups to install.

In the case of generating kickstart files, however, without my patch you 
**cannot** have cfengine be the central authority.

This is precisely because you need to generate the kickstart files on a 
central host (otherwise, how will you generate a kickstart file for a 
machine that isn't built yet?).  But cfengine without my patch **cannot** 
negate the hostname class(es), so the central host's hostname class 
**always** triggers its contingent classes, along with the contingent 
classes for the host you're trying to generate the kickstart file for.

Make sense?  I welcome expressions of confusion as well as being told why my 
argument is flawed. :)

The ability to negate the hostname class(es) gives you another benefit -- 
you can test what cfagent will do for a different host than the one you're 
running cfagent on.  E.g. testing a new server setup on your "sysadmin 
desktop".  You do this without messing up your sysadmin desktop, by 
prefixing all references to "live" files in your cfagent script with e.g. 
"$(liveroot)/".  Then for a real run you set liveroot = ( "" ), and for a 
test run, you set e.g. liveroot = ( "/home/sysadmin/test" ).  This is what 
I'm doing now.

Cheers,
David