Restoring from backup error: self-signed certificate
-
Hi @KS I use Ronivay's precompiled VM which only deploys the latest build. I will have to look into this install script to compile a previous build of the vm. Will let you know if I get it working.
-
Same here, its definately a bug because I was able to do a backup and restore just last week.
I upgraded to the latest 2 days ago and now backups are broken, same version here: -
I can confirm that in the community edition, something between 0ccfb4b and 8e5d9 breaks restoring to hosts with self signed certs.
I had to try and restore a couple of VMs after the upgrade to 8e5d9 and despite a couple of attempts to compile previous commits and see if they would work, nothing did until I reached 0ccfb4b.
Once I had rolled it back that far, the restores were no longer stuck at 0% and there were no problems restoring any of the backups that I tied.
-
Someone else on this forum is having trouble with self-signed certificates. So this issue must be more general than just self-signed certificates when restoring backups.
It must be a bug introduced recently which is specifically when handling self-signed certificates generally.
https://xcp-ng.org/forum/topic/8636/self-signed-cert
Others with this issue is the link shown above similar to what you are experiencing with backup restoration?
@florent Can you please check this out there may be a bug in Xen Orchestra which is affecting the handling of self-signed certificates generally? As it's affecting not just restoration of backups but also the creation of new VMs as well.
-
@john-c
"Someone else on this forum is having trouble with self-signed certificates. "Unfortunately, this function does not work either.
márc 18 14:13:12 xoa xo-server[22559]: 2024-03-18T13:13:12.703Z xo:api WARN bogi.kornel | backupNg.importVmBackup(...) [184ms] =!> Error: self-signed certificate
-
For those finding this post and are using ronivay's XenOrchestraInstallerUpdater, the solution is as follows...
Edit xo-install.cfg with your favourite editor.
Look for the line...
BRANCH="master"
Comment it out and and on a new line add...
#BRANCH="master"
BRANCH="0ccfd4b"If you then run the script and choose 2) Update, it should work.
Because I was in a hurry, I deleted the /opt/ox directory, put the SSL certs that were in it back, and then ran 1) Install so that I knew that I was certain that there were no conflicts with compiling and older version.
But either method should work.
-
@KS Did you try running "xe task-list" to identify the process and then "xe task-cancel force=true uuid=(UUID-of-process)"?
-
@StormMaster thank you. This workaround did exactly what i needed.
-
Thank you @StormMaster
-
-
Ditto the fix from @StormMaster worked for me - many thanks.
-
The command "xe task-cancel force-true ..." with the uuid of the pending tasks did not do anything for me. After trying it on the 3 tasks I had, issuing a "xe task-list" still show me the pending tasks. It it only by rebooting the host that the pending tasks disappear.
-
Going back to an older version of XO source also did the trick for me.
I was in the process of pushing in production a couple VM that were previously in test and that I had backed up a couple of days ago. I was very surprised not to be able to do anything with these VMs stuck on my SR used for VM backup -
@utmoab Strange, but I've seen some tasks "stuck" that could not be cancelled for some reason or aanother. A reboot is a drastic measure, but unfortunate;y sometimes the only recourse.
-
I'm on commit 1b515 and the error still exists.
Pending tasks can be cancelled with "restart toolstack" on host.
-
The BRANCH="0ccfd4b" revert worked for me, backups are working again in the lab.
-
@StormMaster said in Restoring from backup error: self-signed certificate:
BRANCH="0ccfd4b"
This worked for me also, thank you.But after this change, I have tried to run update few times but it seems my commits are falling behind and do not update to the latest.
Am I missing something?
-
@Bub said in Restoring from backup error: self-signed certificate:
Am I missing something?
No, you're "stuck" on commit 0ccfd4b until you revert the change in the config file. It doesn't make sense to do that now, because then you will encounter the issues with backups / restores again. Once a fix has been pushed to the Github repo, then you can switch back to the master branch.
-
@Danp Got you, thanks for the clarification!
-
@Danp Is it safe to say this is being worked on? I don't want to assume anything.
-
@dsiminiuk I would assume so, but I don't know the specifics.
-
-