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.
Adding a GPG key to a product repository after creation did not properly set the "gpgcheck" configuration option in the client's repo file. This fix regenerates changed content and updates configuration when updating the GPG key.
DescriptionGarik Khachikyan
2012-04-19 09:32:59 UTC
Description of problem:
Recent version of rhsm: subscription-manager-0.99.13-1.el6.x86_64 has an issue with gpgcheck: it always set to 0 independent from the fact that the custom repo that I assigned my system using Katello has there GPGkey assigned.
Version-Release number of selected component (if applicable):
subscription-manager-0.99.13-1.el6.x86_64
python-rhsm-0.99.8-1.el6.noarch
How reproducible:
always
Steps to Reproduce:
1.in Katello do prepare repo with GKGkey (e.g.: http://inecas.fedorapeople.org/fakerepos/zoo3/ with gpgkey from: http://inecas.fedorapeople.org/fakerepos/zoo/RPM-GPG-KEY-dummy-packages-generator)
2.sync it and assign a system (self-register would also work) to register and consume that repo.
3.try repolist and then look at: /etc/yum.repos.d/redhat.repo
Actual results:
gpgcheck = 0 in there
Expected results:
in case when repo has gpg key: fetch and use that correctly.
Additional info:
I remember it was working before (had test that was passing before)
There does not appear to be a gpgkey set in those entitlement certs, so at least for those certs, subscription-manager appears to be doing the right thing.
The entitlement cert doesn't actually have a gpg key url set in it.
I just ran a quick test on a katello install, and it looks like if you change the gpgkey url on an existing repository, that change is never propagated down to candlepin. Creating a repository with a gpg key set originally gets the key url into candlepin, and thus into the entitlement cert.
Reassigning to katello.
Hrmmm I have not been able to reproduce the original scenario with katello master and the latest rhsm from 6.2 or the version that Garik mentioned. In both cases gpgcheck is set to 1.
Garik, Which version of katello did you find this with?
Still going to address the issue where you enable/disable the gpg key on an existing repo.
Rather, it's not going to fail but gpgkey will be set in the repo file while gpgcheck will still be 0.
Pull request:
https://github.com/Katello/katello/pull/729
Commit SHA:
a609539ac3b4f9f72c155f15b7521ad4bfd1f429
the above code was actually reverted and the fix was implemented within Candlepin itself.
This bug looks largely like a dupe of:
https://bugzilla.redhat.com/show_bug.cgi?id=824581
which we have as VERIFIED. If QE wants to re-test this go ahead.