Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I'm working on deploying a server.
- On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
- On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated (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]
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.
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server.
- On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
- On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (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
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 toxymon-leave@xymon.com
Hi Bruno,
I most certainly did. 😊
Name : xymon-client Version : 4.3.31 Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9 Architecture : x86_64 Size : 1.0 M Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm Repository : @System From repo : puppet-xymon-snapshot Summary : Client for the Xymon network monitor URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com
From: Bruno Manzoni via Xymon <xymon@xymon.com> Sent: Monday, September 14, 2026 4:40 PM To: xymon@xymon.com Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch> Subject: [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit : Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server.
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated (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@01DD4468.EADF4050]
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>
*Confirmed. You *😎* are the first one, you make my day* 😮!
So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.*
*Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later.
*It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first.
Until that lands, the right place to override them is xymon-rpm.
*And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.*
*Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other.
*One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change.
I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong.
Bruno
Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-client
Version : 4.3.31
Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9
Architecture : x86_64
Size : 1.0 M
Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm
Repository : @System
From repo : puppet-xymon-snapshot
Summary : Client for the Xymon network monitor
URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com
*From:*Bruno Manzoni via Xymon <xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server. 1.On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. 2.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (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 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 toxymon-leave@xymon.com
Hi Scot,
Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what.
Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging.
For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't.
Bruno
Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :
*Confirmed. You *😎* are the first one, you make my day* 😮!
So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.*
*Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later.
*It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first.
Until that lands, the right place to override them is xymon-rpm.
*And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.*
*Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other.
*One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change.
I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong.
Bruno
Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-client
Version : 4.3.31
Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9
Architecture : x86_64
Size : 1.0 M
Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm
Repository : @System
From repo : puppet-xymon-snapshot
Summary : Client for the Xymon network monitor
URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com
*From:*Bruno Manzoni via Xymon <xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server. 1.On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. 2.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (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 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 toxymon-leave@xymon.com
Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-leave@xymon.com
I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes.
Ralph Mitchell
On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Scot,
Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what.
Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging.
For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't.
Bruno
Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :
*Confirmed. You *😎* are the first one, you make my day* 😮!
So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.*
*Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later.
*It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first.
Until that lands, the right place to override them is xymon-rpm.
*And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.*
*Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other.
*One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change.
I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong.
Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-client
Version : 4.3.31
Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9
Architecture : x86_64
Size : 1.0 M
Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm
Repository : @System
From repo : puppet-xymon-snapshot
Summary : Client for the Xymon network monitor
URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com
*From:* Bruno Manzoni via Xymon <xymon@xymon.com> <xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server.
On the client rpm install /etc/xymon-client/clientlaunch.d isnot created. It should be, Debian already creates it.
On the server rpm install, it places the httpd config for xymonbut doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (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]
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
Hi Ralph,
That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too.
Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away.
Both will need a second pair of eyes, and yours are on real RHEL.
Cheers, Bruno
Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :
I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes.
Ralph Mitchell
On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Scot, Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what. Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging. For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't. Bruno Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :*Confirmed. You *😎* are the first one, you make my day* 😮! So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.* *Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later. *It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first. Until that lands, the right place to override them is xymon-rpm. *And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.* *Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other. *One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change. I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong. Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :Hi Bruno, I most certainly did. 😊 Name : xymon-client Version : 4.3.31 Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9 Architecture : x86_64 Size : 1.0 M Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm Repository : @System From repo : puppet-xymon-snapshot Summary : Client for the Xymon network monitor URL : https://github.com/xymon-monitoring/xymon The two pull requests I opened add the directory create and httpd reload into the xymon.spec. I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually. * * *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com *From:*Bruno Manzoni via Xymon <xymon@xymon.com> <mailto:xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <mailto:bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback Hi Scot, This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you. Just some info on your 2 points: > On the client rpm install /etc/xymon-client/clientlaunch.d is not > created. It should be, Debian already creates it. Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream. > On the server rpm install, it places the httpd config for xymon but > doesn't signal httpd to reload configs. That scenario is a little less > clear-cut as to whether it should be automatic. My opinion is that it > should be. I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out. Cheers, Bruno Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit : Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server. 1.On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. 2.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (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 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 toxymon-leave@xymon.com_______________________________________________ Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-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
Bruno,
Some notes on the RHEL9 build: Packager: RHEL9.8 (Plow) Snapshot: xymon-4.3.31-0.20260914git8405d61.202609152222p0082a72.el9.src.rpm
I installed the above source RPM, which dropped off the SPEC file, the tarball and several other files under $HOME/rpmbuild. After the usual folderol of installing necessary devel packages, the build went well. I saw a few compiler warnings, but it still completed successfully.
I installed the main xymon package and a web server, started them both and sat back. Several minutes later a browser showed the toplevel page with the server itself. I made a few common adjustments to the configuration, adding in a couple of process & port tests.
I also added several client machines that are mostly running the Terebithia 4.3.30 packages:
dell7050: RHEL10.2 with the EL9 4.3.0 client elitedesk2: Ubuntu 24.04 gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64 lenovo1: RHEL9.8 with EL9 4.3.0 client lenovo2: RHEL9.8 with EL9 4.3.0 client win10: Windows 10 with the Powershell client
The above clients report to both the new snapshot as well as the older 4.3.30 Xymon on a different server.
I also have the snapshot testing https by pointing it to https://www.xymon.com/
Ralph Mitchell
On Tue, Sep 15, 2026 at 5:50 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Ralph,
That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too.
Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away.
Both will need a second pair of eyes, and yours are on real RHEL.
Cheers, Bruno Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :
I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes.
Ralph Mitchell
On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Scot,
Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what.
Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging.
For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't.
Bruno
Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :
*Confirmed. You *😎* are the first one, you make my day* 😮!
So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.*
*Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later.
*It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first.
Until that lands, the right place to override them is xymon-rpm.
*And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.*
*Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other.
*One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change.
I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong.
Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-client
Version : 4.3.31
Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9
Architecture : x86_64
Size : 1.0 M
Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm
Repository : @System
From repo : puppet-xymon-snapshot
Summary : Client for the Xymon network monitor
URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 | 1-734-915-1444 <(734)%20915-1444> | Scot.Kreienkamp@la-z-boy.com
*From:* Bruno Manzoni via Xymon <xymon@xymon.com> <xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server.
On the client rpm install /etc/xymon-client/clientlaunch.d isnot created. It should be, Debian already creates it.
On the server rpm install, it places the httpd config for xymonbut doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 | 1-734-915-1444 <(734)%20915-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]
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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Tip Top Ralph!
This is the first report we have from genuine RHEL. CI only builds AlmaLinux and Fedora containers, so a run on 9.8 with real clients attached shows us what we cannot see here.
Worth naming: rebuilding from the source rpm exercises the spec. Our published binaries, their signatures, the repository metadata and the install scriptlets are a separate thing, and they are what a user actually installs.
And I think I know why you took the source route. The install instructions were wrong (I will update them now) in a way that would have sent anyone there:
- there has been no release yet, so the stable channel the .repo file enables is empty. It answers, correctly, and holds no package. dnf reports no match and nothing explains it. - the snapshot channel, which is where every build goes, ships disabled. - the sentence saying so sat four paragraphs below the commands.
That is fixed (just now). On the 9.8 host, as root, the whole sequence is:
dnf install epel-release # for fping; Xymon is not in EPEL dnf install dnf-plugins-core # provides config-manager on EL
curl -o /etc/yum.repos.d/xymon.repo
https://xymon-monitoring.github.io/xymon-rpm/xymon.repo
dnf config-manager --set-enabled xymon-snapshot
# ours (...202609160522p2f66d71) sorts above your build # (...202609152222p0082a72), so either of these replaces it rather # than colliding with it dnf install xymon # on a host with nothing installed dnf upgrade xymon # on the one you built by hand
dnf will offer the signing key the first time. It should be
BD24 FB87 154D 561B 66F6 66DF 639D E923 AA08 904A
and afterwards this should name it rather than print (none):
rpm -q --qf '%{RSAHEADER:pgpsig}\n' xymon
One more reason to take the published packages: the build you made does not have the client's drop-in directories. clientlaunch.cfg and xymonclient.cfg each end in "optional directory .../clientlaunch.d" and ".../xymonclient.d", nothing created either, and optional means a missing one is skipped without a word — a file dropped in is simply never read. Scot ran into that; the spec creates them now, so an install from the repository has them (just fixed now) and your rebuild does not. On the build you are running, by hand:
mkdir -p /etc/xymon-client/clientlaunch.d /etc/xymon-client/xymonclient.d
If you have the time, the sequence above would help — replacing your build with the published one. That is what a user gets, and nobody has reported doing it on RHEL.
Bruno
Le 16.09.2026 à 06:56, Ralph M a écrit :
Bruno,
Some notes on the RHEL9 build: Packager: RHEL9.8 (Plow) Snapshot: xymon-4.3.31-0.20260914git8405d61.202609152222p0082a72.el9.src.rpm
I installed the above source RPM, which dropped off the SPEC file, the tarball and several other files under $HOME/rpmbuild. After the usual folderol of installing necessary devel packages, the build went well. I saw a few compiler warnings, but it still completed successfully.
I installed the main xymon package and a web server, started them both and sat back. Several minutes later a browser showed the toplevel page with the server itself. I made a few common adjustments to the configuration, adding in a couple of process & port tests.
I also added several client machines that are mostly running the Terebithia 4.3.30 packages:
dell7050: RHEL10.2 with the EL9 4.3.0 client elitedesk2: Ubuntu 24.04 gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64 lenovo1: RHEL9.8 with EL9 4.3.0 client lenovo2: RHEL9.8 with EL9 4.3.0 client win10: Windows 10 with the Powershell client
The above clients report to both the new snapshot as well as the older 4.3.30 Xymon on a different server.
I also have the snapshot testing https by pointing it to https://www.xymon.com/
Ralph Mitchell
On Tue, Sep 15, 2026 at 5:50 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Ralph, That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too. Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away. Both will need a second pair of eyes, and yours are on real RHEL. Cheers, Bruno Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes. Ralph Mitchell On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote: Hi Scot, Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what. Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging. For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't. Bruno Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :*Confirmed. You *😎* are the first one, you make my day* 😮! So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.* *Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later. *It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first. Until that lands, the right place to override them is xymon-rpm. *And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.* *Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other. *One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change. I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong. Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :Hi Bruno, I most certainly did. 😊 Name : xymon-client Version : 4.3.31 Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9 Architecture : x86_64 Size : 1.0 M Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm Repository : @System From repo : puppet-xymon-snapshot Summary : Client for the Xymon network monitor URL : https://github.com/xymon-monitoring/xymon The two pull requests I opened add the directory create and httpd reload into the xymon.spec. I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually. * * *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 <tel:(734)%20384-6403> | 1-734-915-1444 <tel:(734)%20915-1444> | Scot.Kreienkamp@la-z-boy.com *From:*Bruno Manzoni via Xymon <xymon@xymon.com> <mailto:xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <mailto:bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback Hi Scot, This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you. Just some info on your 2 points: > On the client rpm install /etc/xymon-client/clientlaunch.d is not > created. It should be, Debian already creates it. Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream. > On the server rpm install, it places the httpd config for xymon but > doesn't signal httpd to reload configs. That scenario is a little less > clear-cut as to whether it should be automatic. My opinion is that it > should be. I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out. Cheers, Bruno Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit : Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server. 1.On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. 2.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 <tel:(734)%20384-6403> | 1-734-915-1444 <tel:(734)%20915-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 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 toxymon-leave@xymon.com_______________________________________________ Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-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_______________________________________________ Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
The install procedure for the RPM packages is in the repository README:
https://github.com/xymon-monitoring/xymon-rpm#installing
There are three, because they differ: snapshots on EL 9 and 10, snapshots on Fedora, and releases once there is one. There has been no release yet, so the snapshot channel is the one to enable today -- the repo file ships it disabled.
Each was run in a container against the live repository before being written down: AlmaLinux 9 and 10, Fedora 43, server and client-only.
Still highly experimental: new packaging, no production use, and the layout and versioning may change.
Bruno
Le 16.09.2026 à 09:01, Bruno Manzoni via Xymon a écrit :
Tip Top Ralph!
This is the first report we have from genuine RHEL. CI only builds AlmaLinux and Fedora containers, so a run on 9.8 with real clients attached shows us what we cannot see here.
Worth naming: rebuilding from the source rpm exercises the spec. Our published binaries, their signatures, the repository metadata and the install scriptlets are a separate thing, and they are what a user actually installs.
And I think I know why you took the source route. The install instructions were wrong (I will update them now) in a way that would have sent anyone there:
- there has been no release yet, so the stable channel the .repo file enables is empty. It answers, correctly, and holds no package. dnf reports no match and nothing explains it. - the snapshot channel, which is where every build goes, ships disabled. - the sentence saying so sat four paragraphs below the commands.
That is fixed (just now). On the 9.8 host, as root, the whole sequence is:
dnf install epel-release # for fping; Xymon is not in EPEL dnf install dnf-plugins-core # provides config-manager on EL
curl -o /etc/yum.repos.d/xymon.repo
https://xymon-monitoring.github.io/xymon-rpm/xymon.repo dnf config-manager --set-enabled xymon-snapshot# ours (...202609160522p2f66d71) sorts above your build # (...202609152222p0082a72), so either of these replaces it rather # than colliding with it dnf install xymon # on a host with nothing installed dnf upgrade xymon # on the one you built by hand
dnf will offer the signing key the first time. It should be
BD24 FB87 154D 561B 66F6 66DF 639D E923 AA08 904A
and afterwards this should name it rather than print (none):
rpm -q --qf '%{RSAHEADER:pgpsig}\n' xymon
One more reason to take the published packages: the build you made does not have the client's drop-in directories. clientlaunch.cfg and xymonclient.cfg each end in "optional directory .../clientlaunch.d" and ".../xymonclient.d", nothing created either, and optional means a missing one is skipped without a word — a file dropped in is simply never read. Scot ran into that; the spec creates them now, so an install from the repository has them (just fixed now) and your rebuild does not. On the build you are running, by hand:
mkdir -p /etc/xymon-client/clientlaunch.d /etc/xymon-client/xymonclient.d
If you have the time, the sequence above would help — replacing your build with the published one. That is what a user gets, and nobody has reported doing it on RHEL.
Bruno
Le 16.09.2026 à 06:56, Ralph M a écrit :
Bruno,
Some notes on the RHEL9 build: Packager: RHEL9.8 (Plow) Snapshot: xymon-4.3.31-0.20260914git8405d61.202609152222p0082a72.el9.src.rpm
I installed the above source RPM, which dropped off the SPEC file, the tarball and several other files under $HOME/rpmbuild. After the usual folderol of installing necessary devel packages, the build went well. I saw a few compiler warnings, but it still completed successfully.
I installed the main xymon package and a web server, started them both and sat back. Several minutes later a browser showed the toplevel page with the server itself. I made a few common adjustments to the configuration, adding in a couple of process & port tests.
I also added several client machines that are mostly running the Terebithia 4.3.30 packages:
dell7050: RHEL10.2 with the EL9 4.3.0 client elitedesk2: Ubuntu 24.04 gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64 lenovo1: RHEL9.8 with EL9 4.3.0 client lenovo2: RHEL9.8 with EL9 4.3.0 client win10: Windows 10 with the Powershell client
The above clients report to both the new snapshot as well as the older 4.3.30 Xymon on a different server.
I also have the snapshot testing https by pointing it to https://www.xymon.com/
Ralph Mitchell
On Tue, Sep 15, 2026 at 5:50 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Ralph, That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too. Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away. Both will need a second pair of eyes, and yours are on real RHEL. Cheers, Bruno Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes. Ralph Mitchell On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote: Hi Scot, Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what. Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging. For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't. Bruno Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :*Confirmed. You *😎* are the first one, you make my day* 😮! So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.* *Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later. *It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first. Until that lands, the right place to override them is xymon-rpm. *And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.* *Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other. *One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change. I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong. Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :Hi Bruno, I most certainly did. 😊 Name : xymon-client Version : 4.3.31 Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9 Architecture : x86_64 Size : 1.0 M Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm Repository : @System From repo : puppet-xymon-snapshot Summary : Client for the Xymon network monitor URL : https://github.com/xymon-monitoring/xymon The two pull requests I opened add the directory create and httpd reload into the xymon.spec. I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually. * * *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 <tel:(734)%20384-6403> | 1-734-915-1444 <tel:(734)%20915-1444> | Scot.Kreienkamp@la-z-boy.com *From:*Bruno Manzoni via Xymon <xymon@xymon.com> <mailto:xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <mailto:bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback Hi Scot, This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you. Just some info on your 2 points: > On the client rpm install /etc/xymon-client/clientlaunch.d is not > created. It should be, Debian already creates it. Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream. > On the server rpm install, it places the httpd config for xymon but > doesn't signal httpd to reload configs. That scenario is a little less > clear-cut as to whether it should be automatic. My opinion is that it > should be. I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out. Cheers, Bruno Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit : Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server. 1.On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. 2.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 <tel:(734)%20384-6403> | 1-734-915-1444 <tel:(734)%20915-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 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 toxymon-leave@xymon.com_______________________________________________ Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-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_______________________________________________ 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
Bruno,
You're right, I got bogged down with the install instructions, so I fetched the source RPM knowing that it would contain a working SPEC file to build all the binary packages. I'll take another look this evening.
Did you actually want to test the build process on RHEL9, or just the pre-built binaries? I'm happy to go either way.
Ralph Mitchell
On Wed, Sep 16, 2026 at 3:38 AM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
The install procedure for the RPM packages is in the repository README:
https://github.com/xymon-monitoring/xymon-rpm#installingThere are three, because they differ: snapshots on EL 9 and 10, snapshots on Fedora, and releases once there is one. There has been no release yet, so the snapshot channel is the one to enable today -- the repo file ships it disabled.
Each was run in a container against the live repository before being written down: AlmaLinux 9 and 10, Fedora 43, server and client-only.
Still highly experimental: new packaging, no production use, and the layout and versioning may change.
Bruno
Le 16.09.2026 à 09:01, Bruno Manzoni via Xymon a écrit :
Tip Top Ralph!
This is the first report we have from genuine RHEL. CI only builds AlmaLinux and Fedora containers, so a run on 9.8 with real clients attached shows us what we cannot see here.
Worth naming: rebuilding from the source rpm exercises the spec. Our published binaries, their signatures, the repository metadata and the install scriptlets are a separate thing, and they are what a user actually installs.
And I think I know why you took the source route. The install instructions were wrong (I will update them now) in a way that would have sent anyone there:
- there has been no release yet, so the stable channel the .repo file enables is empty. It answers, correctly, and holds no package. dnf reports no match and nothing explains it.
- the snapshot channel, which is where every build goes, ships disabled.
- the sentence saying so sat four paragraphs below the commands.
That is fixed (just now). On the 9.8 host, as root, the whole sequence is:
dnf install epel-release # for fping; Xymon is not in EPEL dnf install dnf-plugins-core # provides config-manager on EL curl -o /etc/yum.repos.d/xymon.repo \ https://xymon-monitoring.github.io/xymon-rpm/xymon.repo dnf config-manager --set-enabled xymon-snapshot # ours (...202609160522p2f66d71) sorts above your build # (...202609152222p0082a72), so either of these replaces it rather # than colliding with it dnf install xymon # on a host with nothing installed dnf upgrade xymon # on the one you built by handdnf will offer the signing key the first time. It should be
BD24 FB87 154D 561B 66F6 66DF 639D E923 AA08 904Aand afterwards this should name it rather than print (none):
rpm -q --qf '%{RSAHEADER:pgpsig}\n' xymonOne more reason to take the published packages: the build you made does not have the client's drop-in directories. clientlaunch.cfg and xymonclient.cfg each end in "optional directory .../clientlaunch.d" and ".../xymonclient.d", nothing created either, and optional means a missing one is skipped without a word — a file dropped in is simply never read. Scot ran into that; the spec creates them now, so an install from the repository has them (just fixed now) and your rebuild does not. On the build you are running, by hand:
mkdir -p /etc/xymon-client/clientlaunch.d/etc/xymon-client/xymonclient.d
If you have the time, the sequence above would help — replacing your build with the published one. That is what a user gets, and nobody has reported doing it on RHEL.
Bruno
Le 16.09.2026 à 06:56, Ralph M a écrit :
Bruno,
Some notes on the RHEL9 build: Packager: RHEL9.8 (Plow) Snapshot: xymon-4.3.31-0.20260914git8405d61.202609152222p0082a72.el9.src.rpm
I installed the above source RPM, which dropped off the SPEC file, the tarball and several other files under $HOME/rpmbuild. After the usual folderol of installing necessary devel packages, the build went well. I saw a few compiler warnings, but it still completed successfully.
I installed the main xymon package and a web server, started them both and sat back. Several minutes later a browser showed the toplevel page with the server itself. I made a few common adjustments to the configuration, adding in a couple of process & port tests.
I also added several client machines that are mostly running the Terebithia 4.3.30 packages:
dell7050: RHEL10.2 with the EL9 4.3.0 client elitedesk2: Ubuntu 24.04 gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64 lenovo1: RHEL9.8 with EL9 4.3.0 client lenovo2: RHEL9.8 with EL9 4.3.0 client win10: Windows 10 with the Powershell client
The above clients report to both the new snapshot as well as the older 4.3.30 Xymon on a different server.
I also have the snapshot testing https by pointing it to https://www.xymon.com/
Ralph Mitchell
On Tue, Sep 15, 2026 at 5:50 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Ralph,
That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too.
Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away.
Both will need a second pair of eyes, and yours are on real RHEL.
Cheers, Bruno Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :
I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes.
Ralph Mitchell
On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Scot,
Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what.
Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging.
For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't.
Bruno
Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :
*Confirmed. You *😎* are the first one, you make my day* 😮!
So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.*
*Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later.
*It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first.
Until that lands, the right place to override them is xymon-rpm.
*And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.*
*Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other.
*One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change.
I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong.
Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-client
Version : 4.3.31
Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9
Architecture : x86_64
Size : 1.0 M
Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm
Repository : @System
From repo : puppet-xymon-snapshot
Summary : Client for the Xymon network monitor
URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 <(734)%20384-6403> | 1-734-915-1444 <(734)%20915-1444> | Scot.Kreienkamp@la-z-boy.com
*From:* Bruno Manzoni via Xymon <xymon@xymon.com> <xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server.
On the client rpm install /etc/xymon-client/clientlaunch.d isnot created. It should be, Debian already creates it.
On the server rpm install, it places the httpd config forxymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 <(734)%20384-6403> | 1-734-915-1444 <(734)%20915-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]
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
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
Hi Ralph, Scot, Jeremy, and all other Terabithia users,
I think |xymon-rpm| has been compiling correctly for quite some time now, as this is something we addressed as early as possible. Getting the RPM package itself right is another beast, though. It still needs the correct installation instructions and so on—that's the first important point, and your validation would be very useful.
When analysing all the commits of Terabithia, I did find that Terabithia has "advanced build features" compared to Debian and FreeBSD: mainly around build flexibility and better use of native OS capabilities. Now, those features are also becoming available on more and more OSes, so it makes sense to include some of them upstream.
But that's not all: |xymon-rpm| has unique features. The current |xymon-rpm| base was constructed after analysing how to make something close to the existing packaging and what is now possible. I'm not sure whether this is implemented on any other OS; it doesn't seem so to me.
Autobuild snapshots on main Xymon branch updates. (This allows
someone to install the latest features and fixes and test them easily.)*
Swap feature: you will be able to swap between client and server
(the server also having a client: this creates a conflict if we want
to be able to keep the configuration of both and swap and revert
easily without losing either configuration). I implemented it
because I like the idea (not sure it is really working yet: at least
the DNF swap commands work!).Some features are already in: I just hardened the RPMs (Fortify) yesterday, as Roland validated a PR that now allows us to do that.
The priority is to have a working package that runs out of the box as easily as Terabithia, so we can provide a solid alternative for Terabithia/RHEL users with 4.3.31. The gap seems reasonable, and the Xymon base seems to be in very good shape.
I've integrated many of the Terabithia build improvements into upstream PRs under the 4.3.31 milestone. Most are finished on my side and now need review. Other packagers should ideally be involved to ensure that the changes don't cause issues on their platforms. At some point, I cannot push the feature porting further if some critical ones are missing, as some features provide the base for new ones ("new" meaning from Terabithia).
If someone with RHEL/RPM experience can help, we could focus on the priority PRs first, as there seem to be quite a lot of differences between platforms. These are mainly the PRs I mentioned—#411 is one of them. For now, I've duplicated the fix downstream in |xymon-rpm|. So when you encounter a problem, maybe a feature or fix already exists!
We can still override features in the RPM packaging if they aren't validated upstream in time, but I'd prefer to avoid duplication and keep these improvements upstream so that other platforms can benefit as well.
The immediate goal is therefore simple: make sure the package installs and works correctly, then validate the key PRs needed for 4.3.31.
Also, I haven't really pushed for any particular policy regarding |xymon-rpm|. What should or shouldn't be included is still an open question for me, and input from experienced RHEL users would definitely be valuable. But at some point, this is something that will stay in |xymon-rpm|, and my priority is more to fix what should be in Xymon upstream, as those policies do not conflict with any other packager and are probably easier to add later (of course, it can be convenient to have them as well).
This does not change the planned release date, which is still mid-October.
Bruno
Le 16.09.2026 à 16:55, Ralph M via Xymon a écrit :
Bruno,
You're right, I got bogged down with the install instructions, so I fetched the source RPM knowing that it would contain a working SPEC file to build all the binary packages. I'll take another look this evening.
Did you actually want to test the build process on RHEL9, or just the pre-built binaries? I'm happy to go either way.
Ralph Mitchell
On Wed, Sep 16, 2026 at 3:38 AM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
The install procedure for the RPM packages is in the repository README: https://github.com/xymon-monitoring/xymon-rpm#installing There are three, because they differ: snapshots on EL 9 and 10, snapshots on Fedora, and releases once there is one. There has been no release yet, so the snapshot channel is the one to enable today -- the repo file ships it disabled. Each was run in a container against the live repository before being written down: AlmaLinux 9 and 10, Fedora 43, server and client-only. Still highly experimental: new packaging, no production use, and the layout and versioning may change. Bruno Le 16.09.2026 à 09:01, Bruno Manzoni via Xymon a écrit :Tip Top Ralph! This is the first report we have from genuine RHEL. CI only builds AlmaLinux and Fedora containers, so a run on 9.8 with real clients attached shows us what we cannot see here. Worth naming: rebuilding from the source rpm exercises the spec. Our published binaries, their signatures, the repository metadata and the install scriptlets are a separate thing, and they are what a user actually installs. And I think I know why you took the source route. The install instructions were wrong (I will update them now) in a way that would have sent anyone there: - there has been no release yet, so the stable channel the .repo file enables is empty. It answers, correctly, and holds no package. dnf reports no match and nothing explains it. - the snapshot channel, which is where every build goes, ships disabled. - the sentence saying so sat four paragraphs below the commands. That is fixed (just now). On the 9.8 host, as root, the whole sequence is: dnf install epel-release # for fping; Xymon is not in EPEL dnf install dnf-plugins-core # provides config-manager on EL curl -o /etc/yum.repos.d/xymon.repo \ https://xymon-monitoring.github.io/xymon-rpm/xymon.repo dnf config-manager --set-enabled xymon-snapshot # ours (...202609160522p2f66d71) sorts above your build # (...202609152222p0082a72), so either of these replaces it rather # than colliding with it dnf install xymon # on a host with nothing installed dnf upgrade xymon # on the one you built by hand dnf will offer the signing key the first time. It should be BD24 FB87 154D 561B 66F6 66DF 639D E923 AA08 904A and afterwards this should name it rather than print (none): rpm -q --qf '%{RSAHEADER:pgpsig}\n' xymon One more reason to take the published packages: the build you made does not have the client's drop-in directories. clientlaunch.cfg and xymonclient.cfg each end in "optional directory .../clientlaunch.d" and ".../xymonclient.d", nothing created either, and optional means a missing one is skipped without a word — a file dropped in is simply never read. Scot ran into that; the spec creates them now, so an install from the repository has them (just fixed now) and your rebuild does not. On the build you are running, by hand: mkdir -p /etc/xymon-client/clientlaunch.d /etc/xymon-client/xymonclient.d If you have the time, the sequence above would help — replacing your build with the published one. That is what a user gets, and nobody has reported doing it on RHEL. Bruno Le 16.09.2026 à 06:56, Ralph M a écrit :Bruno, Some notes on the RHEL9 build: Packager: RHEL9.8 (Plow) Snapshot: xymon-4.3.31-0.20260914git8405d61.202609152222p0082a72.el9.src.rpm I installed the above source RPM, which dropped off the SPEC file, the tarball and several other files under $HOME/rpmbuild. After the usual folderol of installing necessary devel packages, the build went well. I saw a few compiler warnings, but it still completed successfully. I installed the main xymon package and a web server, started them both and sat back. Several minutes later a browser showed the toplevel page with the server itself. I made a few common adjustments to the configuration, adding in a couple of process & port tests. I also added several client machines that are mostly running the Terebithia 4.3.30 packages: dell7050: RHEL10.2 with the EL9 4.3.0 client elitedesk2: Ubuntu 24.04 gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64 lenovo1: RHEL9.8 with EL9 4.3.0 client lenovo2: RHEL9.8 with EL9 4.3.0 client win10: Windows 10 with the Powershell client The above clients report to both the new snapshot as well as the older 4.3.30 Xymon on a different server. I also have the snapshot testing https by pointing it to https://www.xymon.com/ Ralph Mitchell On Tue, Sep 15, 2026 at 5:50 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote: Hi Ralph, That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too. Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away. Both will need a second pair of eyes, and yours are on real RHEL. Cheers, Bruno Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes. Ralph Mitchell On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote: Hi Scot, Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what. Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging. For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't. Bruno Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :*Confirmed. You *😎* are the first one, you make my day* 😮! So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.* *Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later. *It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first. Until that lands, the right place to override them is xymon-rpm. *And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.* *Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other. *One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change. I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong. Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :Hi Bruno, I most certainly did. 😊 Name : xymon-client Version : 4.3.31 Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9 Architecture : x86_64 Size : 1.0 M Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm Repository : @System From repo : puppet-xymon-snapshot Summary : Client for the Xymon network monitor URL : https://github.com/xymon-monitoring/xymon The two pull requests I opened add the directory create and httpd reload into the xymon.spec. I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually. * * *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 <tel:(734)%20384-6403> | 1-734-915-1444 <tel:(734)%20915-1444> | Scot.Kreienkamp@la-z-boy.com *From:*Bruno Manzoni via Xymon <xymon@xymon.com> <mailto:xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <mailto:bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback Hi Scot, This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you. Just some info on your 2 points: > On the client rpm install /etc/xymon-client/clientlaunch.d is not > created. It should be, Debian already creates it. Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream. > On the server rpm install, it places the httpd config for xymon but > doesn't signal httpd to reload configs. That scenario is a little less > clear-cut as to whether it should be automatic. My opinion is that it > should be. I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out. Cheers, Bruno Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit : Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server. 1.On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it. 2.On the server rpm install, it places the httpd config for xymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be. I opened pull requests for both changes. *Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 <tel:(734)%20384-6403> | 1-734-915-1444 <tel:(734)%20915-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 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 toxymon-leave@xymon.com_______________________________________________ Xymon mailing list --xymon@xymon.com To unsubscribe send an email toxymon-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_______________________________________________ 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_______________________________________________ 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
Hi Bruno, I add my voice to the praises for your work on Xymon in the last
year.
I used RedHat at work and Debian as my main home OS in my past life, and
what I noticed is that Debian does restart/reload daemons when updating,
while RedHat never did, and I assumed that was a difference due to the
latter aiming to be more "enterprise" and less prone to surprises: should
we keep it that way?
Debian has a --no-restart parameter which can be used to avoid it, so
that may be the reason it has that default: are we respecting it?
Nicola
Il giorno mer 16 set 2026 alle ore 21:22 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
Hi Ralph, Scot, Jeremy, and all other Terabithia users,
I think xymon-rpm has been compiling correctly for quite some time now, as this is something we addressed as early as possible. Getting the RPM package itself right is another beast, though. It still needs the correct installation instructions and so on—that's the first important point, and your validation would be very useful.
When analysing all the commits of Terabithia, I did find that Terabithia has "advanced build features" compared to Debian and FreeBSD: mainly around build flexibility and better use of native OS capabilities. Now, those features are also becoming available on more and more OSes, so it makes sense to include some of them upstream.
But that's not all: xymon-rpm has unique features. The current xymon-rpm base was constructed after analysing how to make something close to the existing packaging and what is now possible. I'm not sure whether this is implemented on any other OS; it doesn't seem so to me.
Autobuild snapshots on main Xymon branch updates. (This allows someone to install the latest features and fixes and test them easily.)
Swap feature: you will be able to swap between client and server (the server also having a client: this creates a conflict if we want to be able to keep the configuration of both and swap and revert easily without losing either configuration). I implemented it because I like the idea (not sure it is really working yet: at least the DNF swap commands work!).
Some features are already in: I just hardened the RPMs (Fortify) yesterday, as Roland validated a PR that now allows us to do that.
The priority is to have a working package that runs out of the box as easily as Terabithia, so we can provide a solid alternative for Terabithia/RHEL users with 4.3.31. The gap seems reasonable, and the Xymon base seems to be in very good shape.
I've integrated many of the Terabithia build improvements into upstream PRs under the 4.3.31 milestone. Most are finished on my side and now need review. Other packagers should ideally be involved to ensure that the changes don't cause issues on their platforms. At some point, I cannot push the feature porting further if some critical ones are missing, as some features provide the base for new ones ("new" meaning from Terabithia).
If someone with RHEL/RPM experience can help, we could focus on the priority PRs first, as there seem to be quite a lot of differences between platforms. These are mainly the PRs I mentioned—#411 is one of them. For now, I've duplicated the fix downstream in xymon-rpm. So when you encounter a problem, maybe a feature or fix already exists!
We can still override features in the RPM packaging if they aren't validated upstream in time, but I'd prefer to avoid duplication and keep these improvements upstream so that other platforms can benefit as well.
The immediate goal is therefore simple: make sure the package installs and works correctly, then validate the key PRs needed for 4.3.31.
Also, I haven't really pushed for any particular policy regarding xymon-rpm. What should or shouldn't be included is still an open question for me, and input from experienced RHEL users would definitely be valuable. But at some point, this is something that will stay in xymon-rpm, and my priority is more to fix what should be in Xymon upstream, as those policies do not conflict with any other packager and are probably easier to add later (of course, it can be convenient to have them as well).
This does not change the planned release date, which is still mid-October.
Bruno
Le 16.09.2026 à 16:55, Ralph M via Xymon a écrit :
Bruno,
You're right, I got bogged down with the install instructions, so I fetched the source RPM knowing that it would contain a working SPEC file to build all the binary packages. I'll take another look this evening.
Did you actually want to test the build process on RHEL9, or just the pre-built binaries? I'm happy to go either way.
Ralph Mitchell
On Wed, Sep 16, 2026 at 3:38 AM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
The install procedure for the RPM packages is in the repository README:
https://github.com/xymon-monitoring/xymon-rpm#installingThere are three, because they differ: snapshots on EL 9 and 10, snapshots on Fedora, and releases once there is one. There has been no release yet, so the snapshot channel is the one to enable today -- the repo file ships it disabled.
Each was run in a container against the live repository before being written down: AlmaLinux 9 and 10, Fedora 43, server and client-only.
Still highly experimental: new packaging, no production use, and the layout and versioning may change.
Bruno
Le 16.09.2026 à 09:01, Bruno Manzoni via Xymon a écrit :
Tip Top Ralph!
This is the first report we have from genuine RHEL. CI only builds AlmaLinux and Fedora containers, so a run on 9.8 with real clients attached shows us what we cannot see here.
Worth naming: rebuilding from the source rpm exercises the spec. Our published binaries, their signatures, the repository metadata and the install scriptlets are a separate thing, and they are what a user actually installs.
And I think I know why you took the source route. The install instructions were wrong (I will update them now) in a way that would have sent anyone there:
- there has been no release yet, so the stable channel the .repo file enables is empty. It answers, correctly, and holds no package. dnf reports no match and nothing explains it.
- the snapshot channel, which is where every build goes, ships disabled.
- the sentence saying so sat four paragraphs below the commands.
That is fixed (just now). On the 9.8 host, as root, the whole sequence is:
dnf install epel-release # for fping; Xymon is not in EPEL dnf install dnf-plugins-core # provides config-manager on EL curl -o /etc/yum.repos.d/xymon.repo \ https://xymon-monitoring.github.io/xymon-rpm/xymon.repo dnf config-manager --set-enabled xymon-snapshot # ours (...202609160522p2f66d71) sorts above your build # (...202609152222p0082a72), so either of these replaces it rather # than colliding with it dnf install xymon # on a host with nothing installed dnf upgrade xymon # on the one you built by handdnf will offer the signing key the first time. It should be
BD24 FB87 154D 561B 66F6 66DF 639D E923 AA08 904Aand afterwards this should name it rather than print (none):
rpm -q --qf '%{RSAHEADER:pgpsig}\n' xymonOne more reason to take the published packages: the build you made does not have the client's drop-in directories. clientlaunch.cfg and xymonclient.cfg each end in "optional directory .../clientlaunch.d" and ".../xymonclient.d", nothing created either, and optional means a missing one is skipped without a word — a file dropped in is simply never read. Scot ran into that; the spec creates them now, so an install from the repository has them (just fixed now) and your rebuild does not. On the build you are running, by hand:
mkdir -p /etc/xymon-client/clientlaunch.d/etc/xymon-client/xymonclient.d
If you have the time, the sequence above would help — replacing your build with the published one. That is what a user gets, and nobody has reported doing it on RHEL.
Bruno
Le 16.09.2026 à 06:56, Ralph M a écrit :
Bruno,
Some notes on the RHEL9 build: Packager: RHEL9.8 (Plow) Snapshot: xymon-4.3.31-0.20260914git8405d61.202609152222p0082a72.el9.src.rpm
I installed the above source RPM, which dropped off the SPEC file, the tarball and several other files under $HOME/rpmbuild. After the usual folderol of installing necessary devel packages, the build went well. I saw a few compiler warnings, but it still completed successfully.
I installed the main xymon package and a web server, started them both and sat back. Several minutes later a browser showed the toplevel page with the server itself. I made a few common adjustments to the configuration, adding in a couple of process & port tests.
I also added several client machines that are mostly running the Terebithia 4.3.30 packages:
dell7050: RHEL10.2 with the EL9 4.3.0 client elitedesk2: Ubuntu 24.04 gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64 lenovo1: RHEL9.8 with EL9 4.3.0 client lenovo2: RHEL9.8 with EL9 4.3.0 client win10: Windows 10 with the Powershell client
The above clients report to both the new snapshot as well as the older 4.3.30 Xymon on a different server.
I also have the snapshot testing https by pointing it to https://www.xymon.com/
Ralph Mitchell
On Tue, Sep 15, 2026 at 5:50 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Ralph,
That is excellent news, thank you — a source build on genuine RHEL9 is something I cannot test myself, and you can hold it against an install that has been running for years, which I cannot do either. A client talking to a 4.3.30 server is a good cross-version check on top. The server half is the one still untested, so that would be great too.
Since then Scot hit two bugs on the RPMs: /etc/xymon-client/clientlaunch.d is never created (only Debian's own packaging makes it), and httpd is not reloaded after the Apache config is installed. His pull requests patch the old rpm/xymon.spec in the source tree; I have told him both belong in xymon-rpm and asked whether he or I take them. I do not take over anyone's work without their agreement, so the fixes stay with him until he answers. I take PR #411, which makes the build create those directories itself; then the packaging override can go away.
Both will need a second pair of eyes, and yours are on real RHEL.
Cheers, Bruno Le 15.09.2026 à 22:38, Ralph M via Xymon a écrit :
I just compiled the latest 4.3.31 snapshot on RHEL9. Runs fine as a client, talking to 4.3.30. I'll set up a server later and see how that goes.
Ralph Mitchell
On Tue, Sep 15, 2026, 3:39 PM Bruno Manzoni via Xymon <xymon@xymon.com> wrote:
Hi Scot,
Since yesterday I restructured xymon-rpm to reduce its size— the RPM packaging for RHEL and Fedora, EL 8/9/10 plus Fedora 43/44 — without touching the packaging itself: the only change under rpm/ all day is one word in a comment. Cloning it cost 1.8 GB and now costs 45 MB, and will be down to about 1 MB once the old branch goes, so it should be quick to work with. The published rpms moved out into xymon-rpm-archive and Pages serves them from a build artifact instead. The docs are consistent with each other now, and there are written contribution rules, including which repo takes what.
Snapshot retention also changed: it counts upstream commits rather than published runs, and keeps ten instead of five, so a build now survives a busy day of packaging.
For your Puppet: the repo URL is unchanged and nothing needs doing. But the build you installed aged out just before that change landed — a pinned version will fail, ensure => latest or installed won't.
Bruno
Le 15.09.2026 à 00:04, Bruno Manzoni via Xymon a écrit :
*Confirmed. You *😎* are the first one, you make my day* 😮!
So now let me dig into your 2 problems. The rule: *upstream provides mechanism and location, downstream provides activation and policy.*
*Problem 1 *has its natural place in *upstream *repo (xymon) - the directory is declared in our own clientlaunch.cfg and the build should create it, exactly as it already does for the server's drop-in directories. But it is not only a build change: it changes what "make install" produces, so Debian and FreeBSD both have to follow it in their own packaging. That is precisely why I did not want to release 4.3.31 too early. A pure build problem annoys RPM and stops there; a packaging change means coordinating every downstream packager at once, and there is no quick way to do that. So if we release now, this is a very annoying problem that turns up later.
*It does have a home already: PR #411, which makes the client's install directories settable the way the server's are.* It does not carry clientlaunch.d and xymonclient.d today for a simple reason: #411 only relocates the directories the build already creates, and these two have never been created by anyone. But that is where they belong, and I will add them there. If I put them in for 4.3.31, Roland and Mark will have to modify their packaging — so I need to tell them first.
Until that lands, the right place to override them is xymon-rpm.
*And the old spec should be removed from the xymon repo altogether: the packaging should be able to change without anyone having to touch the source tree.*
*Problem 2 belongs directly in xymon-rpm*, and nowhere else: the service name, the init system and the policy are all distribution business. Nothing on the platform will do it for us either — I checked, httpd ships no file trigger, so the spec is the only thing that can. I can do it, or you can — and the same goes for the interim fix to problem 1. Tell me which you prefer. Either way through a pull request, so we can review each other.
*One warning if you take it: main on xymon-rpm is not protected*, so you can push straight to it. That is something we should probably change.
I built xymon-rpm on my own, with the goal of taking the best of Terabithia, Debian and FreeBSD. *Terabithia turned out to be far more advanced* than the others, and that is where a good part of the new pull requests come from — bringing its work upstream. I would really appreciate help from someone like you. I knew nothing about RPM packaging a month ago, so be indulgent: some of what I say above may well be wrong.
Bruno Le 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-client
Version : 4.3.31
Release : 0.20260903gitd004d18.202608262317p6ff6b58.el9
Architecture : x86_64
Size : 1.0 M
Source : xymon-4.3.31-0.20260903gitd004d18.202608262317p6ff6b58.el9.src.rpm
Repository : @System
From repo : puppet-xymon-snapshot
Summary : Client for the Xymon network monitor
URL : https://github.com/xymon-monitoring/xymon
The two pull requests I opened add the directory create and httpd reload into the xymon.spec.
I should hopefully know more in a few days when I get the Xymon server up and running. Working on bringing my old config over to it right now actually.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated* One La-Z-Boy Drive | Monroe, Michigan 48162 | (734) 384-6403 <(734)%20384-6403> | 1-734-915-1444 <(734)%20915-1444> | Scot.Kreienkamp@la-z-boy.com
*From:* Bruno Manzoni via Xymon <xymon@xymon.com> <xymon@xymon.com> *Sent:* Monday, September 14, 2026 4:40 PM *To:* xymon@xymon.com *Cc:* Bruno Manzoni <bruno.manzoni@ubi-network.ch> <bruno.manzoni@ubi-network.ch> *Subject:* [Xymon] Re: Snapshot feedback
Hi Scot,
This will sound like a stupid question, but: you installed our RPMs — the ones from xymon-monitoring/xymon-rpm ?? PLEASE CONFIRM — on a dozen machines? That is the first report I have from outside CI, which builds on AlmaLinux and so proves nothing about real RHEL. Thank you.
Just some info on your 2 points:
On the client rpm install /etc/xymon-client/clientlaunch.d is not created. It should be, Debian already creates it.
Debian creates it in its own packaging layer (debian/xymon-client.dirs, via dh_installdirs), not in the build. The build creates the server's drop-in directories, in xymond/Makefile, and neither of the client ones, in client/Makefile — so they are missing on RPM and in a plain source install, and I expect on FreeBSD too. Debian is the only packaging that compensates. This is a real problem to unify, and it belongs upstream.
On the server rpm install, it places the httpd config for xymon but doesn't signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I think so too, at install and uninstall time at least. Debian already reloads (invoke-rc.d apache2 reload, in its postinst) and Terabithia does a graceful, so the RPM is the odd one out.
Cheers,
Bruno
Le 14.09.2026 à 20:35, Scot Kreienkamp via Xymon a écrit :
Hey guys, just wanted to pass along some feedback on the snapshot release rpm install. I have the client deployed to about a dozen RHEL9 servers for testing, and I’m working on deploying a server.
On the client rpm install /etc/xymon-client/clientlaunch.d isnot created. It should be, Debian already creates it.
On the server rpm install, it places the httpd config forxymon but doesn’t signal httpd to reload configs. That scenario is a little less clear-cut as to whether it should be automatic. My opinion is that it should be.
I opened pull requests for both changes.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 <(734)%20384-6403> | 1-734-915-1444 <(734)%20915-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]
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
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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
participants (4)
-
Bruno Manzoni
-
Nicola
-
Ralph M
-
Scot Kreienkamp