Let's say I want to add a test that probes for a DHCP server or relay...and that there should be one, and only one on a given LAN (or if more than one, only authorized ones). The test could be run on any client on the LAN, or on the xymon server for the LAN it's on. The test results have nothing to do with the system the test runs on, save that it's on the LAN in question.
(The test isn't that hard; nmap --script broadcast-dhcp-discover -e net0 (change interface name as needed) can collect the data, and the output be examined to look for "Response 1 of 1:" and check that the IP following "Server Identifier:" is as expected; if not, either the DHCP server is missing, or there's one or more that shouldn't be there, or, if there's a single response but the IP is wrong, worst of all, there's one DHCP server, but it's bogus or misconfigured.)
Do I make up a pseudo-hostname (e.g. give each LAN a name of its own), put that in hosts.cfg with a reserved-as-bogus address (can't use 0.0.0.0 if that will cause lookup failures), maybe mark it noconn (since the IP should not be pinged) and multihomed (since the IP is bogus, and the IP that the report comes from may be different), and with the test name? And then make the test script report as if the hostname was the made-up LAN name? And of course NOT use any tests handled by xymonnet for that entry?
I suppose that would work, and if I put those pseudo-hosts in a separate page or section, would only have the DHCPprobe test (or similar tests) column for them.
But is that (a) a reasonable thing to do, or just plain crazy, and (b) is that a reasonable abuse (if that's not an oxymoron) of the facilities xymon provides, or is there some better way to do that sort of thing (e.g. a test that's per-LAN or at any rate doesn't really relate to a single system as such)?
Keep in mind that putting in entries specifically for the DHCP servers/relays themselves may not be helpful insofar the test is not truly just for them (why xymonnet can't do it), that one might want to have a variation to allow more than one legitimate DHCP server per LAN (redundant, perhaps with only static allocation tied to MAC addresses so they don't have to coordinate allocation from a dynamic address range), etc. Not to mention that a DHCP server may be colocated on a router or other infrastructure box, which one might either not want to report at all, or report separately, and which might not support a client extension script, thus requiring the script to run elsewhere anyway.
My case, with a single home LAN, is pretty trivial; but if there were more LANs, the script might end up hard-coding LAN names to use individually (each version of script different), unless it parsed ifconfig output to see what LAN it was on, and then consulted an entire table of LAN addresses (either hardcoded or retrieved from the server) to see what name to use for the LAN. So writing the script to be scalable to multiple LANs without needing each instance tweaked would be harder.
Could xymon handle (pseudo-) hostnames that looked like LAN-192.168.0, or would it choke on those? Names like that would require no bother for how to make them up (no table needed, could be generated from the interface IP and net mask), and would be informative...although it wouldn't work well for net masks that were other than /8, /16, or /24. And how the heck could one generate acceptable IPv6 LAN names that were similarly useful and digestible? :-)
Even with auto-generated LAN names, there would still need to be a table of legitimate DHCP server(s) per LAN, so I suppose that would best be retrieved from the server.
Have I finally come up with an unusual enough idea to make someone's head hurt? :-)