On 6/7/20 8:42 AM, Yedidyah Bar David wrote:
On Sun, Jun 7, 2020 at 4:07 PM Michael Thomas
<wart(a)caltech.edu> wrote:
>
> On 6/7/20 5:01 AM, Yedidyah Bar David wrote:
>> On Sat, Jun 6, 2020 at 8:42 PM Michael Thomas <wart(a)caltech.edu> wrote:
>>>
>>> After a week of iterations, I finally found the problem. I was setting
'PermitRootLogin no' in the global section of the bare metal OS sshd_config, as we
do on all of our servers. Instead, PermitRootLogin is set to 'without-password'
in a match block to allow root logins only from a well-known set of hosts.
I understand that you meant to say that this is already working for
you, right? That you set it to allow without-password from some
addresses and that that was enough. If so:
Correct. Once I added the engine's IP to the Match block allowing root
logins, it worked again.
>>
>> Thanks for the report!
>>
>>>
>>> Can someone explain why setting 'PermitRootLogin no' in the
sshd_config on the hypervisor OS would affect the hosted engine deployment?
>>
>> Because the engine (running inside a VM) uses ssh as root to connect
>> to the host (in which the engine vm is running).
>
> Would it be sufficient to set, on the host, 'PermitRootLogin
> without-password' in a Match block that matches the ovirt management
> network?
>
> Match Address 10.10.10.0/24
> PermitRootLogin without-password
>
> ?
Do you mean here to ask if 10.10.10.10/24 is enough?
The engine VM's IP address should be enough. What this address is,
after deploy finishes, is of course up to you. During deploy it's by
default in libvirt's default network, 192.168.222.0/24, but can be
different if that's already in use by something else (e.g. a physical
NIC).
BTW, I didn't test this myself. I do see in the code that it's
supposed to work. If you find a bug, please report one. Thanks.
I think the two problems that I ran into were:
* Lack of documentation about the requirement that the engine (whether
self-hosted or standalone) be able to ssh into the bare metal hypervisor
host over the ovirt management network using ssh keys.
* No clear error message in the logs describing why this was failing.
The only errors I got were a timeout waiting for the host to be up, and
a generic ""The system may not be provisioned according to the playbook
results: please check the logs for the issue, fix accordingly or
re-deploy from scratch.\n"
I'll file this as a documentation bug.
--Mike