[Xymon] Returning configuration information to the clients

[Jeremy Laidman]

On 28 October 2014 08:09, Gregory J. DeCecco <turranx at hotmail.com> wrote:

> The documentation online gives the schema of the first line of a “client”
> command like this:
>
>         client[/COLLECTORID] HOSTNAME.OSTYPE [HOSTCLASS]
>
> I've seen scripts generate "client" lines like these:
>
>         client name-of-server.example.com.linux linux
>         client name-of-server.example.com.bbwin win32
>         client name-of-server.example.com.bbwin win32 XymonPS v1.6
>
> Strictly speaking, "bbwin" isn't an OS Type so it shouldn't be in that
> position, correct?
>

Correct.  But ultimately, it's just a string that's matched against other
strings.

Whereas, "win32" *is* an OS Type so it should be right next to the host
> name, correct?
>

Yes, probably.


> Exactly what is a "hostclass"? Are they hard-coded values?
>

A host class is a way to describe types of hosts that have the same log
file configurations.  The default host class is the OS string. You can
override a host class on the client by specifying "--class=classname" on
the command-line of the client script runclient.sh.  (You can also override
the OS string with "--os=osstring".)  You can also override the class of a
host by specifying CLASS:classname in hosts.cfg.

The OS names are important, as the server-side client parsers are
OS-specific.  Also, the client script runs a second script based on the OS
string.  To find the OS names available, run the following:

cd ~xymon/client/bin/ && ls xymonclient-*.sh

This will give something like "xymonclient-aix.sh xymonclient-hp-ux.sh" and
so on.  The OS strings are therefore "aix", "hp-ux" etc.  As I said before,
the OS names are used as default host classes, because most instances of an
OS have similar logging setups.

On the Xymon server side, the file client-local.cfg has section defined for
each available OS type and some sample host classes.  You can also add
hostnames in there, to override the OS and class.

Also on the server side, analysis.cfg will allow you to specify a CLASS
qualifier to some rules that you only want to apply to some hosts.  So if
you specify CLASS=webserver then the rule applies to only those in the
webserver class, and if you specify CLASS=linux then it only applies to
servers in the linux class, which probably means those with OS=linux also
(because the OS is the default class).


Perhaps what I need is for someone to point me towards the Xymon service
> source code that parses the incoming messages from clients and I can read
> how it's handled myself.
>

This sort of client message analysis is done lib/misc.c, in get_ostype().
This looks for the various OS strings, including pseudo-OS strings like
"powershell" and "bbwin", and returns a canonical OS string.

This is called from within xymond/xymond_client.c, whenever a client
message is accepted.  If the class is not specified, it is set to the OS
name.

You might be wondering why I'm overly concerned with the specifics of this
> command.  It's because I am writing documentation for Xymon.  Open source
> documentation is rarely up to date with the code.
>

I've seen plenty of closed source documentation that's out of date, or more
a "statement of intent" with features not yet (or ever) implemented.  But I
take your point.  For the most part, Xymon doco is updated as the code
changes.  In this case, I think you're delving into some undocumented
features that may relate more to the Powershell and BBWin tool, and some
historical artefacts, than an inherent design of Xymon.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20141028/9e0a9d2e/attachment.html>