Returning configuration information to the clients 🔗 link

I've been doing research into the communications protocol used by Xymon and
her clients.  I am using the Windows PowerShell client found here:
http://sourceforge.net/p/xymon/code/HEAD/tree/sandbox/WinPSClient/

 
I've read a man page for bb:
http://manpages.ubuntu.com/manpages/hardy/man1/hobbit.1.html 

QUOTE: 

" config FILENAME

              Retrieve  one of the Hobbit configuration files from the
server.

              This command allows a client to pull files from the
$BBHOME/etc/

              directory  on the server, allowing for semi-automatic updates
of

              the client configuration.  Since  the  configuration  files
are

              designed  to  have  a  common  file for the configuration of
all

              hosts in the system - and this is in fact the recommended way
of

              configuring  your  clients  -  this  makes it easier to keep
the

              configuration files synchronized."

 
Using this information, I was able to execute this command.

 
PS> XymonSend "config client-local.cfg" "<xymon_server_name>"

 
. on a Windows server, inside a PowerShell window, and the entire, unedited
'client-local.cfg' file was displayed on screen.  This is good.

 
Then I read the following in the Client-Local.cfg man page:
http://xymon.sourceforge.net/xymon/help/manpages/man5/client-local.cfg.5.htm
l

QUOTE:

"The client-local.cfg file resides on the Xymon server.  When clients
connect to the Xymon server to send in their client data, they will receive
part of this file back from the Xymon server. The configuration received by
the client is then used the next time the client runs."

 
It sounds like the Xymon server will accept a status message from the
client, then parse the message for OS type, host name, etc.  then parse the
client-local.cfg file and find the lines that are applicable to the client
(based upon OS type, host name, etc.) and return those to the client.  None
of my clients are receiving a response from the Xymon server containing
configuration data.  I've tried to construct some messages to simulate an
upload from a linux host, a win32 host, and a hp-ux hosts (all of which have
entries in client-local.cfg), but I never get a reply containing
configuration data from the Xymon server.  

 
Can someone tell me what should be happening and how to simulate it?

 
Thank you very much for your time and assistance.

 
~Greg

Greg,

The "config" command simply downloads a complete file, so "config
client-local.cfg" should give you the complete file.

The specific section of the file client-local.cfg is returned only when
a client reports using the "client" command (not "status") - the section
returned depends on the client name and OS it's running - if an exact
match on name exists that section is returned, otherwise the section
matching the client OS reported (e.g. win32, linux, etc).

David.

http://xymon.sourceforge.net/xymon/help/manpages/man5/client-local.cfg.5.html

-- 

David Baldwin - Senior Systems Administrator (Datacentres + Networks)
Information and Communication Technology Services
Australian Sports Commission          http://ausport.gov.au
Tel 02 62147266 Fax 02 62141830       PO Box 176 Belconnen ACT 2616
user-cbbf693f2c89@xymon.invalid          1 Leverrier Street Bruce ACT 2617
Our Values: RESPECT + INTEGRITY + TEAMWORK + EXCELLENCE


Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au

This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.

On 24 October 2014 04:56, Gregory J. DeCecco <user-e65d382d9698@xymon.invalid> wrote:

Just for demonstration purposes, this is what it looks like on a UNIX
client:

$ xymon $XYMSRV "client name-of-server.example.com.linux linux"
log:/var/og/messages:10240

Typically, my "client" message would also contain a bunch of client data,
but in this case, I've left it out for clarity.  Once a client message is
sent, the server waits for the client to shutdown the transmit side of the
socket, and then it sends the relevant section of client-local.cfg that
matches the OS name, client class, or if present, the hostname.

HTH

Cheers
Jeremy

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?
Whereas, "win32" *is* an OS Type so it should be right next to the host name, correct?
Exactly what is a "hostclass"? Are they hard-coded values?

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.

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.


Thank you for your time and assistance.

On 28 October 2014 08:09, Gregory J. DeCecco <user-e65d382d9698@xymon.invalid> wrote:

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

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

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

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