Red Hat Bugzilla – Bug 235046
The RHN Plugin cannot be used along with the ProtectBase plugin.
Last modified: 2009-02-24 15:11:13 EST
Description of problem:
Using external yum repositories might mean that you expose yourself to several
possible problems. The most important one is protecting the packages from the
Red Hat provided channels. The yum plugin that provides that behavior is
ProtectBase, but I can't really use-it because there is no config file for the
RHN channels. Can you guys include a working ProtectBase in the Extras repo for
RHEL? I really need one.
Steps to Reproduce:
1. Add a non Red-Hat repository such as DAG.
2. Install software from the external repository.
3. Run Yum Update
You might see a few packages that override the RH provided ones.
You should see only the updates to the external packages.
I ended up reading this bug through trying to solve the same problem with the
yum-priorities plugin... which defaults everything to a low priority and
necessitates editing the repo info for base to higher than the 3rd party repo
I'm trying to also include (rpmforge, not that it really matters).
I'm not honestly sure this is a function of the rhn-plugin (and if not, please
comment back and tell me where to file this!) but it's the same problem I'm having.
The problem is that whatever priorities plugin you use, you can't edit the repo
info file for the rhn provided repos. I am looking for a way in which I can add
some properties required by 3rd party plugins to the rhn provided repos.
I know that it's not a function of the rhn-plugin, but making it one is a big
priority for me, because some 3rd party repos (2nd party as they call
themselves), might have some packages that will over-write the rhn provided
ones. I am looking to avoid that situation. I really want to be able to simply
run 'yum update', and not care about such stuff in the future.
I think that this should be filed as a medium severity RFE. It really doesn't
mean that the yum-rhn-plugin is broken in any way. It's just that in order to
sleep at nights, I need some extra functionality from it.
I suspect you'll be much happier by designating one machine with a RHEL
registered license to download *EVERYTHING*, including SRPM's, set up an
internal yum repository, and throw out up2date, the yum-rhn plugin, and most
especially that auto-updating bandwidth and CPU nibbling sneaky package yum-
This gives you much better release management, by allowing you to configure
your own stable um repositories with particular locked down hardware that all
your, say, web servers can look to. Then put these lines
/usr/bin/yum -R 120 -e 0 -d 0 check-update\
/usr/bin/yum -e 0 -d 0 yum list > /var/log/yumlist
# optiional, use if you have the yum-downloadly plugin
/usr/bin/yum -e 0 -d 0 --downloadonly update
Sorry, no, I won't be. I don't want to maintain my own repositories. I want
plugins to work correctly.
RH: Please work on a solution for the problem as reported?
Fair enough. Package management among multiple repositories, some outside the
control of the primary vendor, is a very difficult integration problem. It's
not helped by an inability to use published abilities built into the package
management tool, but are not aware to the DRM based "plugin". I've seen at
least one commercial client switch an 80 node Beowulf cluster to CentOS to
avoid similar sorts of license, installation, and package management pain.
User firstname.lastname@example.org's account has been closed
I've learned, since this antique bug, about the command 'reposync'. Ignore my
old shell script, and simply run 'reposync' as a root user to mirror all RHN
managed repositories. It's not ideal: the repositories found by reposync seem to
lag the 'yum update' command by a day, especially during the recent update to
It works best of the reposync occurs somewhere other than the /var/cache/yum on
a server, and runs createrepo against the repositories to publish them in a
local yum setup. This technique works very well with Xen and VMware virtualized
systems, and makes an RHEL network installation almost (though not quite) as
easy as a CentOS network installation.
*** This bug has been marked as a duplicate of bug 436043 ***