August 2023 - 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

SSL/TLS cert monitoring
by everett.vernon＠gmail.com 02 Sep '23

02 Sep '23

Hi all Haven't been using Xymon for many years, but I now have a small client looking for a lightweight and cost-effective (free) monitoring solution, and Zymon fitted the bill. Most of the config and setup is coming back to me, but I'm a little stuck on certs. Some certs I can point Xymon directly to the URL, and I get the response I want. Others are (multiple) certs on my Xymon client server, not related to a URL, but used by applications. I cannot remember how we configure those to check for expiration. Any tips appreciated. Regards Vernon -- "Accept the challenges so that you can feel the exhilaration of victory" - General George Patton "Don't find fault. Find a remedy" - Henry Ford

9 12

Debuggable files
by jgsuareza1984＠gmail.com 01 Sep '23

01 Sep '23

Hi, which files are debuggable in the log directory of the linux core server -- Saludos, GS

2 1

Histlog file format anomaly - epochtimestamps
by jeremy＠laidman.org 28 Aug '23

28 Aug '23

Hi y'all We've setup some new RHEL 7.9 Xymon servers running 4.3.30-1 from the Terabithia repo. Everything seems to work fine except that the event history list ("last 50 events") has links that use the epoch time format for the individual events, but the files in $XYMONHISTLOGS directories contain files in the old format such as Fri_Aug_25_09:59:03_2023. When I click on an event dot, I'm given a webpage with the message "Historical status log not available". If I rename/symlink the file to the epoch time format (eg 1692921543) then it displays just fine. I'm aware of a patch in the Terabithia packages that change the filename format. But reading through the patch (from the SRPM), it looks like it's supposed to handle both old and new formats just fine. One of the things the patch provides is the ability to override the filename format using either the "--epochtimestamps" switch or setting the "EPOCHIST" variable, to (I think) tell "xymond_history" which format to use when creating new history logfiles. Without these, the code should assume write format, but read either format. So, a couple of things here: 1) With the patch in place, new history log files should be created using the new filename format. But they're being created with the old format. 2) With the patch in place, existing history log files with filenames in the old format should still be readable by the CGI scripts. But they history.sh file is failing when it can't find filenames in the new format. Running strings on the Xymon binaries doesn't show the strings "epochtimestamps" or "EPOCHHIST". So I don't think the patch has been fully applied. And I don't think I can use the --epochtimestamps option to fix it. So I'm not sure if I've done something fundamentally wrong here (probably), or (less likely) if the patch in the SRPM has not cleanly applied when the the RPM was built. Does anyone else have the Terabithia 4.3.30-1 package installed on RHELv7.9, who can tell me what format your history status files (under /var/lib/xymon/histlog/<hostname>/<testname>) are in? And can tell me if the history events display correctly? J

3 4

Xymon, community, updates, and directions (was Re: Is this thing on?)
by cleaver＠terabithia.org 26 Aug '23

26 Aug '23

On Mon, August 14, 2023 21:10, Berry van Sleeuwen wrote: > We recently migrated our server to SLES15 SP4 and found there are a few > network tools missing in the base, arp, netstat, ifconfig and route are > supposed to be replaced by "ip" and "ss" command. While similar the output > of these commands differs from the traditional tools so I guess that would > interfere with the processing of the command output. For now it's solved > by installing net-tools-deprecated but this might not be available in > future versions so we might need support for these commands. I don't now > if that is also the direction for other distributions, but it's at least > the case for Suse and OpenSuse. Agreed; it's similar in the RHEL side. xymond_client updates that can interpret the output of ip and ss are probably called for now. While deprecated net-tools will stick around for sure for current systems, it's only a matter of time until they're removed, and in the meantime it's one less package to have to pull in for compatibility (and to explain). This probably goes higher on the list. -jc

3 3

Xymon, community, updates, and directions (was Re: Is this thing on?)
by josh＠imaginenetworksllc.com 25 Aug '23

25 Aug '23

