CLASS not working as expected

10 messages in this thread

list Steve Hill · Wed, 10 Feb 2016 15:31:02 +0000 ·

Under Xymon 4.3.25, I'm trying to use the class attribute to group hosts together by what monitoring and alerting they need.

So for each host I have a hosts.cfg line like:
192.0.2.1	somehost.example.com	# CLASS:Foo trace ssh

Then in analysis.cfg I have:
CLASS=Foo
	PROC	this
	PROC	that

And alerts.cfg has:
CLASS=Foo
	SCRIPT=blah


However, the tests in analysis.cfg are not being applied.  If I replace CLASS=Foo with HOST=somehost.example.com they work as expected.  Also, CLASS=linux seems to work, which implies that the CLASS: directive in the hosts.cfg is being ignored.

As far as I can tell, the messages on xymon's "client" channel don't contain the class name that was specified in hosts.cfg, so xymond_client is using the class that the client sent instead.  Other channels, such as "status" do include the class name that was specified in hosts.cfg.

Am I misunderstanding how the class is supposed to be used, or is this a bug?

-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
    Email:            user-8cda31fbea61@xymon.invalid
    Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
    Email:            user-2675bcaab7d4@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
    Email:            user-126f03e2871f@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

list Galen Johnson · Wed, 10 Feb 2016 16:21:23 +0000 ·

I've run into this same issue and am curious about the answer.  My understanding from reading the docs is that the CLASS definition in hosts.cfg is supposed to override the class setting being sent back from the client. 

CLASS:Classname
Force the host to belong to a specific class. Class-names are used when configuring log-file monitoring (they can be used as references in client-local.cfg(5), analysis.cfg(5) and alerts.cfg(5) to group log file checks or alerts). Normally, class-names are controlled on the client by starting the Xymon client with the "--class=Classname" option. If you specify it in the hosts.cfg file on the Xymon server, it overrides any class name that the client reports. If not set, then the host belongs to a class named by the operating system the Xymon client is running on

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).

=G=

▸ quoted from Steve Hill

From: Xymon <xymon-bounces at xymon.com> on behalf of Steve Hill <user-8cda31fbea61@xymon.invalid>
Sent: Wednesday, February 10, 2016 10:31 AM
To: xymon at xymon.com
Subject: [Xymon] CLASS not working as expected

Under Xymon 4.3.25, I'm trying to use the class attribute to group hosts
together by what monitoring and alerting they need.

So for each host I have a hosts.cfg line like:
192.0.2.1       somehost.example.com    # CLASS:Foo trace ssh

Then in analysis.cfg I have:
CLASS=Foo
        PROC    this
        PROC    that

And alerts.cfg has:
CLASS=Foo
        SCRIPT=blah

However, the tests in analysis.cfg are not being applied.  If I replace
CLASS=Foo with HOST=somehost.example.com they work as expected.  Also,
CLASS=linux seems to work, which implies that the CLASS: directive in
the hosts.cfg is being ignored.

As far as I can tell, the messages on xymon's "client" channel don't
contain the class name that was specified in hosts.cfg, so xymond_client
is using the class that the client sent instead.  Other channels, such
as "status" do include the class name that was specified in hosts.cfg.

Am I misunderstanding how the class is supposed to be used, or is this a
bug?

--
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
    Email:            user-8cda31fbea61@xymon.invalid
    Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
    Email:            user-2675bcaab7d4@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
    Email:            user-126f03e2871f@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

list Tom Schmidt · Wed, 10 Feb 2016 10:01:31 -0700 ·

I have also seen that the CLASS keyword in hosts.cfg does not seem to 
work.  I wanted to use it with BBWin clients so that I could distinguish 
32-bit and 64-bit versions of Windows for analysis by using a 
CLASS:bbwin_64bit designation.  I worked around this by having the BBWin 
client set the CLASS instead to bbwin_32bit or bbwin_64bit.

Tom

▸ quoted from Galen Johnson


On 02/10/2016 09:21 AM, Galen Johnson wrote:

I've run into this same issue and am curious about the answer.  My understanding from reading the docs is that the CLASS definition in hosts.cfg is supposed to override the class setting being sent back from the client.

CLASS:Classname
Force the host to belong to a specific class. Class-names are used when configuring log-file monitoring (they can be used as references in client-local.cfg(5), analysis.cfg(5) and alerts.cfg(5) to group log file checks or alerts). Normally, class-names are controlled on the client by starting the Xymon client with the "--class=Classname" option. If you specify it in the hosts.cfg file on the Xymon server, it overrides any class name that the client reports. If not set, then the host belongs to a class named by the operating system the Xymon client is running on

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).

=G=

From: Xymon <xymon-bounces at xymon.com> on behalf of Steve Hill <user-8cda31fbea61@xymon.invalid>
Sent: Wednesday, February 10, 2016 10:31 AM
To: xymon at xymon.com
Subject: [Xymon] CLASS not working as expected

Under Xymon 4.3.25, I'm trying to use the class attribute to group hosts
together by what monitoring and alerting they need.

So for each host I have a hosts.cfg line like:
192.0.2.1       somehost.example.com    # CLASS:Foo trace ssh

