May 2024 - Xymon - Xymon mailman web

Trends graph limit
by jeremy＠laidman.org 03 Jun '24

03 Jun '24

Weird flex, I know, but we have trends pages exceeding 100 graphs. One pair of hosts has 144 graphs each. The code has no constraint on the number of graphs. The limitations are likely to be memory on the server and the client. The fix we applied here (described in my post last August) has been entirely successful in preventing the core dump. At the time, JC asked for a core dump to confirm the fault/fix, but I haven't been able to provide this due to my workload and other things going on around me at the time. It's non-trivial for me to arrange for another core dump at this time. J On Sat, 1 Jun 2024 at 06:27, Mario <rower.master at gmail.com> wrote: > Hello Tom, > > I think I have the same issue described by Jeremy here > https://lists.xymon.com/archive/2023-August/048118.html and replied by JC > here https://lists.xymon.com/archive/2023-September/048122.html > In my old Xymon server version I have no issues with trends column. > > > > Thanks & regards, > Mario > > > > > On Thu, May 30, 2024 at 9:25?PM Tom Schmidt <tom at 4schmidts.com> wrote: > >> Mario, >> I don't see any such limit, as my xymon server has 27 graphs under >> its trends. >> >> Tom Schmidt >> >> On Thu, May 30, 2024 at 5:05?PM Mario <rower.master at gmail.com> wrote: >> >>> Hello All, >>> >>> Do trends column have a limitation in number of graphs to load? >>> I can see that is stopping after loading 21 graphs. >>> Is it configurable? >>> >>> My Xymon version is 4.3.30 >>> >>> Thanks in advance. >>> >>> >>> Br, >>> Mario >>> _______________________________________________ >>> Xymon mailing list >>> Xymon at xymon.com >>> http://lists.xymon.com/mailman/listinfo/xymon >>> >> _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

2 5

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

Trends graph limit
by rower.master＠gmail.com 31 May '24

31 May '24

Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario

2 2

findhost.sh with a different cfg env
by jeremy＠laidman.org 23 May '24

23 May '24

Mario I'm not sure. Can you show your wrapper script? How are you having findhost use your abridged hosts.cfg file? Cheers Jeremy On Fri, 24 May 2024, 01:16 Mario, <rower.master at gmail.com> wrote: > Hello Jeremy, > > Thanks for your response. > Yes, this works partially now. > I can call the findhostnwgroup.sh however the issue is that the search > result is showing all found occurences from the entire > monitoring/"official" hosts.cfg file and not only from the specific > hostsnwgroup.cfg file. > Even if I force findhost.sh with --env="" option still shows all from my > system and it seems to don?t load the different env configuration. > Do you have an idea on how to get the findhost.sh load the different env > options? > > > Thanks & regards, > Mario > > > > > On Sun, May 19, 2024 at 9:01?PM Jeremy Laidman <jeremy at laidman.org> wrote: > >> Hi Mario >> >> I imagine that you can still do the same thing. The only difference is >> that findhost.sh is now a binary rather than a script, and instead of it >> calling findhost.cgi, it implements the findhost.cgi functionality itself. >> >> So, in the same way that findhost.sh was a wrapper around findhost.cgi, >> you can write findhost-nwgroupview.sh as a wrapper around the new >> findhost.sh. Simply adjust your script to call findhost.sh instead of >> findhost.cgi. Although findhost.sh is in the cgi-bin directory now, so >> something like: >> >> exec /home/xymon/server/cgi-bin/findhost.sh $CGI_FINDHOST_OPTS >> >> Cheers >> Jeremy >> >> On Sat, 18 May 2024 at 01:05, Mario <rower.master at gmail.com> wrote: >> >>> Hello all, >>> >>> In old xymon/hobbit 4.3.0 version I used to generate different views >>> using bbcmd and modifieds hobbitserver.cfg and bb-hosts files. >>> Also for these different views I was able to create independent >>> findhosts and enable/disable views for these specific env and bb-hosts >>> files. >>> >>> For example: >>> $cat bb-findhost-nwgroupview.sh >>> #!/bin/sh >>> # This is the Hobbit CGI script interface to bb-findhost.CGI >>> . /home/xymon/server/etc/hobbitcginwgroupview.cfg >>> exec /home/xymon/server/bin/bb-findhost.cgi $CGI_FINDHOST_OPTS >>> >>> >>> How can we do this kind of modified findhost cgi calls on Xymon version >>> 4.3.30? How can I use and call findhost.sh to use a modified/renamed >>> cgioptions.cgi ? >>> >>> Thanks in advance. >>> >>> >>> Best regards, >>> Mario >>> >>> >>> >>> _______________________________________________ >>> Xymon mailing list >>> Xymon at xymon.com >>> http://lists.xymon.com/mailman/listinfo/xymon >>> >>

