Returning configuration information to the clients
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 theserver.
This command allows a client to pull files from the$BBHOME/etc/
directory on the server, allowing for semi-automatic updatesof
the client configuration. Since the configuration filesare
designed to have a common file for the configuration ofall
hosts in the system - and this is in fact the recommended wayof
configuring your clients - this makes it easier to keepthe
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.
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 theserver.
This command allows a client to pull files from the$BBHOME/etc/
directory on the server, allowing for semi-automaticupdates of
the client configuration. Since the configurationfiles are
designed to have a common file for theconfiguration of all
hosts in the system - and this is in fact therecommended way of
configuring your clients - this makes it easier tokeep 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...
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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- 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 david.baldwin at ausport.gov.au 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.
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? 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 <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
On 24 October 2014 04:56, Gregory J. DeCecco <turranx at hotmail.com> wrote:
Can someone tell me what should be happening and how to simulate it?
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
participants (3)
-
david.baldwin＠ausport.gov.au
-
jlaidman＠rebel-it.com.au
-
turranx＠hotmail.com