Cannot log into oVirt Manager - certificate issue
I cannot log into oVirt Manager. My browser gave me a warning that the site's certificate has expired. Then when I try to log in, I receive the following error message: "PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed" How can I fix this problem? In advance, thank you for your help. hosted-engine: v4.4.8.6 hosts: oVirt Node v4.4.8.3
On Sun, Jan 30, 2022 at 8:16 PM Diggy Mc <d03@bornfree.org> wrote:
I cannot log into oVirt Manager. My browser gave me a warning that the site's certificate has expired.
If it's a certificate created by engine-setup for you, you can run 'engine-setup' and it can recreate it for you. If you do not want to update the system, you can run it with 'engine-setup --offline'. Otherwise, if it's a certificate you got elsewhere, you should update it manually, perhaps following some of the steps of the procedure to replace the certificate - the one you followed originally.
Then when I try to log in, I receive the following error message:
"PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed"
This is normal in this state. After you update the cert, you might need to restart the engine ('systemctl restart ovirt-engine'), not sure.
How can I fix this problem? In advance, thank you for your help.
Good luck and best regards, -- Didi
On Sun, Jan 30, 2022 at 8:16 PM Diggy Mc <d03(a)bornfree.org> wrote:
If it's a certificate created by engine-setup for you, you can run 'engine-setup' and it can recreate it for you. If you do not want to update the system, you can run it with 'engine-setup --offline'. Otherwise, if it's a certificate you got elsewhere, you should update it manually, perhaps following some of the steps of the procedure to replace the certificate - the one you followed originally.
Good luck and best regards,
It is the original certificate created during initial install/setup. If possible, I would like to have another oVirt generated certificate without upgrading the engine's version. Where can I find instructions on how to do that? What would be the pros and cons of generating my own self-signed certificate with a longer validity period? Where can I find instructions on that? Again, thanks for your help.
On Mon, Jan 31, 2022 at 6:06 PM Diggy Mc <d03@bornfree.org> wrote:
On Sun, Jan 30, 2022 at 8:16 PM Diggy Mc <d03(a)bornfree.org> wrote:
If it's a certificate created by engine-setup for you, you can run 'engine-setup' and it can recreate it for you. If you do not want to update the system, you can run it with 'engine-setup --offline'. Otherwise, if it's a certificate you got elsewhere, you should update it manually, perhaps following some of the steps of the procedure to replace the certificate - the one you followed originally.
Good luck and best regards,
It is the original certificate created during initial install/setup. If possible, I would like to have another oVirt generated certificate without upgrading the engine's version. Where can I find instructions on how to do that? What would be the pros and cons of generating my own self-signed certificate
Generally speaking, this is recommended. The main "con" is simply that it requires some work and responsibility.
with a longer validity period?
You already linked to the pki-renew page. This one links at several bugs, which link to several patches, which (also) explain the reasoning, also linking e.g. at: https://www.thesslstore.com/blog/ssl-certificate-validity-will-be-limited-to... https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/ Latter is old, this one is newer (found by searching their site for "398 days"): https://cabforum.org/2021/04/22/ballot-sc42-398-day-re-use-period/
Where can I find instructions on that?
https://www.ovirt.org/documentation/administration_guide/#appe-Red_Hat_Enter... Actually creating your own CA and signing certs with it is not in the scope of this document. You can search the net and find several guides on how to do that, or you can use the services of an existing CA - letsencrypt is quite popular these days, being free (gratis).
Again, thanks for your help.
Good luck and best regards, -- Didi
Hello, On Tue, Feb 1, 2022 at 8:46 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Jan 31, 2022 at 6:06 PM Diggy Mc <d03@bornfree.org> wrote:
On Sun, Jan 30, 2022 at 8:16 PM Diggy Mc <d03(a)bornfree.org>
If it's a certificate created by engine-setup for you, you can run 'engine-setup' and it can recreate it for you. If you do not want to update the system, you can run it with 'engine-setup --offline'. Otherwise, if it's a certificate you got elsewhere, you should update it manually, perhaps following some of the steps of the procedure to replace the certificate - the one you followed originally.
Good luck and best regards,
It is the original certificate created during initial install/setup. If
wrote: possible, I would like to have another oVirt generated certificate without upgrading the engine's version. Where can I find instructions on how to do that?
What would be the pros and cons of generating my own self-signed certificate
Generally speaking, this is recommended. The main "con" is simply that it requires some work and responsibility.
with a longer validity period?
You already linked to the pki-renew page. This one links at several bugs, which link to several patches, which (also) explain the reasoning, also linking e.g. at:
https://www.thesslstore.com/blog/ssl-certificate-validity-will-be-limited-to... https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/
Latter is old, this one is newer (found by searching their site for "398 days"):
https://cabforum.org/2021/04/22/ballot-sc42-398-day-re-use-period/
Where can I find instructions on that?
https://www.ovirt.org/documentation/administration_guide/#appe-Red_Hat_Enter...
Actually creating your own CA and signing certs with it is not in the scope of this document. You can search the net and find several guides on how to do that, or you can use the services of an existing CA - letsencrypt is quite popular these days, being free (gratis).
Again, thanks for your help.
Good luck and best regards, -- Didi
Unlike my predecessor, I not only lost my vmengine, I also lost the vdsm services on all hosts. All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode, preventing engine-setup --offline from running. Two questions: 1. Is there any automated method to renew the vdsm certificates? 2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them? Thanks, Gilboa
So, what is the problem in restorib the engine from backup ? Best Regards,Strahil Nikolov On Sun, Feb 6, 2022 at 17:30, Gilboa Davara<gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/P3QPMCCZJCS3BC...
On Sun, Feb 6, 2022 at 9:50 PM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
So, what is the problem in restorib the engine from backup ?
Might work as well. When using --restore-from-file, it prompts you asking whether PKI should be renewed if needed. Reply 'yes' and you should be ok, on the engine and on the reinstalled host. I didn't try this myself, though. Best regards, -- Didi
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the vdsm services on all hosts. All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for: https://bugzilla.redhat.com/show_bug.cgi?id=1700460 But: If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine? I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort. If this is really what you want, I suggest something like: 1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.) You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI. Good luck and best regards, -- Didi
Hello, On Mon, Feb 7, 2022 at 8:45 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the vdsm
services on all hosts.
All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
Failed, stating the cluster is not in global maintenance mode. (Understandable, given two of 3 hosts were offline due to certificate issues...)
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for:
https://bugzilla.redhat.com/show_bug.cgi?id=1700460
But:
If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine?
I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort.
If this is really what you want, I suggest something like:
1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed
You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.)
You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI.
Good luck and best regards,
I more of less found a document stating the above somewhere in the middle of the night. Tried it. Got the WebUI working again. However, for the life of me I couldn't get the hosts to work to talk to the engine. (Even though I could use openssl s_client -showcerts -connect host and got valid certs). In the end, @around ~4am, I decided to take the brute force route, clean the hosts, upgrade them to -streams, and redeploy the engine again (3'rd attempt, after sufficient amount of coffee reminded me the qemu-6.1 is broken, and needed to be downgraded before trying to deploy the HE...). Either way, when I finish importing the VMs, I'll open a RFE to add BIG-WARNING-IN-BOLD-LETTERS in the WebUI to notify the admin that the certificates are about to expire. Thanks for the help! - Gilboa
-- Didi
On Mon, Feb 7, 2022 at 1:27 PM Gilboa Davara <gilboad@gmail.com> wrote:
Hello,
On Mon, Feb 7, 2022 at 8:45 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the vdsm services on all hosts. All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
Failed, stating the cluster is not in global maintenance mode.
Please clarify, and/or share relevant logs, if you have them. You had a semi-working existing HE cluster. You ran engine-backup on it, took a backup, while it was _not_ in global maintenance. That's ok and expected. Then you took one of the hosts and evacuated it (or just a new one), (re)installed the OS (or somehow cleaned it up), and ran 'hosted-engine --deploy --import-from-file' with the backup you took. This failed? Where exactly and with what error? If it's the engine-setup running inside the engine VM, with the same error as when running 'engine-setup' (perhaps with --offline) manually, then this shouldn't happen at this point: - engine-backup --mode=restore sets vdc option in the db 'DbJustRestored' - engine-setup checks this and sets its own env[JUST_RESTORED] accordingly
(Understandable, given two of 3 hosts were offline due to certificate issues...)
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for:
https://bugzilla.redhat.com/show_bug.cgi?id=1700460
But:
If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine?
I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort.
If this is really what you want, I suggest something like:
1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed
You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.)
You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI.
Good luck and best regards,
I more of less found a document stating the above somewhere in the middle of the night. Tried it. Got the WebUI working again. However, for the life of me I couldn't get the hosts to work to talk to the engine. (Even though I could use openssl s_client -showcerts -connect host and got valid certs). In the end, @around ~4am, I decided to take the brute force route, clean the hosts, upgrade them to -streams, and redeploy the engine again (3'rd attempt, after sufficient amount of coffee reminded me the qemu-6.1 is broken, and needed to be downgraded before trying to deploy the HE...). Either way, when I finish importing the VMs, I'll open a RFE to add BIG-WARNING-IN-BOLD-LETTERS in the WebUI to notify the admin that the certificates are about to expire.
You should have already received them, no? https://bugzilla.redhat.com/show_bug.cgi?id=1258585 Best regards, -- Didi
Hello, On Mon, Feb 7, 2022 at 2:25 PM Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Feb 7, 2022 at 1:27 PM Gilboa Davara <gilboad@gmail.com> wrote:
Hello,
On Mon, Feb 7, 2022 at 8:45 AM Yedidyah Bar David <didi@redhat.com>
wrote:
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the
vdsm services on all hosts.
All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
Failed, stating the cluster is not in global maintenance mode.
Please clarify, and/or share relevant logs, if you have them.
Sadly enough, no. When I zapped the old vmegine and hosts configuration, I forgot to save the logs. (In my defense, it was 4am...) That said, the fix proposed in BZ#1700460 (Let the user skip the global maintenance check) might have saved my cluster.
You had a semi-working existing HE cluster. You ran engine-backup on it, took a backup, while it was _not_ in global maintenance.
It was rather odd. One of the hosts was still active and running the HE engine. After I updated the apache certs, I could connect to the WebUI, but the WebUI failed to access the nodes, spewing SSL handshake errors. I then processed to replace the hosts certs, which seems to work, (E.g. vdsm-client Host getCapabilities worked), hosted-engine --vm-status worked and I could see all 3 hosts, but the engine failed to communicate with the hosts, hence, even though I had a working cluster and engine, and I could get the cluster into global maintenance mode, engine-setup --offline continued to spew "not-in-global-maintenance-mode' errors. At this stage I decided to simply zap the hosted engine and ovirt-hosted-engine-cleanup the hosts. As my brain was half dead, I decided to do a fresh deployment, and not use the daily backup.
That's ok and expected.
Then you took one of the hosts and evacuated it (or just a new one), (re)installed the OS (or somehow cleaned it up), and ran 'hosted-engine --deploy --import-from-file' with the backup you took. This failed? Where exactly and with what error?
Didn't use the backup. Clean hosted-engine --deploy failed due to qemu-6.1 failure. (I believe it's a known BZ#). Once I remembered to downgrade it to 6.0, everything worked as advertised (minus one export domain, see another email).
If it's the engine-setup running inside the engine VM, with the same error as when running 'engine-setup' (perhaps with --offline) manually, then this shouldn't happen at this point: - engine-backup --mode=restore sets vdc option in the db 'DbJustRestored' - engine-setup checks this and sets its own env[JUST_RESTORED] accordingly
(Understandable, given two of 3 hosts were offline due to certificate issues...)
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for:
https://bugzilla.redhat.com/show_bug.cgi?id=1700460
But:
If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine?
I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed
in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort.
If this is really what you want, I suggest something like:
1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed
You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.)
You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI.
Good luck and best regards,
I more of less found a document stating the above somewhere in the middle of the night. Tried it. Got the WebUI working again. However, for the life of me I couldn't get the hosts to work to talk to the engine. (Even though I could use openssl s_client -showcerts -connect host and got valid certs). In the end, @around ~4am, I decided to take the brute force route, clean the hosts, upgrade them to -streams, and redeploy the engine again (3'rd attempt, after sufficient amount of coffee reminded me the qemu-6.1 is broken, and needed to be downgraded before trying to deploy the HE...). Either way, when I finish importing the VMs, I'll open a RFE to add BIG-WARNING-IN-BOLD-LETTERS in the WebUI to notify the admin that the certificates are about to expire.
You should have already received them, no?
https://bugzilla.redhat.com/show_bug.cgi?id=1258585
Best regards, -- Didi
On Mon, Feb 7, 2022 at 12:33 PM Gilboa Davara <gilboad@gmail.com> wrote:
Hello,
On Mon, Feb 7, 2022 at 8:45 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the
vdsm services on all hosts.
All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
Failed, stating the cluster is not in global maintenance mode. (Understandable, given two of 3 hosts were offline due to certificate issues...)
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for:
https://bugzilla.redhat.com/show_bug.cgi?id=1700460
But:
If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine?
I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort.
If this is really what you want, I suggest something like:
1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed
You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.)
You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI.
Good luck and best regards,
I more of less found a document stating the above somewhere in the middle of the night. Tried it. Got the WebUI working again. However, for the life of me I couldn't get the hosts to work to talk to the engine. (Even though I could use openssl s_client -showcerts -connect host and got valid certs). In the end, @around ~4am, I decided to take the brute force route, clean the hosts, upgrade them to -streams, and redeploy the engine again (3'rd attempt, after sufficient amount of coffee reminded me the qemu-6.1 is broken, and needed to be downgraded before trying to deploy the HE...). Either way, when I finish importing the VMs, I'll open a RFE to add BIG-WARNING-IN-BOLD-LETTERS in the WebUI to notify the admin that the certificates are about to expire.
We already have quite a lot of warnings/alters about certificates which are going to expire soon: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TMJVAJMH5MKUVR... So what exactly are you missing here?
Thanks for the help!
- Gilboa
-- Didi
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/CGSAB7NPWWOYON...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
On Mon, Feb 7, 2022 at 4:03 PM Martin Perina <mperina@redhat.com> wrote:
On Mon, Feb 7, 2022 at 12:33 PM Gilboa Davara <gilboad@gmail.com> wrote:
Hello,
On Mon, Feb 7, 2022 at 8:45 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the
vdsm services on all hosts.
All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
Failed, stating the cluster is not in global maintenance mode. (Understandable, given two of 3 hosts were offline due to certificate issues...)
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for:
https://bugzilla.redhat.com/show_bug.cgi?id=1700460
But:
If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine?
I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort.
If this is really what you want, I suggest something like:
1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed
You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.)
You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI.
Good luck and best regards,
I more of less found a document stating the above somewhere in the middle of the night. Tried it. Got the WebUI working again. However, for the life of me I couldn't get the hosts to work to talk to the engine. (Even though I could use openssl s_client -showcerts -connect host and got valid certs). In the end, @around ~4am, I decided to take the brute force route, clean the hosts, upgrade them to -streams, and redeploy the engine again (3'rd attempt, after sufficient amount of coffee reminded me the qemu-6.1 is broken, and needed to be downgraded before trying to deploy the HE...). Either way, when I finish importing the VMs, I'll open a RFE to add BIG-WARNING-IN-BOLD-LETTERS in the WebUI to notify the admin that the certificates are about to expire.
We already have quite a lot of warnings/alters about certificates which are going to expire soon:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TMJVAJMH5MKUVR...
So what exactly are you missing here?
I don't know how, but the only errors I saw in the WebUI were update related (failed to check updates on host). There was an error in engine-setup, but at this stage it was far, far too late. - Gilboa
Thanks for the help!
- Gilboa
-- Didi
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/CGSAB7NPWWOYON...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
On Mon, Feb 7, 2022 at 3:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
On Mon, Feb 7, 2022 at 4:03 PM Martin Perina <mperina@redhat.com> wrote:
On Mon, Feb 7, 2022 at 12:33 PM Gilboa Davara <gilboad@gmail.com> wrote:
Hello,
On Mon, Feb 7, 2022 at 8:45 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Feb 6, 2022 at 5:09 PM Gilboa Davara <gilboad@gmail.com> wrote:
Unlike my predecessor, I not only lost my vmengine, I also lost the
vdsm services on all hosts.
All seem to be hitting the same issue - read, the certs under /etc/pki/vdsm/certs and /etc/pki/ovirt* all expired a couple of days ago. As such, the hosted engine cannot go into global maintenance mode,
What do you mean by that? What happens if you 'hosted-engine --set-maintenance --mode=global'?
Failed, stating the cluster is not in global maintenance mode. (Understandable, given two of 3 hosts were offline due to certificate issues...)
preventing engine-setup --offline from running.
Actually just a few days ago I pushed a patch for:
https://bugzilla.redhat.com/show_bug.cgi?id=1700460
But:
If you really have a problem that you can't set global maintenance, using this is a risk - HA might intervene in the middle and shutdown the VM. So either make sure global maintenance does work, or stop all HA services on all hosts.
Two questions: 1. Is there any automated method to renew the vdsm certificates?
You mean, without an engine?
I think that if you have a functional engine one way or another, you can automate this somehow, didn't check. Try checking e.g. the python sdk examples - there might be there something you can base on.
2. Assuming the previous answer is "no", assuming I'm somewhat versed in using openssl, how can I manually renew them?
I'd rather not try to invent from memory how this is supposed to work, and doing this methodically and verifying before replying is quite an effort.
If this is really what you want, I suggest something like:
1. Set up a test env with an engine and one host 2. Backup (or use git on) /etc on both 3. Renew the host cert from the UI 4. Check what changed
You should find, IMO, that the key(s) on the host didn't change. I guess you might also find CSRs on one or both of them. So basically it should be something like: 1. Create a CSR on the host for the existing key (one or more, not sure). 2. Copy and sign this on the engine using pki-enroll-request.sh (I think you can find examples for it scattered around, perhaps even in the main guides) 3. Copy back the generated certs to the host 4. Perhaps restart one or more services there (vdsm, imageio?, ovn, etc.)
You can check the code in /usr/share/ovirt-engine/ansible-runner-service-project/project to see how it's done when initiated from the UI.
Good luck and best regards,
I more of less found a document stating the above somewhere in the middle of the night. Tried it. Got the WebUI working again. However, for the life of me I couldn't get the hosts to work to talk to the engine. (Even though I could use openssl s_client -showcerts -connect host and got valid certs). In the end, @around ~4am, I decided to take the brute force route, clean the hosts, upgrade them to -streams, and redeploy the engine again (3'rd attempt, after sufficient amount of coffee reminded me the qemu-6.1 is broken, and needed to be downgraded before trying to deploy the HE...). Either way, when I finish importing the VMs, I'll open a RFE to add BIG-WARNING-IN-BOLD-LETTERS in the WebUI to notify the admin that the certificates are about to expire.
We already have quite a lot of warnings/alters about certificates which are going to expire soon:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TMJVAJMH5MKUVR...
So what exactly are you missing here?
I don't know how, but the only errors I saw in the WebUI were update related (failed to check updates on host).
That is not related to certificates errors used for engine <-> VDSM communication There was an error in engine-setup, but at this stage it was far, far too
late.
The warning/alerts mentioned above are stored in engine's audit log, which can be viewed within Events tab in webadmin, where you should see something like: Host ${VdsName} certification is about to expire at ${ExpirationDate}. Please renew the host's certification. or Engine's certification is about to expire at ${ExpirationDate}. Please renew the engine's certification.
- Gilboa
Thanks for the help!
- Gilboa
-- Didi
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/CGSAB7NPWWOYON...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
Hello, On Mon, Feb 7, 2022 at 4:14 PM Martin Perina <mperina@redhat.com> wrote:
I don't know how, but the only errors I saw in the WebUI were update related (failed to check updates on host).
That is not related to certificates errors used for engine <-> VDSM communication
There was an error in engine-setup, but at this stage it was far, far too
late.
The warning/alerts mentioned above are stored in engine's audit log, which can be viewed within Events tab in webadmin, where you should see something like:
Host ${VdsName} certification is about to expire at ${ExpirationDate}. Please renew the host's certification.
or
Engine's certification is about to expire at ${ExpirationDate}. Please renew the engine's certification.
Hello, I just lost at least two more setups, while (slowly) upgrading it to -streams. Zero warning on the UI (verified twice). Zero warning in the vdsm log (verified before I started the upgrade). Once I upgraded the hosted engine to streams (engine-setup --offline, distro sync, engine-setup), the VDSM's services stopped working on all hosts (sadly enough, at least two setups are single host setups). Tried restarting the VDSM service, and now they are spewing SSL handshake errors. E.g. ERROR ssl handshake: SSLError, address: ::ffff:127.0.0.1 So, given the fact that I have a working HE on all machines, how can I renew the vdsm certificates? I assume I cannot simply restart the HE service and try to enroll new certificates? - Gilboa
From the web UI there is an option to to regenerate the certificate Compute -> Hosts -> Management -> Maintenance -> Installation -> Enroll certificate Also, if you have RH dev subscription , you can check https://access.redhat.com/solutions/3532921 for the manual approach. Best Regards,Strahil Nikolov On Tue, Feb 8, 2022 at 12:13, Gilboa Davara<gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/DQOEYXG2XNM5TF...
Hello, On Tue, Feb 8, 2022 at 5:39 PM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
From the web UI there is an option to to regenerate the certificate Compute -> Hosts -> Management -> Maintenance -> Installation -> Enroll certificate
Also, if you have RH dev subscription , you can check https://access.redhat.com/solutions/3532921 for the manual approach.
Best Regards, Strahil Nikolov
Thanks for the prompt response. Sadly enough as luck would have it, it hit this issues on one of the single-host setups - which cannot go into maintenance. Soon after sending this email, I managed to find the RHV solution, which got VDSM working again. However, I cannot seem to get vmconsole working - trying to get spice console connected still uses the old certificates, even though I replaced and verified /etc/pki/vdsm/libvirt-spice/server-cert.pem $ openssl x509 -in /etc/pki/vdsm/libvirt-spice/server-cert.pem -noout -dates notBefore=Feb 7 13:59:14 2022 GMT notAfter=Feb 7 13:59:14 2027 GMT $ openssl x509 -in /etc/pki/vdsm/libvirt-spice/ca-cert.pem -noout -dates notBefore=Dec 26 16:25:01 2020 GMT notAfter=Dec 25 16:25:01 2030 GMT $ remote-viewer console.vv ... (remote-viewer:14874): Spice-WARNING **: 18:14:33.500: ../subprojects/spice-common/common/ssl_verify.c:506:openssl _verify: ssl: subject 'O=localdomain,CN=gilboa-wx-srv.localdomain' verification failed Any idea what I'm missing? - Gilboa
On Tue, Feb 8, 2022 at 12:13, Gilboa Davara <gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/DQOEYXG2XNM5TF...
I have no clue , but I would give vdsm.service a restart. Best Regards,Strahil Nikolov On Tue, Feb 8, 2022 at 18:19, Gilboa Davara<gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/2GAQH44QD6KTS4...
On Wed, Feb 9, 2022 at 1:05 AM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
I have no clue , but I would give vdsm.service a restart.
Thanks again for the prompt response. Tried that, restarted all services and the all the VMS, didn't work. Any idea how I can verify the certificate information actually being used by qemu for the spice console? remote-viewer just fails, without giving any meaningful error message. - Gilboa
Best Regards, Strahil Nikolov
On Tue, Feb 8, 2022 at 18:19, Gilboa Davara <gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/2GAQH44QD6KTS4...
The certificates used in SPICE connections are stored on the VM hosts. By default they are at /etc/pki/vdsm/libvirt-spice, and configured by VDSM in /etc/libvirt/qemu.conf. Their default names are ca-cert.pem, server-cert.pem, and server-key.pem. Using openssl x509 -noout -text - in </path/to/cert-file> should show you the certificate's expiration info. Note: Don't try to change anything, it will be overwritten by VDSM on the next host update / reinstall. As for remote-viewer, if you run it manually from the console with "remote-viewer --debug </path/to/console.vv>" or "remote-viewer -- verbose </path/to/console.vv>" it will print log information about the connection it's trying to establish. -Patrick Hibbs On Wed, 2022-02-09 at 06:58 +0200, Gilboa Davara wrote:
On Wed, Feb 9, 2022 at 1:05 AM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
I have no clue , but I would give vdsm.service a restart.
Thanks again for the prompt response. Tried that, restarted all services and the all the VMS, didn't work.
Any idea how I can verify the certificate information actually being used by qemu for the spice console? remote-viewer just fails, without giving any meaningful error message.
- Gilboa
Best Regards, Strahil Nikolov
On Tue, Feb 8, 2022 at 18:19, Gilboa Davara <gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/2GAQH44QD6KTS4...
Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/OG57VT2XGDTY2M...
On Wed, Feb 9, 2022 at 7:52 AM Patrick Hibbs <hibbsncc1701@gmail.com> wrote:
The certificates used in SPICE connections are stored on the VM hosts. By default they are at /etc/pki/vdsm/libvirt-spice, and configured by VDSM in /etc/libvirt/qemu.conf. Their default names are ca-cert.pem, server-cert.pem, and server-key.pem. Using openssl x509 -noout -text -in </path/to/cert-file> should show you the certificate's expiration info.
Note: Don't try to change anything, it will be overwritten by VDSM on the next host update / reinstall.
As for remote-viewer, if you run it manually from the console with "remote-viewer --debug </path/to/console.vv>" or "remote-viewer --verbose </path/to/console.vv>" it will print log information about the connection it's trying to establish.
-Patrick Hibbs
Hello, You must have missed my answer above. (Understandable, given the length of this thread...) I replaced and verified /etc/pki/vdsm/libvirt-spice/server-cert.pem Restarted all the services on the host. $ openssl x509 -in /etc/pki/vdsm/libvirt-spice/server-cert.pem -noout -dates notBefore=Feb 7 13:59:14 2022 GMT notAfter=Feb 7 13:59:14 2027 GMT $ openssl x509 -in /etc/pki/vdsm/libvirt-spice/ca-cert.pem -noout -dates notBefore=Dec 26 16:25:01 2020 GMT notAfter=Dec 25 16:25:01 2030 GMT However, remote-viewer still fails: $ remote-viewer --debug console.vv ... (remote-viewer:14874): Spice-WARNING **: 18:14:33.500: ../subprojects/spice-common/common/ssl_verify.c:506:openssl _verify: ssl: subject 'O=localdomain,CN=gilboa-wx-srv.localdomain' verification failed The main problem here is that while we assume the problem is expired certificates, it can be something else (Subject, CN, etc). The error is not informative.. - Gilboa.
On Wed, 2022-02-09 at 06:58 +0200, Gilboa Davara wrote:
On Wed, Feb 9, 2022 at 1:05 AM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
I have no clue , but I would give vdsm.service a restart.
Thanks again for the prompt response. Tried that, restarted all services and the all the VMS, didn't work.
Any idea how I can verify the certificate information actually being used by qemu for the spice console? remote-viewer just fails, without giving any meaningful error message.
- Gilboa
Best Regards, Strahil Nikolov
On Tue, Feb 8, 2022 at 18:19, Gilboa Davara <gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/2GAQH44QD6KTS4...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/OG57VT2XGDTY2M...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/AKQVBARD4EWIS3...
On Wed, Feb 9, 2022 at 9:20 AM Gilboa Davara <gilboad@gmail.com> wrote:
On Wed, Feb 9, 2022 at 7:52 AM Patrick Hibbs <hibbsncc1701@gmail.com> wrote:
The certificates used in SPICE connections are stored on the VM hosts. By default they are at /etc/pki/vdsm/libvirt-spice, and configured by VDSM in /etc/libvirt/qemu.conf. Their default names are ca-cert.pem, server-cert.pem, and server-key.pem. Using openssl x509 -noout -text -in </path/to/cert-file> should show you the certificate's expiration info.
Note: Don't try to change anything, it will be overwritten by VDSM on the next host update / reinstall.
As for remote-viewer, if you run it manually from the console with "remote-viewer --debug </path/to/console.vv>" or "remote-viewer --verbose </path/to/console.vv>" it will print log information about the connection it's trying to establish.
-Patrick Hibbs
Hello,
You must have missed my answer above. (Understandable, given the length of this thread...) I replaced and verified /etc/pki/vdsm/libvirt-spice/server-cert.pem Restarted all the services on the host.
$ openssl x509 -in /etc/pki/vdsm/libvirt-spice/server-cert.pem -noout -dates notBefore=Feb 7 13:59:14 2022 GMT notAfter=Feb 7 13:59:14 2027 GMT $ openssl x509 -in /etc/pki/vdsm/libvirt-spice/ca-cert.pem -noout -dates notBefore=Dec 26 16:25:01 2020 GMT notAfter=Dec 25 16:25:01 2030 GMT
However, remote-viewer still fails: $ remote-viewer --debug console.vv ... (remote-viewer:14874): Spice-WARNING **: 18:14:33.500: ../subprojects/spice-common/common/ssl_verify.c:506:openssl _verify: ssl: subject 'O=localdomain,CN=gilboa-wx-srv.localdomain' verification failed
The main problem here is that while we assume the problem is expired certificates, it can be something else (Subject, CN, etc). The error is not informative..
- Gilboa.
Seems that openvswitch is also using the old certificates. Feb 9 09:56:32 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22660|jsonrpc|WARN|ssl:[::ffff:192.168.2.22]:57924: receive err or: Protocol error Feb 9 09:56:32 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22661|reconnect|WARN|ssl:[::ffff:192.168.2.22]:57924: connectio n dropped (Protocol error) Feb 9 09:56:40 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22662|stream_ssl|WARN|SSL_accept: error:14094415:SSL routines:s sl3_read_bytes:sslv3 alert certificate expired Feb 9 09:56:40 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22663|jsonrpc|WARN|ssl:[::ffff:192.168.2.22]:57928: receive err or: Protocol error Feb 9 09:56:40 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22664|reconnect|WARN|ssl:[::ffff:192.168.2.22]:57928: connection dropped (Protocol error) Seems that https://access.redhat.com/solutions/3532921 is missing a couple of certificates.. (I don't even see it in https://www.ovirt.org/develop/release-management/features/infra/pki.html). - Gilboa
On Wed, 2022-02-09 at 06:58 +0200, Gilboa Davara wrote:
On Wed, Feb 9, 2022 at 1:05 AM Strahil Nikolov <hunter86_bg@yahoo.com> wrote:
I have no clue , but I would give vdsm.service a restart.
Thanks again for the prompt response. Tried that, restarted all services and the all the VMS, didn't work.
Any idea how I can verify the certificate information actually being used by qemu for the spice console? remote-viewer just fails, without giving any meaningful error message.
- Gilboa
Best Regards, Strahil Nikolov
On Tue, Feb 8, 2022 at 18:19, Gilboa Davara <gilboad@gmail.com> wrote: _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/2GAQH44QD6KTS4...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/OG57VT2XGDTY2M...
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org 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/users@ovirt.org/message/AKQVBARD4EWIS3...
Hello all, Seems the engine-setup fails to update the openvswitch certificate on the HE itself. $ openssl x509 -in /etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer -noout -dates notBefore=Dec 26 16:25:04 2020 GMT notAfter=Jan 29 16:25:04 2022 GMT $ engine-setup .... [ INFO ] Stage: Termination [ INFO ] Execution of setup completed successfully $ openssl x509 -in /etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer -noout -dates notBefore=Dec 26 16:25:04 2020 GMT notAfter=Jan 29 16:25:04 2022 GMT $ cat /var/log/messages | grep ovsdb-server ... Feb 9 09:56:32 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22660|jsonrpc|WARN|ssl:[::ffff:192.168.2.22]:57924: receive err or: Protocol error Feb 9 09:56:32 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22661|reconnect|WARN|ssl:[::ffff:192.168.2.22]:57924: connectio n dropped (Protocol error) Feb 9 09:56:40 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22662|stream_ssl|WARN|SSL_accept: error:14094415:SSL routines:s sl3_read_bytes:sslv3 alert certificate expired Feb 9 09:56:40 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22663|jsonrpc|WARN|ssl:[::ffff:192.168.2.22]:57928: receive err or: Protocol error Feb 9 09:56:40 gilboa-wx-vmsrv ovsdb-server[9874]: ovs|22664|reconnect|WARN|ssl:[::ffff:192.168.2.22]:57928: connection dropped (Protocol error) @RH people. Is it a bug? - Gilboa
My engine stopped working after upgrade to 4.4.10, and I get the same errors as yours on the logs. Were you able to fix the problem ?
Okay. Running the command 'engine-setup --offline' fixed the certificate problem without upgrading the engine. While engine-setup was running it made reference to the following page regarding PKI certificates. I'm posting it here for reference by other people who may encounter the same problem I had. https://www.ovirt.org/develop/release-management/features/infra/pki-renew/ Thanks again for the help. Feels good to be back up and running. LOL
participants (7)
-
Diggy Mc -
Gianluca Amato -
Gilboa Davara -
Martin Perina -
Patrick Hibbs -
Strahil Nikolov -
Yedidyah Bar David