What is there works beautifully for me. To say I appreciate the work that everyone has done just doesn't begin to describe how it helped us grow. In the near future I'd love to see a Rocky package. SSL would be kinda neat I guess, but I subscribe to the notion that if you've got a mitm on your system's network you have other problems to worry about anyway. On Mon, Aug 14, 2023 at 6:39?PM Damien Martins via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: Damien Martins <damien at makelofine.org> > To: "J.C. Cleaver" <cleaver at terabithia.org> > Cc: Damien via Xymon <xymon at xymon.com> > Bcc: > Date: Tue, 15 Aug 2023 00:38:28 +0200 > Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: > Is this thing on?) > If i had to vote for something: bring the code to a git(hub?) repo so > people with required skills and time could contribute. > > Regards, > Damien Martins > Le 14 ao?t 2023, ? 22:57, "J.C. Cleaver" <cleaver at terabithia.org> a ?crit: >> >> >> Hello all, >> >> Catching up with the thread from these past few days, this seems the >> proper place for me to chime back in. >> >> While it's possible to call xymon simply a quiet, stable project (which it >> is, with many installs simply and quietly doing their jobs in the >> background out there), it's also very fair to say that the project -- or >> at least the plans I (and, I'll assume, Henrik) had for it has indeed >> reached a stalling point. >> >> That doesn't mean it can't come out of a stall! But it does mean it takes >> effort to resume work on. >> >> >> Following on with others' comments, the Xymon codebase is somewhat... >> intense. When I was performing near-daily performance enhancement and >> tweaks for Xymon for $dayjob, there was a solid ability to stay in the >> zone and I could add features as needed at a rapid clip. Since then, as I >> moved on to other positions and responsibilities, my day-to-day >> involvement with the code base dried up, and getting back into it can be >> difficult unless you're doing a lot of C elsewhere and not spending it >> cursing at kubernetes. >> >> In short, there's a significant ramp-up and re-ramp-up involved, as one >> might expect from any mature codebase. While the underlying documentation >> for use and administration is extremely thorough IMHO, an Intro for Devs >> document was something we never followed through well on. >> >> >> Development plans had at one point been something like: >> - direct SSL support and/or message signing (probably the most frequently >> requested things, for those for whom stunnel-wrapping was not an option) >> - IPv6 (some of which is working in the 4.4 alpha branch) >> - abstraction of remaining formatting to simple CSS to allow for skinning >> and dashboarding >> >> I'd also had in mind things like a JSON endpoint version of >> xymondx{log|board}, and a REST-based C shim .cgi, both of which could help >> folks integrating Xymon with other monitoring systems out there. >> >> >> Of course, the initial target was simply the forklifting of the many >> performance enhancements and tweaks from the Terabithia RPMs into the >> source tarball. This got pretty far there in the 4.4 branch, with only a >> few major components not integrated. However debugging those components >> and patches stalled out, especially with the need to maintain robust >> pan-*nix compatibility. >> >> That, ultimately, is where we are now. >> >> >> To kick things off: In the past, there had been requests to move the >> source to Github in the hopes of creating an easier onramp for patch >> submissions via PRs, bug reports, and the like. While I personally feel >> like SF and svn would still work, I think this probably deserves to be >> back on the table. >> >> In addition, Henrik had mentioned that we'll need a mailing list migration >> at some point coming up soon. >> >> >> Beyond that, to be honest I'm not sure what the next, best step is to >> take. Life had indeed gotten in the way, to follow from the comment below, >> as $dayjob+=4 and other responsibilities cropped up. >> >> I really welcome the entire community's input here going forward. >> >> >> Regards, >> J.C. Cleaver >> >> >> >> On Mon, August 14, 2023 09:58, Bruno Manzoni wrote: >> >>> Hellor Xymon Lovers I'm not a coder either, but I see there's quite a >>> bit of brains out there (and I think if there are enough of us we can >>> try to maintain and improve it). Perhaps the current officials could >>> first tell us what their plans are and how we could help them. On our >>> side, we can perhaps encourage them: it would be good to list what we >>> can bring to the project, as some have done! - I try to maintain >>> "devmon" (on the github repo) and some other xymon tool (I did try to >>> understand how devmon is integrate to xymon, but I am not an expert in >>> Xymon code) - I am a telecom engineer - I can give some some time - I am >>> an independent and I have some infra to play with - Usually I speak >>> swiss-french (so sorry for all my mistakes) Bruno >>> >>> On 14.08.2023 18:36, James Louis wrote: >>> >>>> Is the Terabithia RPM also dead? >>>> >>>> Jim >>>> >>>> On Mon, Aug 14, 2023 at 10:03???AM Scot Kreienkamp >>>> <Scot.Kreienkamp at la-z-boy.com> wrote: >>>> >>>> I would be OK with contributing some as well???. But that???s not >>>> what >>>> Xymon needs.? Xymon needs caretaker(s) to keep it relevant.? That >>>> means code updates to fix bugs, adapt it to new OS versions, etc.? >>>> Otherwise it will fade away to obscurity like many other open >>>> source projects.? I???m not a coder either, or I would gladly give >>>> some time to it. >>>> >>>> *Scot Kreienkamp? | Senior Linux Systems Engineer | La-Z-Boy >>>> Corporate* >>>> One La-Z-Boy Drive | Monroe, Michigan 48162 |( (734) 384-6403 | | >>>> ) 1-734-915-1444 | Email: Scot.Kreienkamp at la-z-boy.com >>>> >>>> *From:* Rod <rodbass63 at gmail.com> >>>> *Sent:* Monday, August 14, 2023 10:56 AM >>>> *To:* Ralph M <ralphmitchell at gmail.com> >>>> *Cc:* Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com>; xymon >> >>>> xymon at xymon.com <xymon at xymon.com> >>>> *Subject:* Re: [Xymon] Is this thing on? >>>> >>>> I would like to continue the legacy. I'm not a developer but I'm >>>> willing to pay for hosting space and the domain name to keep it >>>> going for as long as I'm alive. Its kept me employed for a long >>>> time. >>>> >>>> On Mon, Aug 14, 2023 at 10:32???AM Ralph M <ralphmitchell at gmail.com> >>>> wrote: >>>> >>>> I've been using Xymon at several different? employers since it >>>> was BigBrother owned by a couple of guys in Canada.? My >>>> current Senior VP wants Xymon to go away.? He hasn't actually >>>> told me that directly, but I've heard it via another channel.? >>>> We have SolarWinds on some machines, but I've never even seen >>>> the GUI for that.? We're also distributing Oracle Enterprise >>>> Manager (OEM) to a bunch of machines.? I don't know for sure, >>>> but I suspect a contracting company is whispering in my SVP's >>>> ear to sell support for OEM.? In the meantime, my Xymon server >>>> has 878 days uptime and they're still trying to figure out how >>>> to install and configure the OEM agents.? It's going to be >>>> tons of fun watching them try to replace all the little >>>> scripts I've written with OEM equivalents. >>>> >>>> @Cristoph - I don't know if I can use stunnel.? It's a >>>> military-related company and there are all kinds of >>>> restrictions that sometimes even make sense. >>>> >>>> Ralph Mitchell >>>> >>>> On Mon, Aug 14, 2023 at 9:41???AM Scot Kreienkamp >>>> <Scot.Kreienkamp at la-z-boy.com> wrote: >>>> >>>> No new release since 2019, no activity on the mailing >>>> list, I think it???s safe to say it???s flatlined.? Sad to >>>> see >>>> it fade, I???ve been using it for a decade or more. >>>> >>>> *Scot Kreienkamp? | Senior Linux Systems Engineer | >>>> La-Z-Boy Corporate* >>>> One La-Z-Boy Drive | Monroe, Michigan 48162|((734) >>>> 384-6403 | | )1-734-915-1444| *Scot.Kreienkamp at la-z-boy.com >>>> www.la-z-boy.com <http://www.la-z-boy.com>? | >>>> facebook.com/lazboy <http://facebook.com/lazboy>? ? | >>>> twitter.com/lazboy <http://twitter.com/lazboy>| >>>> youtube.com/lazboy <http://youtube.com/lazboy> >>>> Smaller LZB Only Logo for Sign.png >>>> >>>> *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of >>>> *Neil Simmonds >>>> *Sent:* Monday, August 14, 2023 5:29 AM >>>> *To:* xymon >> xymon at xymon.com <xymon at xymon.com> >>>> *Subject:* Re: [Xymon] Is this thing on? >>>> >>>> Is Xymon dying? No new release since 2019, There was a >>>> roadmap in 2015 that mention Versions 4.4 up to 5 but >>>> nothing seems to have moved on that. >>>> >>>> It feels like Xymon has become a static project that???s >>>> going to fade away. That would be a shame as I for one >>>> think it???s a great tool. >>>> >>>> *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of >>>> *Galen Johnson >>>> *Sent:* Sunday, August 13, 2023 3:01 AM >>>> *To:* xymon >> xymon at xymon.com <xymon at xymon.com> >>>> *Subject:* [Xymon] Is this thing on? >>>> >>>> *[CAUTION]*This is an external email. Do not click links >>>> or open any attachments unless you are sure they are safe. >>>> >>>> Nothing since May seems a bit suss. >>>> >>>> =G= >>>> >>>> Studio is a trading name of Studio Retail Trading Limited >>>> (Company no. 03994833), which is an introducer of credit >>>> not a lender. Studio Pay is provided by Frasers Group >>>> Financial Services Limited (Registered Company no. >>>> 00718151), which is authorised and regulated by the >>>> Financial Conduct Authority (FRN 311908) for consumer >>>> credit and general insurance and a member of the Finance >>>> and Leasing Association. Both companies are registered in >>>> England and their registered office is: Church Bridge >>>> House Henry Street Accrington BB5 4EE. >>>> >>>> *NOTE: This email and any information contained within or >>>> attached in a separate file is confidential and intended >>>> solely for the Individual to whom it is addressed. The >>>> information or data included is solely for the purpose >>>> indicated or previously agreed. Any information or data >>>> included with this e-mail remains the property of Studio >>>> Retail Trading Ltd or Frasers Group Financial Services >>>> Ltd. The recipient will refrain from utilising the >>>> information for any purpose other than that indicated and >>>> upon request will destroy the information and remove it >>>> from their records. Any views or opinions presented are >>>> solely those of the author and do not necessarily >>>> represent those of Studio Retail Trading Ltd or Frasers >>>> Group Financial Services Ltd. If you are not the intended >>>> recipient, be advised that you have received this email in >>>> error and that any use, dissemination, forwarding, >>>> printing, or copying of this email is strictly prohibited. >>>> No warranties or assurances are made in relation to the >>>> safety and content of this e-mail and any attachments. No >>>> liability is accepted for any consequences arising from >>>> it. Studio Retail Trading Ltd and Frasers Group Financial >>>> Services Ltd reserve the right to monitor all e-mail >>>> communications through their internal and external >>>> networks. If you have received this email in error please >>>> let us know. You can find our available contact details by >>>> going to help.studio.co.uk <http://help.studio.co.uk> and >>>> clicking ???Contact Us???.* >>>> >>>> This message is intended only for the individual or entity >>>> to which it is addressed. It may contain privileged, >>>> confidential information which is exempt from disclosure >>>> under applicable laws. If you are not the intended >>>> recipient, you are strictly prohibited from disseminating >>>> or distributing this information (other than to the >>>> intended recipient) or copying this information. If you >>>> have received this communication in error, please notify >>>> us immediately by e-mail or by telephone at the above >>>> number. Thank you. >>>> >>>> ------------------------------ >>>> >>>> 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 >>>> >>>> ------------------------------ >>>> >>>> Xymon mailing list >>>> Xymon at xymon.com >>>> http://lists.xymon.com/mailman/listinfo/xymon >>>> >>>> >>>> >>>> -- >>>> *Jim Louis >>>> >>>> ? ? ? ? ? \\\\||//// >>>> ? ? ? ? ? \ ~ ~? / >>>> ? ? ? ? ? | @ @ | >>>> * >>>> *--oOo---(_)---oOo-- >>>> >>>> * >>>> >>>> /???The part of life we really live is small. All the rest is not life, >>>> but merely time.?? / >>>> >>>> >>>> ------------------------------ >>>> >>>> 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 >> >> >> >> >> ------------------------------ >> >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon >> >> > > > ---------- Forwarded message ---------- > From: Damien Martins via Xymon <xymon at xymon.com> > To: "J.C. Cleaver" <cleaver at terabithia.org> > Cc: Damien via Xymon <xymon at xymon.com> > Bcc: > Date: Tue, 15 Aug 2023 00:38:28 +0200 > Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: > Is this thing on?) > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

4 4

Encryption
by stef.coene＠docum.org 25 Aug '23

25 Aug '23

Update, it's possible that you have to increase #define MAX_REQ_SIZE (1024*1024) in lib/cgi.c to increase the maximum message size a client can send. Stef

1 0

Encryption
by stef.coene＠docum.org 25 Aug '23

25 Aug '23

Hi, We solved the encryption by using a wget and/or curl script alternative for the xymon client. It's a drop-in replacement. We have a setup script that checks if wget or cups exists and it creates a symlink for the xymon command to the script that works. The script uses a username and password to connect to xymoncgimsg.cgi over https to send the data. We use 1 username / paswoord for all clients but with some scripting you can give each client it's own username / password. If wget or cups is not available (some old AIX servers can not connect to a https server...), the good old binary is used without encryption :( I can document it somewhere if anyone is interested. It's not that complicated. For the Windows clients we also use https as much as possible. I have some patches for the Powershell client that allows for testing a new XML file. We want to manage the XML files centrally and want to avoid mistakes that can disable the client. So this allows us to test a new config file before overwriting the old one. I also added the ping test command for this and did some changes so data can be send to multiple Xymon servers. I will create some patches and send them to the mailinglist. Stef

4 4

xymon replacement in python
by clabbe.montjoie＠gmail.com 23 Aug '23

23 Aug '23

Hello I am a big fan of xymon, and I was sad of its current maintainer status. I could have steped as maintainer of it, but the current state of the C code let me fear to lack enough time to masterize it. It will take days just to fix all string management warnings reported by gcc. I tryed to fix some issues and the result could be seen at https://github.com/xython-monitoring/xymon But I have asked myself, the protocol behing xymon is simple, why not trying to do it in python ? My personnal needs is a little subset of what xymon support, so I started to emulate xymon in python as a PoC just to see how long it will be. In a few hours I was able to emulate basic parts and I was more confident to step further. So I decided to publish my current code, but I fear to publish something too early, I pray that some people could find it usefull. I tried to document at maximum, how to test it, but I am very bad at it. You can find the current result at https://github.com/xython-monitoring/xython I started this some month ago and the milestones are already obsolete, I will update them. But before progressing farther, I have still some interogation on how to handle some part. It will be kind if some people share some informations about how they use xymon. I am very interested about: - number of clients (what is the greatest number of clients possible ?) - number of hosts ? messages per second ? - number of network tests Thanks

6 8

Terabithia EL9 RPMs moving from /testing/ to production soon
by cleaver＠terabithia.org 23 Aug '23

23 Aug '23

Hello all, The 4.3.30-1 RPMs available at https://terabithia.org/rpms/xymon/testing/el9/x86_64/ were built quite some time ago, but have stayed in /testing/. As I'm unaware of any bug reports relating to them, I'll be moving them to the production RPM repo https://terabithia.org/rpms/xymon/el9/x86_64/ Friday morning. I believe this should be invisible for current users, but it's worth a pre-notification since it's been so long. If you have a need for EL9 packages and haven't used them before, I'd appreciate it if you could run them from /testing/ ASAP. I'll post another update once it's completed. I'll also be compiling packages for current Fedora releases, assuming no build delays or fun compiler situations beyond the current ones. I'll post an update when those are complete as well. Regards, -jc

2 4