Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
After going through the lengthy process of uploading a manifest and specifically selecting the RHEL 6.2 RPMs repository, syncing it, promoting it to my product's Library -> Development environment, I was baffled as to why my RHEL 6.2 client could not use its content upon a successful subscription. When I ran yum repolist, the client always looked for a *6Server* repository in the SE, but sure enough, as that specific repository had not been synced or promoted, it received a 404.
I talked to several people yesterday about this, and my point was that, if the system is to be managed by the SE and content delivery is controlled based on the subscription to which the system is associated, then my client should not be looking for the *6Server* but for the available *6.2* repository from the subscription.
The issue here is that the client seems to dictate what repository can be used to deliver RHEL content, and not what the SEE provides it. This is basically what yum does: rpm -qf /etc/redhat-release --queryformat "%{VERSION}"
Looking at my client now:
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.2 (Santiago)
# rpm -qf /etc/redhat-release
redhat-release-server-6Server-6.2.0.3.el6.x86_64
# rpm -qi redhat-release-server-6Server-6.2.0.3.el6.x86_64 | grep Version
Version : 6Server
The proposed work around to make sure that my client tries to use the 6.2 repository are as follows, in no particular order:
* call yum with --releasever 6.2
* search for and install for the 6.2 equivalent of redhat-release-server
* select, sync and promote the 6Server repository alongside my 6.2 repository.
I tried the last option, and sure enough it worked, but I strongly believe that if the process of controlling what goes into the client is controlled by the its subscription, then we should not be asking yum for further information, or at least the logic should not be in the client but in the SE.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Description of problem: After going through the lengthy process of uploading a manifest and specifically selecting the RHEL 6.2 RPMs repository, syncing it, promoting it to my product's Library -> Development environment, I was baffled as to why my RHEL 6.2 client could not use its content upon a successful subscription. When I ran yum repolist, the client always looked for a *6Server* repository in the SE, but sure enough, as that specific repository had not been synced or promoted, it received a 404. I talked to several people yesterday about this, and my point was that, if the system is to be managed by the SE and content delivery is controlled based on the subscription to which the system is associated, then my client should not be looking for the *6Server* but for the available *6.2* repository from the subscription. The issue here is that the client seems to dictate what repository can be used to deliver RHEL content, and not what the SEE provides it. This is basically what yum does: rpm -qf /etc/redhat-release --queryformat "%{VERSION}" Looking at my client now: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 (Santiago) # rpm -qf /etc/redhat-release redhat-release-server-6Server-6.2.0.3.el6.x86_64 # rpm -qi redhat-release-server-6Server-6.2.0.3.el6.x86_64 | grep Version Version : 6Server The proposed work around to make sure that my client tries to use the 6.2 repository are as follows, in no particular order: * call yum with --releasever 6.2 * search for and install for the 6.2 equivalent of redhat-release-server * select, sync and promote the 6Server repository alongside my 6.2 repository. I tried the last option, and sure enough it worked, but I strongly believe that if the process of controlling what goes into the client is controlled by the its subscription, then we should not be asking yum for further information, or at least the logic should not be in the client but in the SE. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: