My company is looking to use Xymon in production. It's my job to operationalize it: test it, write about its behavior, document any issues, and create documentation for our run teams.
I've found a behavior of the Xymon server's service that I'm trying to understand: It maintains the host name to OSType mapping until the service is restarted. For example:
Edit the server's hosts.cfg file. Insert a non-existent server'server01' and give it a fake/real IP.
Edit the server's client-local.cfg file. Create several entrieswithin for different OS types:
a. Linux
b. Win32
c. AIX
d. Etc.
Make sure that each section for the OSType contains a unique stringor command. You will use this to identify which OSType the Xymon server service identified 'server01' as.
Wait for 'server01' to show up on the web site. It won't have anystatus data to report yet. This is OK. NOTE: Do not restart the Xymon service.
Find a computer (real/VM) to pretend to be 'server01'. It doesn'tmatter which OS the client has, just as long as you are comfortable running custom scripts upon it.
From 'server01', issue this command, replacing OSType and HostClasswith your favorite values:
a. "client server01.<OSType> <HostClass>"
If you're lucky, the Xymon server will respond back with theappropriate unique string for your OSType from the client-local.cfg file.
Now, change OSType and rerun the command from the same clientmachine. For example, if you first used "win32", now use "linux" instead.
a. "client server01.win32 <HostClass>"
b. "client server01.linux <HostClass>"
Did the Xymon server respond with the unique string from thenew/second OSType? I betcha it didn't. It's still responding with the unique string from the first OSType you used, right?
Edit the server's hosts.cfg file. Insert a non-existent server 'server02' and give it a fake/real IP.
Wait for 'server02' to appear in the web page.
Log on to the server as the user 'xymon' and issue a rename command:
a. ./server/bin/xymon 127.0.0.1 "rename server01 server02"
Wait for the web page to update, showing status information for 'server02', but not 'server01'.
Now, issue the following commands from the client, but use the new/second OSType for both:
a. "client server01.<OSType> <HostClass>"
b. "client server02.<OSType> <HostClass>"
Did the Xymon server respond to 'server01' with the original/first OSType you used? When I performed these steps, I got back the unique string for the original/first OSType, but I was expecting to get back the new/second OSType.
Did the Xymon server respond to 'server02' with the new/second OSType you used? When I performed these steps, I got back the unique string for the new/second OSType.
Edit the server's hosts.cfg file. Remove 'server01' and 'server02'.
Log on to the server as the user 'xymon' and issue a rename commands:
a. ./server/bin/xymon 127.0.0.1 "remove server01"
b. ./server/bin/xymon 127.0.0.1 "remove server02"
Wait for the web site to stop showing server01 and server02.
Edit the server's hosts.cfg file.
a. Insert a non-existent server 'server01' and give it a fake/real IP.
b. Insert a non-existent server 'server02' and give it a fake/real IP.
Wait for 'server01' and 'server02' to appear in the web page.
Now, issue the following commands from the client, but use the new/second OSType for both:
a. "client server01.<OSType> <HostClass>"
b. "client server02.<OSType> <HostClass>"
Did the Xymon server respond to 'server01' with the original/first OSType you used? When I performed these steps, I got back the unique string for the original/first OSType, but I was expecting to get back the new/second OSType.
Did the Xymon server respond to 'server02' with the new/second OSType you used? When I performed these steps, I got back the unique string for the new/second OSType.
Log on to the Xymon server and restart the Xymon service.
Go back through the steps above, you'll see that after a fresh restart, the Xymon service will parse the "client" string, discover the OSType, and maintain an OSType <--> Hostname association until the service is restarted. Is this the expected behavior? I can see how this behavior would get in the way of architecting and rapid testing of a client-local.cfg file with multiple OSType, HostClass, and Hostname entries.
On 28 October 2014 08:45, Gregory J. DeCecco <turranx at hotmail.com> wrote:
Is this the expected behavior?
Yes - if you know what to expect! ;-)
One of the major performance improvements that Xymon has over its predecessor BigBrother, is that it keeps state in memory, and doesn't have to re-read its configuration files every 5 minutes. In some cases, this means that changes are not visible immediately, and require either a bit of time to pass, or an action to take place. This is the case for many configuration files used by Xymon.
I can see how this behavior would get in the way of architecting and
rapid testing of a client-local.cfg file with multiple OSType, HostClass, and Hostname entries.
The contents of the file client-local.cfg is held in memory by xymond, and is not updated unless xymond detects a change. The xymond process can be given a HUP signal to tell it to re-check all of its configuration files for changes, and reload details as required.
You might find this sequence useful:
On the Xymon server:
Create a new entry for server01 in hosts.cfg
Send xymond a HUP signal:
sudo -u xymon pkill -HUP xymond$
- Run: xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This shows the in-memory values for class and OS that xymond uses. As there has never been a client message, the values will be empty.
- Run: a) xymon 127.0.0.1 "client server01.bogos bogos" b) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "bogos|bogos". Note that the "client" message gets nothing from client-local.cfg.
- Run: a) xymon 127.0.0.1 "client server01.win128 win128" b) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "bogos|win128". Also, no output from client-local.cfg, but if there were an entry for [bogos] or [win128] it would have shown something, with preference given to [bogos].
- Run: a) touch hosts.cfg b) sudo -u xymon pkill -HUP xymond$ c) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "|" - that is, no values.
- Run: a) xymon 127.0.0.1 "client server01.win16 win16" b) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "win16|win16".
- Run: a) xymon 127.0.0.1 "client server01.aix bogos"
This should give the [aix] section of client-local.cfg.
HTH
J
In xymon-4.3.12 it sends the client-local block for the hostname, if it is defined OR the block for the OS, correct?? Not a blend of the two, with host-specific entries overriding the generic entries, right??
Does that change in a later release? I need a better way to manage it...
Ralph Mitchell On Oct 27, 2014 9:11 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
On 28 October 2014 08:45, Gregory J. DeCecco <turranx at hotmail.com> wrote:
Is this the expected behavior?
Yes - if you know what to expect! ;-)
One of the major performance improvements that Xymon has over its predecessor BigBrother, is that it keeps state in memory, and doesn't have to re-read its configuration files every 5 minutes. In some cases, this means that changes are not visible immediately, and require either a bit of time to pass, or an action to take place. This is the case for many configuration files used by Xymon.
I can see how this behavior would get in the way of architecting and
rapid testing of a client-local.cfg file with multiple OSType, HostClass, and Hostname entries.
The contents of the file client-local.cfg is held in memory by xymond, and is not updated unless xymond detects a change. The xymond process can be given a HUP signal to tell it to re-check all of its configuration files for changes, and reload details as required.
You might find this sequence useful:
On the Xymon server:
Create a new entry for server01 in hosts.cfg
Send xymond a HUP signal:
sudo -u xymon pkill -HUP xymond$
- Run: xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This shows the in-memory values for class and OS that xymond uses. As there has never been a client message, the values will be empty.
- Run: a) xymon 127.0.0.1 "client server01.bogos bogos" b) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "bogos|bogos". Note that the "client" message gets nothing from client-local.cfg.
- Run: a) xymon 127.0.0.1 "client server01.win128 win128" b) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "bogos|win128". Also, no output from client-local.cfg, but if there were an entry for [bogos] or [win128] it would have shown something, with preference given to [bogos].
- Run: a) touch hosts.cfg b) sudo -u xymon pkill -HUP xymond$ c) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "|" - that is, no values.
- Run: a) xymon 127.0.0.1 "client server01.win16 win16" b) xymon 127.0.0.1 "hostinfo host=server01 fields=XMH_CLASS,XMH_OS"
This will show "win16|win16".
- Run: a) xymon 127.0.0.1 "client server01.aix bogos"
This should give the [aix] section of client-local.cfg.
HTH
J
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 30/10/2014 5:48 AM, "Ralph Mitchell" <ralphmitchell at gmail.com> wrote:
In xymon-4.3.12 it sends the client-local block for the hostname, if it
is defined OR the block for the OS, correct??
I haven't installed anything after 4.3.10, so it might have changed, but I suspect not.
Not a blend of the two, with host-specific entries overriding the generic entries, right??
Yes, a single block (from client-local.conf), not a blend.
Does that change in a later release? I need a better way to manage it...
I've started using includes to better structure my config. For example, I can define a generic web server block in a separate file called client-local.apache.conf, and a separate file for postfix mail servers called client-local.pfx.conf. Also ones for OS-specific features. Then my client-local.conf looks like:
[sunos] include client-local.sunos.conf
[hostname1.example.com] include client-local.sunos.conf include client-local.pfx.conf include client-local.apache.conf
Some built-in way of blending blocks would be nice, but I suspect there's no single solution that would suit everybody, without becoming complicated, which wouldn't suit me.
J
On 10/29/14 14:48, Ralph Mitchell wrote:
In xymon-4.3.12 it sends the client-local block for the hostname, if it is defined OR the block for the OS, correct?? Not a blend of the two, with host-specific entries overriding the generic entries, right??
Does that change in a later release? I need a better way to manage it...
Ralph Mitchell
Hi Ralph
You can get a blend (merge) of the two:
from /help/manpages/man5/client-local.cfg.5.html
"If xymond is started with the "--merge-clientlocal" option, then xymond will instead merge all of the matching sections into one, and return all of this data to the client"
It appears to be global of course, and that may not be what you want.
I only knew about this because I have been working with alerting, and other settings recently and have been in and out of the docs quite a bit. :)
Hope that helps!
Bill
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
The "--merge-clientlocal" option is almost what I'm looking for, but not quite. It would be perfect if the host-specific variables would override matching variables in the generic OS entry. What I want to do is something like this in client-local.cfg:
[linux] file:/some/important/file file:/another/important/file xrate:28k
[server1] xrate:512k
The file names are read by a script that just sends a report with the file sizes and timestamps. The xrate value is used by a different script, for rate-limiting the transfer of an antivirus database file. Some servers are on gigabit network, others are a lot slower, so it would be nice to be able to override the os-level xrate entry with a faster setting where the network can handle it
So, ideally, when server1 checks in, it would be handed the file names and xrate:512k. When server2 checks in, it gets handed the file names and xrate:28k. If server1 is handed both xrate:28k and xrate:512k, can I be sure that they will always show up in that order??
If it would work that way, I could eliminate over 1000 client-local entries. Unfortunately, I'm working with xymon-4.3.12, which doesn't have the --merge-clientlocal option.
Ralph Mitchell
On Wed, Oct 29, 2014 at 5:44 PM, Bill Arlofski <waa-hobbitml at revpol.com> wrote:
On 10/29/14 14:48, Ralph Mitchell wrote:
In xymon-4.3.12 it sends the client-local block for the hostname, if it is defined OR the block for the OS, correct?? Not a blend of the two, with host-specific entries overriding the generic entries, right??
Does that change in a later release? I need a better way to manage it...
Ralph Mitchell
Hi Ralph
You can get a blend (merge) of the two:
from /help/manpages/man5/client-local.cfg.5.html
"If xymond is started with the "--merge-clientlocal" option, then xymond will instead merge all of the matching sections into one, and return all of this data to the client"
It appears to be global of course, and that may not be what you want.
I only knew about this because I have been working with alerting, and other settings recently and have been in and out of the docs quite a bit. :)
Hope that helps!
Bill
-- Bill Arlofski Reverse Polarity, LLC http://www.revpol.com/ -- Not responsible for anything below this line --
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
participants (4)
-
jlaidman＠rebel-it.com.au
-
ralphmitchell＠gmail.com
-
turranx＠hotmail.com
-
waa-hobbitml＠revpol.com