Then in analysis.cfg I have:
CLASS=Foo
         PROC    this
         PROC    that

And alerts.cfg has:
CLASS=Foo
         SCRIPT=blah


However, the tests in analysis.cfg are not being applied.  If I replace
CLASS=Foo with HOST=somehost.example.com they work as expected.  Also,
CLASS=linux seems to work, which implies that the CLASS: directive in
the hosts.cfg is being ignored.

As far as I can tell, the messages on xymon's "client" channel don't
contain the class name that was specified in hosts.cfg, so xymond_client
is using the class that the client sent instead.  Other channels, such
as "status" do include the class name that was specified in hosts.cfg.

Am I misunderstanding how the class is supposed to be used, or is this a
bug?

--
   - Steve Hill
     Technical Director
     Opendium Limited     http://www.opendium.com

Direct contacts:
     Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
     Email:            user-8cda31fbea61@xymon.invalid
     Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
     Email:            user-2675bcaab7d4@xymon.invalid
     Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
     Email:            user-126f03e2871f@xymon.invalid
     Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

--


Micron Technology, Inc., Confidential and Proprietary

Tom L. Schmidt
Central Engineering System Administrator Lead
Micron Technology, Inc.  http://www.micron.com/
8000 S. Federal Way  P.O. Box 6  Mail Stop 01-351  Boise, Idaho USA 
83707-0006
mailto:user-48d3fa8908d4@xymon.invalid  http://cesa.micron.com/

list Steve Hill · Wed, 10 Feb 2016 17:31:00 +0000 ·

▸ quoted from Galen Johnson

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.

▸ quoted from Tom Schmidt


-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
    Email:            user-8cda31fbea61@xymon.invalid
    Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
    Email:            user-2675bcaab7d4@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
    Email:            user-126f03e2871f@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

list Japheth Cleaver · Wed, 10 Feb 2016 13:45:44 -0800 ·

▸ quoted from Steve Hill

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

list Steve Hill · Thu, 11 Feb 2016 15:17:59 +0000 ·

▸ quoted from Japheth Cleaver

On 10/02/16 21:45, J.C. Cleaver wrote:

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.

Thank you - I've tested the patch and it resolves the problem.

▸ quoted from Steve Hill



-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
    Email:            user-8cda31fbea61@xymon.invalid
    Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
    Email:            user-2675bcaab7d4@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
    Email:            user-126f03e2871f@xymon.invalid
    Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

list Galen Johnson · Thu, 25 May 2017 09:09:22 -0400 ·

I hate to revive such an old thread but the context requires it.  Did this
patch ever make it into the main code branch?  I'm going to guess not since
I still see this behavior in 4.3.28 but want to a) confirm this and b) ask
that it be pushed into the main branch for the next release.

thanks

=G=

Note: I'm using the rpms from terabithia so the patch is a bit out of scope
:-).

▸ quoted from Steve Hill


On Thu, Feb 11, 2016 at 10:17 AM, Steve Hill <user-8cda31fbea61@xymon.invalid> wrote:

On 10/02/16 21:45, J.C. Cleaver wrote:

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.

Thank you - I've tested the patch and it resolves the problem.


--
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com

Direct contacts:
   Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
   Email:            user-8cda31fbea61@xymon.invalid
   Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
   Email:            user-2675bcaab7d4@xymon.invalid
   Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
   Email:            user-126f03e2871f@xymon.invalid
   Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

list Bakkies Gatvol · Tue, 7 Nov 2017 16:03:01 +0000 ·

I need this patch too please!  Where can I find it?

▸ quoted from Galen Johnson

From: Xymon <xymon-bounces at xymon.com> on behalf of Galen Johnson <user-fc632e705d24@xymon.invalid>
Sent: Thursday, May 25, 2017 9:09 AM
To: Steve Hill
Cc: Xymon Mailing List
Subject: Re: [Xymon] CLASS not working as expected

I hate to revive such an old thread but the context requires it.  Did this patch ever make it into the main code branch?  I'm going to guess not since I still see this behavior in 4.3.28 but want to a) confirm this and b) ask that it be pushed into the main branch for the next release.

thanks

=G=

Note: I'm using the rpms from terabithia so the patch is a bit out of scope :-).

On Thu, Feb 11, 2016 at 10:17 AM, Steve Hill <user-8cda31fbea61@xymon.invalid<mailto:user-8cda31fbea61@xymon.invalid>> wrote:
On 10/02/16 21:45, J.C. Cleaver wrote:

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.

Thank you - I've tested the patch and it resolves the problem.

--
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com

Direct contacts:


   Instant messager: xmpp:user-8cda31fbea61@xymon.invalid<mailto:user-c7b98c523357@xymon.invalid>
   Email:            user-8cda31fbea61@xymon.invalid<mailto:user-8cda31fbea61@xymon.invalid>
   Phone:            sip:user-8cda31fbea61@xymon.invalid<mailto:user-e123bb42b705@xymon.invalid>

