April 2024 - Xymon - Xymon mailman web

Devmon on RHEL9
by colin.coe＠gmail.com 13 Dec '24

13 Dec '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

4 4

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

03 Jun '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 6

Update on 4.4 (Alpha1 release)
by cleaver＠terabithia.org 15 May '24

15 May '24

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

9 13

noconn & purple status
by tom＠4schmidts.com 25 Apr '24

25 Apr '24

Since you are using "dialup", no tests will go purple, they will instead go clear (white) if no report is received. That is by design (see man hosts.cfg). If you want it to generate the alert for other tests while ignoring the "ping" connection test status, then perhaps you need to use the "?conn" tag. This will make it perform the ping test, but report a clear status if it does not answer. Other tests should still report their normal status. Tom On Thu, Apr 25, 2024 at 4:15?AM Damien via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: damien at makelofine.org > To: Jeremy Ruffer <jeremy.ruffer at gmail.com> > Cc: xymon at xymon.com > Bcc: > Date: Thu, 25 Apr 2024 12:14:48 +0200 > Subject: Re: [Xymon] noconn & purple status > Hi Jeremy, > > My bad, the tag I'm using is dialup, not noconn... > > Le 25/04/2024 11:58, Jeremy Ruffer a ?crit : > > Hi Damian, > > > > I could be wrong, but I think that replacing noconn with dialup might > > suit you better. > > > > HTH > > > > Jeremy > > > > ------ Original Message ------ > > From: "Damien via Xymon" <xymon at xymon.com> > > To: "xymon at xymon.com" <xymon at xymon.com> > > Sent: 25/04/2024 10:46:27 > > Subject: [Xymon] noconn & purple status > > > >> _______________________________________________ > >> Xymon mailing list > >> Xymon at xymon.com > >> http://lists.xymon.com/mailman/listinfo/xymon > > > > ---------- Forwarded message ---------- > From: Damien via Xymon <xymon at xymon.com> > To: Jeremy Ruffer <jeremy.ruffer at gmail.com> > Cc: xymon at xymon.com > Bcc: > Date: Thu, 25 Apr 2024 12:14:48 +0200 > Subject: Re: [Xymon] noconn & purple status > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

1 0

noconn & purple status
by jeremy.ruffer＠gmail.com 25 Apr '24

25 Apr '24

Hi Damian, I could be wrong, but I think that replacing noconn with dialup might suit you better. HTH Jeremy ------ Original Message ------ From: "Damien via Xymon" <xymon at xymon.com> To: "xymon at xymon.com" <xymon at xymon.com> Sent: 25/04/2024 10:46:27 Subject: [Xymon] noconn & purple status >_______________________________________________ >Xymon mailing list >Xymon at xymon.com >http://lists.xymon.com/mailman/listinfo/xymon

2 1

noconn & purple status
by damien＠makelofine.org 25 Apr '24

25 Apr '24

Hi there, While setting some hosts with noconn tag (intermitently online), I faced a behavior that seems not optimal. Some of the tests were not running correctly, but their status stayed white (hence not propagated to non-green page), keeping me ignorant of this issue. I'd like these device tests to be considered online or offline all together. E.g: when CPU test status is green|yellow|red, the other tests are expected to report a status as well. If not, they should be purple. I hope my explanations are clear. My questions: -does anyone know how to configure Xymon to behave this way? -if not, does any of your have any idea how to achieve this? -if not, may I expect a change in future (if any) Xymon release? Regards, Damien

1 0

nvme temperature check broken in Debian bookworm
by zechner＠vrvis.at 23 Apr '24

23 Apr '24

