Bug 1421249 - Cannot use cockpit for hosted-engine setup if gpg keys have not already been accepted
Summary: Cannot use cockpit for hosted-engine setup if gpg keys have not already been ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhev-hypervisor-ng
Version: 4.1.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ovirt-4.1.1
: ---
Assignee: Ryan Barry
QA Contact: Yihui Zhao
URL:
Whiteboard:
: 1422136 1423454 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-10 18:08 UTC by Jake Hunsaker
Modified: 2017-04-20 19:03 UTC (History)
20 users (show)

Fixed In Version: cockpit-ovirt-0.10.7-0.0.11.el7ev
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-20 19:03:25 UTC
oVirt Team: Node
Target Upstream Version:
rbarry: needinfo-


Attachments (Terms of Use)
cockpit_gpg.png (70.01 KB, image/png)
2017-02-16 01:19 UTC, Yihui Zhao
no flags Details
ovirt-hosted-engine-setup.log (870.89 KB, text/plain)
2017-02-16 08:22 UTC, Yihui Zhao
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1114 0 normal SHIPPED_LIVE redhat-virtualization-host bug fix and enhancement update 2017-04-20 22:57:46 UTC

Description Jake Hunsaker 2017-02-10 18:08:22 UTC
Description of problem:

When deploying a new 4.1 hosted engine VM via cockpit, if the user has not already accepted the RH GPG keys from a previous yum command, you cannot finish the deployment via the cockpit interface on a 4.1 RHV-H. 

The installer will hang on the following from any yum command:

Please confirm 'GPG_KEY' Confirm use of GPG Key userid=Red Hat, Inc. (release key 2) <security@redhat.com> hexkeyid=FD431D51
Response is CONFIRM GPG_KEY=yes|no or ABORT GPG_KEY

Version-Release number of selected component (if applicable):
4.1 beta
RHVH-4.1-20170203.1-RHVH-x86_64-dvd1.iso

How reproducible:
100%

Steps to Reproduce:
1. Deploy the RHV-H node
2. Attempt to deploy a hosted engine straight from the cockpit interface
3.

Actual results:
Cockpit interface will hang indefinitely on the above GPG confirmation request

Expected results:
There should either be a way to accept the GPG keys, or the installer should auto-accept the RH keys.

Additional info:

For reference, when running hosted-engine --deploy manually on the RHV-H, I can still properly accept the keys without having to abort the installer.

Comment 1 Ryan Barry 2017-02-10 18:50:15 UTC
How is the package being found? I would expect that a signed package (from channels) doesn't need this.

Cockpit has no logic. It's just stdin and stdout of ovirt-hosted-engine-setup. If this outputs to stderr, it may be missed. I'll check that next week. But I would guess this is not reproducible on a "live" environment

Comment 2 Sandro Bonazzola 2017-02-14 09:00:42 UTC
This bug has been reported also on oVirt during yesterday oVirt Workshop by Stefano Stagnaro.
GPG keys are correctly installed on the system but in order to be able to use them a rpm --import of the keys.
Not sure if this is an anaconda / livemedia creator bug or a node / imgbased issue.

