Quirky behavior 🔗 link

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:

 
1.       Edit the server's hosts.cfg file.  Insert a non-existent server
'server01' and give it a fake/real IP.

2.       Edit the server's client-local.cfg file.  Create several entries
within for different OS types:

a.       Linux

b.      Win32

c.       AIX

d.      Etc.

3.       Make sure that each section for the OSType contains a unique string
or command.  You will use this to identify which OSType the Xymon server
service identified 'server01' as.  

4.       Wait for 'server01' to show up on the web site.  It won't have any
status data to report yet.  This is OK.  NOTE:  Do not restart the Xymon
service.

5.       Find a computer (real/VM) to pretend to be 'server01'.  It doesn't
matter which OS the client has, just as long as you are comfortable running
custom scripts upon it.

6.       From 'server01', issue this command, replacing OSType and HostClass
with your favorite values:

a.       "client server01.<OSType> <HostClass>"

7.       If you're lucky, the Xymon server will respond back with the
appropriate unique string for your OSType from the client-local.cfg file.

8.       Now, change OSType and rerun the command from the same client
machine.  For example, if you first used "win32", now use "linux" instead. 

a.       "client server01.win32 <HostClass>"

b.      "client server01.linux <HostClass>"

9.       Did the Xymon server respond with the unique string from the
new/second OSType?  I betcha it didn't.  It's still responding with the
unique string from the first OSType you used, right?

10.   Edit the server's hosts.cfg file.  Insert a non-existent server
'server02' and give it a fake/real IP.

11.   Wait for 'server02' to appear in the web page.

12.   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"

13.   Wait for the web page to update, showing status information for
'server02', but not 'server01'.

14.   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>"

15.   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.

16.   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.

17.   Edit the server's hosts.cfg file.  Remove 'server01' and 'server02'.

18.   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"

19.   Wait for the web site to stop showing server01 and server02.

20.   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.

21.   Wait for 'server01' and 'server02' to appear in the web page.

22.   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>"

23.   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.

24.   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.

25.   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 <user-e65d382d9698@xymon.invalid> 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

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:

1. Create a new entry for server01 in hosts.cfg

2. Send xymond a HUP signal:

  sudo -u xymon pkill -HUP xymond$

3. 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.

4. 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.

5. 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].

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

7. 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".

8. 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" <user-71895fb2e44c@xymon.invalid> wrote:

On 30/10/2014 5:48 AM, "Ralph Mitchell" <user-00a5e44c48c0@xymon.invalid> wrote:

I haven't installed anything after 4.3.10, so it might have changed, but I
suspect not.

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:

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 <user-0b8af203a56e@xymon.invalid>

wrote:

:)