- Xymon - Xymon mailman web

Missing support for HTTP/2 ?
by abe＠deuxchevaux.org 01 Nov '23

01 Nov '23

Hi, On Wed, Nov 01, 2023 at 02:21:04PM +0100, Ingeborg Hellemo via Xymon wrote: > I have a webserver which works ok when you visit it in a browser or when you > use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" > from the command line works as expected. > > Could the culprit be that xymonnet does not support HTTP/2 ? I don't think so. It's probably more an issue of incompatible ciphers or so. Or is that an HTTP/2-only server? So far I'm also not aware of any HTTP/2 only (production) web server. Maybe this will come in the future. But yeah, as far as I know, xymonnet does not support HTTP/2 ? nor HTTP/3. Then again, it might be possible to implement a minimal client via protocols.cfg hex syntax like with e.g. ajp13 or rdp. But if the handshake needs anything outside the standard TLS handshake (and I'm not that versed in HTTP/2), it will not work. And indeed, builtin xymonnet support for HTTP/2 and HTTP/3 would be nice, especially if you could monitor the availability of protocol versions separately (like for HTTPS and HTTP). But I suspect this would need an 3rd party library like curl or nghttp2 to be used. Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/

3 3

Missing support for HTTP/2 ?
by ingeborg.hellemo＠uit.no 01 Nov '23

01 Nov '23

I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ? /#curl --head https://<servername>/ HTTP/2 200 cache-control: private content-length: 4423 content-type: text/html strict-transport-security: max-age=31536000 date: Wed, 01 Nov 2023 13:15:44 GMT --Ingeborg -- Ingeborg ?strem Hellemo -- ingeborg.hellemo at uit.no Dep. of Information Technology --- Univ. of Troms?

1 0

Looking for clarification on Xymon client / server hierarchy.
by jeremy＠laidman.org 17 Oct '23

17 Oct '23

On Tue, 17 Oct 2023 at 14:19, Grant Taylor via Xymon <xymon at xymon.com> wrote: > 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. > 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 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). You can set XYMONNETWORK to something in the NET: tags in hosts.cfg, and only those devices will be polled. So in hosts.cfg: 10.1.2.3 mywebserver.example.com # NET:enclave XYMSERVERS=xymon-server-or-IP XYMONTMP=/tmp XYMONNETWORK=enclave /usr/lib/xymon/server/bin/xymonnet --loadhostsfromxymond 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. > 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. 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. 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 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. > 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. I'm not aware of a DPI firewall that can parse Xymon packets. > 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 actually don't know. I don't use either of these features. I also wonder where the command comes into play to have clients download > updated (tar files) from the central server and install them. > 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. 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. J

2 1

Can custom client-side tests leverage the server-side value in analysis.cfg?
by jeremy＠laidman.org 17 Oct '23

17 Oct '23

On Tue, 17 Oct 2023 at 13:55, Grant Taylor via Xymon <xymon at xymon.com> wrote: > > Oh my! Isn't AIX5.3 like a decade beyond end-of-support? > > At least. > > Does "legacy" and "out to pasture" or even "business critical" mean > anything to you? My $DAY_JOB is care and feeding of old systems that > nobody else wants to touch. I enjoy it and it pays the bills. > Oh dear. I'm glad you enjoy that sort of thing. I suppose if the expectations aren't high, then you can always exceed expectations. Do you happen to program in COBOL? ;-) J

2 1

Looking for clarification on Xymon client / server hierarchy.
by jeremy＠laidman.org 17 Oct '23

17 Oct '23

