GPG keys not working?
On Katello 188.8.131.52
I have created several Products (5 Oracle Linux repositories) with the same GPG key assigned. When going to Content > Products the GPG key is selected/assigned to the repositories. When going to Content > GPG keys and selecting Details on that GPG key I see the content of the key. Selecting Repositories I see the 5 repositories I have assigned with the key. But selecting Products I only get that I have no Products associated to this GPG key.
Additionally when adding the repository to a client, I'm able to install packages from the local repository with yum but the GPG key is never downloaded even if I enable GPG key check.
Am I missing something or is this a bug?
#4 Updated by Brad Buckingham about 5 years ago
I just tried out GPGKeys on my development environment and they appear to be working well. It is possible that our procedures are different or the issue you are experiencing has been resolved since 184.108.40.206 was released.
The procedure that I followed (using the UI) was the following:
- created gpgkey
- created product
- associated gpgkey with product
- created repo in that product
- observed (Content -> Products) - key is associated with product and repository
- observed (Content -> GPGKeys) - key is lists product and repository
- created a content view, added the repo and published
- created an activation key, associated content view, added subscription for product
- registered a client using the activation key
- yum clean all && yum repolist
- attempted to install a package from the repo
- observed download attempt to pull in my GPG key, see below for example
[root@rhel7-client1 ~]# yum install bear Loaded plugins: package_upload, product-id, search-disabled-repos, subscription-manager, tracer_upload Default_Organization_gpgkeyed_keyedzoo | 2.1 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package bear.noarch 0:4.1-1 will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================== Package Arch Version Repository Size ============================================================================================================== Installing: bear noarch 4.1-1 Default_Organization_gpgkeyed_keyedzoo 2.8 k Transaction Summary ============================================================================================================== Install 1 Package Total download size: 2.8 k Installed size: 42 Is this ok [y/d/N]: y Downloading packages: warning: /var/cache/yum/x86_64/7Server/Default_Organization_gpgkeyed_keyedzoo/packages/bear-4.1-1.noarch.rpm: Header V4 RSA/SHA1 Signature, key ID f78fb195: NOKEY Public key for bear-4.1-1.noarch.rpm is not installed bear-4.1-1.noarch.rpm | 2.8 kB 00:00:00 Retrieving key from https://centos7-devel.example.com/katello/api/repositories/110/gpg_key_content Importing GPG key 0xDEB62A91: Userid : "Brad Buckingham (test) <email@example.com>" Fingerprint: 8067 1ceb 433a 69e6 fde2 4a99 0041 0d3a deb6 2a91 From : https://centos7-devel.example.com/katello/api/repositories/110/gpg_key_content Is this ok [y/N]: N Didn't install any keys
I attempted the same scenario, but associating the gpg key with the repository versus the product and observed the same behavior. Is there anything different you see in our procedures?
Would you be interested in upgrading to the latest katello 3.3 to see if the issue is resolved there?
#6 Updated by Kent Knudsen about 5 years ago
Thanks for looking into this. After I initially posted I crashed my Katello installation and created a new server with more space for more repos, so I can't reproduce the GPG key issue.
On the new Katello server I now have no issues with the GPG keys. My steps are similar to your steps. The only difference I can think of is that on the old server I didn't promote the content views, I only published them. Don't know if that should make any difference for the GPG key functionality. When looking at the activation keys they now show everything as it should be.
I have no idea why this didn't work but I think we can close this issue.
#7 Updated by Brad Buckingham about 5 years ago
- Status changed from Need more information to Rejected
- Legacy Backlogs Release (now unused) changed from 211 to 166
Thanks for the feedback and apologies for the delay getting to attempt the reproducer.
For now, I'll go ahead and close the issue; however, if the issue reappears, please let me know and we can we can re-open it. (I am setting it to 'rejected' only to indicate that no code changes were made, as of this time.)