Project direction and next steps – GitHub migration and branch model
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-mirrorto preserve the full SVN lineage as a read-only reference. - Created a new active Git repository
xymonunder xymon-monitoring, cloned fromxymon-svn-mirrorwith full history intact. - Set
mainto track the stable 4.3.x line (anchored at Release 4.3.30). - Kept
4.x-masteras the ongoing development branch for 4.4. - Changed the default branch to
mainto 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
On Fr, 16 Jan 2026, Bruno Manzoni wrote:
- Migrate source control from SVN/SourceForge to GitHub as the primary workflow.
This seems to be done in https://github.com/xymon-monitoring/xymon
- Establish a clean, shared Git workflow with clear governance.
There is much to do, but a first build pipeline (does only a build of client and server, without creating packages or testing) was suggested in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you finds time to review this.
- Incorporate pending patches and publish a new 4.3.x release.
I started with these by creating some merge requests (the most important and generic patches from the Debian repository), see https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers of these.
- Address technical debt (PCRE2 migration, build warnings, compatibility issues).
A merge request for PCRE2 is in https://github.com/xymon-monitoring/xymon/pull/5
FEEDBACK AND INITIATIVES REQUESTED
- Does the current branch model (
main= 4.3.x stable,4.x-master= 4.4 development) make sense?
For me that's okay. I'm open for alternative names of '4.x-master' (maybe 'devel' or the like?), but I don't think that this is really relevant.
- What should be prioritized next: patch integration, CI/CD setup, packaging, testing, or documentation?
From my point of view, patch integration and fixing build warnings and the like has highest priority. It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE) currently don't seem to package xymon themselves. Users of these distributions have to use packages from J.C.'s https://terabithia.org/xymon/ 3rd party repository.
But this seems to have stopped beeing updated after fc38, maybe because of the PCRE2 incompatibility of newer OS distributions?
Without knowing, whether J.C. will continue to update this repository in the future (his last vital sign on the xymon list was nearly two years ago), we should think about building/providing at least RPM packages via pipeline.
One open question to me is, why J.C. (as the person, who released upstream 4.3.30) applied that many patches in https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm, that do not seem to be applied upstream. Seems that we should review them for integration into main, to find out whether they are RPM specific or whether they are useful for everybody.
Greetings Roland
I agree building for (at least) ubuntu-latest is a good start, but I would also add some RPM variant before publishing
Nicola
Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
Il giorno dom 18 gen 2026 alle ore 12:35 Roland Rosenfeld < roland@spinnaker.de> ha scritto:
On Fr, 16 Jan 2026, Bruno Manzoni wrote:
- Migrate source control from SVN/SourceForge to GitHub as the primary workflow.
This seems to be done in https://github.com/xymon-monitoring/xymon
- Establish a clean, shared Git workflow with clear governance.
There is much to do, but a first build pipeline (does only a build of client and server, without creating packages or testing) was suggested in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you finds time to review this.
- Incorporate pending patches and publish a new 4.3.x release.
I started with these by creating some merge requests (the most important and generic patches from the Debian repository), see https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers of these.
- Address technical debt (PCRE2 migration, build warnings, compatibility issues).
A merge request for PCRE2 is in https://github.com/xymon-monitoring/xymon/pull/5
FEEDBACK AND INITIATIVES REQUESTED
- Does the current branch model (
main= 4.3.x stable,4.x-master= 4.4 development) make sense?For me that's okay. I'm open for alternative names of '4.x-master' (maybe 'devel' or the like?), but I don't think that this is really relevant.
- What should be prioritized next: patch integration, CI/CD setup, packaging, testing, or documentation?
From my point of view, patch integration and fixing build warnings and the like has highest priority. It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE) currently don't seem to package xymon themselves. Users of these distributions have to use packages from J.C.'s https://terabithia.org/xymon/ 3rd party repository.
But this seems to have stopped beeing updated after fc38, maybe because of the PCRE2 incompatibility of newer OS distributions?
Without knowing, whether J.C. will continue to update this repository in the future (his last vital sign on the xymon list was nearly two years ago), we should think about building/providing at least RPM packages via pipeline.
One open question to me is, why J.C. (as the person, who released upstream 4.3.30) applied that many patches in https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm, that do not seem to be applied upstream. Seems that we should review them for integration into main, to find out whether they are RPM specific or whether they are useful for everybody.
Greetings Roland
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
I downloaded and installed the source RPM from Terebithia. The pristine tarball included in that matches the 4.3-master tarball from Sourceforge, in both size and md5sum, and there are a ton of patch files as well. Some of the patches relate to the backfeed queue, not sure about the remainder. Possibly the patches are backported from 4.4-alpha?
I don't know the first thing about making Ubuntu/Debian packages, but I can make RPMs.
Ralph Mitchell
On Sun, Jan 18, 2026 at 8:55 AM Nicola <canne74@gmail.com> wrote:
I agree building for (at least) ubuntu-latest is a good start, but I would also add some RPM variant before publishing
Nicola
Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
Il giorno dom 18 gen 2026 alle ore 12:35 Roland Rosenfeld < roland@spinnaker.de> ha scritto:
On Fr, 16 Jan 2026, Bruno Manzoni wrote:
- Migrate source control from SVN/SourceForge to GitHub as the primary workflow.
This seems to be done in https://github.com/xymon-monitoring/xymon
- Establish a clean, shared Git workflow with clear governance.
There is much to do, but a first build pipeline (does only a build of client and server, without creating packages or testing) was suggested in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you finds time to review this.
- Incorporate pending patches and publish a new 4.3.x release.
I started with these by creating some merge requests (the most important and generic patches from the Debian repository), see https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers of these.
- Address technical debt (PCRE2 migration, build warnings, compatibility issues).
A merge request for PCRE2 is in https://github.com/xymon-monitoring/xymon/pull/5
FEEDBACK AND INITIATIVES REQUESTED
- Does the current branch model (
main= 4.3.x stable,4.x-master= 4.4 development) make sense?For me that's okay. I'm open for alternative names of '4.x-master' (maybe 'devel' or the like?), but I don't think that this is really relevant.
- What should be prioritized next: patch integration, CI/CD setup, packaging, testing, or documentation?
From my point of view, patch integration and fixing build warnings and the like has highest priority. It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE) currently don't seem to package xymon themselves. Users of these distributions have to use packages from J.C.'s https://terabithia.org/xymon/ 3rd party repository.
But this seems to have stopped beeing updated after fc38, maybe because of the PCRE2 incompatibility of newer OS distributions?
Without knowing, whether J.C. will continue to update this repository in the future (his last vital sign on the xymon list was nearly two years ago), we should think about building/providing at least RPM packages via pipeline.
One open question to me is, why J.C. (as the person, who released upstream 4.3.30) applied that many patches in https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm, that do not seem to be applied upstream. Seems that we should review them for integration into main, to find out whether they are RPM specific or whether they are useful for everybody.
Greetings Roland
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
I have the tarball workflow done, just pending committing it if the repo is ready for it.
I don’t know anything about crafting rpms. If you could share that with us that would really help me getting that workflow together.
Scot Kreienkamp
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]
On Jan 18, 2026, at 12:30 PM, Ralph M <ralphmitchell@gmail.com> wrote:
I downloaded and installed the source RPM from Terebithia. The pristine tarball included in that matches the 4.3-master tarball from Sourceforge, in both size and md5sum, and there are a ton of patch files as well. Some of the patches relate to the backfeed queue, not sure about the remainder. Possibly the patches are backported from 4.4-alpha?
I don't know the first thing about making Ubuntu/Debian packages, but I can make RPMs.
Ralph Mitchell
On Sun, Jan 18, 2026 at 8:55 AM Nicola <canne74@gmail.com<mailto:canne74@gmail.com>> wrote: I agree building for (at least) ubuntu-latest is a good start, but I would also add some RPM variant before publishing
Nicola
Mastodon<https://joinmastodon.org/>: @nic@mathstodon.xyz<mailto:nic@mathstodon.xyz>
Il giorno dom 18 gen 2026 alle ore 12:35 Roland Rosenfeld <roland@spinnaker.de<mailto:roland@spinnaker.de>> ha scritto: On Fr, 16 Jan 2026, Bruno Manzoni wrote:
- Migrate source control from SVN/SourceForge to GitHub as the primary workflow.
This seems to be done in https://github.com/xymon-monitoring/xymon
- Establish a clean, shared Git workflow with clear governance.
There is much to do, but a first build pipeline (does only a build of client and server, without creating packages or testing) was suggested in https://github.com/xymon-monitoring/xymon/pull/4 Maybe some of you finds time to review this.
- Incorporate pending patches and publish a new 4.3.x release.
I started with these by creating some merge requests (the most important and generic patches from the Debian repository), see https://github.com/xymon-monitoring/xymon/pulls Looking for reviewers of these.
- Address technical debt (PCRE2 migration, build warnings, compatibility issues).
A merge request for PCRE2 is in https://github.com/xymon-monitoring/xymon/pull/5
FEEDBACK AND INITIATIVES REQUESTED
- Does the current branch model (
main= 4.3.x stable,4.x-master= 4.4 development) make sense?
For me that's okay. I'm open for alternative names of '4.x-master' (maybe 'devel' or the like?), but I don't think that this is really relevant.
- What should be prioritized next: patch integration, CI/CD setup, packaging, testing, or documentation?
From my point of view, patch integration and fixing build warnings and the like has highest priority. It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I noticed that the RPM distributions (Fedora/RedHat/CentOS/SuSE) currently don't seem to package xymon themselves. Users of these distributions have to use packages from J.C.'s https://terabithia.org/xymon/ 3rd party repository.
But this seems to have stopped beeing updated after fc38, maybe because of the PCRE2 incompatibility of newer OS distributions?
Without knowing, whether J.C. will continue to update this repository in the future (his last vital sign on the xymon list was nearly two years ago), we should think about building/providing at least RPM packages via pipeline.
One open question to me is, why J.C. (as the person, who released upstream 4.3.30) applied that many patches in https://terabithia.org/xymon/f38/SRPMS/xymon-4.3.30-1.fc38.src.rpm, that do not seem to be applied upstream. Seems that we should review them for integration into main, to find out whether they are RPM specific or whether they are useful for everybody.
Greetings Roland
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>
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>
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.
On Jan 18, 2026, at 04:35, Roland Rosenfeld <roland@spinnaker.de> wrote:
It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I agree. I think 4.3.31 as our test run should be a roll up of patches collected by distros and other small patches that have been floating around which don't risk changing behavior or build dependencies. That would exclude the PCRE2 change for this release as we don't know how this will affect non-Linux/BSD platforms. It should be fine as PCRE2 has been around a long time, but nobody has ever tried to build it on e.g., Solaris yet
Mark
Hi Mark!
On Sun, 18 Jan 2026, Mark Felder via Xymon wrote:
It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I agree. I think 4.3.31 as our test run should be a roll up of patches collected by distros and other small patches that have been floating around which don't risk changing behavior or build dependencies. That would exclude the PCRE2 change for this release as we don't know how this will affect non-Linux/BSD platforms. It should be fine as PCRE2 has been around a long time, but nobody has ever tried to build it on e.g., Solaris yet
But not upgrading to PCRE2 but staying with the old library, which was last updated 2021-06-22 (8.45) and is now officially "no longer being actively maintained" (see https://www.pcre.org/) means, that RHEL 10 and Debian 13 (trixie) are no longer supported, since these do no longer ship the old pcre library.
BTW: pcre2 was first released in 2015, so I expect that every OS should be able to build/ship this in more than 10 years.
I have to admit, that I didn't try this out on Solaris yet, but is there really anybody running a xymon server on Solaris nowadays? If you only need the client (with conftype "server"), no pcre is needed at all (only for the client with conftype "client"), so for most users, who only need a client on a "special" OS, this shouldn't be an issue.
A short search showed me, that pcre2 seems to be available on Solaris 10 and 11: https://www.opencsw.org/package/pcre2/ (but I didn't try this out myself, since I'm very happy to have shut down all Solaris boxes last year and so I no longer have to pray, if one of them hicks up and nobody is there to fix it).
Greetings Roland
PS: Do you also see my mails on the ML "From: Roland Rosenfeld <roland@spinnaker.de>"? While I see most postings in the ML as "From: Some Name as xymon <xymon@xymon.com>", I see myself (and some others) with their real addresses (and get DMARC warnings, because the list breaks DKIM (by adding a signature) and SPF (since the list server isn't permitted for spinnaker.de)...
On 19/01/2026 01:22, Scot Kreienkamp wrote:
Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.
please don't. Why would you do this?
Scot Kreienkamp
*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>
LaZboy Logo
On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de> wrote:
Hi Mark!
On Sun, 18 Jan 2026, Mark Felder via Xymon wrote:
It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I agree. I think 4.3.31 as our test run should be a roll up of patches collected by distros and other small patches that have been floating around which don't risk changing behavior or build dependencies. That would exclude the PCRE2 change for this release as we don't know how this will affect non-Linux/BSD platforms. It should be fine as PCRE2 has been around a long time, but nobody has ever tried to build it on e.g., Solaris yet
But not upgrading to PCRE2 but staying with the old library, which was last updated 2021-06-22 (8.45) and is now officially "no longer being actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/>) means, that RHEL 10 and Debian 13 (trixie) are no longer supported, since these do no longer ship the old pcre library.
BTW: pcre2 was first released in 2015, so I expect that every OS should be able to build/ship this in more than 10 years.
I have to admit, that I didn't try this out on Solaris yet, but is there really anybody running a xymon server on Solaris nowadays? If you only need the client (with conftype "server"), no pcre is needed at all (only for the client with conftype "client"), so for most users, who only need a client on a "special" OS, this shouldn't be an issue.
A short search showed me, that pcre2 seems to be available on Solaris 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> (but I didn't try this out myself, since I'm very happy to have shut down all Solaris boxes last year and so I no longer have to pray, if one of them hicks up and nobody is there to fix it).
Greetings Roland
PS: Do you also see my mails on the ML "From: Roland Rosenfeld <roland@spinnaker.de>"? While I see most postings in the ML as "From: Some Name as xymon <xymon@xymon.com>", I see myself (and some others) with their real addresses (and get DMARC warnings, because the list breaks DKIM (by adding a signature) and SPF (since the list server isn't permitted for spinnaker.de)...
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
Why not? One doesn't exclude the other, right? I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients? @Scot, why do you think the client wouldn't be viable? @Christoph, why the 'please don't'? It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!
Bruno
Le 19.01.2026 à 07:20, Christoph Zechner a écrit :
On 19/01/2026 01:22, Scot Kreienkamp wrote:
Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.
please don't. Why would you do this?
Scot Kreienkamp
*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>
LaZboy Logo
> On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de> wrote: > > Hi Mark! > > On Sun, 18 Jan 2026, Mark Felder via Xymon wrote: > >>> It would be great to have a 4.3.31 without architectural changes >>> but with the current painpoints fixed. > >> I agree. I think 4.3.31 as our test run should be a roll up of >> patches collected by distros and other small patches that have been >> floating around which don't risk changing behavior or build >> dependencies. That would exclude the PCRE2 change for this release >> as we don't know how this will affect non-Linux/BSD platforms. It >> should be fine as PCRE2 has been around a long time, but nobody has >> ever tried to build it on e.g., Solaris yet > > But not upgrading to PCRE2 but staying with the old library, which was > last updated 2021-06-22 (8.45) and is now officially "no longer being > actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/>) means, that RHEL 10 > and Debian 13 (trixie) are no longer supported, since these do no > longer ship the old pcre library. > > BTW: pcre2 was first released in 2015, so I expect that every OS > should be able to build/ship this in more than 10 years. > > I have to admit, that I didn't try this out on Solaris yet, but is > there really anybody running a xymon server on Solaris nowadays? If > you only need the client (with conftype "server"), no pcre is needed > at all (only for the client with conftype "client"), so for most > users, who only need a client on a "special" OS, this shouldn't be an > issue. > > A short search showed me, that pcre2 seems to be available on Solaris > 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> (but I didn't try > this out myself, since I'm very happy to have shut down all Solaris > boxes last year and so I no longer have to pray, if one of them hicks > up and nobody is there to fix it). > > Greetings > Roland > > PS: Do you also see my mails on the ML "From: Roland Rosenfeld > <roland@spinnaker.de>"? > While I see most postings in the ML as "From: Some Name as xymon > <xymon@xymon.com>", I see myself (and some others) with their real > addresses (and get DMARC warnings, because the list breaks DKIM > (by adding a signature) and SPF (since the list server isn't > permitted for spinnaker.de)... > _______________________________________________ > 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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
On 19/01/2026 09:04, Bruno Manzoni via Xymon wrote:
Why not? One doesn't exclude the other, right? I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients? @Scot, why do you think the client wouldn't be viable? @Christoph, why the 'please don't'?
because deployment via Docker is cumbersome and annoying IMO, Docker containers are notoriously unsafe (especially when run by the root user which is the default), hard to isolate network-wise and offer no real advantage here. Deploying xymon in a secure way (with encryption via stunnel for example) takes time and lots of configuration entries, I really don't see how putting the server component into a container would make things better.
Christoph
It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!
Bruno
Le 19.01.2026 à 07:20, Christoph Zechner a écrit :
On 19/01/2026 01:22, Scot Kreienkamp wrote:
Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.
please don't. Why would you do this?
Scot Kreienkamp
*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>
LaZboy Logo
> On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de> wrote: > > Hi Mark! > > On Sun, 18 Jan 2026, Mark Felder via Xymon wrote: > >>> It would be great to have a 4.3.31 without architectural changes >>> but with the current painpoints fixed. > >> I agree. I think 4.3.31 as our test run should be a roll up of >> patches collected by distros and other small patches that have been >> floating around which don't risk changing behavior or build >> dependencies. That would exclude the PCRE2 change for this release >> as we don't know how this will affect non-Linux/BSD platforms. It >> should be fine as PCRE2 has been around a long time, but nobody has >> ever tried to build it on e.g., Solaris yet > > But not upgrading to PCRE2 but staying with the old library, which was > last updated 2021-06-22 (8.45) and is now officially "no longer being > actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/>) means, that RHEL 10 > and Debian 13 (trixie) are no longer supported, since these do no > longer ship the old pcre library. > > BTW: pcre2 was first released in 2015, so I expect that every OS > should be able to build/ship this in more than 10 years. > > I have to admit, that I didn't try this out on Solaris yet, but is > there really anybody running a xymon server on Solaris nowadays? If > you only need the client (with conftype "server"), no pcre is needed > at all (only for the client with conftype "client"), so for most > users, who only need a client on a "special" OS, this shouldn't be an > issue. > > A short search showed me, that pcre2 seems to be available on Solaris > 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> (but I didn't try > this out myself, since I'm very happy to have shut down all Solaris > boxes last year and so I no longer have to pray, if one of them hicks > up and nobody is there to fix it). > > Greetings > Roland > > PS: Do you also see my mails on the ML "From: Roland Rosenfeld > <roland@spinnaker.de>"? > While I see most postings in the ML as "From: Some Name as xymon > <xymon@xymon.com>", I see myself (and some others) with their real > addresses (and get DMARC warnings, because the list breaks DKIM > (by adding a signature) and SPF (since the list server isn't > permitted for spinnaker.de)... > _______________________________________________ > 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
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
On 19/1/2026 08:12, Christoph Zechner wrote:
On 19/01/2026 09:04, Bruno Manzoni via Xymon wrote:
Why not? One doesn't exclude the other, right? I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients? @Scot, why do you think the client wouldn't be viable? @Christoph, why the 'please don't'?
because deployment via Docker is cumbersome and annoying IMO, Docker containers are notoriously unsafe (especially when run by the root user which is the default), hard to isolate network-wise and offer no real advantage here. Deploying xymon in a secure way (with encryption via stunnel for example) takes time and lots of configuration entries, I really don't see how putting the server component into a container would make things better.
Christoph
Well, funny this topic came up, but I have been planning on moving my xymon install to a container in the kubernetes cluster.
Advantages are that I no longer need to ensure the old physical machine is working, any single physical machine failure will allow kubernetes to restart the container on another node. Storage is persistent using the existing k8s storage (network). Of course, cluster failure will mean monitoring failure, and here is where my plan was to simply run a second instance in another cluster (at another location) to monitor the first and vice versa.
As far as isolation, sure, it is possible for an exploit of xymon to result in an exploit on the physical node, and ultimately the entire cluster..... this is a trade-off, the same as all other container based workloads.
I haven't done the work yet, so am not certain that it will work well, but that is my plan.
As for other discussions on new releases, I'd actually suggest to focus on tarball and/or docker releases. Let the distributions pick up the maintained tarball and create their own packages, at least in the short term. That is, focus on creating a stable new release with existing patches, rather than worry about how to create packaged versions.
Just my 0.02c
Regards, Adam
It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!
Bruno
Le 19.01.2026 à 07:20, Christoph Zechner a écrit :
On 19/01/2026 01:22, Scot Kreienkamp wrote:
Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.
please don't. Why would you do this?
Scot Kreienkamp
*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>
LaZboy Logo
> On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de> wrote: > > Hi Mark! > > On Sun, 18 Jan 2026, Mark Felder via Xymon wrote: > >>> It would be great to have a 4.3.31 without architectural changes >>> but with the current painpoints fixed. > >> I agree. I think 4.3.31 as our test run should be a roll up of >> patches collected by distros and other small patches that have been >> floating around which don't risk changing behavior or build >> dependencies. That would exclude the PCRE2 change for this release >> as we don't know how this will affect non-Linux/BSD platforms. It >> should be fine as PCRE2 has been around a long time, but nobody has >> ever tried to build it on e.g., Solaris yet > > But not upgrading to PCRE2 but staying with the old library, which was > last updated 2021-06-22 (8.45) and is now officially "no longer being > actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/>) means, that RHEL 10 > and Debian 13 (trixie) are no longer supported, since these do no > longer ship the old pcre library. > > BTW: pcre2 was first released in 2015, so I expect that every OS > should be able to build/ship this in more than 10 years. > > I have to admit, that I didn't try this out on Solaris yet, but is > there really anybody running a xymon server on Solaris nowadays? If > you only need the client (with conftype "server"), no pcre is needed > at all (only for the client with conftype "client"), so for most > users, who only need a client on a "special" OS, this shouldn't be an > issue. > > A short search showed me, that pcre2 seems to be available on Solaris > 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> (but I didn't try > this out myself, since I'm very happy to have shut down all Solaris > boxes last year and so I no longer have to pray, if one of them hicks > up and nobody is there to fix it). > > Greetings > Roland > > PS: Do you also see my mails on the ML "From: Roland Rosenfeld > <roland@spinnaker.de>"? > While I see most postings in the ML as "From: Some Name as xymon > <xymon@xymon.com>", I see myself (and some others) with their real > addresses (and get DMARC warnings, because the list breaks DKIM > (by adding a signature) and SPF (since the list server isn't > permitted for spinnaker.de)... > _______________________________________________ > 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
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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Bruno,
Normally the processes running in the container are isolated. The only files it can see are within the image, the only procs are those running in the image, ports, etc. I’ve never tried to break that isolation to let anything “out of the box” of the image. Did a bit of googling though, it looks like even the client might be able to work in a docker image. Maybe.
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: Bruno Manzoni via Xymon <xymon@xymon.com> Sent: Monday, January 19, 2026 3:05 AM To: xymon@xymon.com Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch> Subject: [Xymon] Re: Project direction and next steps – GitHub migration and branch model
Why not? One doesn't exclude the other, right? I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients? @Scot, why do you think the client wouldn't be viable? @Christoph, why the 'please don't'? It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!
Bruno Le 19.01.2026 à 07:20, Christoph Zechner a écrit : On 19/01/2026 01:22, Scot Kreienkamp wrote:
Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.
please don't. Why would you do this?
Scot Kreienkamp
*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/><http://www.la-z-boy.com/> facebook.com/lazboy <http://facebook.com/lazboy><http://facebook.com/lazboy> |instagram.com/lazboy <https://instagram.com/lazboy><https://instagram.com/lazboy> |youtube.com/lazboy <http://youtube.com/ lazboy><http://youtube.com/lazboy>
LaZboy Logo
On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de><mailto:roland@spinnaker.de> wrote:
Hi Mark!
On Sun, 18 Jan 2026, Mark Felder via Xymon wrote:
It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I agree. I think 4.3.31 as our test run should be a roll up of patches collected by distros and other small patches that have been floating around which don't risk changing behavior or build dependencies. That would exclude the PCRE2 change for this release as we don't know how this will affect non-Linux/BSD platforms. It should be fine as PCRE2 has been around a long time, but nobody has ever tried to build it on e.g., Solaris yet
But not upgrading to PCRE2 but staying with the old library, which was last updated 2021-06-22 (8.45) and is now officially "no longer being actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/><https://www.pcre.org/>) means, that RHEL 10 and Debian 13 (trixie) are no longer supported, since these do no longer ship the old pcre library.
BTW: pcre2 was first released in 2015, so I expect that every OS should be able to build/ship this in more than 10 years.
I have to admit, that I didn't try this out on Solaris yet, but is there really anybody running a xymon server on Solaris nowadays? If you only need the client (with conftype "server"), no pcre is needed at all (only for the client with conftype "client"), so for most users, who only need a client on a "special" OS, this shouldn't be an issue.
A short search showed me, that pcre2 seems to be available on Solaris 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/><https://www.opencsw.org/package/pcre2/> (but I didn't try this out myself, since I'm very happy to have shut down all Solaris boxes last year and so I no longer have to pray, if one of them hicks up and nobody is there to fix it).
Greetings Roland
PS: Do you also see my mails on the ML "From: Roland Rosenfeld <roland@spinnaker.de><mailto:roland@spinnaker.de>"? While I see most postings in the ML as "From: Some Name as xymon <xymon@xymon.com><mailto:xymon@xymon.com>", I see myself (and some others) with their real addresses (and get DMARC warnings, because the list breaks DKIM (by adding a signature) and SPF (since the list server isn't permitted for spinnaker.de)...
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>
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>
Thanks, Scot and Christoph, for the clear and candid feedback — I appreciate the direct tone.
The security and complexity concerns are understood, even if I don’t yet have a complete picture — thanks, Christoph, for the explanations.
Exploring whether there are use cases that make sense (testing, integration, small environments) and better understanding the trade-offs still seems like a good idea to me. At this stage, it doesn’t feel like a priority topic, although I may be mistaken, as there is generally a lack of testing and this could help address that to some extent.
There don’t seem to be any immediate stakes around this, so it really feels like an exploratory subject. Since Scot already seems to have a working version, it’s good to know that this has been explored, and it seems fine for him to continue in whatever direction he finds useful. Thanks, Scot, for the idea and the proposal.
Bruno
Le 19.01.2026 à 15:04, Scot Kreienkamp a écrit :
Bruno,
Normally the processes running in the container are isolated. The only files it can see are within the image, the only procs are those running in the image, ports, etc. I’ve never tried to break that isolation to let anything “out of the box” of the image. Did a bit of googling though, it looks like even the client might be able to work in a docker image. Maybe.
*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:*Bruno Manzoni via Xymon <xymon@xymon.com> *Sent:* Monday, January 19, 2026 3:05 AM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Project direction and next steps – GitHub migration and branch model
Why not? One doesn't exclude the other, right?
I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients?
@Scot, why do you think the client wouldn't be viable? @Christoph, why the 'please don't'?
It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!
Bruno
Le 19.01.2026 à 07:20, Christoph Zechner a écrit :
On 19/01/2026 01:22, Scot Kreienkamp wrote: Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution. please don't. Why would you do this? Scot Kreienkamp * * *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/> <http://www.la-z-boy.com/> facebook.com/lazboy <http://facebook.com/lazboy> <http://facebook.com/lazboy> |instagram.com/lazboy <https://instagram.com/lazboy> <https://instagram.com/lazboy> |youtube.com/lazboy <http://youtube.com/ lazboy> <http://youtube.com/lazboy> LaZboy Logo > On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de> <mailto:roland@spinnaker.de> wrote: > > Hi Mark! > > On Sun, 18 Jan 2026, Mark Felder via Xymon wrote: > >>> It would be great to have a 4.3.31 without architectural changes >>> but with the current painpoints fixed. > >> I agree. I think 4.3.31 as our test run should be a roll up of >> patches collected by distros and other small patches that have been >> floating around which don't risk changing behavior or build >> dependencies. That would exclude the PCRE2 change for this release >> as we don't know how this will affect non-Linux/BSD platforms. It >> should be fine as PCRE2 has been around a long time, but nobody has >> ever tried to build it on e.g., Solaris yet > > But not upgrading to PCRE2 but staying with the old library, which was > last updated 2021-06-22 (8.45) and is now officially "no longer being > actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/> <https://www.pcre.org/>) means, that RHEL 10 > and Debian 13 (trixie) are no longer supported, since these do no > longer ship the old pcre library. > > BTW: pcre2 was first released in 2015, so I expect that every OS > should be able to build/ship this in more than 10 years. > > I have to admit, that I didn't try this out on Solaris yet, but is > there really anybody running a xymon server on Solaris nowadays? If > you only need the client (with conftype "server"), no pcre is needed > at all (only for the client with conftype "client"), so for most > users, who only need a client on a "special" OS, this shouldn't be an > issue. > > A short search showed me, that pcre2 seems to be available on Solaris > 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/> <https://www.opencsw.org/package/pcre2/> (but I didn't try > this out myself, since I'm very happy to have shut down all Solaris > boxes last year and so I no longer have to pray, if one of them hicks > up and nobody is there to fix it). > > Greetings > Roland > > PS: Do you also see my mails on the ML "From: Roland Rosenfeld > <roland@spinnaker.de> <mailto:roland@spinnaker.de>"? > While I see most postings in the ML as "From: Some Name as xymon > <xymon@xymon.com> <mailto:xymon@xymon.com>", I see myself (and some others) with their real > addresses (and get DMARC warnings, because the list breaks DKIM > (by adding a signature) and SPF (since the list server isn't > permitted for spinnaker.de)... > _______________________________________________ > 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 _______________________________________________ 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 toxymon-leave@xymon.com
Testing is an excellent point that I missed. Containerization would enable very easy testing of new releases, especially for developers.
I am not a programmer so I can’t contribute directly as many others can, but I can certainly continue with containerization, RPM’s for installs, etc. I believe containerization would be beneficial based on how things work in our own environment. At worst I just waste my own time. 😊
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: Bruno Manzoni via Xymon <xymon@xymon.com> Sent: Monday, January 19, 2026 9:46 AM To: xymon@xymon.com Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch> Subject: [Xymon] Re: Project direction and next steps – GitHub migration and branch model
Thanks, Scot and Christoph, for the clear and candid feedback — I appreciate the direct tone.
The security and complexity concerns are understood, even if I don’t yet have a complete picture — thanks, Christoph, for the explanations.
Exploring whether there are use cases that make sense (testing, integration, small environments) and better understanding the trade-offs still seems like a good idea to me. At this stage, it doesn’t feel like a priority topic, although I may be mistaken, as there is generally a lack of testing and this could help address that to some extent.
There don’t seem to be any immediate stakes around this, so it really feels like an exploratory subject. Since Scot already seems to have a working version, it’s good to know that this has been explored, and it seems fine for him to continue in whatever direction he finds useful. Thanks, Scot, for the idea and the proposal.
Bruno Le 19.01.2026 à 15:04, Scot Kreienkamp a écrit : Bruno,
Normally the processes running in the container are isolated. The only files it can see are within the image, the only procs are those running in the image, ports, etc. I’ve never tried to break that isolation to let anything “out of the box” of the image. Did a bit of googling though, it looks like even the client might be able to work in a docker image. Maybe.
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<mailto:Scot.Kreienkamp@la-z-boy.com>
From: Bruno Manzoni via Xymon <xymon@xymon.com><mailto:xymon@xymon.com> Sent: Monday, January 19, 2026 3:05 AM To: 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 – GitHub migration and branch model
Why not? One doesn't exclude the other, right? I'm curious to hear both sides. What would be the pros and cons of having a Dockerized server receiving data from native clients? @Scot, why do you think the client wouldn't be viable? @Christoph, why the 'please don't'? It seems like a good hybrid idea to me, but I’d love to understand your technical concerns!
Bruno Le 19.01.2026 à 07:20, Christoph Zechner a écrit : On 19/01/2026 01:22, Scot Kreienkamp wrote:
Would it be worthwhile to create a docker image of xymon? The server could run in docker. The client could not though. Too much information would not be visible to make it a viable solution.
please don't. Why would you do this?
Scot Kreienkamp
*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/><http://www.la-z-boy.com/> facebook.com/lazboy <http://facebook.com/lazboy><http://facebook.com/lazboy> |instagram.com/lazboy <https://instagram.com/lazboy><https://instagram.com/lazboy> |youtube.com/lazboy <http://youtube.com/ lazboy><http://youtube.com/lazboy>
LaZboy Logo
On Jan 18, 2026, at 4:58 PM, Roland Rosenfeld <roland@spinnaker.de><mailto:roland@spinnaker.de> wrote:
Hi Mark!
On Sun, 18 Jan 2026, Mark Felder via Xymon wrote:
It would be great to have a 4.3.31 without architectural changes but with the current painpoints fixed.
I agree. I think 4.3.31 as our test run should be a roll up of patches collected by distros and other small patches that have been floating around which don't risk changing behavior or build dependencies. That would exclude the PCRE2 change for this release as we don't know how this will affect non-Linux/BSD platforms. It should be fine as PCRE2 has been around a long time, but nobody has ever tried to build it on e.g., Solaris yet
But not upgrading to PCRE2 but staying with the old library, which was last updated 2021-06-22 (8.45) and is now officially "no longer being actively maintained" (see https://www.pcre.org/ <https:// www.pcre.org/><https://www.pcre.org/>) means, that RHEL 10 and Debian 13 (trixie) are no longer supported, since these do no longer ship the old pcre library.
BTW: pcre2 was first released in 2015, so I expect that every OS should be able to build/ship this in more than 10 years.
I have to admit, that I didn't try this out on Solaris yet, but is there really anybody running a xymon server on Solaris nowadays? If you only need the client (with conftype "server"), no pcre is needed at all (only for the client with conftype "client"), so for most users, who only need a client on a "special" OS, this shouldn't be an issue.
A short search showed me, that pcre2 seems to be available on Solaris 10 and 11: https://www.opencsw.org/package/pcre2/ <https:// www.opencsw.org/package/pcre2/><https://www.opencsw.org/package/pcre2/> (but I didn't try this out myself, since I'm very happy to have shut down all Solaris boxes last year and so I no longer have to pray, if one of them hicks up and nobody is there to fix it).
Greetings Roland
PS: Do you also see my mails on the ML "From: Roland Rosenfeld <roland@spinnaker.de><mailto:roland@spinnaker.de>"? While I see most postings in the ML as "From: Some Name as xymon <xymon@xymon.com><mailto:xymon@xymon.com>", I see myself (and some others) with their real addresses (and get DMARC warnings, because the list breaks DKIM (by adding a signature) and SPF (since the list server isn't permitted for spinnaker.de)...
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>
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>
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/18/26 13:58, Roland Rosenfeld wrote:
But not upgrading to PCRE2 but staying with the old library, which was last updated 2021-06-22 (8.45) and is now officially "no longer being actively maintained" (see https://www.pcre.org/) means, that RHEL 10 and Debian 13 (trixie) are no longer supported, since these do no longer ship the old pcre library.
That's fair. I wasn't worried about Debian because they already patched it and didn't know the state of things on RHEL. We might as well consider that Debian has tested this pretty well already and make a fair assumption that PCRE2 is available on platforms that still want Xymon updates.
PS: Do you also see my mails on the ML "From: Roland Rosenfeld <roland@spinnaker.de>"? While I see most postings in the ML as "From: Some Name as xymon <xymon@xymon.com>", I see myself (and some others) with their real addresses (and get DMARC warnings, because the list breaks DKIM (by adding a signature) and SPF (since the list server isn't permitted for spinnaker.de)...
A quick search shows I'm not seeing any mails from you coming through the list properly, or it would show they're "From: Roland Rosenfeld via Xymon <xymon@xymon.com>". I think we need to remember to reply to all for now or some messages might get lost...
Mark
Regarding the PCRE2 migration, I am worried about making a breaking change (if anything at all, it will have to be installed) with a minor release which is also the first after a long time and the first from the newly formed group. It would be perfect if that was a choice or an automatic detection upon running "configure"
Nicola
Mastodon <https://joinmastodon.org/>: @nic@mathstodon.xyz
Il giorno mer 21 gen 2026 alle ore 03:30 Mark Felder via Xymon < xymon@xymon.com> ha scritto:
On 1/18/26 13:58, Roland Rosenfeld wrote:
But not upgrading to PCRE2 but staying with the old library, which was last updated 2021-06-22 (8.45) and is now officially "no longer being actively maintained" (see https://www.pcre.org/) means, that RHEL 10 and Debian 13 (trixie) are no longer supported, since these do no longer ship the old pcre library.
That's fair. I wasn't worried about Debian because they already patched it and didn't know the state of things on RHEL. We might as well consider that Debian has tested this pretty well already and make a fair assumption that PCRE2 is available on platforms that still want Xymon updates.
PS: Do you also see my mails on the ML "From: Roland Rosenfeld <roland@spinnaker.de>"? While I see most postings in the ML as "From: Some Name as xymon <xymon@xymon.com>", I see myself (and some others) with their real addresses (and get DMARC warnings, because the list breaks DKIM (by adding a signature) and SPF (since the list server isn't permitted for spinnaker.de)...
A quick search shows I'm not seeing any mails from you coming through the list properly, or it would show they're "From: Roland Rosenfeld via Xymon <xymon@xymon.com>". I think we need to remember to reply to all for now or some messages might get lost...
Mark
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Le Fri, Jan 16, 2026 at 07:42:59AM +0100, Bruno Manzoni via Xymon a écrit :
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.
Hello
I am really pleased to see the Xymon development moving to GitHub, thank you very much for inviting me to join the organization! Having a central place to store patches and issues was really needed.
Even if i have no time to help on C code, I find the original Xymon base quite dated and challenging to modernize, which is why I am so happy with my full Python rewrite, I will be very glad to contribute my CI/testing work to the Xymon project Like the CI for testing BSD (https://github.com/xymon-monitoring/xymon/pull/36) or testing the web interface via some docker (See https://github.com/xython-monitoring/xython/blob/master/docker/livetests/xyt...)
Regards
Hi Corentin, all,
testing the web interface via some Docker (See https://github.com/xython-monitoring/xython/blob/master/docker/livetests/xyt...)
This seems interesting too.
Like the CI for testing BSD (https://github.com/xymon-monitoring/xymon/pull/36)
I reused that approach 🙂
I added a CMake build running in parallel with the current build system. - This is only a first step. There are clearly more steps ahead, but it is already quite interesting. - Working with CMake makes dependencies explicit, which is important. This first step already gives a better view of binaries and dependencies.
BSD is working, as well as Ubuntu (latest) and on Ubuntu: installation from source
This is the first time I am doing this kind of work, and as it is quite complex, I will need your help, Corentin, Mark, Roland or anybody else . It would be great if you could have a look at the CMake part of the build process.
Scot is working on packaging, so maybe we will have something concrete quite soon.
Also some external dependencies for you Scot (Build and Runtime) https://github.com/bonomani/xymon/tree/cmake/bootstrap ci/deps/data/deps-server.yaml ci/deps/data/deps-map.yaml
Bruno
Hi to the list,
Just FYI, it might be interesting for the project…..
Today, just for testing, I've installed an Oracle Linux 10 x86_64 from scratch, followed by the repo's updates and the known prerequisites to install Xymon.
Then I've cloned the Xymon 4.3.30 github from https://github.com/xymon-monitoring/xymon (hope it's the right one....)
Running configure did throw me that error as first:
Checking for PCRE ...
test-pcre.c:1:10: fatal error: pcre.h: No such file or directory
1 | #include <pcre.h>
| ^~~~~~~~compilation terminated.
make: *** [Makefile.test-pcre:4: test-compile] Error 1
ERROR: Cannot compile using PCRE library.
/usr/bin/ld: cannot find test-pcre.o: No such file or directory
/usr/bin/ld: cannot find -lpcre: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile.test-pcre:7: test-link] Error 1
ERROR: Cannot link with PCRE library.
Missing PCRE include- or library-files. These are REQUIRED for xymond
PCRE can be found at http://www.pcre.org/
If you have PCRE installed, use the "--pcreinclude DIR" and "--pcrelib DIR"
options to configure to specify where they are.
Google’ing around, I found this site: https://dl.marmotte.net/rpms/redhat/el10/x86_64/pcre-8.45-1.el10.8/
From there, I've downloaded:
pcre-8.45-1.el10.8.src.rpm
pcre-8.45-1.el10.8.x86_64.rpm
pcre-cpp-8.45-1.el10.8.x86_64.rpm
pcre-cpp-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-debugsource-8.45-1.el10.8.x86_64.rpm
pcre-devel-8.45-1.el10.8.x86_64.rpm
pcre-doc-8.45-1.el10.8.noarch.rpm
pcre-static-8.45-1.el10.8.x86_64.rpm
pcre-tools-8.45-1.el10.8.x86_64.rpm
pcre-tools-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-utf16-8.45-1.el10.8.x86_64.rpm
pcre-utf16-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-utf32-8.45-1.el10.8.x86_64.rpm
pcre-utf32-debuginfo-8.45-1.el10.8.x86_64.rpm
…and installed:
rpm -i pcre-8.45-1.el10.8.x86_64.rpm \
pcre-devel-8.45-1.el10.8.x86_64.rpm \pcre-utf16-8.45-1.el10.8.x86_64.rpm \
pcre-utf32-8.45-1.el10.8.x86_64.rpm \
pcre-cpp-8.45-1.el10.8.x86_64.rpm \
pcre-tools-8.45-1.el10.8.x86_64.rpm
After this, with the next configure, the next error came to me:
Checking for RRDtool ...
Found RRDtool < 1.9.0 via pkg-config
Not RRDtool 1.0.x, checking for 1.2.x
test-rrd.c: In function ‘main’:
test-rrd.c:32:36: error: passing argument 2 of ‘rrd_graph’ from incompatible pointer type [-Wincompatible-pointer-types]
32 | result = rrd_graph(pcount, rrdargs, &calcpr, &xsize, &ysize, NULL, &ymin, &ymax);
| ^~~~~~~
| |
| char **In file included from test-rrd.c:3:
/usr/include/rrd.h:185:5: note: expected ‘const char **’ but argument is of type ‘char **’
185 | const char **,
| ^~~~~~~~~~~~~make: *** [Makefile.test-rrd:4: test-compile] Error 1
ERROR: Cannot compile with RRDtool.
ERROR: Linking with RRDtool fails
RRDtool include- or library-files not found.
These are REQUIRED for trend-graph support in Xymon, but Xymon can
be built without them (e.g. for a network-probe only installation.
RRDtool can be found at http://oss.oetiker.ch/rrdtool/
If you have RRDtool installed, use the "--rrdinclude DIR" and "--rrdlib DIR"
options to configure to specify where they are.
Continuing with all trend-graph support DISABLED
Now I’m stuck at this stage.
But this is just to let you guys know what happened to me on Oracle Linux 10.
Regards
Christian
Recently I tried to install xymon-4.3.30. I had similar results trying to run .configure on CentOS Stream 10 and openSUSE Leap 16.0. Xymon configure can't seem to find or work with rrdtool, openSSH or OpenLDAP. I have confirmed that I have the following versions installed: RRDtool 1.9.0 Copyright by Tobias Oetiker <tobi@oetiker.ch> Compiled Aug 08 2024 16:56:07
OpenSSH_10.0p2, OpenSSL 3.5.0 8 Apr 2025
OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
I am thrilled to see the Xymon project moving forward. We have been using Xymon for over 15 years and it continues to be an essential tool for us. Rather than try to upgrade the old distro it's running on, I look forward to standing up a new server if this project updates the installer. I am open to using whichever Linux distro will work. Thank you so much everyone for your efforts to maintain Xymon! Regards, Chris R.
From: Becker Christian via Xymon <xymon@xymon.com> Sent: Thursday, February 5, 2026 9:09 AM To: Xymon mailinglist <xymon@xymon.com> Cc: Becker Christian <christian.becker@rhein-zeitung.net> Subject: [Xymon] Re: Project direction and next steps – GitHub migration and branch model
Hi to the list,
Just FYI, it might be interesting for the project…..
Today, just for testing, I've installed an Oracle Linux 10 x86_64 from scratch, followed by the repo's updates and the known prerequisites to install Xymon.
Then I've cloned the Xymon 4.3.30 github from https://github.com/xymon-monitoring/xymon (hope it's the right one....)
Running configure did throw me that error as first:
Checking for PCRE ...
test-pcre.c:1:10: fatal error: pcre.h: No such file or directory
1 | #include <pcre.h>
| ^~~~~~~~compilation terminated.
make: *** [Makefile.test-pcre:4: test-compile] Error 1
ERROR: Cannot compile using PCRE library.
/usr/bin/ld: cannot find test-pcre.o: No such file or directory
/usr/bin/ld: cannot find -lpcre: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile.test-pcre:7: test-link] Error 1
ERROR: Cannot link with PCRE library.
Missing PCRE include- or library-files. These are REQUIRED for xymond
PCRE can be found at http://www.pcre.org/
If you have PCRE installed, use the "--pcreinclude DIR" and "--pcrelib DIR"
options to configure to specify where they are.
Google’ing around, I found this site: https://dl.marmotte.net/rpms/redhat/el10/x86_64/pcre-8.45-1.el10.8/
From there, I've downloaded:
pcre-8.45-1.el10.8.src.rpm
pcre-8.45-1.el10.8.x86_64.rpm
pcre-cpp-8.45-1.el10.8.x86_64.rpm
pcre-cpp-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-debugsource-8.45-1.el10.8.x86_64.rpm
pcre-devel-8.45-1.el10.8.x86_64.rpm
pcre-doc-8.45-1.el10.8.noarch.rpm
pcre-static-8.45-1.el10.8.x86_64.rpm
pcre-tools-8.45-1.el10.8.x86_64.rpm
pcre-tools-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-utf16-8.45-1.el10.8.x86_64.rpm
pcre-utf16-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-utf32-8.45-1.el10.8.x86_64.rpm
pcre-utf32-debuginfo-8.45-1.el10.8.x86_64.rpm
…and installed:
rpm -i pcre-8.45-1.el10.8.x86_64.rpm \
pcre-devel-8.45-1.el10.8.x86_64.rpm \pcre-utf16-8.45-1.el10.8.x86_64.rpm \
pcre-utf32-8.45-1.el10.8.x86_64.rpm \
pcre-cpp-8.45-1.el10.8.x86_64.rpm \
pcre-tools-8.45-1.el10.8.x86_64.rpm
After this, with the next configure, the next error came to me:
Checking for RRDtool ...
Found RRDtool < 1.9.0 via pkg-config
Not RRDtool 1.0.x, checking for 1.2.x
test-rrd.c: In function ‘main’:
test-rrd.c:32:36: error: passing argument 2 of ‘rrd_graph’ from incompatible pointer type [-Wincompatible-pointer-types]
32 | result = rrd_graph(pcount, rrdargs, &calcpr, &xsize, &ysize, NULL, &ymin, &ymax);
| ^~~~~~~
| |
| char **In file included from test-rrd.c:3:
/usr/include/rrd.h:185:5: note: expected ‘const char **’ but argument is of type ‘char **’
185 | const char **,
| ^~~~~~~~~~~~~make: *** [Makefile.test-rrd:4: test-compile] Error 1
ERROR: Cannot compile with RRDtool.
ERROR: Linking with RRDtool fails
RRDtool include- or library-files not found.
These are REQUIRED for trend-graph support in Xymon, but Xymon can
be built without them (e.g. for a network-probe only installation.
RRDtool can be found at http://oss.oetiker.ch/rrdtool/
If you have RRDtool installed, use the "--rrdinclude DIR" and "--rrdlib DIR"
options to configure to specify where they are.
Continuing with all trend-graph support DISABLED
Now I’m stuck at this stage.
But this is just to let you guys know what happened to me on Oracle Linux 10.
Regards
Christian
The City of Milwaukee is subject to Wisconsin Statutes related to public records. Unless otherwise exempted from the public records law, senders and receivers of City of Milwaukee e-mail should presume that e-mail is subject to release upon request, and is subject to state records retention requirements.
Anything based on RHEL10 (Oracle Linux 10, Centos 10, etc) won't have the "pcre" package. That's been deprecated and by RHEL10 it has finally been removed. The replacement is "pcre2". Someone referred to a bunch of patches for Debian, I think, that replaces pcre with pcre2. I don't know where that is, but I think it'll be rolled into the Git repository some time.
For RRD to work, you need the rrdtool-devel packages, because that installs the headers and library files. Similarly for several other dependencies - openssl-devel, libtirp-devel, openssh-devel, and probably others. Whenever you add one, and recompile, you'll be told about the next thing you need to install.
Ralph Mitchell
On Thu, Feb 5, 2026 at 11:11 AM Robles, Chris via Xymon <xymon@xymon.com> wrote:
Recently I tried to install xymon-4.3.30. I had similar results trying to run .configure on CentOS Stream 10 and openSUSE Leap 16.0. Xymon configure can't seem to find or work with rrdtool, openSSH or OpenLDAP. I have confirmed that I have the following versions installed: RRDtool 1.9.0 Copyright by Tobias Oetiker <tobi@oetiker.ch> Compiled Aug 08 2024 16:56:07
OpenSSH_10.0p2, OpenSSL 3.5.0 8 Apr 2025
OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
I am thrilled to see the Xymon project moving forward. We have been using Xymon for over 15 years and it continues to be an essential tool for us. Rather than try to upgrade the old distro it's running on, I look forward to standing up a new server if this project updates the installer. I am open to using whichever Linux distro will work. Thank you so much everyone for your efforts to maintain Xymon! Regards, Chris R.
*From:* Becker Christian via Xymon <xymon@xymon.com> *Sent:* Thursday, February 5, 2026 9:09 AM *To:* Xymon mailinglist <xymon@xymon.com> *Cc:* Becker Christian <christian.becker@rhein-zeitung.net> *Subject:* [Xymon] Re: Project direction and next steps – GitHub migration and branch model
Hi to the list,
Just FYI, it might be interesting for the project…..
Today, just for testing, I've installed an Oracle Linux 10 x86_64 from scratch, followed by the repo's updates and the known prerequisites to install Xymon.
Then I've cloned the Xymon 4.3.30 github from https://github.com/xymon-monitoring/xymon (hope it's the right one....)
Running configure did throw me that error as first:
Checking for PCRE ...
test-pcre.c:1:10: fatal error: pcre.h: No such file or directory
1 | #include <pcre.h> | ^~~~~~~~compilation terminated.
make: *** [Makefile.test-pcre:4: test-compile] Error 1
ERROR: Cannot compile using PCRE library.
/usr/bin/ld: cannot find test-pcre.o: No such file or directory
/usr/bin/ld: cannot find -lpcre: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile.test-pcre:7: test-link] Error 1
ERROR: Cannot link with PCRE library.
Missing PCRE include- or library-files. These are REQUIRED for xymond
PCRE can be found at http://www.pcre.org/
If you have PCRE installed, use the "--pcreinclude DIR" and "--pcrelib DIR"
options to configure to specify where they are.
Google’ing around, I found this site: https://dl.marmotte.net/rpms/redhat/el10/x86_64/pcre-8.45-1.el10.8/
From there, I've downloaded:
pcre-8.45-1.el10.8.src.rpm
pcre-8.45-1.el10.8.x86_64.rpm
pcre-cpp-8.45-1.el10.8.x86_64.rpm
pcre-cpp-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-debugsource-8.45-1.el10.8.x86_64.rpm
pcre-devel-8.45-1.el10.8.x86_64.rpm
pcre-doc-8.45-1.el10.8.noarch.rpm
pcre-static-8.45-1.el10.8.x86_64.rpm
pcre-tools-8.45-1.el10.8.x86_64.rpm
pcre-tools-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-utf16-8.45-1.el10.8.x86_64.rpm
pcre-utf16-debuginfo-8.45-1.el10.8.x86_64.rpm
pcre-utf32-8.45-1.el10.8.x86_64.rpm
pcre-utf32-debuginfo-8.45-1.el10.8.x86_64.rpm
…and installed:
rpm -i pcre-8.45-1.el10.8.x86_64.rpm \ pcre-devel-8.45-1.el10.8.x86_64.rpm \pcre-utf16-8.45-1.el10.8.x86_64.rpm \
pcre-utf32-8.45-1.el10.8.x86_64.rpm \
pcre-cpp-8.45-1.el10.8.x86_64.rpm \
pcre-tools-8.45-1.el10.8.x86_64.rpm
After this, with the next configure, the next error came to me:
Checking for RRDtool ...
Found RRDtool < 1.9.0 via pkg-config
Not RRDtool 1.0.x, checking for 1.2.x
test-rrd.c: In function ‘main’:
test-rrd.c:32:36: error: passing argument 2 of ‘rrd_graph’ from incompatible pointer type [-Wincompatible-pointer-types]
32 | result = rrd_graph(pcount, rrdargs, &calcpr, &xsize, &ysize, NULL, &ymin, &ymax);
| ^~~~~~~ | | | char **In file included from test-rrd.c:3:
/usr/include/rrd.h:185:5: note: expected ‘const char **’ but argument is of type ‘char **’
185 | const char **,
| ^~~~~~~~~~~~~make: *** [Makefile.test-rrd:4: test-compile] Error 1
ERROR: Cannot compile with RRDtool.
ERROR: Linking with RRDtool fails
RRDtool include- or library-files not found.
These are REQUIRED for trend-graph support in Xymon, but Xymon can
be built without them (e.g. for a network-probe only installation.
RRDtool can be found at http://oss.oetiker.ch/rrdtool/
If you have RRDtool installed, use the "--rrdinclude DIR" and "--rrdlib DIR"
options to configure to specify where they are.
Continuing with all trend-graph support DISABLED
Now I’m stuck at this stage.
But this is just to let you guys know what happened to me on Oracle Linux 10.
Regards
Christian
The City of Milwaukee is subject to Wisconsin Statutes related to public records. Unless otherwise exempted from the public records law, senders and receivers of City of Milwaukee e-mail should presume that e-mail is subject to release upon request, and is subject to state records retention requirements.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Hi all,
- PCRE on RHEL10-based systems
Anything based on RHEL10 (Oracle Linux 10, CentOS Stream 10, Rocky/Alma 10, etc.) does not ship the legacy "pcre" (PCRE1 / pcre.h) package in the standard repositories.
- Xymon 4.3.x still depends on legacy PCRE (PCRE 8.x).
- As a result, ./configure fails by default on EL10 due to missing pcre-devel.
What works today:
- Install legacy PCRE from a compat / third-party repository (e.g. pcre-8.45-1.el10.8 and pcre-devel-8.45-1.el10.8).
- Rerun ./configure; the PCRE check passes.
Where this is going:
- EL10 natively provides PCRE2.
- PCRE2 support is under active upstream review: https://github.com/xymon-monitoring/xymon/pull/5
- RRDtool 1.9.0 compatibility
RRDtool 1.9.0 (released 2024-07-29) introduced incompatible header changes in rrd.h. This requires changing affected call sites from char ** to const char **.
What is known to work:
- Debian ships an initial compatibility patch here: https://salsa.debian.org/debian/xymon/-/blob/master/debian/patches/101_rrdto...
What is upstream now:
- The updated fix merged via https://github.com/xymon-monitoring/xymon/pull/57 includes a build-time switch (based on pkg-config) to support both RRDtool 1.9.0 and older versions.
Note:
- This version-based switch is a tactical solution and should later be replaced by a cleaner build system approach (see build system work / #35).
- Build and packaging tooling
Work is ongoing to move from configure / make / make install to CMake. The goal is to modernize dependency handling and simplify packaging, while keeping existing installs working during the transition.
- Initial focus is on Debian and FreeBSD.
- The existing build system remains available in parallel.
Help welcome: Anyone with hands-on experience in packaging on EL/Fedora or other BSD variants is welcome to help validate the build and packaging work on those platforms.
Thanks again to everyone testing on newer platforms and sharing results. This feedback is exactly what we need to keep Xymon building cleanly on modern toolchains.
Bruno
Hi,
I added the 2 current issues to the wiki: https://github.com/xymon-monitoring/xymon-wiki/wiki
I think it's better to point users to the wiki so we don't have to repeat / repost this on the mailinglist everything this question pops up.
Stef
On 2026-02-06 00:24, Bruno Manzoni via Xymon wrote:
Hi all,
- PCRE on RHEL10-based systems
Anything based on RHEL10 (Oracle Linux 10, CentOS Stream 10, Rocky/Alma 10, etc.) does not ship the legacy "pcre" (PCRE1 / pcre.h) package in the standard repositories.
- Xymon 4.3.x still depends on legacy PCRE (PCRE 8.x).
- As a result, ./configure fails by default on EL10 due to missing pcre- devel.
What works today:
- Install legacy PCRE from a compat / third-party repository (e.g. pcre-8.45-1.el10.8 and pcre-devel-8.45-1.el10.8).
- Rerun ./configure; the PCRE check passes.
Where this is going:
- EL10 natively provides PCRE2.
- PCRE2 support is under active upstream review: https://github.com/xymon-monitoring/xymon/pull/5
- RRDtool 1.9.0 compatibility
RRDtool 1.9.0 (released 2024-07-29) introduced incompatible header changes in rrd.h. This requires changing affected call sites from char ** to const char **.
What is known to work:
- Debian ships an initial compatibility patch here: https://salsa.debian.org/debian/xymon/-/blob/master/debian/ patches/101_rrdtool1.9.patch
What is upstream now:
- The updated fix merged via https://github.com/xymon-monitoring/xymon/ pull/57 includes a build-time switch (based on pkg-config) to support both RRDtool 1.9.0 and older versions.
Note:
- This version-based switch is a tactical solution and should later be replaced by a cleaner build system approach (see build system work / #35).
- Build and packaging tooling
Work is ongoing to move from configure / make / make install to CMake. The goal is to modernize dependency handling and simplify packaging, while keeping existing installs working during the transition.
- Initial focus is on Debian and FreeBSD.
- The existing build system remains available in parallel.
Help welcome: Anyone with hands-on experience in packaging on EL/Fedora or other BSD variants is welcome to help validate the build and packaging work on those platforms.
Thanks again to everyone testing on newer platforms and sharing results. This feedback is exactly what we need to keep Xymon building cleanly on modern toolchains.
Bruno
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Hi Stef,
Yes, I think it is quite hard to follow the mailing list across multiple subjects. Many times we end up with the same information repeated, or even contradictory information.
I’m not using the GitHub wiki because I was told that a repository wiki is not indexed by search engines (e.g., Google). In case someone wants to build a wiki, I created a dedicated repository called *xymon-wiki*, which can be indexed by search engines and is published as a website.
Also, we can pin three issues so they stay at the top of the Issues list. We should also reconsider issue titles and scope (more precise vs. more general), and ensure each issue includes enough context to remain clear over time. Potentially, we could maintain a single “index” issue that tracks and links to the key topics.
For problem that are not "Code Problem", I did create some years ago a demo "xymon-problem" repo. I need to clean it up.
In the "private" repository, I have also reserved several channel names as placeholders for potential future use on Telegram (easy API/bots) and Signal (high security).
I don’t have any problem keeping things as they are now. I see this as an iterative process: if a step makes things better, that is already a good outcome. It doesn’t have to be perfect.
Thanks for trying to make things better.
Bruno
Le 09.02.2026 à 09:28, Stef Coene a écrit :
Hi,
I added the 2 current issues to the wiki: https://github.com/xymon-monitoring/xymon-wiki/wiki
I think it's better to point users to the wiki so we don't have to repeat / repost this on the mailinglist everything this question pops up.
Stef
On 2026-02-06 00:24, Bruno Manzoni via Xymon wrote:
Hi all,
- PCRE on RHEL10-based systems
Anything based on RHEL10 (Oracle Linux 10, CentOS Stream 10, Rocky/Alma 10, etc.) does not ship the legacy "pcre" (PCRE1 / pcre.h) package in the standard repositories.
- Xymon 4.3.x still depends on legacy PCRE (PCRE 8.x).
- As a result, ./configure fails by default on EL10 due to missing pcre- devel.
What works today:
- Install legacy PCRE from a compat / third-party repository (e.g. pcre-8.45-1.el10.8 and pcre-devel-8.45-1.el10.8).
- Rerun ./configure; the PCRE check passes.
Where this is going:
- EL10 natively provides PCRE2.
- PCRE2 support is under active upstream review: https://github.com/xymon-monitoring/xymon/pull/5
- RRDtool 1.9.0 compatibility
RRDtool 1.9.0 (released 2024-07-29) introduced incompatible header changes in rrd.h. This requires changing affected call sites from char ** to const char **.
What is known to work:
- Debian ships an initial compatibility patch here: https://salsa.debian.org/debian/xymon/-/blob/master/debian/ patches/101_rrdtool1.9.patch
What is upstream now:
- The updated fix merged via https://github.com/xymon-monitoring/xymon/ pull/57 includes a build-time switch (based on pkg-config) to support both RRDtool 1.9.0 and older versions.
Note:
- This version-based switch is a tactical solution and should later be replaced by a cleaner build system approach (see build system work / #35).
- Build and packaging tooling
Work is ongoing to move from configure / make / make install to CMake. The goal is to modernize dependency handling and simplify packaging, while keeping existing installs working during the transition.
- Initial focus is on Debian and FreeBSD.
- The existing build system remains available in parallel.
Help welcome: Anyone with hands-on experience in packaging on EL/Fedora or other BSD variants is welcome to help validate the build and packaging work on those platforms.
Thanks again to everyone testing on newer platforms and sharing results. This feedback is exactly what we need to keep Xymon building cleanly on modern toolchains.
Bruno
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
Hi,
I didn't know that wiki pages on github are skipped by search engines :(
It looks like .md files are indexed however, I will convert the wiki pages I created to md files so at least they are indexed. Later on, the information can be moved if a beter solution for documentation is found.
Stef
Hi Stef,
I created a simple page as an example showing how a repository can be used as a wiki and published with GitHub Pages.
https://xymon-monitoring.github.io/xymon-wiki/ (Feel free to use or extend this repository)
This URL is a normal public website and can be indexed by search engines. However, indexing may take some time and can be improved by submitting the site through a Google account (e.g., via Google Search Console).
In many projects, seems to me that the wiki content can live inside the README.md + "docs|"| folder of the main code repository. However, for the Xymon server repo, the docs directory is already used for the built-in help files, which are typically HTML rather than Markdown, so it may not be the best location for this case.
Bruno
Le 09.02.2026 à 15:47, Stef Coene a écrit :
Hi,
I didn't know that wiki pages on github are skipped by search engines :(
It looks like .md files are indexed however, I will convert the wiki pages I created to md files so at least they are indexed. Later on, the information can be moved if a beter solution for documentation is found.
Stef
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
participants (12)
-
Adam Goryachev
-
Becker Christian
-
Bruno Manzoni
-
Christoph Zechner
-
Corentin Labbe
-
Mark Felder
-
Nicola
-
Ralph M
-
Robles, Chris
-
Roland Rosenfeld
-
Scot Kreienkamp
-
Stef Coene