[uyuni-users] New SLES15-Client: 4-Signatures public key is not available
Hi, I created a new SLES15-machine with a minimal setup and tried to add it to Uyuni using the "Bootstrapping" function at the WebGUI. Initially it stopped after creating a Salt key but without any error message on the Uyuni-server and obviously without any deoployment on Uyuni or on the client. It turned out that the resolv.conf was missing on the client and so the client wasn't able to start a connection to the Uyuni-server. After creation of the resolv.conf the bootstrapping / registration process automatically continued, including "Apply states" (channels, packages, etc.) - everything seemed fine now. But during installation of the pre-defined package list an error occured during the installation of one package. A manual installation using zypper install fails with the same message: htop-2.2.0-bp150.2.4.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 65176565: NOKEY htop-2.2.0-bp150.2.4.x86_64 (SUSE-PackageHub-15-Standard-Pool for x86_64): Signature verification failed [4-Signatures public key is not available] The repository list looks fine: # zypper lr |egrep '(Standard|Alias)' # | Alias | Name | Enabled | GPG Check | Refresh 13 | susemanager:suse-packagehub-15-x86_64 | SUSE-PackageHub-15-Standard-Pool for x86_64 | Yes | ( p) Yes | Yes Installation of the same package is no problem on other salt-clients using the same channel. Any idea how to fix this (automatically)? -- Regards, Tobias Crefeld. xmpp (no email): crefeld@xabber.de -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
AFAIK the SLE instances do not trust the Packagehub by default. So I think you need something similar to: https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-... If I am not wrong, the key from PackageHub should be uploaded to /srv/www/ htdocs/pub @doc team, shouldn't we describe how to trust GPG keys for third party repositories at the clients? I can't see it at https://www.uyuni-project.org/ uyuni-docs/uyuni/administration/custom-channels.html On viernes, 24 de abril de 2020 14:40:36 (CEST) Tobias Crefeld wrote:
Hi,
I created a new SLES15-machine with a minimal setup and tried to add it to Uyuni using the "Bootstrapping" function at the WebGUI.
Initially it stopped after creating a Salt key but without any error message on the Uyuni-server and obviously without any deoployment on Uyuni or on the client.
It turned out that the resolv.conf was missing on the client and so the client wasn't able to start a connection to the Uyuni-server.
After creation of the resolv.conf the bootstrapping / registration process automatically continued, including "Apply states" (channels, packages, etc.) - everything seemed fine now.
But during installation of the pre-defined package list an error occured during the installation of one package. A manual installation using zypper install fails with the same message:
htop-2.2.0-bp150.2.4.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 65176565: NOKEY htop-2.2.0-bp150.2.4.x86_64 (SUSE-PackageHub-15-Standard-Pool for x86_64): Signature verification failed [4-Signatures public key is not available]
The repository list looks fine:
# zypper lr |egrep '(Standard|Alias)' # | Alias | Name | Enabled | GPG Check | Refresh 13 | susemanager:suse-packagehub-15-x86_64 | SUSE-PackageHub-15-Standard-Pool for x86_64 | Yes | ( p) Yes | Yes
Installation of the same package is no problem on other salt-clients using the same channel.
Any idea how to fix this (automatically)?
-- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Am Fri, 24 Apr 2020 15:46:20 +0200 schrieb Julio González Gil <jgonzalez@suse.com>:
AFAIK the SLE instances do not trust the Packagehub by default.
Thanks for the hint - seems that you're right! I checked the GPG-keys rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}\t%{SUMMARY}\n' and found an additional key gpg-pubkey-65176565 gpg(openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org>) on the "old" SLES15 systems. "Backports" is the forerunner of PackageHub, according to their homepage. During manual installation from an repository with an unknown key you usually get a dialogue if you want to import the key. This is of course no strategy for an auto deployment.
So I think you need something similar to:
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/clients-...
If I am not wrong, the key from PackageHub should be uploaded to /srv/www/ htdocs/pub
Haven't fully understood this advice as yet but I keep trying.
@doc team, shouldn't we describe how to trust GPG keys for third party repositories at the clients? I can't see it at https://www.uyuni-project.org/ uyuni-docs/uyuni/administration/custom-channels.html
Actually my expectation is that a channel that is provided via "Admin / Setup Wizard / Products" redistributes the respective GPG-key as well. Writing this I remember that I already had some problems with this channel earlier during the initial setup of Uyuni. The resolution was a manual call spacewalk-repo-sync -c suse-packagehub-15-x86_64 with an dialogue if I want to import the GPG-key. -- Gruss, Tobias Crefeld. xmpp (no email): crefeld@xabber.de -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
On viernes, 24 de abril de 2020 17:31:32 (CEST) Tobias Crefeld wrote:
Am Fri, 24 Apr 2020 15:46:20 +0200
schrieb Julio González Gil <jgonzalez@suse.com>:
So I think you need something similar to:
https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/client s-opensuse.html#_trust_gpg_keys_on_clients
If I am not wrong, the key from PackageHub should be uploaded to /srv/www/ htdocs/pub
Haven't fully understood this advice as yet but I keep trying.
Basically I think this can be fixed by one of the following alternatives: a) Bootstrap script Copy the packagehub gpg key file to /srv/www/htdocs/pub at the server. Thenk you can add it to the bootstrap script (there's a variable for that) and that should add the gpg key to the clients you bootstrap, therefore they will trust the packages fro the Package Hub. b) Salt state As an alternative (or only option if you bootstrap from WebUI), you can create a salt state to send the GPG file to the clients, and to trust it on such clients. This would work even for onboarded clients as you can apply the state.
@doc team, shouldn't we describe how to trust GPG keys for third party repositories at the clients? I can't see it at https://www.uyuni-project.org/ uyuni-docs/uyuni/administration/custom-channels.html
Actually my expectation is that a channel that is provided via "Admin / Setup Wizard / Products" redistributes the respective GPG-key as well.
I am pretty sure this was discussed in the past, and IIRC the conclusion was that this could be insecure, and that if the base OS doesn't trust a GPG (such is this case as SLE doesn't trust the GPG key for PackageHub by default: https://packagehub.suse.com/how-to-use/), then trusting it on clients should not be transparent for the Uyuni administrator as otherwise the administrator wouldn't notice what's going. As this comes provided by SCC, the question is if SLE should trust this key by default. But that's not something Uyuni can fix on its side. Of course, with enough changes to the code, maybe Uyuni could assume that if a repository came from SCC the key must be accepted on reposync, and then it should the passed to the clients and trusted on the clients. But I'd say that's not really trivial (our developers should tell). So at least for short term, the solution is the highstate/change to the bootstrap script, and IMHO it should be part of the official doc.
Writing this I remember that I already had some problems with this channel earlier during the initial setup of Uyuni. The resolution was a manual call
spacewalk-repo-sync -c suse-packagehub-15-x86_64
with an dialogue if I want to import the GPG-key.
Same as above, yes. In this case it's the Uyuni Server the one that doesn't trust the key as it considers the package hub as a third party repository, just as SLE and openSUSE do. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Am Fri, 24 Apr 2020 19:26:01 +0200 schrieb Julio González Gil <jgonzalez@suse.com>:
I am pretty sure this was discussed in the past, and IIRC the conclusion was that this could be insecure, and that if the base OS doesn't trust a GPG (such is this case as SLE doesn't trust the GPG key for PackageHub by default: https://packagehub.suse.com/how-to-use/), then trusting it on clients should not be transparent for the Uyuni administrator as otherwise the administrator wouldn't notice what's going.
Actually I only agree partly with this conclusion. If a GPG-key is provided by Uyuni the client should trust him as Uyuni is not only a dumb repository mirror but is provided root-privilege via salt-scripts.
As this comes provided by SCC, the question is if SLE should trust this key by default. But that's not something Uyuni can fix on its side.
Certainly both are no acceptable approaches due to security reason.
Of course, with enough changes to the code, maybe Uyuni could assume that if a repository came from SCC the key must be accepted on reposync, and then it should the passed to the clients and trusted on the clients.
IMO it would be enough if any software channel has a place for its GPG-key and automatically deploys this key whenever a client gets subscribed to this channel. OK., this will cause some coding effort but if I look at the WebUI there already seem to be some fields referring to GPG-keys.
Same as above, yes. In this case it's the Uyuni Server the one that doesn't trust the key as it considers the package hub as a third party repository, just as SLE and openSUSE do.
From principle it is absolutely acceptable if I have to do some extra tasks to add 3rd-party repositories. My main problem was that I wasn't aware that PackageHub is a 3rd party repo. As Uyuni's WebUI PackageHub is part of the "Products" tree, I expected that all repositories that are shown under "Products" are trusted by default which means that their public keys are known by Uyuni's default setup. -- Gruss, Tobias Crefeld. xmpp (no email): crefeld@xabber.de -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
participants (2)
-
Julio González Gil -
Tobias Crefeld