<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 3, 2016 at 10:19 PM Thomas Eckert <<a href="mailto:thomas.eckert@it-eckert.de" target="_blank">thomas.eckert@it-eckert.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 03 May 2016, at 08:46, Adam Goryachev <<a href="mailto:mailinglists@websitemanagers.com.au" target="_blank">mailinglists@websitemanagers.com.au</a>> wrote:</div><br><div>
<div bgcolor="#FFFFFF" text="#000000">
<div>On 03/05/16 12:02, Jeremy Laidman
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Sun, Apr 24, 2016 at 5:44 PM Thomas Eckert
<<a href="mailto:thomas.eckert@it-eckert.de" target="_blank">thomas.eckert@it-eckert.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Galen,</p><p dir="ltr">if egress SSH is allowed you could use an SSH
tunnel from the central to the regional Servers opening
say port 1985. Then use that for the communication between
the Xymon servers.</p><p dir="ltr">This will weaken the intentions of the security
policy of course ...</p><p dir="ltr">The tunnel can be managed by the ssh-tunnels
extension by Padraig Lennon (on Xymonton) or my slightly
extended version (on <a href="http://www.it-eckert.com/software/patches/ssh-tunnel/" target="_blank">http://www.it-eckert.com/software/patches/ssh-tunnel/</a>).
There are also some blog posts on my site on setup and
combining with xymonproxy.</p>
</blockquote>
<div>Sorry to be so late to the scene. I have a similar
requirement, but don't quite get the proposed solutions. I
have a couple of headless "probe" Xymon servers located on
less trusted networks, and a pair of Xymon servers that
primarily probe devices (testing TCP services, ping checks
etc) on our internal network. I want to be able to view the
results of the probe servers on the internal server
screens. I can't have the probe servers connect inbound to
the internal Xymon servers, except perhaps via ssh tunnel.</div>
<div><br>
</div>
<div>JC suggested that xymonfetch could be run on the regional
(probe) servers to send in to the internal servers. I
haven't used xymonfetch before, so I'm not intimately
familiar with how it's used. Nevertheless, in reading the
documentation I can see that xymonfetch is intended to run
on a Xymon server to connect to a Xymon client that has
msgcache running. This doesn't seem to be the model
described by JC, where msgcache isn't mentioned. Or am I
misunderstanding something?</div>
<div><br>
</div>
<div>Perhaps relevant to a solution, the Xymon probe servers
periodically connect to the Xymon clients over ssh, create a
reverse tunnel, and run xymonclient.sh with suitable
environment variables to push the client data through the
reverse tunnel.</div>
<div><br>
</div>
<div>Perhaps what I need to do is something like this. I fire
up a msgcache on each probe server, having everything feed
into the msgcache instead of xymond, and I periodically run
xymonfetch on each probe server to push the messages into
the real xymond running there. (I'd probably have xymond
listen on an alternative port, and have msgcache run on
1984.) I would then have the ability to run a second
instance of xymonfetch on the probe servers, but being
called via ssh from each internal server, complete with a
reverse tunnel, so that the xymonfetch would inject into the
xymond on the internal server. What I can't figure out here
is how to allow a msgcache queue to be pushed into the probe
server's xymond without being emptied and hence unavailable
for the internal xymon server.</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
I would guess you can pass messages to xymonproxy, which will pass
messages to the local xymon server plus xymonmsgcache, then the
remote server will connect with ssh and collect the pending messages
from the xymonmsgcache?<br>
<br>
I hope that is what you were asking about.<br></div></div></blockquote></div></div></blockquote></div><div dir="ltr"><div class="gmail_quote"><div><span style="line-height:1.5">Yep, that sort of thing. </span><br></div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div bgcolor="#FFFFFF" text="#000000"></div></div></blockquote></div></div><div style="word-wrap:break-word"><div>I’ve only used `msgcache` on a single client up to now (for isolated hosts).</div><div>But I _seem_ to remember that there are limits on the amount of messages it can cache (beside other drawbacks, listed here <<a href="http://www.it-eckert.com/blog/2014/remote-site-monitoring-with-ssh-tunnel/" target="_blank">http://www.it-eckert.com/blog/2014/remote-site-monitoring-with-ssh-tunnel/</a>>).</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>That's a great point. Yes, I remember reading about the limitations of msgcache, now that you mention it.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="line-height:1.5">As I understand the intended use is</span><br></div><div><br></div><div>Xymon (central) — Xymon (region1) — multiple clients region1</div><div> |</div><div> — Xymon (region2) — multiple clients region2</div><div> |</div> — … </div></blockquote><div><span style="line-height:1.5"><br></span></div></div></div><div dir="ltr"><div class="gmail_quote"><div><span style="line-height:1.5">Yes.</span><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div><span style="line-height:1.5"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>This would lead to a potential huge number of messages on the regional Xymon servers that might well go beyond the capacity of `msgcache`.</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Agreed.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="line-height:1.5">Using `xymonproxy` on the regional servers would allow to deliver the status-messages to the (local) regional server _and_ the central one.</span></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Makes perfect sense.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="line-height:1.5">This is outlined here <</span><a href="http://www.it-eckert.com/blog/2014/combine-ssh-tunnel-with-xymonproxy/" style="line-height:1.5" target="_blank">http://www.it-eckert.com/blog/2014/combine-ssh-tunnel-with-xymonproxy/</a><span style="line-height:1.5">> (the "remote-datacenter” would be a regional server). To have the data available on the regional server as well the `xymond` there has to listen on say `127.0.0.1:1986` and xymonproxy report to that location as well (xymonproxy-option for sending to multiple servers `--server=SERVERIP[:PORT][,</span><span style="line-height:1.5">SERVER2IP[:PORT]]` — according to `xymonproxy(8)` up to 3 servers are possible, configuration it pulled from the _last_ in the list!). The order of the xymonproxy “receivers” would also allow the configuration of the regions to be either from central or from the regional server.</span></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I think what's missing from this plan is that the xymonnet probes need to be diverted to the xymonproxy instance also. But apart from that, I can't see why it wouldn't work for me.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="line-height:1.5">The ssh-tunnel is handled by the central server using the `ssh-tunnel` extension (either original <</span><a href="https://wiki.xymonton.org/doku.php/addons:ssh_tunnel" style="line-height:1.5" target="_blank">https://wiki.xymonton.org/doku.php/addons:ssh_tunnel</a><span style="line-height:1.5">> or extended version <</span><a href="http://www.it-eckert.com/software/patches/ssh-tunnel/" style="line-height:1.5" target="_blank">http://www.it-eckert.com/software/patches/ssh-tunnel/</a><span style="line-height:1.5">>)</span><span style="line-height:1.5"> that takes care the tunnel is up.</span></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I'm not sure why, but I prefer to have transient ssh tunnels for the duration of the message transfer, rather than persistent tunnels that hang around forever. (Either way, ssh encryption and authentication is provided.) It looks like xymonproxy has a buffer, and so it may be able to queue messages destined for the central server for a short period of time, and the --lqueue size can be adjusted to manage this. Although I would be more comfortable if it had the ability to save its queue to disk so as to survive restarts, and also to allow for a much larger queue.</div><div><br></div><div>If xymonproxy offers the same queueing capability as msgcache, without the shortcomings, then it seems like an easy choice to make. I just don't know if it can queue things for long enough if my central server "checks in" every 5 minutes, instead of having a persistent tunnel. Come to think of it, I probably need to know what happens to the queue if a persistent tunnel goes down for a period of time (eg a firewall crashes and the link goes down for 30 minutes). Will the extra messages overflow? What would happen if a red-to-green transition was lost?</div><div><br></div><div>J</div><div><br></div></div></div></div>