[Xymon] Quirky behavior

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.