[Xymon] Getting data from a "pull only" site

John Thurston john.thurston at alaska.gov
Fri Dec 26 23:50:44 CET 2014


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



More information about the Xymon mailing list