Sales / enquiries contacts:
   Email:            user-2675bcaab7d4@xymon.invalid<mailto:user-2675bcaab7d4@xymon.invalid>
   Phone:            +XX-XXXX-XXXXXX<tel:%2B44-1792-824568> / sip:user-2675bcaab7d4@xymon.invalid<mailto:user-e3f39cc2d0bd@xymon.invalid>

Support contacts:
   Email:            user-126f03e2871f@xymon.invalid<mailto:user-126f03e2871f@xymon.invalid>
   Phone:            +XX-XXXX-XXXXXX<tel:%2B44-1792-825748> / sip:user-126f03e2871f@xymon.invalid<mailto:user-043169e0a6c5@xymon.invalid>

list Bakkies Gatvol · Thu, 7 Dec 2017 03:05:06 +0000 ·

Sorry if I missed the obvious - where can I find this patch ?

▸ quoted from Galen Johnson

From: Xymon <xymon-bounces at xymon.com> on behalf of Galen Johnson <user-fc632e705d24@xymon.invalid>
Sent: Thursday, May 25, 2017 9:09 AM
To: Steve Hill
Cc: Xymon Mailing List
Subject: Re: [Xymon] CLASS not working as expected

I hate to revive such an old thread but the context requires it.  Did this patch ever make it into the main code branch?  I'm going to guess not since I still see this behavior in 4.3.28 but want to a) confirm this and b) ask that it be pushed into the main branch for the next release.

thanks

=G=

Note: I'm using the rpms from terabithia so the patch is a bit out of scope :-).

On Thu, Feb 11, 2016 at 10:17 AM, Steve Hill <user-8cda31fbea61@xymon.invalid<mailto:user-8cda31fbea61@xymon.invalid>> wrote:
On 10/02/16 21:45, J.C. Cleaver wrote:

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.

Thank you - I've tested the patch and it resolves the problem.

--
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com

Direct contacts:
   Instant messager: xmpp:user-8cda31fbea61@xymon.invalid<mailto:user-c7b98c523357@xymon.invalid>
   Email:            user-8cda31fbea61@xymon.invalid<mailto:user-8cda31fbea61@xymon.invalid>
   Phone:            sip:user-8cda31fbea61@xymon.invalid<mailto:user-e123bb42b705@xymon.invalid>

Sales / enquiries contacts:
   Email:            user-2675bcaab7d4@xymon.invalid<mailto:user-2675bcaab7d4@xymon.invalid>
   Phone:            +XX-XXXX-XXXXXX<tel:%2B44-1792-824568> / sip:user-2675bcaab7d4@xymon.invalid<mailto:user-e3f39cc2d0bd@xymon.invalid>

Support contacts:
   Email:            user-126f03e2871f@xymon.invalid<mailto:user-126f03e2871f@xymon.invalid>
   Phone:            +XX-XXXX-XXXXXX<tel:%2B44-1792-825748> / sip:user-126f03e2871f@xymon.invalid<mailto:user-043169e0a6c5@xymon.invalid>

list Sebastian Auriol · Mon, 11 Dec 2017 13:54:34 +0000 ·

A quick Google showed me the patch is listed here:
http://lists.xymon.com/archive/2016-February/043015.html
As:
http://lists.xymon.com/pipermail/xymon/attachments/20160210/da9f93a9/attachment.bin
Simply save that file as e.g. attachment.txt and open with a text editor to
verify that it is indeed the patch as I did.

Regards,
SebA

▸ quoted from Bakkies Gatvol


On 7 December 2017 at 03:05, Bakkies Gatvol <user-66e2e196cd54@xymon.invalid> wrote:

Sorry if I missed the obvious - where can I find this patch ?

*From:* Xymon <xymon-bounces at xymon.com> on behalf of Galen Johnson <
user-fc632e705d24@xymon.invalid>
*Sent:* Thursday, May 25, 2017 9:09 AM
*To:* Steve Hill
*Cc:* Xymon Mailing List
*Subject:* Re: [Xymon] CLASS not working as expected

I hate to revive such an old thread but the context requires it.  Did this
patch ever make it into the main code branch?  I'm going to guess not since
I still see this behavior in 4.3.28 but want to a) confirm this and b) ask
that it be pushed into the main branch for the next release.

thanks

=G=

Note: I'm using the rpms from terabithia so the patch is a bit out of
scope :-).

On Thu, Feb 11, 2016 at 10:17 AM, Steve Hill <user-8cda31fbea61@xymon.invalid> wrote:

On 10/02/16 21:45, J.C. Cleaver wrote:

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.


Thank you - I've tested the patch and it resolves the problem.


--
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com

Direct contacts:
   Instant messager: xmpp:user-8cda31fbea61@xymon.invalid
   Email:            user-8cda31fbea61@xymon.invalid
   Phone:            sip:user-8cda31fbea61@xymon.invalid

Sales / enquiries contacts:
   Email:            user-2675bcaab7d4@xymon.invalid
   Phone:            +XX-XXXX-XXXXXX / sip:user-2675bcaab7d4@xymon.invalid

Support contacts:
   Email:            user-126f03e2871f@xymon.invalid
   Phone:            +XX-XXXX-XXXXXX / sip:user-126f03e2871f@xymon.invalid

CLASS not working as expected 🔗 link

CLASS not working as expected