[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