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.6Strictly 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