Project direction and next steps - feedback requested
Hi all,
Quick follow-up.
So far, there seems to be agreement that:
- 4.3 is the current production version.
- 4.4 is unfinished and experimental.
- The main blocker is the lack of a shared Git workflow.
To move forward, feedback is needed, and input from everyone is welcome. Feedback from long-time maintainers and contributors would be especially appreciated (JC Cleaver in particular; Henrik Storner is already involved).
In short:
- Who is willing to help?
- Is https://github.com/xymon-monitoring/xymon-svn-mirror a good place to move forward?
- If not, is there a better proposal (for example under https://github.com/xymon-monitoring)?
- What should be the next concrete step?
Short replies are perfectly fine.
Thanks, runo
Hi, I am willing to help (unfortunately my C skills are at the "hello world" level, from university studies). My votes:
- rename (or duplicate)
xymon-svn-mirrortoxymon - link the Xymon website to the new repo, instead of SVN/SourceForge
- incorporate the pending patches and publish a 4.3.31 (or maybe 4.3.32, since there's already a branch for .31) version, so we can also measure the interest
- enable github actions if anyone has experience to publish releases when a new tag is submitted
- either backport the needful from 4.4alpha or start testing fixes in there
Nicola Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
Il giorno gio 15 gen 2026 alle ore 06:47 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
Hi all,
Quick follow-up.
So far, there seems to be agreement that:
- 4.3 is the current production version.
- 4.4 is unfinished and experimental.
- The main blocker is the lack of a shared Git workflow.
To move forward, feedback is needed, and input from everyone is welcome. Feedback from long-time maintainers and contributors would be especially appreciated (JC Cleaver in particular; Henrik Storner is already involved).
In short:
- Who is willing to help?
- Is https://github.com/xymon-monitoring/xymon-svn-mirror a good place to move forward?
- If not, is there a better proposal (for example under https://github.com/xymon-monitoring)?
- What should be the next concrete step?
Short replies are perfectly fine.
Thanks, runo
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
I have experience with Github actions for other reasons… I could probably figure out the tags. It would be great if it could automatically build the RPMs, tarballs, debs, or whatever other packaging is necessary on each release so there’s a real pipeline. I don’t have experience with building packages though.
Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@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] From: Nicola <canne74@gmail.com> Sent: Thursday, January 15, 2026 12:44 PM To: Xymon mailinglist <xymon@xymon.com> Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch> Subject: [Xymon] Re: Project direction and next steps - feedback requested
You don't often get email from canne74@gmail.com<mailto:canne74@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi, I am willing to help (unfortunately my C skills are at the "hello world" level, from university studies). My votes:
- rename (or duplicate)
xymon-svn-mirrortoxymon - link the Xymon website to the new repo, instead of SVN/SourceForge
- incorporate the pending patches and publish a 4.3.31 (or maybe 4.3.32, since there's already a branch for .31) version, so we can also measure the interest
- enable github actions if anyone has experience to publish releases when a new tag is submitted
- either backport the needful from 4.4alpha or start testing fixes in there
Nicola Mastodon<https://joinmastodon.org/>: @nic@mathstodon.xyz<mailto:nic@mathstodon.xyz>
Il giorno gio 15 gen 2026 alle ore 06:47 Bruno Manzoni via Xymon <xymon@xymon.com<mailto:xymon@xymon.com>> ha scritto:
Hi all,
Quick follow-up.
So far, there seems to be agreement that: · 4.3 is the current production version. · 4.4 is unfinished and experimental. · The main blocker is the lack of a shared Git workflow.
To move forward, feedback is needed, and input from everyone is welcome. Feedback from long-time maintainers and contributors would be especially appreciated (JC Cleaver in particular; Henrik Storner is already involved).
In short: · Who is willing to help? · Is https://github.com/xymon-monitoring/xymon-svn-mirror a good place to move forward? · If not, is there a better proposal (for example under https://github.com/xymon-monitoring)? · What should be the next concrete step?
Short replies are perfectly fine.
Thanks, runo
Xymon mailing list -- xymon@xymon.com<mailto:xymon@xymon.com> To unsubscribe send an email to xymon-leave@xymon.com<mailto:xymon-leave@xymon.com>
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.
I don't know much about GitHub, but I have been building RPMs at work. I have enough server hardware at home to be able to spin up VMs for RHEL7 / 8 / 9 / 10 to make test builds. I can't really host repositories, though.
Ralph Mitchell
On Thu, Jan 15, 2026, 1:36 PM Scot Kreienkamp <Scot.Kreienkamp@la-z-boy.com> wrote:
I have experience with Github actions for other reasons… I could probably figure out the tags. It would be great if it could automatically build the RPMs, tarballs, debs, or whatever other packaging is necessary on each release so there’s a real pipeline. I don’t have experience with building packages though.
*Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate * (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@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 | instagram.com/lazboy | youtube.com/lazboy
[image: LaZboy Logo]
*From:* Nicola <canne74@gmail.com> *Sent:* Thursday, January 15, 2026 12:44 PM *To:* Xymon mailinglist <xymon@xymon.com> *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Project direction and next steps - feedback requested
You don't often get email from canne74@gmail.com. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>
Hi, I am willing to help (unfortunately my C skills are at the "hello world" level, from university studies).
My votes:
rename (or duplicate)
xymon-svn-mirrortoxymonlink the Xymon website to the new repo, instead of SVN/SourceForge
incorporate the pending patches and publish a 4.3.31 (or maybe 4.3.32, since there's already a branch for .31) version, so we can also measure the interest
enable github actions if anyone has experience to publish releases when a new tag is submitted
either backport the needful from 4.4alpha or start testing fixes in there
Nicola
Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
Il giorno gio 15 gen 2026 alle ore 06:47 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
Hi all,
Quick follow-up.
So far, there seems to be agreement that:
· 4.3 is the current production version.
· 4.4 is unfinished and experimental.
· The main blocker is the lack of a shared Git workflow.
To move forward, feedback is needed, and input from everyone is welcome. Feedback from long-time maintainers and contributors would be especially appreciated (JC Cleaver in particular; Henrik Storner is already involved).
In short:
· Who is willing to help?
· Is https://github.com/xymon-monitoring/xymon-svn-mirror a good place to move forward?
· If not, is there a better proposal (for example under https://github.com/xymon-monitoring)?
· What should be the next concrete step?
Short replies are perfectly fine.
Thanks, runo
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
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@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
The tarballs are easy. I know Terabithia repo is building RPM’s… if they or someone can give me basic directions on how it’s currently being done I that would help. Once I know how to do it locally it’s not difficult to add anything into the GitHub actions.
Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate One La-Z-Boy Drive | Monroe, Michigan 48162 | • (734) 384-6403 | | • 1-734-915-1444 | Email: Scot.Kreienkamp@la-z-boy.com
From: Ralph M <ralphmitchell@gmail.com> Sent: Thursday, January 15, 2026 2:11 PM To: Xymon mailinglist <xymon@xymon.com> Subject: [Xymon] Re: Project direction and next steps - feedback requested
I don't know much about GitHub, but I have been building RPMs at work. I have enough server hardware at home to be able to spin up VMs for RHEL7 / 8 / 9 / 10 to make test builds. I can't really host repositories, though.
Ralph Mitchell
On Thu, Jan 15, 2026, 1:36 PM Scot Kreienkamp <Scot.Kreienkamp@la-z-boy.com<mailto:Scot.Kreienkamp@la-z-boy.com>> wrote: I have experience with Github actions for other reasons… I could probably figure out the tags. It would be great if it could automatically build the RPMs, tarballs, debs, or whatever other packaging is necessary on each release so there’s a real pipeline. I don’t have experience with building packages though.
Scot Kreienkamp | Applications Infrastructure Architect | La-Z-Boy Corporate (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com<mailto:Scot.Kreienkamp@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:image001.png@01DC8629.90091E10] From: Nicola <canne74@gmail.com<mailto:canne74@gmail.com>> Sent: Thursday, January 15, 2026 12:44 PM To: Xymon mailinglist <xymon@xymon.com<mailto:xymon@xymon.com>> Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch<mailto:bruno.manzoni@ubi-network.ch>> Subject: [Xymon] Re: Project direction and next steps - feedback requested
You don't often get email from canne74@gmail.com<mailto:canne74@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi, I am willing to help (unfortunately my C skills are at the "hello world" level, from university studies). My votes:
- rename (or duplicate)
xymon-svn-mirrortoxymon - link the Xymon website to the new repo, instead of SVN/SourceForge
- incorporate the pending patches and publish a 4.3.31 (or maybe 4.3.32, since there's already a branch for .31) version, so we can also measure the interest
- enable github actions if anyone has experience to publish releases when a new tag is submitted
- either backport the needful from 4.4alpha or start testing fixes in there
Nicola Mastodon<https://joinmastodon.org/>: @nic@mathstodon.xyz<mailto:nic@mathstodon.xyz>
Il giorno gio 15 gen 2026 alle ore 06:47 Bruno Manzoni via Xymon <xymon@xymon.com<mailto:xymon@xymon.com>> ha scritto:
Hi all,
Quick follow-up.
So far, there seems to be agreement that: • 4.3 is the current production version. • 4.4 is unfinished and experimental. • The main blocker is the lack of a shared Git workflow.
To move forward, feedback is needed, and input from everyone is welcome. Feedback from long-time maintainers and contributors would be especially appreciated (JC Cleaver in particular; Henrik Storner is already involved).
In short: • Who is willing to help? • Is https://github.com/xymon-monitoring/xymon-svn-mirror a good place to move forward? • If not, is there a better proposal (for example under https://github.com/xymon-monitoring)? • What should be the next concrete step?
Short replies are perfectly fine.
Thanks, runo
Xymon mailing list -- xymon@xymon.com<mailto:xymon@xymon.com> To unsubscribe send an email to xymon-leave@xymon.com<mailto:xymon-leave@xymon.com>
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@xymon.com<mailto:xymon@xymon.com> To unsubscribe send an email to xymon-leave@xymon.com<mailto:xymon-leave@xymon.com>
On 1/15/26 09:43, Nicola wrote:
Hi, I am willing to help (unfortunately my C skills are at the "hello world" level, from university studies).
Yeah, I'm in a similar position. I don't have a lot of C experience, but I have very broad skills across a bunch of languages and networking/sysadmin. We have a lot of tools at our disposal to help us though, and that giant "Fix a large number of GCC build warnings and issues (Tom Schmidt, with Ralph Mitchell)" commit definitely helps clean up the codebase.
It would probably help if we try to make the effort of forcing warnings to be errors so we can catch anti-patterns quickly. I'm not sure how much more work will be required to achieve this, but I'll look into it.
I think getting this migration announced would be good as well because it might attract additional contributors with the barriers being lowered a lot now.
Some quick wins might include small quality of life changes like improving the default web design/templates.
I'm also very curious about how many users out there rely on it for some of these legacy Unix systems (AIX, HPUX, etc) because if we get some folks interested in doing things like rewriting xymonnet, xymonping, etc in Rust I don't want to squash that enthusiasm, but we have to be sure it's still possible to target those platforms and I haven't really investigated that. I just know Rust currently cannot target all the architectures C can.
- enable github actions if anyone has experience to publish releases when a new tag is submitted
Not sure if this is really necessary as a tag and a release on Github will provide links to the source tarballs for us, but CI/CD production of RPMs or DEBs would be useful if it's not too much trouble.
- either backport the needful from 4.4alpha or start testing fixes in there
We might have to rely on some advice from Henrik and JC here to see if this is worth pursuing at this time. I'd definitely like to understand what the overall architecture plan was for supporting IPv6 because there are a lot of assumptions about IPv4 in this project -- e.g., the addresses in the hosts file and its interaction with the "testip" setting.
If we're ever to rearchitect xymonnet I think it would be excellent if we could just rely on libcurl because it has support for nearly everything we would want to test (HTTP/HTTPS/IMAP/POP/SMTP/LDAP...) and it wouldn't require custom scripts to test things like the TLS upgrade certificate on SMTP port 25; our tests would actually speak the real protocols!
Anyway I'm droning on enough. As you can tell there's so much potential for Xymon. We *can* modernize it.
Mark
Hi,
I also want to help. I'm not a C programmer, but I can help with documentation and testing.
I also have some small patches and enhancements that I want to contribute.
Like wget and curl drop-in replacement scripts for the xymon binary for encrypted https communication between client and server.
I also have a patch to allow for a filter in the graphs so you can easy filter the data you want to display. And a patch for a list of rrd files so you can create graphs with exactly the data you want. We are using this to display disks graphs with all the disks for an AIX volume group. The URL is generated with an external scripts to include the needed disks.
Stef
On 2026-01-15 07:47, Bruno Manzoni via Xymon wrote:
Hi all,
Quick follow-up.
So far, there seems to be agreement that:
- 4.3 is the current production version.
- 4.4 is unfinished and experimental.
- The main blocker is the lack of a shared Git workflow.
To move forward, feedback is needed, and input from everyone is welcome. Feedback from long-time maintainers and contributors would be especially appreciated (JC Cleaver in particular; Henrik Storner is already involved).
In short:
- Who is willing to help?
- Is https://github.com/xymon-monitoring/xymon-svn-mirror a good place to move forward?
- If not, is there a better proposal (for example under https:// github.com/xymon-monitoring)?
- What should be the next concrete step?
Short replies are perfectly fine.
Thanks, runo
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
On 1/15/26 10:31, Stef Coene wrote:
Hi,
I also want to help. I'm not a C programmer, but I can help with documentation and testing.
I also have some small patches and enhancements that I want to contribute.
Like wget and curl drop-in replacement scripts for the xymon binary for encrypted https communication between client and server.
I also have a patch to allow for a filter in the graphs so you can easy filter the data you want to display. And a patch for a list of rrd files so you can create graphs with exactly the data you want. We are using this to display disks graphs with all the disks for an AIX volume group. The URL is generated with an external scripts to include the needed disks.
Stef, I think you posted about these on the mailing list a long time ago and I found them when I was going through mailing list history since the last release. Very very interested in these additions too. The trick to submit the client data over HTTPS was very clever -- I was about to build that myself.
Would it be practical to implement network encryption for IPv4, then circle back for IPv6 later? I don't really know what's involved in that, but I have several thousand clients using my own curl script to report, because I'm required to use encrypted connections.
I tried compiling on RHEL10 last week. There's a problem there to address
- pcre has been deprecated and replaced with pcre2. The old pcre is still present up to RHEL9, but it's missing in 10. I;ll take a look and see what I can do with it, but I'm not a hot-shot programmer so it might take a while.
Ralph Mitchell
On Thu, Jan 15, 2026 at 2:54 PM Mark Felder via Xymon <xymon@xymon.com> wrote:
On 1/15/26 10:31, Stef Coene wrote:
Hi,
I also want to help. I'm not a C programmer, but I can help with documentation and testing.
I also have some small patches and enhancements that I want to contribute.
Like wget and curl drop-in replacement scripts for the xymon binary for encrypted https communication between client and server.
I also have a patch to allow for a filter in the graphs so you can easy filter the data you want to display. And a patch for a list of rrd files so you can create graphs with exactly the data you want. We are using this to display disks graphs with all the disks for an AIX volume group. The URL is generated with an external scripts to include the needed disks.
Stef, I think you posted about these on the mailing list a long time ago and I found them when I was going through mailing list history since the last release. Very very interested in these additions too. The trick to submit the client data over HTTPS was very clever -- I was about to build that myself.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
I have not yet started using RHEL 10 but I did find the following earlier ...
https://extras.getpagespeed.com/redhat/10/x86_64/repoview/pcre.html
Thanks, Matt
On Thu, Jan 15, 2026 at 4:04 PM Ralph M <ralphmitchell@gmail.com> wrote:
Would it be practical to implement network encryption for IPv4, then circle back for IPv6 later? I don't really know what's involved in that, but I have several thousand clients using my own curl script to report, because I'm required to use encrypted connections.
I tried compiling on RHEL10 last week. There's a problem there to address
- pcre has been deprecated and replaced with pcre2. The old pcre is still present up to RHEL9, but it's missing in 10. I;ll take a look and see what I can do with it, but I'm not a hot-shot programmer so it might take a while.
Ralph Mitchell
On Thu, Jan 15, 2026 at 2:54 PM Mark Felder via Xymon <xymon@xymon.com> wrote:
On 1/15/26 10:31, Stef Coene wrote:
Hi,
I also want to help. I'm not a C programmer, but I can help with documentation and testing.
I also have some small patches and enhancements that I want to contribute.
Like wget and curl drop-in replacement scripts for the xymon binary for encrypted https communication between client and server.
I also have a patch to allow for a filter in the graphs so you can easy filter the data you want to display. And a patch for a list of rrd files so you can create graphs with exactly the data you want. We are using this to display disks graphs with all the disks for an AIX volume group. The URL is generated with an external scripts to include the needed disks.
Stef, I think you posted about these on the mailing list a long time ago and I found them when I was going through mailing list history since the last release. Very very interested in these additions too. The trick to submit the client data over HTTPS was very clever -- I was about to build that myself.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
-- Matthew Goebel : m <goebel@emunix.emich.edu>goebel@emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating medher... "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer
I implemented some github automation for Python by following from https://blog.jaraco.com/skeleton/ and it wasn't bad.
I really like the idea of libcurl, and if everyone picks a task, I think we can get features in a reasonable time. The only thing I think is missing is code testing: not familiar with what's available in C, but no "test" dir is there... I was thinking about the UI as well, but the existing one is a sort of signature of Xymon, so I would be cautious unless it's just a series of CSS files which can be plugged in. I guess multi-tenancy but retaining the current simplicity would be a big improvement, if any user is interested.
Should we start with issues per feature (any other method to gather these is welcome) and get some sort of voting to understand what customers want?
Nicola Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
Il giorno gio 15 gen 2026 alle ore 21:11 Matthew Goebel via Xymon < xymon@xymon.com> ha scritto:
I have not yet started using RHEL 10 but I did find the following earlier ...
https://extras.getpagespeed.com/redhat/10/x86_64/repoview/pcre.html
Thanks, Matt
On Thu, Jan 15, 2026 at 4:04 PM Ralph M <ralphmitchell@gmail.com> wrote:
Would it be practical to implement network encryption for IPv4, then circle back for IPv6 later? I don't really know what's involved in that, but I have several thousand clients using my own curl script to report, because I'm required to use encrypted connections.
I tried compiling on RHEL10 last week. There's a problem there to address - pcre has been deprecated and replaced with pcre2. The old pcre is still present up to RHEL9, but it's missing in 10. I;ll take a look and see what I can do with it, but I'm not a hot-shot programmer so it might take a while.
Ralph Mitchell
On Thu, Jan 15, 2026 at 2:54 PM Mark Felder via Xymon <xymon@xymon.com> wrote:
On 1/15/26 10:31, Stef Coene wrote:
Hi,
I also want to help. I'm not a C programmer, but I can help with documentation and testing.
I also have some small patches and enhancements that I want to contribute.
Like wget and curl drop-in replacement scripts for the xymon binary for encrypted https communication between client and server.
I also have a patch to allow for a filter in the graphs so you can easy filter the data you want to display. And a patch for a list of rrd files so you can create graphs with exactly the data you want. We are using this to display disks graphs with all the disks for an AIX volume group. The URL is generated with an external scripts to include the needed disks.
Stef, I think you posted about these on the mailing list a long time ago and I found them when I was going through mailing list history since the last release. Very very interested in these additions too. The trick to submit the client data over HTTPS was very clever -- I was about to build that myself.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
-- Matthew Goebel : m <goebel@emunix.emich.edu>goebel@emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating medher... "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
As others have said, I'm keen to help where I can, although I'm not an accomplished C programmer, and really don't have any skills in software development.
Moving the source code repository seems a fairly obvious way to modernise the workflow. I'm totally behind this.
There are two ways I interact with the current Xymon codebase. One is via the source code, and the other is to install packages from the official repository aka Terabithia. This second touch point is important in a corporate environment that has a deployment model that relies on reliable and trusted repositories, and requires long-term consistency. I'd be hesitant to switch repositories from Terabithia to something new, until I became confident it would still be around in 18 months.
To a non-insignificant degree, Terabithia is part of the current Xymon ecosystem (for me). It would be ideal for new releases to be packaged up and then published on the existing Terabithia repo. It's not clear how this would happen. If JC is able to continue to maintain Terabithia, hosting the building and publishing process, pointing instead at the new source code repo, then this would be a huge benefit to the project. Alternatively, perhaps JC would prefer to hand over the domain to another volunteer, to maintain the existing repo URLs that are configured on no doubt thousands of systems.
(Of course, not wanting to diminish the importance of other package maintainers. I'm just Red Hat centric, as I imagine would be common for corporate deployments.)
This thread has been a place where people have expressed their frustrations with the current release of Xymon. I think it's helpful to do this, and I also like that people are suggesting solutions that could be implemented in new releases. This is aspirational, and I encourage this discussion. At the same time, none of the discussion will lead to any progress unless and until the basics are in place: a) source code repo, b) build and test pipeline, c) leadership team with time to vet contributions and publish releases. (And hopefully, selfishly, an RPM repository.) We should not lose focus on these objectives in the short term. And I'm heartened that we've seen so much progress in such a short time, thanks to this generous and insightful community.
Cheers Jeremy
Here's some theme elements that are welcome to be incorporated. https://gitlab.com/ionetworkadmin/xymon-server-custom-theme
Kris Springer On January 15, 2026 2:26:57 PM Nicola <canne74@gmail.com> wrote:
I implemented some github automation for Python by following from https://blog.jaraco.com/skeleton/ and it wasn't bad.
I really like the idea of libcurl, and if everyone picks a task, I think we can get features in a reasonable time. The only thing I think is missing is code testing: not familiar with what's available in C, but no "test" dir is there... I was thinking about the UI as well, but the existing one is a sort of signature of Xymon, so I would be cautious unless it's just a series of CSS files which can be plugged in. I guess multi-tenancy but retaining the current simplicity would be a big improvement, if any user is interested.
Should we start with issues per feature (any other method to gather these is welcome) and get some sort of voting to understand what customers want?
Nicola
Mastodon: @nic@mathstodon.xyz
Il giorno gio 15 gen 2026 alle ore 21:11 Matthew Goebel via Xymon <xymon@xymon.com> ha scritto:
I have not yet started using RHEL 10 but I did find the following earlier ...
https://extras.getpagespeed.com/redhat/10/x86_64/repoview/pcre.html
Thanks, Matt
On Thu, Jan 15, 2026 at 4:04 PM Ralph M <ralphmitchell@gmail.com> wrote:
Would it be practical to implement network encryption for IPv4, then circle back for IPv6 later? I don't really know what's involved in that, but I have several thousand clients using my own curl script to report, because I'm required to use encrypted connections.
I tried compiling on RHEL10 last week. There's a problem there to address
- pcre has been deprecated and replaced with pcre2. The old pcre is still present up to RHEL9, but it's missing in 10. I;ll take a look and see what I can do with it, but I'm not a hot-shot programmer so it might take a while.
Ralph Mitchell
On Thu, Jan 15, 2026 at 2:54 PM Mark Felder via Xymon <xymon@xymon.com> wrote:
On 1/15/26 10:31, Stef Coene wrote:
Hi,
I also want to help. I'm not a C programmer, but I can help with documentation and testing.
I also have some small patches and enhancements that I want to contribute.
Like wget and curl drop-in replacement scripts for the xymon binary for encrypted https communication between client and server.
I also have a patch to allow for a filter in the graphs so you can easy filter the data you want to display. And a patch for a list of rrd files so you can create graphs with exactly the data you want. We are using this to display disks graphs with all the disks for an AIX volume group. The URL is generated with an external scripts to include the needed disks.
Stef, I think you posted about these on the mailing list a long time ago and I found them when I was going through mailing list history since the last release. Very very interested in these additions too. The trick to submit the client data over HTTPS was very clever -- I was about to build that myself.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
--
Matthew Goebel : mgoebel@emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating medher... "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Dear all,
very excited to see this flurry of activity, big thanks to everyone involved! While we're not fluent C programmers either, we would be willing to help with testing and integration. I did a deep dive into 4.4-alpha almost exactly 1 year ago that I'd be happy to repeat/extend when there's progress. We're also committed to further supporting and improving our xymon dashboard [1] that we've been using on a daily basis for almost 8 years now (yikes!). If packaging/hosting on GH doesn't pan out for some reason, we'd be glad to offer repo hosting as well.
thanks and kind regards, -Christian
[1]https://github.com/daduke/Xymondash
-- Dr. Christian Herzog <herzog@phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
On 1/15/26 13:04, Ralph M wrote:
Would it be practical to implement network encryption for IPv4, then circle back for IPv6 later? I don't really know what's involved in that, but I have several thousand clients using my own curl script to report, because I'm required to use encrypted connections.
I tried compiling on RHEL10 last week. There's a problem there to address - pcre has been deprecated and replaced with pcre2. The old pcre is still present up to RHEL9, but it's missing in 10. I;ll take a look and see what I can do with it, but I'm not a hot-shot programmer so it might take a while.
Don't worry, the Debian folks already have a patch that changes Xymon to use PCRE2. We'll get that merged.
Mark
That's good that someone already did the PCRE2 change. I just downloaded the RHEL9 source for pcre and it compiles OK on RHEL10, but I wouldn't want to rely on maintaining it somewhere for all users to download.
Ralph
On Thu, Jan 15, 2026 at 4:43 PM Mark Felder <feld@pobox.feld.me> wrote:
On 1/15/26 13:04, Ralph M wrote:
Would it be practical to implement network encryption for IPv4, then circle back for IPv6 later? I don't really know what's involved in that, but I have several thousand clients using my own curl script to report, because I'm required to use encrypted connections.
I tried compiling on RHEL10 last week. There's a problem there to address - pcre has been deprecated and replaced with pcre2. The old pcre is still present up to RHEL9, but it's missing in 10. I;ll take a look and see what I can do with it, but I'm not a hot-shot programmer so it might take a while.
Don't worry, the Debian folks already have a patch that changes Xymon to use PCRE2. We'll get that merged.
Mark
participants (10)
-
Bruno Manzoni
-
Christian Herzog
-
Jeremy Laidman
-
Kris Springer
-
Mark Felder
-
Matthew Goebel
-
Nicola
-
Ralph M
-
Scot Kreienkamp
-
Stef Coene