1 0

Xymon PSClient version 3
by stef.coene＠docum.org 20 May '24

20 May '24

Hi, Recently we had a customer where random dll files in the Temp directory are flagged as malware. It turned out that this was caused by the nssm.exe used for the Xymon client service. Has anyone else had nssm.exe flagged as ransomware? I decided to rewrite the client and integrated the code from this script so nssm.exe is not needed: https://github.com/JFLarvoire/SysToolsLib/blob/master/PowerShell/PSService.… FYI, this also creates an .exe file and random files in the temp directory but they are nog flagged as malware. It looks like the random files are a way for Windows Service Manager to cope with the an .exe file as service. I also made sure I can do a seamless upgrade to this new client. This also means patching the 2.xxx client so it can be upgraded to this new version without interaction. I have to clean up my 2.xxx code and the new script and will update my github page in the next few weeks: https://github.com/StefCoene/xymon-stuff/tree/main/WinPSClient I also have to rollout the new client in our production environments so its' possible that I encounter some unexpected bugs. Stef

2 1

4.4alpha1: MACHINE setting
by roland＠spinnaker.de 20 May '24

20 May '24

Hi! I'm just working on packaging 4.4 Alpha1 for Debian (see experimental branch of https://salsa.debian.org/debian/xymon for more information). Doing so I had some trouble (change of behavior) with the setting of MACHINE when using a FQDN as hostname in xymon. If the system hostname (from /proc/sys/kernel/hostname used via uname call) contains any dots, these are not converted to commas, since commafy() returns a string with dots replaced by commas (while uncommafy() does return void and does the replacement directly in the given parameter). The attached 102_commafy_MACHINE.patch fixes this issue. If I try to set MACHINEDOTS somewhere in xymonserver.cfg, MACHINE needs to manually be set in relation to this replacing dots by commas. This isn't very handy but error prone, so I created 103_MACHINEDOTS2MACHINE.patch, which automatically sets MACHINE when MACHINEDOTS is set with dots replaced by commas. I'm not very good in coding C, so there may be better ways to implement this, but from my point of view such an automatism should be a good idea... Greetings Roland

1 0

findhost.sh with a different cfg env
by rower.master＠gmail.com 20 May '24

20 May '24

Hello all, In old xymon/hobbit 4.3.0 version I used to generate different views using bbcmd and modifieds hobbitserver.cfg and bb-hosts files. Also for these different views I was able to create independent findhosts and enable/disable views for these specific env and bb-hosts files. For example: $cat bb-findhost-nwgroupview.sh #!/bin/sh # This is the Hobbit CGI script interface to bb-findhost.CGI . /home/xymon/server/etc/hobbitcginwgroupview.cfg exec /home/xymon/server/bin/bb-findhost.cgi $CGI_FINDHOST_OPTS How can we do this kind of modified findhost cgi calls on Xymon version 4.3.30? How can I use and call findhost.sh to use a modified/renamed cgioptions.cgi ? Thanks in advance. Best regards, Mario

2 1

how to force a procs check
by malcolm.r.hunter＠gmail.com 15 May '24

15 May '24

You have to restart the client on all hosts you want to check On 15 May 2024 10:20:29 Ian Diddams via Xymon <xymon at xymon.com> wrote: > > how to force a procs check > FromIan Diddams didds3 at yahoo.co.uk > Date15 May, 10:20 > CCxymon at xymon.com > > > > the procs check is the usual out-of-the-box every-five-minutes check done > automagically by xymon of course. > > If one was to update analysis.cfg on the xymon server is there a way to > immediately force a procs check rather than wait several minutes for the > check to be run? > > didds

1 0

how to force a procs check
by stef.coene＠docum.org 15 May '24

15 May '24

No, you can not force a pros check because this is triggered by the client that sends data. You can restart the clients to force it to resend the data as quickly as possible. Stef On 2024-05-15 11:10, Ian Diddams via Xymon wrote: > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon

1 0

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