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 | 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
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.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