-----Original Message-----
From: J.C. Cleaver [mailto:user-87556346d4af@xymon.invalid] Sent: 13 March 2015 03:24
To: SebA
Cc: 'Xymon MailingList'
Subject: Re: Dependencies for xymond and xymonnet (with particular reference to JC's terabithia.org RPMs)
Hi,
Yes, in a case such as yours the main xymon server RPM is going to pull in
a few things that you don't need. Primarily, it's httpd (and whatever
httpd pulls in, such as apr and whatnot) and rrdtool (and cairo, some
display libs).
The reason httpd is a hard dependency is that some things are configured
to be owned by the apache user, and the xymon.conf apache snippet is
dropped in the directory.
Understood.
It should be safe to install xymon with --nodeps to bypass those two
packages, although you'll get some complaints as it installs. Assuming
you're running ping checks, you'll want to manually pull in 'fping'. You
can ignore net-snmp-libs if you're not going to be using
xymon-snmpcollect.
The semanage stuff from policycoreutils-python is SELinux. Aside from the
error output, it should be safe to ignore that as well.
The (mini-)server does have SELinux enabled and enforced though, so I
assumed that I would need the tools the RPM wants for configuring everything
correctly for SELinux?
Alas, you're correct in that yum will attempt to continue to pull in
dependencies when they're available, so you'll continue to get these
warnings.
Actually, I hadn't considered that it might continue trying to get httpd et
al whenever I do a yum update, but it does not seem to be doing it so far. I
suppose it will if a new xymon package is available...
I'd given consideration to splitting things out into xymon-xymonnet,
xymon-proxy, xymon-server, xymon-xymongen and the like (in fact, a really,
really old version of the RPM did just that), but it really felt like more
complexity (and effort) than it was worth, especially since the upstream
had had unified things together.
If there's enough demand, I'm open to creating sub-packages for it. But it
does rather significantly increase complexity for people doing installs
since they have to think of the different components coming in. The flip
side is that for cases such as yours, or in micro-sized cloud/container
environments, you can install the base RPM and avoid bringing in other
dependencies.
And for the security nuts who don't want things installed that they don't
need.
One thing I can fix right away, though is wrapping the errors out of the
semanage calls. Although the RPM is built with SELinux in mind, if the
toolset isn't present there's no reason to annoy the user with the
messages. I'll put that in the next update for sure.
Only if it can still configure SELinux correctly using other methods? chcon
was already installed and available (part of coreutils)... Otherwise I would
rather know there was a problem.
Regards,
-jc
Kind regards,
SebA