On Sun, Jun 7, 2020 at 6:37 PM Michael Thomas <wart(a)caltech.edu> wrote:
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.
Thanks and best regards,