Description of problem: If a system with entitlements is unregistered, broken yum repositories are left laying around and never cleaned up. How reproducible: Very Steps to Reproduce: 1. Register a system. 2. Consume one or more entitlements, anything will do, verify this results in /etc/yum.repos.d/redhat.repo being populated with some repositories. 3. Unregister from the CLI. Actual results: redhat.repo still has the old repositories, and will not clean them up even after the cert daemon runs. I think this somewhat breaks yum as we likely won't have a valid cert for that content anymore. Expected results: These repositories should be cleaned up. Additional info: Problem originating in certmgr.py main method, we bail out if not registered. Need to either keep going here, or make sure that these repos are cleaned up immediately with we unregister. The latter is probably the best option.
Just adding my observation.... - with rhsmcertd stopped... - yes I can reproduce Devan's claim that the redhat.repo appears dirty after unregistering. In fact, I first noticed this behavior months ago - however, if you followup with a yum call such as "yum repolist" (I think any yum call works) you'll find that the repolist has been cleaned automatically and that the redhat.repo file is now be emptied of repos. I don't know enough about yum to say why this happens, but yum does not seem to get tripped up by what appears to be a dirty redhat.repo left behind. - In fact, if you cat /etc/yum.repos.d/redhat.repo immediately after you subscribed, you'll find that the file is empty of repos. However a call to "yum repolist" does the right thing and another call to cat /etc/yum.repos.d/redhat.repo shows the populated repos. Strange - yes, but it works. Therefore I'm not sure how big of a deal this bug is. Nevertheless, my inclination when I first saw this behavior was the same as Devan.
Yesterday I was hitting some yum breakage after the unregister, due to our test data not having actual usable paths. However I cannot reproduce this in my testing this morning, everything I try to do with yum seems to clean up the old repos before any errors can happen. Possible my workstation did not have the plugin installed properly. Based on John's feedback above I think it's probably safe to pull this off beta blockers and postpone.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Fixed on RHEL5.7 branch in 6e2fc59dfc8c03a4e000b527ffcb7f036b20c948, version 0.95.5.8
Fixed on master branch in 09b026111ef401fdac405ec162e196f3a1de1c34, version 0.96.2
Verifying Version... [root@jsefler-onprem-5server ~]# rpm -q subscription-manager subscription-manager-0.95.5.18-1.git.4.364aa10.el5 [root@jsefler-onprem-5server ~]# cat /etc/yum.repos.d/redhat.repo # # Red Hat Repositories # Managed by (rhsm) subscription-manager # [root@jsefler-onprem-5server ~]# subscription-manager register --username=admin--password=admin --autosubscribe 712de4e1-5b16-4ff6-b8aa-7294aeb5ae2e jsefler-onprem-5server.usersys.redhat.com Installed Products: Awesome OS Workstation Bits - Subscribed Awesome OS Scalable Filesystem Bits - Subscribed Awesome OS Modifier Bits - Subscribed Awesome OS Server Bits - Subscribed Management Bits - Subscribed Clustering Bits - Not Subscribed Awesome OS for S390X Bits - Not Subscribed Awesome OS Developer Basic - Not Subscribed Load Balancing Bits - Not Subscribed Large File Support Bits - Not Subscribed Awesome OS Premium Architecture Bits - Not Subscribed Multiplier Product Bits - Not Subscribed Awesome OS Developer Bits - Not Subscribed Shared Storage Bits - Not Subscribed [root@jsefler-onprem-5server ~]# cat /etc/yum.repos.d/redhat.repo # # Red Hat Repositories # Managed by (rhsm) subscription-manager # [root@jsefler-onprem-5server ~]# yum repolist Loaded plugins: product-id, security, subscription-manager Updating Red Hat repositories. https://cdn.redhat.com/foo/path/always/repodata/repomd.xml: [Errno 14] HTTP Error 403: Forbidden Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: always-enabled-content. Please verify its path and try again [root@jsefler-onprem-5server ~]# cat /etc/yum.repos.d/redhat.repo # # Red Hat Repositories # Managed by (rhsm) subscription-manager # [awesomeos-workstation-scalable-fs] name = awesomeos-workstation-scalable-fs baseurl = https://cdn.redhat.com/path/to/awesomeos-workstation-scalable-fs enabled = 1 gpgcheck = 1 gpgkey = https://cdn.redhat.com/path/to/awesomeos/gpg/ sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/2080039185946909125-key.pem sslclientcert = /etc/pki/entitlement/2080039185946909125.pem metadata_expire = 3600 [awesomeos-modifier] name = awesomeos-modifier baseurl = http://example.com/awesomeos-modifier enabled = 1 gpgcheck = 1 gpgkey = http://example.com/awesomeos-modifier/gpg sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/5681630191767577496-key.pem sslclientcert = /etc/pki/entitlement/5681630191767577496.pem [awesomeos-server-scalable-fs] name = awesomeos-server-scalable-fs baseurl = https://cdn.redhat.com/path/to/awesomeos-server-scalable-fs enabled = 1 gpgcheck = 1 gpgkey = https://cdn.redhat.com/path/to/awesomeos/gpg/ sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/2080039185946909125-key.pem sslclientcert = /etc/pki/entitlement/2080039185946909125.pem metadata_expire = 3600 [always-enabled-content] name = always-enabled-content baseurl = https://cdn.redhat.com/foo/path/always enabled = 1 gpgcheck = 1 gpgkey = https://cdn.redhat.com/foo/path/always/gpg sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/8727447157264162718-key.pem sslclientcert = /etc/pki/entitlement/8727447157264162718.pem metadata_expire = 200 [content-label] name = content baseurl = https://cdn.redhat.com/foo/path enabled = 1 gpgcheck = 1 gpgkey = https://cdn.redhat.com/foo/path/gpg/ sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/8727447157264162718-key.pem sslclientcert = /etc/pki/entitlement/8727447157264162718.pem metadata_expire = 0 [never-enabled-content] name = never-enabled-content baseurl = https://cdn.redhat.com/foo/path/never enabled = 0 gpgcheck = 1 gpgkey = https://cdn.redhat.com/foo/path/never/gpg sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/8727447157264162718-key.pem sslclientcert = /etc/pki/entitlement/8727447157264162718.pem metadata_expire = 600 [root@jsefler-onprem-5server ~]# subscription-manager unregister System has been un-registered. [root@jsefler-onprem-5server ~]# cat /etc/yum.repos.d/redhat.repo # # Red Hat Repositories # Managed by (rhsm) subscription-manager # [root@jsefler-onprem-5server ~]# ls -l /etc/yum.repos.d/redhat.repo -rw-r--r-- 1 root root 73 May 20 17:15 /etc/yum.repos.d/redhat.repo [root@jsefler-onprem-5server ~]# yum repolist Loaded plugins: product-id, security, subscription-manager Updating Red Hat repositories. repolist: 0 [root@jsefler-onprem-5server ~]# cat /etc/yum.repos.d/redhat.repo # # Red Hat Repositories # Managed by (rhsm) subscription-manager # [root@jsefler-onprem-5server ~]# ls -l /etc/yum.repos.d/redhat.repo -rw-r--r-- 1 root root 67 May 20 17:15 /etc/yum.repos.d/redhat.repo ^^^ Verified that the contents of /etc/yum.repos.d/redhat.repo are now happily cleaned out after calling subscription-manager unregister. Moreover, running yum repolist after the unregister also re-writes the cleaned out /etc/yum.repos.d/redhat.repo. Also observe that after auto/subscribing, the contents of /etc/yum.repos.d/redhat.repo still appear empty until a yum transaction is performed. Although this behavior is harmless, it is what prompted this bug to be opened in the first place.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-1078.html