help-cfengine
[Top][All Lists]
Advanced

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

Re: possible to undefine hostname class?


From: David Kewley
Subject: Re: possible to undefine hostname class?
Date: Tue, 27 Apr 2004 00:06:31 -0700
User-agent: KMail/1.5

Thanks Eric and Tim for your suggestions!

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.

Tim's suggestion is interesting.  I suppose I could add all the RH-defined 
langage-specific package groups to workstations after the kickstart.  But 
I'm not completely sure that would work correctly, and besides, I've 
already made cfagent work for me the way I originally wanted (read on...).

Attached is a patch to cfengine 2.1.5.  It alters two functions in 
install.c: InstallControlRValue() and InstallGroupRValue().  The patch does 
two things, basically.

First, it fixes what I think is pretty clearly a bug in 
InstallGroupRValue().  In the "case simple:" stanza, it does both of these:

                   if (IsItemIn(VHEAP,buff))  /* group reference */
                      {
                      AddClassToHeap(GROUPBUFF);
                      break;
                      }

                   if (IsDefinedClass(buff))
                      {
                      AddClassToHeap(GROUPBUFF);
                      break;
                      }

IsDefinedClass() already checks to see if the string argument is in VHEAP, 
which means that the "if (IsItemIn())" stanza is redundant.  Also, and more 
importantly, leaving the "if (IsItemIn())" stanza in breaks 
IsDefinedClass()'s check whether the class is in VNEGHEAP (that is, if it 
was "negated" by -N on the command line to cfagent).  The result is that 
the class named in "buff" is both defined and negated, the GROUPBUFF class 
is added to the heap anyway.  I think this is clearly wrong.

Here's an illustration.  If you have

  classes:
    A = ( any )
    B = ( A )

and run cfagent with

  cfagent -N A ...

A is both defined and negated, and B gets defined even though A was negated.  
The desirable behavior (which my patch provides) is that B does not get 
defined when A is negated on the command line.

The second thing my patch does is enable the negation of the local hostname 
classes.  Let's suppose we're running cfagent on a host with the 
unqualified name "host1".  And suppose you have

  classes:
    C = ( host1 )

Normally, of course, C gets defined when run on host1.  The thing that I 
believe is a bug is that if you run cfagent with

  cfagent -N host1 ...

C still gets defined on host1.  With my patch, C does not get defined in 
these circumstances.

The combination of these fixes give me the behavior that I orginally asked 
about:  I can now do multiple cfagent runs on host1, where each cfagent run 
is launched with

  cfagent -D hostN -N host1

where hostN is one of my hosts, and hostN changes from run to run.  Now on 
each run, class tests will be done for hostN, but NOT for host1.

This is the behavior I want, and as far as I can see, my patches not only 
provide this behavior, but do not break anything else.  If someone sees 
breakage causes by my patches, do speak up. :)

Mind you, this patch is the result of this day's work (the first time I've 
dived into cfengine's source code), and I've only done basic tests.  I 
haven't actually used my patch in production yet, but I expect to very 
shortly.

I've generated a patch on the current development cfengine, and will send it 
to bug-cfengine next.

David

Attachment: cfengine-2.1.5-enable-hostname-negation.patch
Description: Text Data


reply via email to

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