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.