February 2026 - Xymon - Xymon mailman web

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

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

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

Xymon and RHEL 10
by phaleintx＠gmail.com 11 Feb '26

11 Feb '26

Hello all, So glad to see development is picking back up on this project. I've run Xymon (and BB/Hobbit) for monitoring at our location since the late 1990's. I've written a ton of plugins (mostly in PERL) as well over the years and find Xymon to be the most flexible monitoring solution. We are working on a new RHEL 10 deployment and we noticed that the terabithia.org repository does not currently have a build of the xymon packages for RHEL 10. Does anyone have a prod or test build of the Xymon packages for RHEL 10? If so, would you all mind sharing? Thanks, Phil

2 1

Project direction and next steps – GitHub migration and branch model
by Bruno Manzoni 09 Feb '26

09 Feb '26

Hi All, Below is a structured summary of the current status following recent discussions and actions around the Xymon project, together with proposed next steps. Feedback from everyone is explicitly requested. PEOPLE – ROLES AND SKILLS (inferred from the latest email exchanges only; non-exhaustive and not limiting) - Bruno Manzoni – coordination; project management, workflow organization - Nicola – contributor; development support, automation - Stef Coene – contributor; development support, testing - Scot Kreienkamp – contributor; build and release automation - Ralph Mitchell – contributor; build and platform support - Mark Felder – contributor; technical guidance, system-level development - Matthew Goebel – contributor; platform support - Jeremy Laidman – contributor; deployment and lifecycle support - Kris Springer – contributor; interface customization - All listed participants have been invited and currently have owner access to the repository. GLOBAL SUMMARY – WHAT IS PROPOSED - Migrate source control from SVN/SourceForge to GitHub as the primary workflow. - Establish a clean, shared Git workflow with clear governance. - Treat 4.3 as the stable production line; keep 4.4 experimental. - Incorporate pending patches and publish a new 4.3.x release. - Enable GitHub Actions for tagging, releases, and CI/CD. - Improve packaging pipelines (RPM, tarballs, possibly DEB) while preserving existing ecosystems. - Address technical debt (PCRE2 migration, build warnings, compatibility issues). - Modernize networking and encryption incrementally (libcurl, HTTPS reporting). - Improve testing, documentation, and UI without breaking Xymon identity. PROJECT CONTEXT – RELEVANT CONSTRAINTS AND DEPENDENCIES - Existing packaging and repositories (e.g. Terabithia) are part of current production deployments and must be preserved or transitioned carefully. - Development momentum depends on early establishment of: - a source repository - a CI/build pipeline - a lightweight review and decision process - Multiple pending patches and enhancements are already available and can be integrated early to deliver visible progress. STEPS COMPLETED - Archived the historical repository `xymon-svn-mirror` to preserve the full SVN lineage as a read-only reference. - Created a new active Git repository `xymon` under xymon-monitoring, cloned from `xymon-svn-mirror` with full history intact. - Set `main` to track the stable 4.3.x line (anchored at Release 4.3.30). - Kept `4.x-master` as the ongoing development branch for 4.4. - Changed the default branch to `main` to align with production usage. FEEDBACK AND INITIATIVES REQUESTED - Does the current branch model (`main` = 4.3.x stable, `4.x-master` = 4.4 development) make sense? - Are there objections or improvements to the proposed Git workflow and governance? - What should be prioritized next: patch integration, CI/CD setup, packaging, testing, or documentation? - If you would like to take initiative, feel free to: - pick any area that interests you, - propose or start any concrete action (issue, patch, CI setup, documentation, release work, experimentation, etc.), - work independently or coordinate with others, as you prefer. - Opening issues, suggesting plans, or submitting early or draft PRs is explicitly encouraged. - Short replies and concrete input are perfectly fine. Thanks, Bruno

12 27

workflow updates
by Scot Kreienkamp 02 Feb '26

02 Feb '26

I've been working through the process of creating RPMs of Xymon, what we can and cannot do on GitHub actions. First, the GitHub actions to create the RPMs must run under Ubuntu, as it's the only Linux version directly available in actions, and it has to be a current version of Ubuntu at that. They phase out older versions fairly quickly. The RPM building commands are available under Ubuntu, but the file locations and such may differ, which could present a problem. The other option is I use podman or docker in Ubuntu based GitHub action to run a RedHat or Rocky Linux image to build the packages in. I might have to go that route to get packaging for older OS versions. If so, I might as well just use that to generate each OS version's packages so the only thing I would have to change between major OS versions is the image being used to compile it. Hopefully. Second, I'm still working through learning how to build the RPMs themselves. I'm still beginner level on how to do this so it's not fast progress. 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.

5 7