- Xymon - Xymon mailman web

Hello Xymon world!
by Xymon mailinglist 09 Jun '26

09 Jun '26

Just testing the email list. Had a little trouble getting subscribed. I have a few updates to share if this is working.

2 2

Still here, just AFK
by Mark Felder 26 May '26

26 May '26

I know I helped kick off the renewed interest in Xymon, but I've just been a bit too busy with other things to dig in deeper at the moment. I'm watching and reading everything going on, though. Keep up the good work everyone :) Mark

2 4

Mailing list and project status?
by Ian Box 24 Apr '26

24 Apr '26

Hi, After a flurry of activity about the project to bring new life to Xymon, which seemed very encouraging to me, I've not received anything from the mailing list since 25th March. I've tried subscribing again, but the response was that I'm already subscribed. Has there really been no activity since then? Regards Ian Box

4 6

Two Draft PRs: PCRE Compatibility and RRDtool 1.9 Support – Request for Testing
by Bruno Manzoni 25 Mar '26

25 Mar '26

Hi all, I just opened two PRs: * PCRE1/PCRE2 compatibility layer migration: (draft) https://github.com/xymon-monitoring/xymon/pull/74 * RRDtool compatibility for < 1.9 and >= 1.9: https://github.com/xymon-monitoring/xymon/pull/72 Both implement a compatibility layer and aim to make the new libraries the mainstream code path. If someone could run the checklist tests, that would be super helpful. Once we have a couple of confirmations, we could .. move toward making a release! I pulled ideas from lots of the existing issues/PRs - even if I do not remember every detail, they were really useful. And since I am not exactly a C expert, that support helped me a lot to get these two PRs ready. If I missed something or got anything wrong, please tell me. Thanks a lot in advance! Bruno

4 15

Report: CMake build work progress: Blocking Build failure and package dependencies info
by Bruno Manzoni 09 Mar '26

09 Mar '26

Hi all, As you may know (or not), I am currently**working on*delivering a functional CMake build*: - *It will run in parallel with the current build process for as long as needed; the existing build and packaging tools remain fully usable and untouched.* - *It should help us automate distribution packaging* and improve/optimize the packaging workflows over time, and also incorporate some of Terabithia's build improvements (futur). Unfortunately, parts of the *current build process are now impacted by changes in upstream package availability and major changes in linked libraries.* Since I do not want to build a migration path on top of an obsolete baseline, *I (we) first need to resolve the remaining package-related build issues.* This also aligns with the work already done by Roland (Debian) that is not yet fully merged into main, but is already published in the Debian distribution. To ensure a working CMake build, I need a clear and comprehensive overview of the current (legacy) build, so *we can later compare both build systems reliably.* For that, *I created a CI tool that builds using the existing flow (configure, make, make install) *- and it also works with the new CMake build - and *collects build and install status, along with additional detailed information to support build comparisons. *This is a high-level summary of some of the information the tool provides: *OS coverage and build variant lanes (see below for details) and package dependencies info * *- Scope: 177 lane jobs* *- Outcome: 165 passed, 12 failed * CI environment note: *this CI pipeline runs on GitHub infrastructure only *(GitHub-hosted runners), using the available execution backends there (Docker containers, host-based jobs, and VMs where applicable).*It does not assume any external or self-hosted build environment*. (This tool is not currently available on the upstream repo, but it is already available on my branch (see link below) and will be added upstream when ready? and more reliable.) This run also includes preliminary work to *capture per-lane package dependencies*, to establish a *baseline for the future CMake build*. Note: this is not produced by CMake (but it can); *it is generated using the standard legacy build flow* (configure, make, make install). Bugs may still exist in this baseline/dependency extraction work. *OS coverage summary:* *Fully passing (all lanes passed):* - Alpine (3.19-3.23, edge) amd64/arm64 - Arch Linux (base/latest) - CentOS 7 - Debian 11.11-slim amd64/arm64 - Debian 12.13-slim amd64/arm64 - Fedora 40/41/42 - FreeBSD 13.5 / 14.3 / 15.0 - macOS 14 / 15 / 26 / latest (work in progress; not fully available yet, despite what these tests might suggest) - NetBSD 9.2 / 9.3 / 9.4 / 10.0 / 10.1 - OpenBSD 7.6 / 7.7 / 7.8 - openSUSE Leap 15.5 / 15.6 / 16.0 - Oracle Linux 8 / 9 - Rocky Linux 8 / 9 - Ubuntu 20.04 / 22.04 / 24.04 (amd64/arm64) *Not fully passing (some lanes failed):* - AlmaLinux 10: PASS ct-server; FAIL ct-client and Server - Debian 13.3-slim (amd64/arm64): PASS ct-server; FAIL ct-client and Server (see note) - openSUSE Tumbleweed: PASS ct-server; FAIL ct-client and Server - Oracle Linux 10 (arm64 and 10-slim amd64): PASS ct-server; FAIL ct-client and Server Note:* - Debian 13.3 (Trixie)* has been patched by Roland, so installation works from the standard apt repositories for all lanes. -*Variant "ct-client"* is a client build that can perform some of the work normally done on the server on the client host; it does not appear to be widely used in practice. *All current failures are PCRE dependency-related* and*fail to build using standard distribution repositories* (no extra/third-party repos). The PCRE-related failures are a blocking prerequisite, and they likely conceal additional package dependency issues that will only become visible once PCRE is fixed. *Some next fixes (PRs) are already prepared but still need review:* - rrd: detect argv const-ABI (1.9+/1.8 backports) and drop RRDtool <1.2 gates (PR #80) - snmpcollect: switch MD5 to SHA1 when MD5 is unavailable (PR #75) *The PCRE work (PR #5) and these two fixes should resolve the package dependency issues* we are currently experiencing (and that also block my progress), and should bring the main branch much closer to Roland's work. For more info on this analysis: *https://github.com/bonomani/xymon/actions/runs/22792414183* Bruno

