Xymon Mailing List Archive search

CLASS not working as expected

list Japheth Cleaver
Wed, 10 Feb 2016 13:45:44 -0800
Message-Id: <user-c67f64bd50eb@xymon.invalid>

On Wed, February 10, 2016 9:31 am, Steve Hill wrote:
On 10/02/16 16:21, Galen Johnson wrote:
I read that as if I didn't add the --class argument to the xymon client
command then what is in hosts.cfg should be the class used.  However,
this seems to not be the case (although I would argue that it should
work this way).
I read it as the hosts.cfg CLASS: tag would always override anything the
client sends.  From reading the code it appears that the data the client
sends to the server is copied as-is into the "client" channel (i.e. the
class supplied by the client isn't replaced).  This means that
xymond_client sees the client's original class, not the one in
hosts.cfg.  As far as I can tell, xymond_client doesn't read the CLASS:
tag from hosts.cfg either, so I'm not sure how this was intended to work.

--

I believe this reading is correct. For the default collector, an incoming
client report with a 'class' type will have that type passed onward to the
client channel. If the class is blank in the client message, the OS type
is used as a default.

Separately, and after the message is placed onto the client channel,
xymond examines the value of CLASS: as stored/read from hosts.cfg. If
present, we reset our value to this. If not present, and a class was
submitted by the client message we're now looking at, we save the incoming
class as the "CLASS:" value (note: subject to later overriding by future
hosts.cfg loads).

It is *this* updated class value that's used for reading back the
appropriate section from client-local.cfg as a configuration reply (for
logfetch, etc.)


So it's definitely confusing, and it means that there's no proscriptive
way to force CLASS=based groupings in analysis.cfg.

Given that the hosts.cfg(5) doc explicitly indicates an override at the
host level valid for all of those config files, I'd consider this a bug,
and probably one for fixing in 4.3.x.

The enclosed patch - simply doing the canonicalization before handing the
message off - should modify the behavior so it matches the documentation.
Please let me know if it works for you.


HTH,
-jc