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

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 <steve at opendium.com> 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:steve at opendium.com Email: steve at opendium.com Phone: sip:steve at opendium.com

Sales / enquiries contacts: Email: sales at opendium.com Phone: +44-1792-824568 / sip:sales at opendium.com

Support contacts: Email: support at opendium.com Phone: +44-1792-825748 / sip:support at opendium.com

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- 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:tschmidt at micron.com http://cesa.micron.com/

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

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 <steve at opendium.com> 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:steve at opendium.com Email: steve at opendium.com Phone: sip:steve at opendium.com

Sales / enquiries contacts: Email: sales at opendium.com Phone: +44-1792-824568 / sip:sales at opendium.com

Support contacts: Email: support at opendium.com Phone: +44-1792-825748 / sip:support at opendium.com

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

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

From: Xymon <xymon-bounces at xymon.com> on behalf of Galen Johnson <solitaryr at gmail.com> 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 <steve at opendium.com<mailto:steve at opendium.com>> 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:steve at opendium.com<mailto:xmpp%3Asteve at opendium.com> Email: steve at opendium.com<mailto:steve at opendium.com> Phone: sip:steve at opendium.com<mailto:sip%3Asteve at opendium.com>

Sales / enquiries contacts: Email: sales at opendium.com<mailto:sales at opendium.com> Phone: +44-1792-824568<tel:%2B44-1792-824568> / sip:sales at opendium.com<mailto:sip%3Asales at opendium.com>

Support contacts: Email: support at opendium.com<mailto:support at opendium.com> Phone: +44-1792-825748<tel:%2B44-1792-825748> / sip:support at opendium.com<mailto:sip%3Asupport at opendium.com>

Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon