3:38 p.m.
On 03/12/2014 07:05 AM, Vojtech Szocs wrote:
----- Original Message -----
> From: "Keith Robertson" <kroberts(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)redhat.com>, "Sandro Bonazzola"
> <sbonazzo(a)redhat.com>
> Sent: Tuesday, March 11, 2014 7:13:08 PM
> Subject: Re: Small suggestions for engine-log-collector
>
>
>
> ----- Original Message -----
>> From: "Vojtech Szocs" <vszocs(a)redhat.com>
>> To: "engine-devel" <engine-devel(a)ovirt.org>
>> Cc: "Keith Robertson" <kroberts(a)redhat.com>, "Einav
Cohen"
>> <ecohen(a)redhat.com>
>> Sent: Tuesday, March 11, 2014 1:57:11 PM
>> Subject: Small suggestions for engine-log-collector
>>
>> Hi guys,
>>
>> based on my testing during last week's oVirt 3.4 RC test day [1],
>> I have a couple of small suggestions for engine-log-collector:
>>
>> 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
>>
>> #key-file=/etc/pki/engine/keys/engine_id_rsa
>>
>> should be:
>>
>> #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
>>
>
> ACK
http://gerrit.ovirt.org/#/c/25653/
>
>
>> 2, to force password-based ssh auth, one has to do this:
>>
>
> In the normal scenario, the the ovirt user's public key should be installed
> into each hypervisor. Unless something has changed as a part of the
> hypervisor registration process this should be something that we can depend
> upon.
My host was F19 VM added to oVirt Engine via WebAdmin GUI. I thought that
host deploy script should do the public key registration, though.
I'm pretty sure that public key registration used to be part of the
deploy script. If this is no longer the case it is a fairly major
supportability issue.
>
> Clearly, there are edge cases where you need to collect logs from a
> hypervisor that isn't properly registered with the RHEV-M. Was this your
> situation and how common do you think this scenario is?
It was either a misconfiguration on my part or that I skipped some step with
regard to public key registration.
Understand.
The reason why we bias the LC towards public key auth and fall back to
PW auth is that the LC needs to make multiple calls[1] to each
Hypervisor and, if you're not using public key auth it is definitely a
sub-optimal usage experience. Multiply [1] times the N number of
hyper-visors and the user's annoyance factor will surely reach a boiling
point. ;)
[1]
- 1 ssh call to launch sos
- 1 sftp call to get the report and remove it from /tmp
>
>> engine-log-collector -k ""
>>
>
> Yes, you are nulling out the default value which causes the LC to prompt you
> for a PW. Perhaps we should document this as opposed to supplying a
> specific option? Sandro?
Well, the doc text says "If a identity file is not supplied..." which I
understood as not supplying option value (i.e. "") at all, but this was
just my understanding.
Your understanding is correct and you forced the tool not to find the
default identity file with a clever null argument.
There's nothing wrong with this usage per-se and maybe we should either
document it or provide an explicit option to force PW auth.
>
>> because running this:
>>
>> engine-log-collector -k
>>
>> returns error message:
>>
>> error: -k option requires an argument
>>
>> however, help for -k option mentions *supplying* the argument:
>>
>> If a identity file is not supplied the program will prompt for a
>> password.
>>
>> so either the help text should mention empty string,
>> or -k option should allow missing argument (this was
>> my initial understanding according to help text)
>>
>> Since these are just small things, I'm wondering if I should
>> create RFE or if Keith/others can say if they are relevant.
>>
>> Thanks,
>> Vojtech
>>
>> [1] http://etherpad.ovirt.org/p/3.4-testday-3
>>
>
--
Keith Robertson
Supervisor, Software Engineering
Red Hat Subscription Engineering