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