another cfservd idiosyncracy

[Marion Hakanson]

Folks,

I discovered to my pleasure that 2.0.8p1 and 2.1.0p1 have a new class
defined which describes the version of the current cfengine, e.g.
"cfengine_2_0_8p1" or "cfengine_2_1_0p1", and so on.  Yay!

But, it is not defined in the context of cfservd, so it cannot be
used in cfservd.conf.  Darn!  Especially if, like me, you foolishly
tried to use that new class in a global file which is imported by
cfagent.conf, update.conf, and cfservd.conf.  Sigh.

Here's a patch which seems to "fix" that oversight.  It applies to both
2.0.8p1 and 2.1.0p1:

================================================
--- src/cfservd.c       Sat Oct 18 01:41:30 2003
+++ src/cfservd.c.new   Fri Nov 21 15:47:08 2003
@@ -196,6 +196,9 @@
 
 AddClassToHeap("any");      /* This is a reserved word / wildcard */
 
+snprintf(VBUFF,bufsize,"cfengine_%s",CanonifyName(VERSION));
+AddClassToHeap(VBUFF);
+
 while ((c=getopt_long(argc,argv,"L:d:f:vmhpFV",CFDOPTIONS,&optindex)) != EOF)
   {
   switch ((char) c)
================================================


Oh yes, I did notice that cfagent.c initializes all the Linux-specific
classes before it parses the command-line options.  Poor cfservd.c
parses command-line options first, and then does the Linux-classes.
This looks like an excellent opportunity to rationalize things by
putting that duplicated code (Linux class inits, others) into a single
shared location, and calling it from both programs.  Alas, I have not
the familiarity (nor my boss' patience) to do that myself....

Regards,

-- 
Marion Hakanson <hakanson@cse.ogi.edu>
CSE Computing Facilities