February 2024 - Xymon - Xymon mailman web

Possible bug in xymon svcstatus causing segfault (buffer overrun?)
by jeremy＠laidman.org 31 May '24

31 May '24

Hi all I'm not a C programmer by any stretch, so I'm seeking confirmation that my working is sound. At our site we run 4.3.30-1 from Terabithia RPM. For most hosts, the "trends" page displays just fine, but for some hosts, the webserver gives a CGI error, and when I manually run the CGI directly it crashes with a seg fault. This seems to be more likely for hosts with a lot of entries on the trends page, but some with more trends graphs are OK than others with fewer. I believe I've tracked the issue down to the last few lines of code in svcstatus-trends.c, where a URL is constructed for one graph entry, before being added to the list of trends in a buffer. My reading of the code suggests that it first pre-allocates (using malloc()) a 16k buffer for the trends data, then sequentially appends trend strings (which include a URL) into the buffer, until the length of a string would exceed the size of the buffer. In that case, an extra 4k of memory is added to the buffer (using realloc()), and then the string is added to the buffer. The problem with the code, as I see it, is that the string might be more than 4k long, in which case, adding string would cause a buffer overrun. I don't really know what's in each string, so I don't know if it's ever likely to be 4k, but we're seeing the process dumping core immediately after this bit of code, so that's the suspicion. Here's the bit of code, which is attempting to add the string "onelink" to the buffer, after seeing if it's going to exceed the buffer, and extending the buffer if required: if ((buflen + strlen(onelink)) >= allrrdlinks_buflen) { SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+4096); allrrdlinksend = allrrdlinks + buflen; } allrrdlinksend += snprintf(allrrdlinksend, (allrrdlinks_buflen - (allrrdlinksend - allrrdlinks)), "%s", onelink); Elsewhere in other code, the SBUF_REALLOC macro is used to add extra bufferspace by calculating a new buffer size of [existing buffer size plus 4k plus the length of the string being added]. So if the string to be added had 20 bytes, SBUF_REALLOC would be used to add 4k+20 bytes to the buffer size. Notably, the size of the string is included in the calculation. For example this bit of code elsewhere in the same file does a similar buffer extension: if ((strlen(rrdlink) + strlen(partlink) + 1) >= rrdlink_buflen) { SBUF_REALLOC(rrdlink, rrdlink_buflen + strlen(partlink) + 4096); } strncat(rrdlink, partlink, (rrdlink_buflen - strlen(rrdlink))); Note the extra "+ strlen(<stringvar>)" bit in the extra memory being allocated that isn't there in the first block of code above. So my thinking is that the SBUF_REALLOC() needs to take the string's size into account, like so: SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+strlen(onelink)+4096); Is anyone with C skills able to confirm that this does indeed look like a bug, and also that my proposed change is a suitable fix? After applying this change and recompiling, we haven't yet seen a seg fault from this bit of code, so I'm hoping it's all fixed, and without negative side effects. Cheers Jeremy

3 3

Update on 4.4 (Alpha1 release)
by tom＠4schmidts.com 15 May '24

15 May '24

