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

[SebA]

Thanks for the additional info JC. Much appreciated.

Kind regards, 

SebA  


 

> -----Original Message-----
> From: J.C. Cleaver [mailto:cleaver at terabithia.org] 
> Sent: 14 March 2015 02:22
> To: SebA
> Cc: 'Xymon MailingList'
> Subject: RE: Dependencies for xymond and xymonnet (with 
> particular reference to JC's terabithia.org RPMs)
> 
> On Fri, March 13, 2015 2:51 am, SebA wrote:
> 
> >>
> >> 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?
> 
> 
> Yeah, does sound like you'd had policycoreutils installed, but not
> policycoreutils-python. For loadable policies modification, semanage
> really is the tool most appropriate for the job. (I actually 
> kind of find
> it a little odd it's not in the base package, or @base package set.)
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterpri
> se_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced
> _Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_sema
> nage_fcontext.html
> 
> 
> >
> >> 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...
> >
> 
> Correct. "yum check" might complain too about existing errors.
> 
> 
> 
> >> 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.
> 
> Quite true.
> 
> To do this right will also mean breaking out the various utilities
> (xymongen, xymonnet, xymonproxy, etc.) into their own 
> tasks.d/ snippets
> instead of the monolithic tasks.cfg given out now...
> 
> This is something that might be best done at a 4.4.x release, 
> to help ease
> transition pain.
> 
> 
> > 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.
> 
> 
> Policy loading and context setting again really ought to be done with
> semanage, otherwise you're not making a permanent change.
> 
> 
> Regards,
> 
> -jc
> 
> 
>