On Sun, Dec 6, 2020 at 7:25 PM Derek Atkins <[email protected]> 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 <[email protected]> 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
_______________________________________________
Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/[email protected]/message/X6QMM72ZC6GQGDGUPBMPE2TPINK5MU5U/