J.C., Thank you again J.C. for reviving the updates for Xymon. I am willing to help update it as well, even though I am now retired and only have a small install of Xymon 4.3.30 at home for my home network. I have contributed to Xymon several times in the past when I had it installed in a large corporate environment before I retired. J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings. I have not fully tested 4.4-alpha1 yet, but wanted to get these first patches released for 4.4-alpha2. Tom Schmidt On Wed, Sep 20, 2023 at 2:38?PM J.C. Cleaver <cleaver at terabithia.org> wrote: > Hello all! Just wanted to update everyone on a few things. > > Going through the 4.x codebase re-familiarizing myself again with the > state of everything, I recalled that I'd actually built a release artifact > before development was paused, including a testing RPM that has actually > been running unbeknownst on a VM for quite a while. Unfortunately, while > validating that compiles from source worked I ran into what looked like > showstopper bugs. These weren't showing up in the package, so I had to > pore through a lot more code* than I expected to try to figure out where > the package was accidentally fixing it. > > (*message-sending code, which changes a lot in 4.4 to support compression, > TLS, HTTP, and size-prefixed messages) > > Fortunately, it ended up being a relatively simple issue (isn't it > always?), with easy-enough validation and workaround (given below). > Although more fixes could be put in (and I'm sure will be needed!), I > believe there's some benefit to having a stable starting point using a > build artifact from 2019. > > As a result, I'm pleased to announce the first alpha for Xymon 4.4! As > this is an alpha release, this is absolutely NOT suitable for production > use and is intended mainly for smoketesting by source users. (And I expect > there will be smoke.) The release tarball is available now at: > > > https://sourceforge.net/projects/xymon/files/Xymon/4.4-alpha/xymon-4.4-alph… > > > Major improvements are too many to list here but are noted in the Changes > and RELEASENOTES files. README documents for compression, TLS, and IPv6 > are in progress. > > Some of the changes and improvements other than TLS support have been in > the Terabithia packages (to some extent) for a while, so there will be > less of a delta for those users to this alpha. > > For the moment, I'd like to focus on source tarball users and others > running xymon from scratch to help fix underlying issues and any smoketest > failures, which I expect may crop up particularly on untested non-Linux > platforms. Once the lower-hanging fruit is fixed and more patches are > upstreamed and cleaned up, I'll release an alpha2 release at which point > packages may be released to help with testing iteration and downstream > distributors. > > Please flag bug reports or patches as related to "alpha1" in the subject > line to help keep things clear. > > > Thank you to everyone in the community for remaining part of it -- and > xymon users! -- during this interregnum. Restarting development has been a > process, but I'm glad to take this important first step to our next > release. > > > Regards, > -jc > > > > *** KNOWN ISSUES -- IMPORTANT *** > > The configure script is likely setting XYMONHOME/XYMONCLIENTHOME and > XYMSRV/XYMSERVERS/XYMONSERVERS incorrectly, which will prevent xymonlaunch > from correctly launching anything. Double check the xymon environment > files (xymonserver/xymonclient.cfg) before starting either the server or > client. > > The tools/xymon-client.default and tools/xymonlaunch files may be placed > into /etc/{sysconfig,default}/{xymon-client,xymonlaunch} to more easily > set $XYMONSERVERS > > Revealed by the above issue is a bug causing a crash in the client (or > anywhere) when given an empty string as the destination argument (instead > of 0, 127.0.0.1 or no variable set). Don't do this --> [ xymon '' "ping" ] > > The client and logfetch binary may be being re-compiled during 'make > install' > > Compilation may fail if c-ares and at least one compression library is not > present (lzo/lz4/zlib are all options). xxHash libraries are also highly > recommended as the plan is for xxhash to replace md5 for checksumming > functionality. libtirpc may be necessary on some platforms, and it's > possible the build code is still expecting traditional (Sun) RPC > > > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

5 6

Devmon on RHEL9
by colin.coe＠gmail.com 29 Feb '24

29 Feb '24

Hi all Has anyone got DEVMON working on RHEL9? I'm working with https://github.com/bonomani/devmon but can't get any SNMP polling working. The current server is RHEL6 and working (mostly) fine but I need to get off RHEL6/7. Thanks

3 3

xymon-client for linux over ssl
by kspringer＠innovateteam.com 19 Feb '24

19 Feb '24

Can anyone advise on the method to have the Debian xymon-client send its data to the Server using SSL instead of port 1984? Thanks so much --- Kris Springer

5 4

Xymon client with encryption + updated powershell client Windows
by stef.coene＠docum.org 18 Feb '24

18 Feb '24

Hi, I created a github repo with my drop-in replacement for the xymon binary on Unix (tested on AIX & Linux) that uses wget or curl for communication. This makes the data stream encrypted (https) and protected with username & password. I also added a copy of the Windows client with some bugfixes and enhancement. Link to the repo: https://github.com/StefCoene/xymon-stuff/ Stef

2 1

