Snapshot feedback

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

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 |  (XXX) XXX-XXXX | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid

From: Bruno Manzoni via Xymon <xymon@xymon.com>
Sent: Monday, September 14, 2026 4:40 PM
To: xymon@xymon.com
Cc: Bruno Manzoni <user-81df5df13c04@xymon.invalid>
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 | X-XXX-XXX-XXXX | user-9678697f1438@xymon.invalid
One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com
facebook.com/lazboy  | instagram.com/lazboy | youtube.com/lazboy