On Tue, 17 Oct 2023 at 12:34, Grant Taylor via Xymon <xymon at xymon.com> wrote: > The scenario that I'm working with can be described as a primary Xymon > (display) server in one network with a small lab network behind a NATing > / SPI firewall. Clients on the inside side / opposite of the Xymon > server are free to send outgoing packets. It's just that xymonnet > running on the Xymon server can't send probes into the clients. > > > You can run xymonnet stand-alone, and set environment variables to tell > > it where to send its messages. If you already have a xymon client > > installed on the client host, you can execute xymonnet from > > clientlaunch.cfg and it should then know where to send packets due to > > the environment that is setup. > > Oh! This is promising. > > I misinterpreted comments in the tasks.cfg file to mean that xymonnet > depended on xymond. Now it sounds like xymonnet can be satisified by > the xymon client. > 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"). 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 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. Running xymonproxy + xymonnet + xymonclient on a system inside of the > firewall might do what I'm wanting to do. > 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. 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. 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 quite okay with '${XYMON} ${XYMSRV} "config hosts.cfg" > hosts.cfg' > on the internal system running xymonnet. > 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) 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. 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. 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. 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. 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. Cheers Jeremy

2 1

Can custom client-side tests leverage the server-side value in analysis.cfg?
by jeremy＠laidman.org 17 Oct '23

17 Oct '23

On Tue, 17 Oct 2023 at 12:22, Grant Taylor via Xymon <xymon at xymon.com> wrote: > Sounds like use what's best for the situation, even if there might be a > slight affinity one way or the other. > Yes. One of the things I love about Xymon is that it's extremely flexible so that you get to choose from a range of different ways to solve a problem, based on your skillset, environment, and preferences. It's modular and extensible. > > With central mode, client data messages are sent to the server, into > > the xymond daemon. Then code on the server asks the xymond daemon for > > the client message of each host, parses them for possible problems, > > and constructs a status message with the colour in the header and a > > text report in the body. > > My understanding is that's one way to do it. > Yes, one way (see my previous comment ;-). But it's also the way Xymon does it internally. Well, kind-of. Instead of "asks the xymond daemon" a xymon module connects to a channel and receives from the xymon daemon. But the data flow is pretty much the same, and I suppose that's what I was trying to convey, while avoiding the technical complexities. My understanding that another way to do it is to hook in as a channel > and receive a copy of all messages (of the proper type) and act > appropriately. > Yes indeed. You're really getting into the nitty-gritty of things. Most Xymon admins never have to know that channels are a thing, because they're mostly used for Xymon to talk to itself (eg to parse a client data message and create status messages). So consider yourself levelled-up! When writing server-side extensions that use client data, you can write your own parser that periodically fetches the latest client message, or you can tap into the channel to get it. Xymon taps into the channel. I'm trying to get my hands on a compilation of any version for AIX 5.3 > (?). For now I'm running the hobbitclient-aix.sh via telnet w/ echo > scheduled via cron. It's working and providing most of what I need and > much of what I want. > Oh my! Isn't AIX5.3 like a decade beyond end-of-support? I've sort of taken what previous colleagues poked once in a while and > ran with it to make things better for $DAY_JOB, myself, and a friend > that I help. I've also intrigued another friend enough to install and > play with it. > > I think I say that I'm liking Xymon. ;-) > Good to see. > > The patch is applied to the packages available from the Terabithia > > repository, but I don't believe it's included when Xymon is built from > > original source code. > > Please elaborate and / or point me where I can go do some more reading. > About the "sections" patch? I don't know much about the background to its conception and existence, but there's probably a CHANGELOG and that might provide some info. If you haven't yet, perhaps install an RPM from the Terabithia website, or unpack an SRPM to review any extra README files or the like. I've seen references to 4.4 being in alpha status. > Yes indeed. I've not started testing this yet myself. Yep. Naming things and knowing where / how to start counting are three > of the hardest things in computers. > LoL. Cheers Jeremy

2 1

Looking for clarification on Xymon client / server hierarchy.
by jeremy＠laidman.org 17 Oct '23

17 Oct '23

