Description of problem: spacewalk-common-channel has outdated URL for public GPG key Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1. spacewalk-common-channels -u <admin> -p <password> spacewalk-nightly-client-centos5 2. spacewalk-repo-sync --channel spacewalk-nightly-client-centos5-x86_64 3. Browse to the Spacewalk Night Client channel and make note of the GPG key url. Actual results: The URL does not match the current GPG key on http://spacewalk.redhat.com/yum/ The GPG key URL that gets installed automatically at the channel is: http://spacewalk.redhat.com/yum/RPM-GPG-KEY-spacewalk There is no key named RPM-GPG-KEY-spacewalk located there. There is only: RPM-GPG-KEY-spacewalk-2008 20-Apr-2010 14:45 1.7K RPM-GPG-KEY-spacewalk-2010 13-Aug-2010 07:36 1.3K RPM-GPG-KEY-spacewalk-2012 06-Mar-2012 07:18 1.8K Expected results: Spacewalk GPG key named "RPM-GPG-KEY-spacewalk" should be created and published at http://spacewalk.redhat.com/yum
Fixed in Spacewalk 1.8, 835b2e37762dea7770d7aa42f2c2c15f648220f9.
Not fixed in RH Satellite! What if I don't want to or cannot update to Spacewalk 1.8?
(In reply to comment #2) > Not fixed in RH Satellite! What if I don't want to or cannot update to > Spacewalk 1.8? Mr. Schonecker, please contact the Red Hat support to properly triage the issue you experience with Red Hat Network Satellite product. By avoiding Red Hat support process and opening bugzilla directly, you've forced to track the issue on Red Hat engineering side but as your comment 2 shows, it did not get anybody any closer to getting the issue resolved in Satellite. Bugzilla is an engineering tool and as such, Red Hat engineering uses it to track engineering information. The issue was addresses in Satellite's upstream project, Spacewalk, and the status of this bugzilla as well as the comment 1 reflects this *internal* development information. You certainly are not expected to "update to Spacewalk". Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat
This will be resolved with the future Satellite 5.6 release. This is being tracked against that release.
Red Hat is claiming that the Spacewalk community needs to fix this. You're telling me that Red Hat needs to fix this. I opened a ticket 00822363 at Red Hat and they're pushing off responsibility. All I want is for someone to put http://spacewalk.redhat.com/yum/RPM-GPG-KEY-spacewalk back (or create it) so that Red Hat Satellite people can get their channels fixed.
In this Satellite bugzilla, we as Red Hat in comment 6 say that with the upcoming Satellite 5.6 release, the path in the spacewalk-common-channels.ini definition file will be fixed to point to http://yum.spacewalkproject.org/RPM-GPG-KEY-spacewalk-2012 URL for all Spacewalk yum repos. However, please note that for Spacewalk nightly repos that will not help much anyway because the nightly packages are *not* signed at all -- there might be some signed packages in those yum repositories, inherited from older Spacewalk releases, but in general, Spacewalk nightly (nor server, nor client) do not have GPG signatures so for yum operations from those repos, the --nogpgcheck will still be needed, unless you for example resign them before pushing them to your Satellite server. So technically, the most correct solution would probably be removing that GPG key URL from the Spacewalk nightly repositories altogether.
The latest Satellite 5.6 Beta compose contains spacewalk-common-channels definitions based on Spacewalk 1.9 version.
Satellite 5.6 has been released. This bug was tracked under the release. This bug was either VERIFIED or RELEASE_PENDING (re-verified prior shortly before release). Moving to CLOSED CURRENT_RELEASE. Text from Upgrade Erratum follows: Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1395.html