Comment 5 Ryan Barry 2017-02-14 14:00:09 UTC
(In reply to Sandro Bonazzola from comment #2)
> This bug has been reported also on oVirt during yesterday oVirt Workshop by
> Stefano Stagnaro.
> GPG keys are correctly installed on the system but in order to be able to
> use them a rpm --import of the keys.
> Not sure if this is an anaconda / livemedia creator bug or a node / imgbased
> issue.

I'll check today.

My initial inclination is the same as the first comment, though. This is not likely to be a bug in anaconda/livemedia-creator or node/imgbased.

The prompt to accept GPG keys only happens if the keys are not present in /etc/pki/rpm-gpg. node/imgbased don't change this at all.

I'll make sure the keys are there, but this is either missing keys (installation not from a channel downstream, missing keys in ovirt-release upstream) or a change in the behavior of yum.

There are very strong odds that this is also reproducible with cockpit-ovirt on RHEL.

We can probably work around this in cockpit by attaching to stderr, as I'd guess the message is going there rather than stdout, but this behavior should not be happening in the first place.

Comment 6 Yihui Zhao 2017-02-15 07:15:31 UTC
I can't reproduce the bug.

Version-Release number of selected component (if applicable):
rhvh-4.1-0.20170208.0+1

Steps to Reproduce:

1. Install RHVH4.1
2. Subscribe to RHN (enable repos)
3. Deploy HE via cockpit
4. 

After step3, I will download the rhvm-appliance*.rpm with yum command via cockpit,
it worked well and don't reproduce the issue.

Additional info:
I don't find the iso : RHVH-4.1-20170203.1-RHVH-x86_64-dvd1.iso.

Comment 8 Sandro Bonazzola 2017-02-15 13:18:55 UTC
*** Bug 1422136 has been marked as a duplicate of this bug. ***

Comment 9 Yaniv Lavi 2017-02-15 13:24:14 UTC
Since there is a easy workaround of using the CLI instead of Cockpit, I'm lowering the priority. We should fix this as soon as we can, but this is not blocking.

Comment 10 Yihui Zhao 2017-02-16 01:18:38 UTC
Can  reproduce the bug with the iso:RHVH-4.1-20170203.1-RHVH-x86_64-dvd1.iso

Version-Release number of selected component (if applicable):
RHVH-4.1-20170203.1-RHVH-x86_64-dvd1.iso

Steps to Reproduce:
1. Install RHVH4.1
2. Subscribe to RHN (enable repos)
3. Deploy HE via cockpit
4. 

After step3, the bug was reproduced . and cockpit was hung.

Please confirm 'GPG_KEY' Confirm use of GPG Key userid=Red Hat, Inc. (release key 2) <security@redhat.com> hexkeyid=FD431D51
Response is CONFIRM GPG_KEY=yes|no or ABORT GPG_KEY

Comment 11 Yihui Zhao 2017-02-16 01:19:36 UTC
Created attachment 1250753 [details]
cockpit_gpg.png

Comment 12 Yihui Zhao 2017-02-16 01:21:23 UTC
(In reply to Yihui Zhao from comment #11)
> Created attachment 1250753 [details]
> cockpit_gpg.png

The cockpit was hung with picture :

https://bugzilla.redhat.com/attachment.cgi?id=1250753&action=edit

Comment 13 Yedidyah Bar David 2017-02-16 06:55:23 UTC
Ryan told me in private that the problem is probably related to otopi's machine dialog. Can you please attach ovirt-hosted-engine-setup logs of a reproduction? Thanks.

Comment 14 Yihui Zhao 2017-02-16 08:22:26 UTC
Created attachment 1250799 [details]
ovirt-hosted-engine-setup.log

Comment 15 Yihui Zhao 2017-02-16 08:23:16 UTC
(In reply to Yedidyah Bar David from comment #13)
> Ryan told me in private that the problem is probably related to otopi's
> machine dialog. Can you please attach ovirt-hosted-engine-setup logs of a
> reproduction? Thanks.

ovirt-hosted-engine-setup.log :

https://bugzilla.redhat.com/attachment.cgi?id=1250799

Comment 16 Yedidyah Bar David 2017-02-16 09:04:15 UTC
Thanks.

Bottom of the log is:

2017-02-16 08:19:10 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND       ***CONFIRM GPG_KEY Confirm use of GPG Key userid=Red Hat, Inc. (release key 2) <security@redhat.com> hexkeyid=FD431D51
2017-02-16 08:19:10 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND       ###
2017-02-16 08:19:10 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND       ### Please confirm 'GPG_KEY' Confirm use of GPG Key userid=Red Hat, Inc. (release key 2) <security@redhat.com> hexkeyid=FD431D51
2017-02-16 08:19:10 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND       ### Response is CONFIRM GPG_KEY=yes|no or ABORT GPG_KEY

Seems to be in accordance with otopi's README.dialog. Ryan - please open a bug on otopi if anything is missing. Admittedly, we didn't change anything in this code when adapting otopi to cockpit/node-ng, but it might be good enough as-is. Thanks.

For current bug, if possible, it might be better, security-wise, to include the key in the image.

Comment 17 Ryan Barry 2017-02-16 13:08:41 UTC
We do include the key in the image, but including it in /etc/pki/rpm-gpg does not seem to automatically accept it.

Using ***CONFIRM is clear enough, it's just somewhat ugly to parse this out, since otopi's machine dialog otherwise puts "visible' messages under ###, and "Response is CONFIRM GPG_KEY=yes|no or ABORT GPG_KEY" is particularly ugly to show to users.

There is no **%QStart or **%QDefault here, so those need to be parsed out separately.

This isn't really complicated to do, and the current patch does it, but it's inconsistent otherwise.

Comment 18 Yedidyah Bar David 2017-02-16 13:34:42 UTC
(In reply to Ryan Barry from comment #17)
> We do include the key in the image, but including it in /etc/pki/rpm-gpg
> does not seem to automatically accept it.

Perhaps something like 'rpmkeys --import' helps?

> 
> Using ***CONFIRM is clear enough, it's just somewhat ugly to parse this out,
> since otopi's machine dialog otherwise puts "visible' messages under ###,
> and "Response is CONFIRM GPG_KEY=yes|no or ABORT GPG_KEY" is particularly
> ugly to show to users.

So your problem isn't parsing '***CONFIRM', but to prevent the '###' notes from showing. I think nothing currently relies on them, so we might be able to drop or replace them. These are from two places [1] [2], please say what you want.

In principle, these are useful for debugging, and also if someone wants for some reason to run host-deploy manually (and not through the engine).

[1] https://gerrit.ovirt.org/gitweb?p=otopi.git;a=blob;f=src/plugins/otopi/packagers/yumpackager.py;h=d51c0127d45d07c16460e2c807ced13d4deda34b;hb=HEAD#l95
[2] https://gerrit.ovirt.org/gitweb?p=otopi.git;a=blob;f=src/plugins/otopi/dialog/machine.py;h=604db829d4992ced836531bf16bfb54bb53fdcb1;hb=HEAD#l363

> 
> There is no **%QStart or **%QDefault here, so those need to be parsed out
> separately.

The 'Q' is 'Query', and this isn't one :-) We can add CStart, CEnd, etc., if you want.

> 
> This isn't really complicated to do, and the current patch does it, but it's
> inconsistent otherwise.

Not sure why it was added initially, but it's hardly used - AFAICS only in dnf/yum packages in otopi and once in host-deploy. In setup code we use queryBoolean, which is in ovirt-setup-lib. It wraps queryString, so behaves like any other Query.

If it can be postponed to 4.2, we can probably get rid of 'confirm' and replace calls to it with queryString. I'd not do this for 4.1, though, especially if 'rpmkeys' solves your current problem.

Comment 19 Ryan Barry 2017-02-17 14:19:45 UTC
*** Bug 1423454 has been marked as a duplicate of this bug. ***

Comment 22 Yihui Zhao 2017-03-08 02:41:05 UTC
Test result: Yum successfully and deploy HE successfully

Version:
cockpit-ovirt-dashboard-0.10.7-0.0.11.el7ev.noarch
rhvh-4.1-0.20170223.0+1
ovirt-hosted-engine-ha-2.1.0.3-1.el7ev.noarch
ovirt-host-deploy-1.6.1-1.el7ev.noarch
ovirt-hosted-engine-setup-2.1.0.3-1.el7ev.noarch



Test steps:
1. Install RHVH4.1 via PXE
2. Subscibe with correct account and password via cockpit
3. Enable needed repos via CLI 
[root@dell-per730-35 ~]# subscription-manager repos --list-enabled |grep "Repo ID"
Repo ID:   rhel-7-server-rhvh-4-debug-rpms
Repo ID:   rhel-7-server-rhvh-4-beta-source-rpms
Repo ID:   rhel-7-server-rhvh-4-beta-debug-rpms
Repo ID:   rhel-7-server-rhvh-4-beta-rpms
Repo ID:   rhel-7-server-rhvh-4-source-rpms
Repo ID:   rhel-7-server-rhvh-4-rpms

4. Deploy HE via cockpit without pre-install engine-appliance,and download the rpm via cockpit.

After step 4, download the rpm successfully and deploy HE successfully.

So the bug's status is verified.

Comment 23 Emma Heftman 2017-03-22 13:25:30 UTC
Hi Ryan. Please set the requires_doc_text flag to - or to ? and then add the text. Thanks

Comment 24 errata-xmlrpc 2017-04-20 19:03:25 UTC
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.

https://access.redhat.com/errata/RHEA-2017:1114


Note You need to log in before you can comment on or make changes to this bug.