I wanted to be able to see how my network looked from the "outside". Xymonnet running http tests was going to be perfect. A major sticking point was our local network access policies which made it very difficult for a host on the internet to access an "inside" server to deliver xymon messages.
The solution I am currently testing uses:
Outside: A Xymon server enabling only xymonnet and msgcache in tasks.cfg
Inside: A line in my hosts.cfg for the "outside" server with a "pulldata" tag Enabling xymonfetch in tasks.cfg
xymonnet on the "outside" Xymon server performs whatever tests are defined in its hosts.cfg. It reports the results to msgcache running locally.
xymonfetch on the "inside" Xymon server finds the "pulldata" flag, contacts the "outside" server, pulls all new messages from it, and passes them to xymond running locally. xymond handles the messages using its regular let of rules.
This lash-up lets me perform network tests from outside my network, but display the test results alongside all my other tests on the main Xymon web server. This is done even though the outside server is not allowed to reach the inside server.
Limitations:
The PULLDATA tag is supposed to support [=ip[:port]] modifiers. These modifiers do not work. xymonfetch always queries port 1984 of the specified host's IP address. This is a defect.
The data is passed un-encrypted across the network. In my case, all of the data is a result of testing publicly accessible web pages. Consider what your messages contain before trying this.
msgcache has an option to limit transfers to requests from only certain IP addresses. Since my "outside" network is NAT'd, I chose to implement my access restrictions at the firewall layers.
One PULLDATA tag is all that is required to retrieve all new messages from the distant msgcache. If the host/client names on the messages match up with entries on the main Xymon server, the messages will be incorporated.
All messages are accepted from the distant site, including "drop" and "rename" commands. This lash-up requires that you trust that no one will send malicious messages to the msgcache on the distant site. I only see one way around this; create a "pulling" server, running xymonfetch and xymonproxy, on a new IP address and use the --admin-senders option on xymond of the main Xyon server.
I don't know how many (or how quickly) messages can be cached by msgcache. It was designed to accept messages from an isolated client. It is possible that it will not be able to keep up with an influx of messages from xymonnet.
Do things because you should, not just because you can.John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska