Bug 235046
Summary: | The RHN Plugin cannot be used along with the ProtectBase plugin. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Razvan Corneliu C.R. VILT <razvan.vilt> |
Component: | yum-rhn-plugin | Assignee: | John Matthews <jmatthew> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 5.0 | CC: | jb, nkadel, pkilambi, sputhenp |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-24 20:11:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Razvan Corneliu C.R. VILT
2007-04-03 15:42:00 UTC
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- 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 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? 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 jslagle'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 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. *** This bug has been marked as a duplicate of bug 436043 *** |