9:44 a.m.
On Sun, Dec 6, 2020 at 7:25 PM Derek Atkins <derek(a)ihtfp.com> wrote:
HI,
On Sun, December 6, 2020 7:44 am, Yedidyah Bar David wrote:
> On Sun, Dec 6, 2020 at 12:34 AM Derek Atkins <derek(a)ihtfp.com> wrote:
[snip]
>> So.... Is there a command-line way to re-enroll manually and update the
>> host certs?
>
> I don't think you'll find anything like this.
>
> People did come up in the past with various procedure to hack pki like
> what
> you want, but these are, generally speaking, quite fragile - usually do
> not
> get updated over versions etc.
>
> I am pretty certain the only way to do this using "official" tools/docs
> is:
>
> 1. Stop all VMs except for the engine one.
>
> 2. Take a backup with engine-backup.
>
> 3. Stop the engine VM.
>
> 4. Reinstall the host OS from scratch or use ovirt-hosted-engine-cleanup.
>
> 5. Provision the host again as a hosted-engine host, using
> '--restore-from-file'.
> Either using new storage for the engine, or after cleaning up the existing
> hosted-engine storage.
If I were to go this route I might as well upgrade to EL8 / 4.4 at the
same time. However, I would rather not do that; I consider that a very
dangerous operation, with a generally too-high probability of failure.
I assume you'll do that anyway, some time later, no? So why not now?
I think 4.4.3 is a pretty good version.
I agree it's "dangerous" in the sense that it involves lots of rather
complex actions, some of which are hard to debug/fix if they fail.
But: You can plan and test ahead on a test machine somewhere - even
a VM, with nested-kvm. Just make sure it has no access to your host
and storage (network-wise), so that it does not try to manage/access
them.
> If you still want to try doing this manually, then the tool to use is
> pki-enroll-request.sh. IIRC it's documented. You should find what
> keys/certs
> you want to replace, generate new keys and CSRs (or use existing keys and
> generate CSRs, or even use existing CSRs if you find them), copy to the
> engine,
> sign with pki-enroll-request.sh, then copy the generated cert to the host.
Thanks. I will look into this method.
> I am
> almost certain there is no way to tell vdsm (and other processes) to
> reload
> the certs, so you'll have to restart it (them) - and this usually
> requires putting
> the host in maintenance (and therefore stop (migrate) all VMs).
I don't mind stopping the VMs in order to reboot the host if I can plan
that. My understanding is that because there is no place to migrate the
hosted-engine, that implies even I stop all the other VMs, I still cannot
put the host into maintenance mode. Is my understanding correct?
You are right - for a single host, you should do something like this:
1. Stop all VMs except for the engine
2. Put it to global maintenance
3. Stop the engine VM ('poweroff' from inside it, or 'hosted-engine
--vm-shutdown')
4. Restart whatever services you want, or just reboot
5. Exit global maintenance
6. Engine VM should be started automatically in a few minutes. If it
does not, you
can 'hosted-engine --vm-start'. You can monitor agent.log in the meanwhile.
>> Or some other way to get all the leftover certs renewed?
>
> Which ones, specifically?
I think I listed them all: <host>*.cer and vmconsole*.cer on the engine,
and of course everything on the host itself.
engine-setup is not designed to touch hosts.
Hosts should be managed by the engine, usually.
Does it matter that ca.der didn't change? I don't know if that is a
self-signed cert that might be problematic?
ca.der is not used by anything, you can ignore it. The private key of
the CA is in /etc/pki/ovirt-engine/private/ca.pem, and the public key
is in /etc/pki/ovirt-engine/ca.pem. That's what all tools use.
>>
>> Thanks,
>>
>> -derek
>>
>> [1] Not only did it not update the Host's cert, it did not update any of
>> the vmconsole-proxy certs, nor the certs in /etc/pki/ovirt-vmconsole/,
>> and
>> obviously nothing in /etc/pki/ on the host itself.
>
> AFAIR no process uses these certs as such. There are only processes that
> use
> the ssh-format keys extracted from them, which do not include a signature
> (sha1 or whatever).
>
> If you think I am wrong, and/or notice other certs that need to be
> regenerated,
> that's a bug - please open one. Thanks!
I have not noticed anything, yet, but I have not restarted the host or
vdsm since I re-ran engine-setup.
> Re remote-viewer/spice: You didn't say if you tried again after
> engine-setup
> and what happened. In any case, this is unrelated to vmconsole (which is
> for
> serial consoles, using ssh). But you might still need to regenerate the
> host
> cert.
Sorry, I thought I did. Yes, I did try re-running remote-viewer after
running engine-setup. There was no change in the console.vv file (except
of course for the password and sso-token), so yes, it failed in the same
way.
Note, however, that I did not restart vdsm or the host after running
engine-setup.
OK.
> BTW: You can try using novnc and websocket-proxy - engine-setup does
> update
> the cert for the latter, so this might work as-is.
Yes, that does work indeed, so as a short-term solution that can work for
me. I'll ask my colleague on a Mac if that works for him.
But it would be nice to get remote-viewer working, IMHO, which would
require a way to renew / refresh the host cert -- which of course would be
nice to do without having to re-install!
I agree it would be nice, but I think it would require quite a lot of work.
Generally speaking, the project considers the "standard" use case to be a
setup of at least two hosts, and at least one host "extra" (in terms of
capacity), so that if a host fails, you can still keep everything up. In
that regard, a single-host setup is considered a kind of "corner case",
meant mainly for testing/development, not production. Is there such a big
advantage in using oVirt for a single host, compared to virt-manager?
Good luck and best regards,
--
Didi