Bug 235046 - The RHN Plugin cannot be used along with the ProtectBase plugin.
The RHN Plugin cannot be used along with the ProtectBase plugin.
Status: CLOSED DUPLICATE of bug 436043
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum-rhn-plugin (Show other bugs)
5.0
All Linux
medium Severity high
: ---
: ---
Assigned To: John Matthews
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-03 11:42 EDT by Razvan Corneliu C.R. VILT
Modified: 2009-02-24 15:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-24 15:11:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Razvan Corneliu C.R. VILT 2007-04-03 11:42:00 EDT
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.

How reproducible:
Always

Steps to Reproduce:
1. Add a non Red-Hat repository such as DAG.
2. Install software from the external repository.
3. Run Yum Update
  
Actual results:
You might see a few packages that override the RH provided ones.

Expected results:
You should see only the updates to the external packages.
Comment 1 JB Segal 2007-07-10 13:46:08 EDT
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.
Comment 2 Razvan Corneliu C.R. VILT 2007-07-10 15:35:19 EDT
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.
Comment 3 Nico Kadel-Garcia 2007-07-10 16:37:31 EDT
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-
updatesd out.

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 
in /etc/cron.daily/yum.cron:

#!/bin/sh

/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

Comment 4 JB Segal 2007-07-10 19:31:46 EDT
Sorry, no, I won't be. I don't want to maintain my own repositories. I want
plugins to work correctly.

Thanks, though.

RH: Please work on a solution for the problem as reported?
Comment 5 Nico Kadel-Garcia 2007-07-11 18:23:24 EDT
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.
Comment 6 Red Hat Bugzilla 2007-10-25 20:51:57 EDT
User jslagle@redhat.com's account has been closed
Comment 7 Nico Kadel-Garcia 2008-06-21 12:34:55 EDT
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
RHEL 5.2.

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.
Comment 8 Pradeep Kilambi 2009-02-24 15:11:13 EST

*** This bug has been marked as a duplicate of bug 436043 ***

Note You need to log in before you can comment on or make changes to this bug.