Hi, the temperature check in xymon's version of bookworm is broken in a rather strange way. The check is located in /usr/lib/xymon/client/ext/temp and fails for all NVMe disks that contain several temperature sensors: For example the first NVMe in Lynx which holds its temperature values in /sys/block/nvme0n1/device/hwmon0/: files name value min max crit temp1_* Composite 27.85 -273.15 86.85 87.85 temp2_* Sensor 1 27.85 -273.15 65261.85 n/a temp3_* Sensor 2 31.85 -273.15 65261.85 n/a The inner logic of the temperature check works as follows to calculate the values for red and yellow: 1) if there is a crit and a max value use them 2) if there is a max and a mid value use them 3) if there is a max and a min value, use them 4) if there is only a max file, use it for both 5) if there is only a crit file, use it for both. The sensor 'Composite' uses max and crit as they're both available. 'Sensor 1' and 'Sensor 2' however do only provide max and min. Therefor these values are being used but lead to 'yellow' warnings as the min value actually isn't an upper boundary as assumed but a lower boundary. The linux kernel documentation (https://docs.kernel.org/hwmon/sysfs-interface.html) also outlines that every file using 'min' in their name is a low threshold: The common scheme for files naming is: <type><number>_<item>. Usual types for sensor chips are "in" (voltage), "temp" (temperature) and "fan" (fan). Usual items are "input" (measured value), "max" (high threshold, "min" (low threshold). The proposed fix would be to either use max value for yellow and red or to at least sanity check whether min is below zero and in that specific case only use the max value for both: In /usr/lib/xymon/client/ext/temp beginning on line 182: my ($red, $yellow); if (-r $crit_file and -r $max_file) { $red = read_one_chomped_line_from_file($crit_file); $yellow = read_one_chomped_line_from_file($max_file); } elsif (-r $max_file and -r $mid_file) { $red = read_one_chomped_line_from_file($max_file); $yellow = read_one_chomped_line_from_file($mid_file); } elsif (-r $max_file and -r $min_file) { $red = read_one_chomped_line_from_file($max_file); #TODO: min_file contains the lower temperature boundary and # *not* the warning value; only solution to this would # be to set either yellow to red or to at least do that # when yellow is below 0 for example. $yellow = read_one_chomped_line_from_file($min_file); $yellow = $yellow > 0 ? $yellow : $red; # Alternative solution: do not use min at all v1: #$red = $yellow = read_one_chomped_line_from_file($max_file); # Alternative solution: do not use min at all v2: remove this 'elsif' } elsif (-r $max_file) { $red = $yellow = read_one_chomped_line_from_file($max_file); } elsif (-r $crit_file) { $red = $yellow = read_one_chomped_line_from_file($crit_file); } There are three ways to solve this: * sanitize min by checking whether the value is below 0 and in that case use the max value * use the max value in any way * completely remove the 'elsif' that reads min and max as the next 'elsif' just reads and uses max Thanks in advance! Best regards Christoph

3 2

Port Check on a Server
by bb＠buglecreek.com 22 Apr '24

22 Apr '24

Hello, I have a system that is running a rsyslog server on a non standard port and is an appliance. I need to check that the several ports are up and listening, however I can not install a client on the system. The test would need to be initiated from the xymon server. I assume I need a custom script, can someone point me in the right direction for this. Heres nmap output. Preferably I'd like to check if the port 443, 517,8001, 8002,and 80003 are all open. If any of those are not open, go red. PORT STATE SERVICE 22/tcp closed ssh 443/tcp open https 517/tcp open XXXX 8001/tcp open XXXX 8002/tcp open XXXX 8003/tcp open XXXX

5 5

wiki.xymonton.org ?
by jeremy＠laidman.org 21 Apr '24

21 Apr '24

Galen Johnson (cc) is the maintainer. On Thu, 11 Apr 2024, 19:09 Damien via Xymon, <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: damien at makelofine.org > To: Becker Christian <christian.becker at rhein-zeitung.net> > Cc: "'xymon at xymon.com'" <xymon at xymon.com> > Bcc: > Date: Thu, 11 Apr 2024 11:01:06 +0200 > Subject: Re: [Xymon] wiki.xymonton.org ? > Indeed, it looks like the sqlite module is not loaded as per the error > message. > I've no idea why. > > Who admins this website? > > Le 11/04/2024 10:42, Becker Christian a ?crit : > > Hello to the list, > > > > does anybody know what happened to wiki.xymonton.org? There are errors > > on the site that prevent it to work. > > > > Regards > > > > Christian > > _______________________________________________ > > Xymon mailing list > > Xymon at xymon.com > > http://lists.xymon.com/mailman/listinfo/xymon > > > > ---------- Forwarded message ---------- > From: Damien via Xymon <xymon at xymon.com> > To: Becker Christian <christian.becker at rhein-zeitung.net> > Cc: "'xymon at xymon.com'" <xymon at xymon.com> > Bcc: > Date: Thu, 11 Apr 2024 11:01:06 +0200 > Subject: Re: [Xymon] wiki.xymonton.org ? > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

4 4

wiki.xymonton.org ?
by christian.becker＠rhein-zeitung.net 11 Apr '24

11 Apr '24

Hello to the list, does anybody know what happened to wiki.xymonton.org? There are errors on the site that prevent it to work. Regards Christian

2 1