Import GPG Key for 3rd-party channel in Satellite

Latest response

We have added the EPEL channel to our Base Channels (which then gets cloned).

I retrieved EPEL GPG keys and publish them in /pub/RPM-GPG-KEY-epel (/pub/RPM-GPG-KEY-epel-6) on my Satellite.

[root@rhnsat01 2014-09-03]# spacecmd softwarechannel_details  cln14wk25-epel-x86_64-server-5  | sed 's/XXX.YYY/mycompany/g'
INFO: Connected to https://localhost/rpc/api as satman
Label:              cln14wk25-epel-x86_64-server-5
Name:               cln14wk25-epel-x86_64-server-5
Architecture:       x86_64
Parent:             cln14wk25-rhel-x86_64-server-5
Systems Subscribed: 49
Number of Packages: 8683

Summary
-------
cln14wk25-epel-x86_64-server-5

GPG Key:            217521F6
GPG Fingerprint:    B940 BE07 7D71 0A28 7D7F  2DD1 119C C036 2175 21F6
GPG URL:            http://rhnsat01.mycompany.com/pub/RPM-GPG-KEY-epel

I guess I had hoped that the key would be "auto-imported" when I had subscribed a host to that child-channel?

How are other folks managing the GPG keys? It is easy enough to run: rpm --import http://rhnsat01.mycompany.com/pub/RPM-GPG-KEY-epel or disable gpgcheck.

If someone has advice, or knows which doc I should be looking at, it would be appreciated.

Thanks!

Responses

James,

I've had the same issue in the past with GPG keys + Satellite.

The way I resolved (worked around?) this was to import all the keys as part of the initial kickstart, which isn't ideal if you are adding a channel after your environment has been built.

-edit-

It seems there is a solution and explanation here:
https://access.redhat.com/solutions/47159

RHNplugin doesn't support http URLs for GPG keys for security reasons, so deploying the GPG key as a configuration file to /etc/pki/rpm-gpg and then referencing the file:// location in your repo configuration may be the fix.

There is a bugzilla here which explains the issue:
https://bugzilla.redhat.com/show_bug.cgi?id=530598

I remember reading this bugzilla when I had the same issue because the last post suggests bundling and deploying the gpg keys in an RPM.. which results in a catch 22.

Thanks Pixel!

I had similar thoughts (regarding the RPM) when I was trying to figure out how my solution was "broken" compared to when I add the external EPEL repo (on my workstation, for example).. then it dawned on me... when you add the external EPEL repo, you typically do an yum install of their RPM to add the repo.

I am going to test adding the GPG-key to /etc/pki/rpm-gpg/ via a ConfigChannel. I can't think of a reason why this is a bad idea. Although I don't know if it will work - my concern is that when you import the key using the accepted method, it updates rpmdb, or some other "thing" and simply having the key present in /etc/pki/rpm-gpg is not sufficient.

not a big deal either way, I suppose.

Thanks again for the datapoints!