Hi Grant The xymonnet process needs to be able to send probe packets (eg ping, web requests, and whatever you're trying to monitor) to the clients. If the firewall is blocking the probe traffic, then it's not going to work. The xymon proxy only proxies xymon messages, such as the ones sent by the xymonnet process to the xymond process when reporting the status of the probes (success or failure, and round-trip times). It seems to me that you need a xymonnet process running on the client side of the firewall. For example, if you can run xymonnet on one of the clients, then the firewall only needs to allow xymon traffic from the client to the Xymon server, so that xymonnet can report the status of its probes. You can run xymonnet stand-alone, and set environment variables to tell it where to send its messages. If you already have a xymon client installed on the client host, you can execute xymonnet from clientlaunch.cfg and it should then know where to send packets due to the environment that is setup. The only thing I'm not certain of, is how xymonnet knows which hosts to probe and what probes to send to them. When xymonnet is running on the Xymon server, it has access to the hosts.cfg file that's there. When running elsewhere, I'm not sure. I know that there's a way to fetch the hosts.cfg contents using xymon messages, so my guess is that xymonnet can do that too, but might need to be told to do so. And if so, you would only want that xymonnet instance to probe devices inside the client network, so you might need to make use of the "NET:" tags in hosts.cfg. J On Tue, 17 Oct 2023 at 02:51, Grant Taylor via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: Grant Taylor <gtaylor at tnetconsulting.net> > To: xymon at xymon.com > Cc: > Bcc: > Date: Mon, 16 Oct 2023 10:49:42 -0500 > Subject: Looking for clarification on Xymon client / server hierarchy. > Hi, > > Would someone help me understand the Xymon client / server / proxy > hierarchy a little bit better? > > My scenario is I have two locations separated by a firewall wherein > clients inside can send things out to the larger network, but the > xymonnet can't reach in to probe clients in the private LAN. > > I had thought that an Xymon proxy might be the answer for this. -- I > did get internal clients to relay updates out through the xymonproxy to > the Xymon (display) server. However xymonnet seems to not utilize the > xymonproxy to initiate tests therefrom. > > What is the recommended way to have Xymon monitor internal clients that > can't be directly reached from the Xymon (display) server? > > Aside: It seems as if the xymonproxy might be for the other way around, > to have clients in the wild get messages into a protected Xymon server > which can reach out and touch the clients. > > Thank you and have a good day. > > > > -- > Grant. . . . > unix || die > > > > ---------- Forwarded message ---------- > From: Grant Taylor via Xymon <xymon at xymon.com> > To: xymon at xymon.com > Cc: > Bcc: > Date: Mon, 16 Oct 2023 10:49:42 -0500 > Subject: [Xymon] Looking for clarification on Xymon client / server > hierarchy. > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

2 1

Can custom client-side tests leverage the server-side value in analysis.cfg?
by jeremy＠laidman.org 17 Oct '23

17 Oct '23

Responding inline: On Tue, 17 Oct 2023 at 02:47, Grant Taylor via Xymon <xymon at xymon.com> wrote: > > > The "DS" means "data source". It's a term used by the RRD (round-robin > > database) library (and tools) that Xymon uses for storing historical > data. > > Thank you for clarifying. I sort of deduced that as I got further into > the custom graphs, which I've now got working. But it's one of those > things that when you're newer to something "DS" is unfortunately vague > and lost in a sea of new information. > Agreed. Xymon/Hobbit, and its spiritual predecessor BigBrother, come from a tradition of using a common collection of disparate tools for monitoring networked devices and hosts. One of these foundational tools is RRD, which is used by other network monitors (Cacti, MRTG, etc). The "culture" of Xymon can sometimes assume knowledge of how the other tools work. And while there's references to RRD in the Xymon doco, it couldn't hurt to add some extra definitions or explanations within the Xymon doco, to help those who don't have a history in this space that extends back to the last millenium (showing my age, aren't I). > As a general principle, Xymon clients operate in local mode or central > > mode. In (the older) local mode, the clients do all of their own > > analysis and create their own data and status messages. In (the more > > modern) central mode, the clients do a lot less of that, and instead > > simply gather data for the server to parse and alert on. > > Would it be fair to say that the older local mode uses status messages > with color and newer central mode use data messages without color? -- > As a rough generalization, not a hard and fast rule. > Yes and no. The central/local mode choice relates to the bulk of the core OS resource metric collection and processing. Choosing central mode doesn't prevent the use of client-side processing and status messages (with colour) being sent from the client. I know you didn't ask this, but I'm just making sure I'm not giving the wrong idea. With local mode, the client looks for faults, and sends a status message with the colour in the header and a text report in the body. With central mode, client data messages are sent to the server, into the xymond daemon. Then code on the server asks the xymond daemon for the client message of each host, parses them for possible problems, and constructs a status message with the colour in the header and a text report in the body. So the last part of the process is the same. The Xymon server receives status messages from itself for clients in central mode, or from the clients when they're in local mode. To bring it back to your phrasing, local mode uses status messages with colo(u)r and central mode also uses status messages with colo(ur) but those messages come from the Xymon server itself. In central mode, the colours are determined by the server (eg in analysis.cfg), whereas in local mode, the colours are determined by the client. > You could create a script in the "sections" subdirectory, and the > > Xymon client will automatically run it and include the output in > > the [mailq] section of the client message. > > This is very intriguing. I spent a moment looking for "section" (case > insensitive) in the client directory tree (`fgrep -ir "section"` type > thing) and found reference to the client/local directory. Upon testing, > I see that I end up with the output of my executable (currently a > script) with a heading named `[local:test_script.sh]`. > Yes, the "client/sections" directory is a relatively recent feature that was added as a "patch" to the original client-side script. My mistake for assuming that everyone had this. The patch is applied to the packages available from the Terabithia repository, but I don't believe it's included when Xymon is built from original source code. The "client/local" directory is "standard" Xymon (as long as you create the directory), but it has the side-effect of making section names with the "local" prefix. There are probably good reasons for this prefixing (I'm guessing to prevent collisions with standard section names), so if it works for you, that's great. My guess is that the next release of Xymon will include client/sections in the source, in addition to supporting client/local. A snippet from the README in client/sections/ from the Terabithia package: "This directory is intended for use with automatically deployed files. Local scripts for this host should be placed in the client/local/ directory instead." It seems like the gist of the idea is to receive the client status > message, extract the section, and generate updates therefor. > Exactly. The client is as simple as it can be, so that it doesn't need constant tweaking. The server does all the smarts, including parsing, graphing, thresholding, so that the client host can spend more cycles doing its main function. > And optionally turn the mail queue size into a graphable data point > > (either create a trends message with the number, or use a > > colon-separated value format for the Xymon parser to detect). The Xymon > > doco has a "how to setup custom graphs" page with a few different ways > > to do this type of thing. > > Yep. I used that very page to get NCV based custom graphs working > Friday evening. > > I still need to explore the DS analysis / color declaration therefor. > You're well on your way, so well done! Feel free to ask more questions on this list. The more questions the better our shared knowledge! (Although it's easier to respond to if each question is in a separate thread.) J

