[Xymon] Looking for clarification on Xymon client / server hierarchy.

[Grant Taylor]

On 10/17/23 12:37 AM, Jeremy Laidman wrote:
> Correct. The man page for xymonnet should cover the various env vars 
> that it supports. I think the only ones that might be required are some 
> combination of (XYMSRV, XYMONSERVERS, XYMSERVERS) as per doco to specify 
> the display servers, and access to the hosts.cfg file, and XYMONTMP. In 
> fact if you run xymonnet with the --loadhostsfromxymond switch, it 
> doesn't even need a local copy of hosts.xfg. Try something like this 
> from a device in your enclave, and see if the output looks OK, then drop 
> the --no-update to run it for real:
> 
> XYMSERVERS=xymon-server-or-IP XYMONTMP=/tmp 
> /usr/lib/xymon/server/bin/xymonnet --no-update --loadhostsfromxymond

I'll give that a try.

I think there is some benefit to leveraging xymonlaunch as in it's 
somewhat more common way to start / stop a process than modifying 
crontab.  But that's more outside of Xymon's wheelhouse.

> Optionally, try the --debug and/or --dump switches. You can specify the 
> FQDN of a target server if you just want to probe one device (eg for 
> testing).

I need to try this with a couple of systems that seem to keep flapping 
on TLS protected services when their unencrypted counterparts don't 
flap.  --  I think I saw a bug about a patch this year about a latency 
sensitive issue that may be related.

> You can set XYMONNETWORK to something in the NET: tags in hosts.cfg, and 
> only those devices will be polled. So in hosts.cfg:

Yep.  I'm doing exactly this.

I've got three separate Xymon installations that I'm helping administer:

  - $DAY_JOB -- has two environments, production in primary DC and DR in 
a secondary DC.  There is incomplete communications between prod and DR. 
  Hence the need for xymonnet, and maybe xymonproxy, in DR for things in 
DR to be tested properly.
  - $PERSONAL -- single site, common configuration.
  - $HELPING_A_FRIEND -- Now three sites; production, office, and 
friend's house.  Where office and friend's house are basically SOHO 
NATing routers that port forward SSH to an internal host.  So I'll be 
looking at xymonclient + xymonnet therein.

> 10.1.2.3 mywebserver.example.com # NET:enclave

Yep, I've got something like this already.  It's working great.

> XYMSERVERS=xymon-server-or-IP XYMONTMP=/tmp XYMONNETWORK=enclave 
> /usr/lib/xymon/server/bin/xymonnet --loadhostsfromxymond

I'll definitely give that a try for manual debugging.

But for normal production, I think a distro package of xymon-server with 
a trimmed down tasks.cfg to run xymonclient and xymonnet will suffice 
and be clean with OS init script expectations.

> Yep, agreed. And if that's the only exposure, then we're golden. Might 
> be a private key that the Xymon user accesses to authenticate for one of 
> its probes to an HTTPS server with client auth. Might be 
> /var/tmp/ps-dump that someone is running from their cron, to diagnose 
> some fault, not realising that someone else's process has 
> "--with-password=M0nkey", because that user didn't realise that args are 
> visible to all. Might be a core dump that someone copied to /tmp/, 
> without knowing that they can contain passwords and private keys.

All very valid examples of -- what I generally consider -- Oops! type 
mistakes / unintentional exposures.

> Of course most possible exploits are really unlikely, and require a bit 
> of stupidity and a bit of mis-fortune. I'm not trying to suggest likely 
> exposures, just possible exposures under some circumstances. We can't 
> mitigate all of them, but we can address the likely ones even if it 
> takes effort, and we also should address the unlikely ones where it 
> takes very little effort.

ACK

> I suppose my point here is, if a client doesn't need to access an 
> arbitrary file on a server, then it shouldn't be able to. If a client 
> doesn't need to access any file on a server, then it shouldn't be able 
> to. And a feature that permits this, and is on by default, and is seldom 
> used or necessary, and is possibly not known about by the sysadmin, 
> probably should be addressed, or at least assessed.

I completely agree.

I've often heard this as "business justification".  Which I have heard a 
translation of that I like better; "what benefit does doing this provide 
to the business".  IMHO "justification" can have negative connotation 
and / or baggage associated.

> Only for some threat models. Every xymon client has to be able to 
> connect to the xymon server on TCP/1984[*]. A firewall can allow or deny 
> that. But a firewall can't allow status and data messages while blocking 
> config messages.

ACK

> I'm not aware of a DPI firewall that can parse Xymon packets.

I strongly suspect that I could configure an IPTables "string" match to 
detect requests in normal unencrypted traffic.

But your point is taken and I digress.  ;-)

> I actually don't know. I don't use either of these features.

I've used the config support a few times.

I like the idea of having xymonnet `--loadhostsfromxymond`, which I 
assume needs `config` support.

> Yes. If my memory serves, the original BigBrother, on which Xymon was 
> based, was often deployed so that it could upgrade itself. This process 
> required that the BB server had tarballs of the various clients. The 
> clients would periodically check their versions with the latest 
> available, and if there was an updated, the client would fetch it and 
> untar over itself.

I used the option to pull in a tar file using `clientversion` (syntax 
from memory) once.  I can see using it to distribute additional local 
files and / or extensions.

We'll see.

> This mechanism was in place when compiling from source code was the only 
> way to deploy open source. So it seemed like a good idea at the time. 
> And it has merit. But these days, we're all used to using packages, and 
> we make good use of the additional features a package manage can bring. 
> So the way I see the download command is that it's a relic from a 
> previous generation, that most people won't ever use. Might come in 
> handy, but if there's another way to do it, probably use the nother way.

Eh ... package managers have their place.  But they don't, and IMHO, 
shouldn't cover everything.  Config and / or extensions probably don't 
go in custom distro packages.  --  Re-using a distro distribution system 
for custom configuration packages may make sense.  Arguably using a 
configuration management system makes the most sense, but they aren't 
always available.  It's a balancing act of what works in each use case 
with the fewest side effects / exposures.



-- 
Grant. . . .
unix || die