[Xymon] CLASS not working as expected

[J.C. Cleaver]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usecanonicalclass.patch
Type: text/x-patch
Size: 584 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20160210/da9f93a9/attachment.bin>