On Sun, Dec 6, 2020 at 7:25 PM Derek Atkins <derek@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@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