2 1

Looking for clarification on Xymon client / server hierarchy.
by gtaylor＠tnetconsulting.net 16 Oct '23

16 Oct '23

Hi, Would someone help me understand the Xymon client / server / proxy hierarchy a little bit better? My scenario is I have two locations separated by a firewall wherein clients inside can send things out to the larger network, but the xymonnet can't reach in to probe clients in the private LAN. I had thought that an Xymon proxy might be the answer for this. -- I did get internal clients to relay updates out through the xymonproxy to the Xymon (display) server. However xymonnet seems to not utilize the xymonproxy to initiate tests therefrom. What is the recommended way to have Xymon monitor internal clients that can't be directly reached from the Xymon (display) server? Aside: It seems as if the xymonproxy might be for the other way around, to have clients in the wild get messages into a protected Xymon server which can reach out and touch the clients. Thank you and have a good day. -- Grant. . . . unix || die

1 0

Can custom client-side tests leverage the server-side value in analysis.cfg?
by jeremy＠laidman.org 16 Oct '23

16 Oct '23

Grant, a few quick responses to your message: The "DS" means "data source". It's a term used by the RRD (round-robin database) library (and tools) that Xymon uses for storing historical data. As a general principle, Xymon clients operate in local mode or central mode. In (the older) local mode, the clients do all of their own analysis and create their own data and status messages. In (the more modern) central mode, the clients do a lot less of that, and instead simply gather data for the server to parse and alert on. For your requirement, what I would do is to have the client collect the queue size (and other data) and include this in the client message and one of the sections, eg [mailq]. The contents of this could simply be the output of the "mailq" command. You could create a script in the "sections" subdirectory, and the Xymon client will automatically run it and include the output in the [mailq] section of the client message. Then on the server, run a script (eg from tasks.cfg or something like tasks.d/mailq) that dumps the client data message for every client, and if a [mailq] section is found, create a status message. And optionally turn the mail queue size into a graphable data point (either create a trends message with the number, or use a colon-separated value format for the Xymon parser to detect). The Xymon doco has a "how to setup custom graphs" page with a few different ways to do this type of thing. J On Sat, 14 Oct 2023 at 08:20, Grant Taylor via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: Grant Taylor <gtaylor at tnetconsulting.net> > To: xymon at xymon.com > Cc: > Bcc: > Date: Fri, 13 Oct 2023 16:18:08 -0500 > Subject: Re: [Xymon] Can custom client-side tests leverage the server-side > value in analysis.cfg? > Hi Conor, > > Thank you for your reply. > > The overall gist of what I've understood thus far is that it's > /indirectly/ possible to have custom client-side scripts use server-side > values by arranging for a copy of those values to be available (cached) > on the client for local use. -- Is that an accurate summary? > > On 10/13/23 1:20?PM, Conor McCarthy wrote: > > Yes, a simple way is to use the "config" command, this lets you > > download any .cfg (or arbitrary files, if ALLOWALLCONFIGFILES="TRUE" > > but don't do that :) files from the server's etc/ directory. > > > > client/bin/xymon $XYMONSERVER "config analysis.cfg" > tmp/analysis.cfg > > > > If you use "include" or "directory" directives in the .cfg files > > Xymon will send you the "flattened" expanded contents. > > I'm glad to know that the analysis.cfg will be flattened as we're making > extensive use of includes. > > > You will need to parse that file to do anything useful though. > > > > Alternatively, fetching the hosts.cfg and using xymongrep > > client/bin/xymon $XYMONSERVER "config hosts.cfg" > tmp/hosts.cfg > > HOSTSCFG=tmp/hosts.cfg client/bin/xymongrep mytag:* > > might be simpler for simple configuration data that you can put in a > > "tag:" for each host. > > I'd rather have the values being checked against -- as opposed to what > tests are run -- in the analysis.cfg file. It seems to me like having > value entries in an additional file could potentially end up in some > confusion. Which file do I check CPU load in? What about mail queue > size? Type thing. > > > xymongrep is normally used server-side to loop over multiple hosts, > > you will likely need to match just one client name from its output > > for a client script. > > That's the impression I had gotten. > > I feel like the ability to access the config, and thus what other > clients are being monitored, is a little bit of an information leak. > Probably not one that matters. And it's not like I can do anything > about that. > > > Alternatively, instead of using analysis.cfg the client-local.cfg > > file is logically cleaner (and automatically shipped to clients, see > > client/tmp/logfetch.HOSTNAME.cfg). > > ACK > > > This specifies the client-side part of log and file checks, although > > it's not documented, you can add arbitrary lines to this file, e.g. > > [myhostname] > > x-my-specialvarA one > > x-my-specialvarB two > > log:/var/log/message:16384 > > ignore MARK > > Good to know. > > > Each client will pick this up and store its own "personal" stanza > > from the global client-local.cfg, this is automatically refreshed > > each client run cycle. > > Does the server send the personalized version? Or does the client > receive the full version and only store it's own personal values? > > > Any non-documented parameters are explicitly ignored, but best placed > > above any of the documented ones to make sure. > > Noted. > > > status: yes (though "clear" might be an option), > > Interesting call on the "clear" color. > > That has the added benefit of not declaring a green / yellow / read. > > > data: no. > > Noted. > > > There's also a "modify" message you can use after the fact to > > change a status/colour (though take care not to trigger flapping). > > Ya. I had seen modify. I figured that might be part of how the server > side tweaking of client side colors might happen. > > I believe there is some restriction on once a message has been modified, > only the same thing can modify it again. -- I assume that restriction > is only there until a new status message comes in from the client. > > > Seems like fetching the hosts.cfg and using xymongrep should work > > for that without too much trouble, at least as an exercise, and is > > reasonably self-evident. > > ACK > > > hosts.cfg: > > 10.1.2.3 mailhost1 # ssh smtps MAILQ:qwarn=200,qcrit=500 > > > > Then in a bash script (light on error checking) for example: > > client/bin/xymon $XYMONSERVER "fetch hosts.cfg" > tmp/hosts.cfg > > HOSTSCFG=tmp/hosts.cfg client/bin/xymongrep "MAILQ:*" | > > while read hostip hostname hostcfg; do > > if [[ "$hostname" == ${MACHINEDOTS} ]]; then > > mailcfg="" > > [[ "$hostcfg" =~ MAILQ:(.*) ]] && mailcfg="${BASH_REMATCH[1]}" > > for var in qwarn qcrit; do > > [[ "$mailcfg" =~ "($var)=([^,;]+) ]] && declare > > "cfg_${BASH_REMATCH[1]}"="${BASH_REMATCH[2]}" > > done > > # declare -p ${!cfg_*} ##DEBUG## > > # mailq logic using $cfg_qwarn $cfg_qcrit goes here > > # xymon status submit goes here > > fi > > done > > This is some very tight and nice Bash. I like how you're using test > ([[) and parameter expansion. -- Much to come back to and look at in > more detail later. > > Aside: Did you mean "fetch" or "config" when calling xymon? > > I think the biggest gotcha that I have is that some of the systems in my > config are using different host names and relying on CLIENT: to make > things match. But I think that's a matter of finding and grinding out > the CLIENT: from the ${hostcfg}. > > > You could dispense with the outer while loop by using > > read hostip hostname hostcfg < <(xymongrep MAILQ:* | grep > "$MACHINEDOTS") > > ACK > > > There is no xymongrep equivalent for client-local.cfg, you could adapt > > the above to parse the client cached copy (tmp/logfetch.HOSTNAME.cfg) - > > simple enough since the server does not provide the entire client-local > > config, just the client-specific matching stanza. > > I like the idea that the server only provides the client specific stanza. > > But I also like the idea that I can pull the analysis.cfg file using > `${XYMON} ${XYMSRV} "config analysis.cfg"`. > > Initial skim of the xymongrep man page make me think that it's intended > for the hosts.cfg file and not going to work with other files. So I'd > need to parse it. > > > I know there were some old, old mailq client scripts, there's still > > some RRD related residue for parsing their output in Xymon. I've > > never used it, but likely this was one: > > > https://web.archive.org/web/20080718210020/http://www.deadcat.net/viewfile.… > > $RESEARCH++ > > > The bf/nmailq-bf.sh script therein simply barfs out a bit of sendmail's > > "mailq" output. The point being if you have the data in an RRD then > > you can also use "DS" in analysis.cfg to alert based on a GAUGE > > type metric. There's more than one way to skin a (dead)cat :) > > I have seen many references to "DS", but I'm still not quite sure what > that means. I need to read the custom graphing again and work to > understand it. > > > To scale up the configuration complexity or number of discrete > > service checks it would be better to dispense with xymongrep and > > distribute your own easy-to-parse configuration file(s), or use the > > client-local.cfg approach (my preference). > > ACK > > The ability to pull config files from the server makes this a bit > easier. It means that the client can get access to the configuration > data to be able to more accurately set clear / green / yellow / red > colors in reports. > > Thank you Conor. I'll re-read, research, and do some thinking. > > > > -- > Grant. . . . > unix || die > > > > > ---------- Forwarded message ---------- > From: Grant Taylor via Xymon <xymon at xymon.com> > To: xymon at xymon.com > Cc: > Bcc: > Date: Fri, 13 Oct 2023 16:18:08 -0500 > Subject: Re: [Xymon] Can custom client-side tests leverage the server-side > value in analysis.cfg? > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

2 1