2 2

Struggle supporting new OSs
by Nicola 06 Mar '26

06 Mar '26

Hi, I have been thinking about this in a while, and I am now convinced that we should aim at a 4.4.0 release which just drops support for old libraries not available or deprecated in modern OSs/distributions. We can rename and `sed` the version for the current 4.4 branch, but this will ease many of the efforts which are draining our energies to keep compatibility, and at the same time if we need minor bugfixes in the 4.3 branch, we can add them for dinosaurs which still require old libraries. What do you think? Nicola Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz

8 9

Thank you.
by Grant Taylor 02 Mar '26

02 Mar '26

Thank you for Xymon software and to the Xymon community. I wanted to send a quick note saying that a month doesn't go by, sometimes not even a week, I think to my self or slip and say "but Xymon does that" when asking why some other monitoring solution doesn't catch something that seems trivial. The list of things that Xymon detects that other solutions have failed to detect: - incorrect time - CPU test - lack of reports a la. PURPLE - TLS certificate expiration - sslcert - HTTP reply status codes - http I'm sure there are many other things that have made me mumble to myself. Yes, I know that other things can be configured to monitor some or all of these things, but that requires additional effort. Conversely Xymon just does it with no more effort than configuring it to look at a port. But the incorrect time has been a BIG problem for many of of the other monitoring solutions that my employer uses. Xymon has made it extremely easy to monitor these things and has proven to be EXTREMELY useful. Thank you. -- Grant. . . .

2 5

Subject: Upstream Architecture Proposal – Community Input Requested
by Bruno Manzoni 24 Feb '26

24 Feb '26

Dear all, I would like to share a proposal for discussion. First of all, it is important to recognize that the project is still available and functional on modern systems largely thanks to the continued efforts of distribution maintainers. Their pragmatic and disciplined work has kept the package alive across releases. That deserves clear acknowledgment. The reflection below is a general one, not a criticism of this project or its maintainers. In many long-lived open-source projects, when evolution is mainly driven by packaging constraints, changes tend to focus on restoring buildability and runtime stability with minimal scope. This is entirely reasonable from a distribution perspective. However, over time, this can lead to accumulated complexity, defensive layering, and limited architectural consolidation upstream. For that reason, I propose forming a small upstream architecture group with a clear mandate: - Define and protect the architecture - Manage compatibility - Reduce complexity - Ensure convergence across platforms The goal is not to replace existing maintainers, but to complement the current model with a clearer long-term technical direction. Personally, I would very much like to see Nicola as part of this group, given his experience and long-standing involvement with the project. At the same time, I believe such a team should consist of at least two people, to ensure balance, continuity, and shared responsibility. I would appreciate your thoughts: - Does this proposal make sense to you? - Would you support the creation of such a group? - Would you be willing to participate in it? If there is interest, we can define scope and structure together. Bruno

1 0

Thank you for your efforts
by Stefan Elsinga 18 Feb '26

18 Feb '26

Hi, I just want to say it warms my heart that you all are working on Xymon again. I've been using it for more that 30 years and the easy of use and number of options are stellar. Ofcourse, with the newer TLS-versions, correctly and consistently monitoring websites and TLS-certificates has its challenges nowadays. Hopefully you can update Xymon sufficiently. Thank you, thank you. -- Stefan

1 0

RPM compile
by Scot Kreienkamp 18 Feb '26

18 Feb '26

Gents, I hate to say this, but I've bitten off too much here. I've been working with the spec file from JC as well as the original spec file from Henrik. I don't want to throw away all the work JC has done on the spec file... there's too much good stuff there. I've got a good 40+ hours into trying to build a new one from it with very little progress. I've come to the conclusion that I'm not going to be able to author the new spec file. There's too much programming knowledge required that I just don't have. I'm still willing and able to create and maintain the workflows for the RPMs, help with testing, spec file maintenance, etc, but the new spec file is going to have to be authored by someone else. Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp(a)la-z-boy.com One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com<http://www.la-z-boy.com/> facebook.com/lazboy<http://facebook.com/lazboy> | instagram.com/lazboy<https://instagram.com/lazboy> | youtube.com/lazboy<http://youtube.com/lazboy> [cid:lazboy_2024_inc_navy_4a4d68ec-613a-4141-a2aa-d73a2ae749f6.png] 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.

3 3