Hide Forgot
Custom channels created in Satellite have a "GPG key URL" field that is practically undocumented and behaves in a rather unintuitive manner. At the very least, the documentation should be updated to better describe this field. However, I believe there would also be value in adjusting the behavior of this field to make it useful and intuitive. Maybe I should start by presenting the two use cases under which I was expecting to make use of this field. 1) I currently use Satellite to manage a number of RHEL servers using only standard RHEL packages. When Satellite was originally rolled out in my organization, no GPG keys were distributed for validating packages other than the standard RHEL packages. We recently had a need to patch one of the standard RHEL packages and distribute our patched copy in place of the original. I would like to configure Satellite to facilitate distribution of the GPG key used to sign this custom package. 2) Satellite 5.4 has a new feature that allows the creation of a custom Channel that pulls packages from an arbitrary Yum repository. I would like to use this mechanism to install some EPEL packages on particular servers. As in the above case, I would like to configure Satellite to facilitate distribution of the GPG key used to sign EPEL packages. My initial assumption was that the "GPG key URL" field in Satellite was equivalent to the "gpgkey" repository option in yum.conf. In other words, I assumed that if yum encountered a package signed by an unknown key, it would ask the user if the key at the specified URL should be installed. However, this is apparently not the case. The is_valid_gpg_key_url() method in /usr/share/yum-plugins/rhnplugin.py causes yum to silently ignore the value provided by the Satellite server unless it begins with "file:///etc/pki/rpm-gpg/". So, basically, it appears that this field can only be used to facilitate distribution of replacement keys (by building a package containing the replacement key, signing the package with an existing key, then changing the GPG key URL to point at the new key file), and new keys cannot be distributed using this mechanism. I assume this was done for security reasons, but I'm not sure I fully understand the logic behind this. Let's say the Satellite server and a client server are run by two different organizations that do not trust each other. It makes sense that the Satellite server should not be able to automatically trigger the client server to install a new GPG key. However, if a user on the client server manually tries to install a package signed by a new GPG key, is there any reason not to prompt them to install that GPG key? At the very least, why doesn't it print out an informative message to explain why it is refusing to install that GPG key and how the user can manually install it? And why does the Manage Software Channels page in the Satellite web interface even accept arbitrary URLs if those are considered invalid and silently ignored? Regardless of why this was implemented this way, such unintuitive behavior would not be a problem if it were documented. However, the ONLY reference I see to this particular field in any of the RedHat documentation is in the Satellite Channel Management Guide (http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/5.4/pdf/Channel_Management_Guide/Red_Hat_Network_Satellite-5.4-Channel_Management_Guide-en-US.pdf), which only briefly mentions the GPG key URL field once (on page 15), and doesn't say anything about this field's purpose or limitations. Another user also noticed this behavior back in 2009 and posted to the Spacewalk mailing list about it. A RedHat Satellite Engineer responded stating that this sounded like a bug (https://www.redhat.com/archives/spacewalk-list/2009-October/msg00143.html). The CentOS Spacewalk HowTo even gives an example of configuring Spacewalk to use EPEL (http://wiki.centos.org/HowTos/PackageManagement/Spacewalk#head-6cdea36ae188dc1a5237726ca1c279ce75225616), and says that the GPG key URL field should be populated with "http://download.fedora.redhat.com/pub/epel/RPM-GPG-KEY-EPEL", and it doesn't mention anything about manually importing that key on the client. Does this field behave differently in Spacewalk under CentOS, or is this HowTo just poorly written? Please consider updating the documentation and/or software behavior to make this field and its limitations more obvious.