How to retrieve the global state of Xymon?
by henrik＠hswn.dk 18 Feb '24

18 Feb '24

An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20240218/56172df9/attach…>

1 0

How to retrieve the global state of Xymon?
by tom＠4schmidts.com 18 Feb '24

18 Feb '24

You could simply look for the '<BODY class="green">' line in the ~xymon/server/www/nongreen.html or xymon.html file. The color shown for the "class" will match the overall state. A simple script could be written to run on your xymon server to gather this and send it to your monitor. Tom On Fri, Feb 16, 2024 at 8:16?AM Wim Nelis via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: Wim Nelis <wim.nelis at ziggo.nl> > To: xymon at xymon.com > Cc: > Bcc: > Date: Fri, 16 Feb 2024 15:48:14 +0100 > Subject: How to retrieve the global state of Xymon? > > Hello, > > > my current project is (trying to) display the global state of Xymon, that > is the state (colour) shown in the main view. A sort of a traffic light is > used, which is controlled by an ESP8266 micro controller running > microPython. > > > This state must be determined from the states of all the tests, which can > be retrieved using the 'xymondboard' command. As far as I know, there is no > other way of retrieving the global state of Xymon. Is this correct? > > > The NOPROP* tags seem complicate things. One can retrieve the tag(s) per > host, using f.i. 'xymondboard fields=...,XMH_NOPROPRED', but the tag is > shown, not the result of combining it with the command line parameters of > xymongen. Is there another way of retrieving this information? > > > Kind regards, > > Wim Nelis. > > > > > > ---------- Forwarded message ---------- > From: Wim Nelis via Xymon <xymon at xymon.com> > To: xymon at xymon.com > Cc: > Bcc: > Date: Fri, 16 Feb 2024 15:48:14 +0100 > Subject: [Xymon] How to retrieve the global state of Xymon? > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

3 2

How to retrieve the global state of Xymon?
by wim.nelis＠ziggo.nl 16 Feb '24

16 Feb '24

An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20240216/d24da747/attach…>

1 0

Can XYMSRV be a fqdn/hostname not an IP
by cleaver＠terabithia.org 14 Feb '24

14 Feb '24

On Tue, February 13, 2024 07:53, Ian Diddams wrote: > simple question...?? as time marches on etc has xymon/hobbit reached a > stage yet when XYMSRV can be set to a hostname rather than an IP address? > > eg?? rather than > > XYMSRV = "10.10.10.10" > > we could have > > XYMSRV = "xymonhost" > > where "xymonhost" resolves in dns to 10.10.10.10? > > This would be a huge benefit where anytime a xymon server is migrated to > another system eg underling EOL OS, one wouldn't have to go around > changing every single client server's xymon configs to a new Ip...?? all > that would be required is a reset in an appropriate dns zonefile so dns > just provides the new IP after the TTL passes etc. > > ??? > > cheers > ian Hi, Yes, $XYMSRV (or the recipient specified directly on the command line to the 'xymon' client program) can be a FQDN, even in 4.3.30, and a lookup will be performed. It's fine to do this, just with the caveat that this introduces working DNS resolution as a requirement for client log submission. This might be an OK tradeoff if, as you say, you're doing migration, or have a floating xymon VIP, or are doing other things with xymonproxy and need admin flexibility w/o touching every machine. -jc

3 2

xymon uses an old version of Openssl
by dito74＠gmail.com 14 Feb '24

14 Feb '24

I've recently migrated my xymon server from an old ubuntu to the latest, I've kept a bunch of old config files (and that might the be issue, but I am not sure where to look). My current openssl version is OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.1.4 24 Oct 2023) however my xymonnet uses a version that is 2 years older xymonnet version 4.3.30 SSL library : OpenSSL 3.0.0 7 sep 2021 LDAP library: OpenLDAP 20506 And that results into an SSL issue testing for some HTTPS site. Unspecified SSL error in SSL_connect to https error:0A000410:SSL routines::sslv3 alert handshake failure Should it use the latest builtin in system openssl? How do I fix that? Gab

1 0