On 10/16/23 9:51?PM, Jeremy Laidman wrote:

Indeed. Perhaps more precisely, it can be satisfied by xymonlaunch, which also runs the main Xymon client script (xymonclient.sh). It's also possible to run xymonnet from cron, or set it up as a systemd service, or even trigger its execution by running from a remote ssh session (something like "ssh client-host /usr/local/bin/xymonnet --env=/usr/local/etc/xymonnet.conf").

Okay. That sounds very promising.

I had naively assumed that xymonnet used some sort of IPC to xymond and was thus dependent on it.

Now I get the impression that it's more that xymonnet needs a properly configured environment and that the easiest way to do that is to use Xymon / xymonlaunch to manage that for you. But it sounds like it's quite possible to crate said environment and call xymonnet directly.

In most cases, running from within a xymoncmd environment (which is implied when run by xymonlaunch) takes away the need to explicitly set all of the required options. So you could have a cron job like so: */5 * * * * xymon /usr/lib/xymon/client/bin/xymoncmd /usr/local/bin/xymonnet >>/var/log/xymon/xymonnet.log 2>&1

Very good to know.

I ran into a situation this evening where I need to duplicate the firewalled environment behind another host that is currently a stand alone client.

But it's worth taking a look at the xymonnet entries in the tasks.cfg file on the Xymon server. There is a xymonnet-again (I think) task that runs more frequently but only performs probes for failed tests. In this way when a fault is detected, the polling rate increases so that you can more quickly see when a service is restored, and SLA times are more accurate.

Yep.

I suspect that I'll be installing the distro provided xymon-server and tweaking tasks.cfg to run the client, xymonnet, and xymonnet-again. But not the xymond / display server.

I don't think xymonproxy is required for this. If your clients can talk directly to your xymon server on TCP/1984, then that's all xymonclient.sh and xymonnet need to be able to do.

Good to know.

I think xymonproxy is only required if your clients can't connect directly to your server. And it will add delays, and become an extra point of failure.

Noted.

If you haven't already, look into msgcache and xymonfetch. These can be used to bridge networks in a slightly different way to xymonproxy.

I'm aware of them and I've skimmed (parts of) their manual pages. I've not yet needed to go to -- what I call -- the poll methodology. Currently, -- ... -- the push methodology has been sufficient to get data from clients to the server.

The biggest hiccup I've had is running xymonnet inside the firewalled network.

Makes sense, and should work fine.

:-)

I actually like "xymongrep" for its ability to do searches. By default it looks for hosts.cfg, but if given the --loadhostsfromxymond?switch, it'll connect to the Xymon server and send a "config hosts.cfg" command and filter for the tags you're interested in. So you could do something like:

xymoncmd xymongrep "NET:behindfirewall" > hosts.cfg

(multiple search strings can be used, and lines that match any of them will be returned)

Interesting idea.

This brings up a possible issue for some installations and security postures. In a multi-network multi-security-level environment, some consider the "config" command to be a feature that's not worth the potential risk. For example, if there's a coding error in Xymon, there might be a way to request the config file /etc/shadow.

Understood and appreciated.

But if Xymon is running as anything other than root, it's chances of reading the /etc/shadow file are -- dare I say -- exceedingly small.

But I completely get that Xymon coding errors could make it possible to read any file that the user that Xymon is running as can read.

Or if someone doesn't realise that hosts.cfg is potentially exposed outside the Xymon server in this way, they might put a password or private key in the hosts.cfg file (eg in a tag for a custom extension). An example of this is that the "devmon" add-on uses the DEVMON: tag to specify SNMP parameters, including community string, and the operator might not realise that the community strings are accessible by any Xymon client.

Yep.

If this is of concern to you, then you should consider ways to mitigate this. Choosing to not use this feature in your scripts doesn't mean an attacker can't do so.

Yep.

I fully understand that the capability can be used by a bad actor, even if I don't use it myself.

I don't know if there's a way to prevent "config" messages from being honoured by the xymond process. It's possible to have xymond ignore messages (including config) from IP addresses that aren't in hosts.cfg, so this will minimise any exposure.

I should investigate that.

I assume that a firewall also helps here.

There's a similar feature where you can send a "download" message and receive a copy of the named file. The download feature can be disabled by adding "--no-download" to the xymond command line arguments.

Doesn't the download feature also have a more lax mode where it will allow you to download things that aren't config files? Or am I conflating config and download?

I also wonder where the command comes into play to have clients download updated (tar files) from the central server and install them.

-- Grant. . . . unix || die