[Xymon] Dependencies for xymond and xymonnet (with particular reference to JC's terabithia.org RPMs)

[SebA]

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