October 2023 - Xymon - Xymon mailman web

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

Can custom client-side tests leverage the server-side value in analysis.cfg?
by conor＠conormccarthy.ie 13 Oct '23

13 Oct '23

> Date: Thu, 12 Oct 2023 19:23:17 -0500 > From: Grant Taylor <gtaylor at tnetconsulting.net> > To: Xymon <xymon at xymon.com> > Subject: Can custom client-side tests leverage the server-side value > in analysis.cfg? > > Hi, > > I'm relatively new to Xymon -- working with it for three months at a new > job -- and am wondering about how to have a custom client-side test > leverage the value of the server-side analysis.cfg. 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. 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. 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. 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). 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 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. Any non-documented parameters are explicitly ignored, but best placed above any of the documented ones to make sure. > Do I /have/ /to/ declare a color in a `status` or `data` message to Xymon? status: yes (though "clear" might be an option), data: no. There's also a "modify" message you can use after the fact to change a status/colour (though take care not to trigger flapping). https://xymon.sourceforge.io/xymon/help/manpages/man1/xymon.1.html > Is there a way to have the color be determined by a value in the > server-side analysis.cfg file? > > E.g. I'd like to write a custom test to monitor /var/spool/mqueue on > multiple MTAs and I'd like to have different values for the green / > yellow / red levels on different servers. 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. 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 You could dispense with the outer while loop by using read hostip hostname hostcfg < <(xymongrep MAILQ:* | grep "$MACHINEDOTS") 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 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.… 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 :) 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). C. > Ideally I'd like the custom client-side test that I put in > ${XYMONHOME}/ext/ to be identical across all clients and the only > difference being the value each system has in the analysis.cfg file on > the server. > > Am I /required/ to send a color; green, yellow, red, and then have > something override / update that color server side? Or can I omit the > color and let something server side set it using values for the given > client? > > I'm thinking about things like DISK / LOAD / etc. where I can set warn > and critical levels, or even ignore. > > Or am I looking at a custom server-side xymond_channel receiver that > will receive `data` (?) from the client and alter things? -- Even that > `data` is likely going to require a color. > > Would someone with more experience with Xymon than me give me a pointer > in a direction that I can go research? > > Please and thank you. > > > > -- > Grant. . . . > unix || die > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon > > > ------------------------------ > > End of Xymon Digest, Vol 151, Issue 10 > **************************************

2 1

Can custom client-side tests leverage the server-side value in analysis.cfg?
by gtaylor＠tnetconsulting.net 13 Oct '23

13 Oct '23

Hi, I'm relatively new to Xymon -- working with it for three months at a new job -- and am wondering about how to have a custom client-side test leverage the value of the server-side analysis.cfg. Do I /have/ /to/ declare a color in a `status` or `data` message to Xymon? Is there a way to have the color be determined by a value in the server-side analysis.cfg file? E.g. I'd like to write a custom test to monitor /var/spool/mqueue on multiple MTAs and I'd like to have different values for the green / yellow / red levels on different servers. Ideally I'd like the custom client-side test that I put in ${XYMONHOME}/ext/ to be identical across all clients and the only difference being the value each system has in the analysis.cfg file on the server. Am I /required/ to send a color; green, yellow, red, and then have something override / update that color server side? Or can I omit the color and let something server side set it using values for the given client? I'm thinking about things like DISK / LOAD / etc. where I can set warn and critical levels, or even ignore. Or am I looking at a custom server-side xymond_channel receiver that will receive `data` (?) from the client and alter things? -- Even that `data` is likely going to require a color. Would someone with more experience with Xymon than me give me a pointer in a direction that I can go research? Please and thank you. -- Grant. . . . unix || die

1 0

Could not determine size of directory
by kspringer＠innovateteam.com 05 Oct '23

05 Oct '23

Anyone have a clue why the following folder size can't be determined when I add it to analysis.cfg and client-local.cfg ? "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS" Could not determine size of directory "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS" These other folders are working fine. C:\inetpub\logs C:\Windows\Temp C:\Windows\Logs\CBS C:\ProgramData\Microsoft\Windows\WER The only difference I see is spaces in the path.? I've put "" around it, but that doesn't seem to fix it. Does someone have a working example that includes spaces in the path? -- Kris Springer

4 6

Xymon social media presences
by cleaver＠terabithia.org 05 Oct '23

05 Oct '23

Along the lines of the previous update, I've reactivated a Facebook page that I'd set up for the project a long while back (which FB had hidden over time), as well as created handle accounts on various social media services: https://facebook.com/XymonMonitor New accounts have been created here, primarily for #hashtag and @account reference purposes at the moment: https://twitter.com/XymonMonitor https://instagram.com/XymonMonitor https://reddit.com/u/XymonMonitor In addition, there are a few resource groups out there, including: https://www.linkedin.com/groups/2776122/ - XymonAdmins (unlisted) https://www.xymon.jp/ - Japanese Xymon User Group - https://www.facebook.com/groups/126643144159684/ - Using hashtag #xymonjp on Twitter One thing I've noticed is that Xymon looks to be a rather common name in some countries, which does make direct searching a little difficult. "Xymon Monitor" seems to be something a bit more trackable (with the full name "Xymon Systems and Network Monitor" as entitled on our SF page), but we might have to see in the future what references become useful more organically. Nevertheless, hopefully this is a start. Feel free to like/comment/tag/subscribe/share/etc these in the future. Regards, -jc

3 4

Bug in Mailman version 2.1.29: We're sorry, we hit a bug!
by bruno.manzoni＠ubi-network.ch 04 Oct '23

04 Oct '23

Hi Henrik, JC, I did try to confirm that thers is a problem or not with the mailing list: So I try to subscribe to the mailing list and I receive this message: ------------------------ Bug in Mailman version 2.1.29 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs or the web server logs. ------------------------ *This seems to confirm that, people are currently unable to subscribe* And maybe also as Liang, Ye-Fee wrote: "and now find myself *unable to email to the mailing list*" (29.9.2023) Norbert wrote "*It is not possible to sign up for the Xymon user group anymore *(we are long time users and can comment, but no new users are allowed). If someone can take over this mail service this would be more important then code updates imho, to show that the project is still alive. (14.8.2023) I am pretty sure this is not normal and would propose you my help (if you need it) to resolve this problem Let me know what I can do. I will also contact mailman3.com? a make you a summary. Bruno

2 1