_______________________________________________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 clientelitedesk2: Ubuntu 24.04gondor: Fedora43 with xymon-client-4.3.30-1.fc38.x86_64lenovo1: RHEL9.8 with EL9 4.3.0 clientlenovo2: RHEL9.8 with EL9 4.3.0 clientwin10: 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,
BrunoLe 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.
BrunoLe 14.09.2026 à 22:48, Scot Kreienkamp a écrit :
Hi Bruno,
I most certainly did. 😊
Name : xymon-clientVersion : 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,
BrunoLe 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
facebook.com/lazboy | instagram.com/lazboy | youtube.com/lazboy
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.comTo 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