Nagios XI RedHat patching

[krobertson71]

They are patching our monitoring apps today. I just got this from one of our Unix Admins. Can we please address this as it keeps coming up.

Forgot to mention, this is running on RHEL 6.

This is the output from the update on nagiast01.

Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package rubygem-json.x86_64 0:1.4.6-1.el6 will be updated
--> Processing Dependency: rubygem-json = 1.4.6-1.el6 for package: ruby-json-1.4.6-1.el6.x86_64
---> Package rubygem-json.x86_64 0:1.5.1-1.el6.rf will be an update
--> Finished Dependency Resolution
Error: Package: ruby-json-1.4.6-1.el6.x86_64 (@epel)
Requires: rubygem-json = 1.4.6-1.el6
Removing: rubygem-json-1.4.6-1.el6.x86_64 (@epel)
rubygem-json = 1.4.6-1.el6
Updated By: rubygem-json-1.5.1-1.el6.rf.x86_64 (rpmforge)
rubygem-json = 1.5.1-1.el6.rf


I would be curious to know if the EPEL stuff was put on by Nagios along with the RPMForge stuff.


If not then we could try pulling off the EPEL packages and putting them back on with RPMForge.


If this is something that Nagios is doing then they need to review their process as it is broken.

[abrist]

The EPEL repo is indeed added by our installer. I think there has been some talk about yanking rpmforge from the installer and just providing the couple of packages we need from that repo.

[krobertson71]

Well they are asking me for decision on this. Is this a known issue? Is there a way around this for the time being?

So you are saying to not remove epel. But when we are patching we are getting the error from the first post.

Not sure what to do here. We will patch again in 4 weeks and this will come up again.

[sreinhardt]

The issue here is that you do not appear to be updating epel. These packages must be updated, and should not be pulled from rpmforge as they have vastly different packaging standards that often break standard cent\rhel packages. The only other option would be to build all of the epel package we need from source, and that is not something we are willing to partake in.

If you want to remove epel, you are more than welcome to. However it should be noted, that this will cause issues that only get worse with time as abandoned packages that depend on specific base or updates packages are no longer the correct version. Do your admins have an alternative to epel packages other than rpmforge? I would be happy to consider possible alternatives, but I'm not sure how viable they will be. Also if you could ask them to elaborate on what is broken, if there is a better way of handling it, we would be open to suggestion.

[krobertson71]

The issue here is that you do not appear to be updating epel. These packages must be updated, and should not be pulled from rpmforge as they have vastly different packaging standards that often break standard cent\rhel packages. The only other option would be to build all of the epel package we need from source, and that is not something we are willing to partake in.

If you want to remove epel, you are more than welcome to. However it should be noted, that this will cause issues that only get worse with time as abandoned packages that depend on specific base or updates packages are no longer the correct version. Do your admins have an alternative to epel packages other than rpmforge? I would be happy to consider possible alternatives, but I'm not sure how viable they will be. Also if you could ask them to elaborate on what is broken, if there is a better way of handling it, we would be open to suggestion.

With respect I think you have misunderstood what the Unix admin was saying..

We did not put RPM forge repo on the Red Hat server. This was a vanilla install of RHEL 6 and then Nagios XI was installed. RPMForge was put there by Nagios itself as well as EPEL. The unix admin is saying their should not be both , but yet there is. It is apparent from my first post that the epel package was rejected and then attempted to pull from RPMForge.

Unix admins have assured me that they do not put the RPM Forge repo on any of our Unix servers for the very reasons you have described.

Do we need to reinstall? Another Nagios support person mentioned in this threat that there was a couple of packages pulled from RPMForge by Nagios XI.

So I ask again, if we did not put it there, Did Nagios XI create this need of RPM Forge repo?

[sreinhardt]

Ah sorry about the misunderstanding there, you are correct I read it as he was saying neither should be installed, which seemed very odd and difficult to handle properly. While some packages may switch between the newest of either repo, if you have to stay with one or the other, epel would be preferred as it provides some 60-70% of our packages and overlaps much with rpmforge. I think there are only one or two packages epel may not provide, or that we prefer from rpmforge generally. Those are likely fping and scons. I believe everything else should be provided by epel as well. Rpmforge is actually something we have been working to remove, but those last couple packages are making it a sticking point the last time we looked into it.

Edit: Also yes, we do install both by default.

[krobertson71]

Yes and thank you very much for repling back.

To the ruby-json packacke at hand.

How would be update this package properly. They actually stopped it from updating. It looked to epel but the version did not match and tried to pull from forge.

Any way around this so it pulls the epel package for ruby-json?

[sreinhardt]

In this case, I would suggest staying with the epel version. It seems that other packages depend on this specific version. Removal of the rpmforge repo is probably best at this point, otherwise you can certainly run yum update with an exclusion for rpmforge with:

Code: Select all

yum update --disablerepo=rpmforge