Bug 855624 - RHEV Tools- Log Collector - root password is asked 3 * (# of hosts) + 1 times. very annoying. due to missing SSH key during host installtion
RHEV Tools- Log Collector - root password is asked 3 * (# of hosts) + 1 times...
Status: CLOSED DUPLICATE of bug 837690
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-config (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Alon Bar-Lev
Pavel Stehlik
infra integration
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-09 08:06 EDT by Barak Dagan
Modified: 2014-07-13 19:18 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-27 06:09:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log collector's log (70.50 MB, application/x-xz)
2012-09-09 08:36 EDT, Barak Dagan
no flags Details
working bootstrap log (6.61 KB, application/x-gzip)
2012-09-27 06:01 EDT, Barak Dagan
no flags Details

  None (edit)
Description Barak Dagan 2012-09-09 08:06:54 EDT
Description of problem:
As can be seen from the copied shell, the utility askes for root password for each host 4 times (all of the hosts are joined in te first line).


[root@fire-vdc ~]# rhevm-log-collector collect
Please provide the REST API password for the admin@internal RHEV-M user (CTRL+D to skip): 
About to collect information from 2 hypervisors. Continue? (Y/n): y
INFO: Gathering information from selected hypervisors...
INFO: collecting information from puma31.scl.lab.tlv.redhat.com
INFO: collecting information from puma32.scl.lab.tlv.redhat.com
root@puma32.scl.lab.tlv.redhat.com's password: root@puma31.scl.lab.tlv.redhat.com's password: 
root@puma32.scl.lab.tlv.redhat.com's password: 
root@puma31.scl.lab.tlv.redhat.com's password: 
root@puma32.scl.lab.tlv.redhat.com's password: 
root@puma31.scl.lab.tlv.redhat.com's password: 
root@puma32.scl.lab.tlv.redhat.com's password: 
root@puma31.scl.lab.tlv.redhat.com's password: 
INFO: finished collecting information from puma32.scl.lab.tlv.redhat.com


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Barak Dagan 2012-09-09 08:36:51 EDT
Created attachment 611213 [details]
Log collector's log
Comment 2 Keith Robertson 2012-09-09 10:26:26 EDT
This is not a LC bug it is a problem with the installer, with the way the hypervisor was registered, or both.

The LC uses key based authorization to the hypervisors.  The private key used by the LC is /etc/pki/ovirt-engine/keys/engine_id_rsa.  If this private does not have an associated public key in the hypervisor's /root/.ssh/authorized_key2 file you *will* get prompted for a password, plain and simple, and you will get prompted multiple times (the man page documents this behavior).


You can independently verify a mismatch between the RHEV-M's private key and the hypervisor by executing the following SSH command.  If you get prompted for a password you have a mismatch:



ssh -i /etc/pki/ovirt-engine/keys/engine_id_rsa root@<hypervisor here>
Comment 3 Oded Ramraz 2012-09-11 05:30:36 EDT
We are using RHEL hosts . The keys do not appear in the hosts authorized keys file under /root/.ssh . 
I'm not sure that this is installer issue , or maybe you meant bootstrap issue ? 

(In reply to comment #2)
> This is not a LC bug it is a problem with the installer, with the way the
> hypervisor was registered, or both.
> 
> The LC uses key based authorization to the hypervisors.  The private key
> used by the LC is /etc/pki/ovirt-engine/keys/engine_id_rsa.  If this private
> does not have an associated public key in the hypervisor's
> /root/.ssh/authorized_key2 file you *will* get prompted for a password,
> plain and simple, and you will get prompted multiple times (the man page
> documents this behavior).
> 
> 
> You can independently verify a mismatch between the RHEV-M's private key and
> the hypervisor by executing the following SSH command.  If you get prompted
> for a password you have a mismatch:
> 
> 
> 
> ssh -i /etc/pki/ovirt-engine/keys/engine_id_rsa root@<hypervisor here>
Comment 4 Alon Bar-Lev 2012-09-11 05:51:26 EDT
Oded, are you sure that right after bootstrap, the ~/.ssh/authorized_keys does not contain engine key?
Comment 5 Barak Dagan 2012-09-16 04:04:44 EDT
(In reply to comment #4)
> Oded, are you sure that right after bootstrap, the ~/.ssh/authorized_keys
> does not contain engine key?

yes, we are sure. In fact, the is a time out in that part when re0installing the host
Comment 6 Alon Bar-Lev 2012-09-16 05:36:05 EDT
Please open a different bug if there is a time out.

If there is a timeout - of course no ssh key will be installed, no need to discuss this here.

Discussing two issue at same bug will not make bug resolved faster.

Still don't understand...

What I expect:

1. A clear statement that there is a successful bootstrap.

2. After (1) missing key in authorized_keys.

3. Some hint if this is local problem for this server or generic problem.

Thanks.
Comment 7 Rami Vaknin 2012-09-27 05:24:24 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Oded, are you sure that right after bootstrap, the ~/.ssh/authorized_keys
> > does not contain engine key?
> 
> yes, we are sure. In fact, the is a time out in that part when re0installing
> the host

Oded, Alon, this vds machine is under foreman control which has a puppet modules that overrides /root/.ssh/authorized_keys so never expect this file to keep any changes, puppet runs every 30 minutes and overrides it!!!
Comment 8 Barak Dagan 2012-09-27 06:01:17 EDT
Created attachment 617982 [details]
working bootstrap log
Comment 9 Barak Dagan 2012-09-27 06:09:37 EDT
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Oded, are you sure that right after bootstrap, the ~/.ssh/authorized_keys
> > > does not contain engine key?
> > 
> > yes, we are sure. In fact, the is a time out in that part when re0installing
> > the host
> 
> Oded, Alon, this vds machine is under foreman control which has a puppet
> modules that overrides /root/.ssh/authorized_keys so never expect this file
> to keep any changes, puppet runs every 30 minutes and overrides it!!!

1) According to rami's comment, the issue is ont a bug but configuration.
2) As for the TO during bootstrap process, I tried to install the same host with newer version (si18.1), and it worked, log-collector worked smoothly as well.
Comment 10 Alon Bar-Lev 2012-09-27 07:26:47 EDT

*** This bug has been marked as a duplicate of bug 837690 ***

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