-----Original Message----- From: J.C. Cleaver [mailto:cleaver at terabithia.org] 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