On Sun, Jun 7, 2020 at 6:37 PM Michael Thomas
> 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>
>>>>> 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
>>> 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
>> 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.
I agree it's not detailed enough.
We have it briefly mentioned e.g. here:
For some reason it's marked "Optional", not sure why.
> * 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.