Restoring from backup error: self-signed certificate
-
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
-
A abudef referenced this topic on
-
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.
-
M Mathieu referenced this topic on
-
M manilx referenced this topic on
-
@StormMaster
I dont see a PR or even an issue posted on the github. I can add one to the board for ronivay unless someones working on it. -
@michmoor0725 Sure!
I don't think that it is a ronivay issue as it appears to be occurring with any self-signed certificate. Regardless of what was used to compile it.
That said, if some people check there instead of here, it mays good sense to have something posted there as well.
-
U uwood referenced this topic on
