@florent I updated to build 16498 and followed your suggestion. Now it is showing that the connection is running and successful. I have a 2-day object lock enabled. In BackBlaze B2 Buckets once object lock is enabled you cannot disable it. You can change the days to lock to 0 but that will only affect new files. Existing files will be locked based on the Object lock settings applied when the file was saved.

It appears that this is resolved. I will try to run a few backups to my BackBlaze buckets to see if it runs.

Solved. After a bit more playing around I finally figured it out.

In the Configuration for XOA set the following in the "AutoDiscovery URL" https://{Yourdomainname}.okta.com/.well-known/openid-configuration. Do not fill in any of the Advanced fields. They will work just fine.

Then in OKTA for the 'Sign in' redirect URLs put in the following. https://{Your XO servername}/signin/oidc/callback if you access the server through multiple URLs you may need to add additional lines.

Make sure you have the PKCE checkbox turned off or you will get a 500 server error on the client side. The OIDC plugin does not like to use PKCE.

If you choose to have the option of "Login Initiated by" set to either OKTA or App then you will need to set the "Initiate login URI" to be the same as your 'Sign in' redirect. This way you can have your XOA control panel in your list of available SAAS apps in your OKTA browser plugin for authorized users.

Leave off the wildcard checkbox since it just makes you less safe.

This should help anyone else who is not an OIDC expert figure out how to make XOA behave with your OKTA installation, hopefully, this will help out the next person who runs in this challenge.

@florent I updated to build 16498 and followed your suggestion. Now it is showing that the connection is running and successful. I have a 2-day object lock enabled. In BackBlaze B2 Buckets once object lock is enabled you cannot disable it. You can change the days to lock to 0 but that will only affect new files. Existing files will be locked based on the Object lock settings applied when the file was saved.

It appears that this is resolved. I will try to run a few backups to my BackBlaze buckets to see if it runs.

This is the message that appeared in the logs when Object lock was enabled. After changing the Object lock on the B2 bucket back to 0 the error resolved. In Backblaze once Object lock is enabled it cannot be disabled.

remote.test
{
"id": "395eab46-2f98-4581-b8da-1444f40da06a"
}
{
"message": "Cannot read properties of undefined (reading 'httpStatusCode')",
"name": "TypeError",
"stack": "TypeError: Cannot read properties of undefined (reading 'httpStatusCode')
at S3Handler._sync (/opt/xo/xo-builds/xen-orchestra-202404121746/@xen-orchestra/fs/src/s3.js:462:27)"
}

As a quick test, I turned the Object lock to 2 days and ran the connectivity test.

This is the error message that came back with a 2-day object lock.

Error

    {
      "name": "InvalidRequest",
      "$fault": "client",
      "$metadata": {
        "httpStatusCode": 400,
        "requestId": "4d2e36629f72e33e",
        "extendedRequestId": "aNKplp2YaZs40bWLzODM5kTl4N05hXWT/",
        "attempts": 1,
        "totalRetryDelay": 0
      },
      "Code": "InvalidRequest",
      "message": "Missing required header for this request: Content-MD5"
    }

Test step
    write

If I change the Object lock back to 0 days and rerun the connectivity test I get the following result. "The remote appears to work correctly"

I have been testing and was looking at trying to use the Amazon S3 settings with the BackBlaze buckets. I can get the Buckets to appear to work, but if I turn on 'Object Lock', the storage destination will fail. Reporting a write error. I suspect that XOA is trying to do something or clean up by deleting objects that the Object lock prohibits.

The purpose of the Object Lock is to ensure that once backed up all files/items are read-only and cannot be modified after written. To prevent malware from trying to delete or encrypt the backups.

Is this just a thing to have to accept from XOA, or is there some kind of a fix coming to allow for Object Lock to be used safely?

Solved. After a bit more playing around I finally figured it out.

In the Configuration for XOA set the following in the "AutoDiscovery URL" https://{Yourdomainname}.okta.com/.well-known/openid-configuration. Do not fill in any of the Advanced fields. They will work just fine.

Then in OKTA for the 'Sign in' redirect URLs put in the following. https://{Your XO servername}/signin/oidc/callback if you access the server through multiple URLs you may need to add additional lines.

Make sure you have the PKCE checkbox turned off or you will get a 500 server error on the client side. The OIDC plugin does not like to use PKCE.

If you choose to have the option of "Login Initiated by" set to either OKTA or App then you will need to set the "Initiate login URI" to be the same as your 'Sign in' redirect. This way you can have your XOA control panel in your list of available SAAS apps in your OKTA browser plugin for authorized users.

Leave off the wildcard checkbox since it just makes you less safe.

This should help anyone else who is not an OIDC expert figure out how to make XOA behave with your OKTA installation, hopefully, this will help out the next person who runs in this challenge.

@DustinB I do have that. Internally its called https://xoa-os.lcco.co.lucas.oh.us which redirects to https://xoa-os.lcco.co.lucas.oh.us/signin .
Your suggestion was one of the first things I tried. just put https://xoa-os.lcco.co.lucas.oh.us/ then https://xoa-os.lcco.co.lucas.oh.us/* at both my redirect URLs usually that's all I need to have it work.

none of these URIs are externally visible or routable outside. But to the browser, it works correctly. Or are you suggesting that I have to have the DNS name exposed externally? That would require that I create an A record in the public DNS, which I would rather not do.

I am playing with the XO installation using the open source and the OAuth. While trying to get the OAuth working I keep running into an issue where the redirect URI fails.

Following the directions in the https://login.my domain.com/ should work. but instead, I get the following error. "Your request resulted in an error. The 'redirect_uri' parameter must be a Login redirect URI in the client app settings: " Does anyone have any suggestions on what it may look for in this URI?

After doing a few migrations and watching the XOA installation it appears that the migration goes thought he XOA device. So there is a benefit to having the XOA running on a fast network interface.

@DustinB Thanks.

When you say machine to machine you mean going from the XCP-ng servers management interface? In my case, the management interface eth0 was a 1Gb interface while eth2 and eth3 were 10Gb interfaces. I have since changed the management interface to bond0 (20Gb interface). I will have to see if that makes things faster.

So far I have found only the Windows machines need to have the VMware tools removed. All my Ubuntu images just move and work. Followed up by using "apt install xe-guest-utilities" though I have found the label for the ethX changes and requires a bit of fixing in the /etc folder.

I also have found the Citrix drivers need to be used for the Windows 2022 servers or the ethernet interface is stuck at 1Gb. When I use Citrix the drivers show the available interface at 100Gb. I suspect that may be due to the open-source drivers not being updated in a long time. On my Windows 2012 server, the 1Gb interface was acceptable.

It would also seem that if you install the open source drivers and then uninstall them the VM is rendered unbootable. Unable to find the working volume. I think I saw a note about the drivers missing for the open-source drivers causing the issue, the article had a fix of manually loading the drivers off a driver ISO image.

Since I am just using ESXi I just shut down the VM and then migrate. Each one moved well.

Next up once my last VM is moved I will add a DL360 Gen10+ server to the pool and see how the configuration handles this.

I am slowly moving ESXi VM images to XCP using XOA. But I have a few questions. When the migration takes place does it move the image directly from host to host? Or does the migration move through the XOA VM?

I have my ESXi on a 20Gb ethernet connection and the XCP-ng-migration server is also bonded to the 20Gb ethernet. However, the XCP-ng-migration is attached to a 1Gb connection with a different interface and IP since it was set up before I created the LACP bond that I put the VMs on. My question is what path that the images take when migrating?

What path does this take to move the VM? Is there a way to speed this up by moving interfaces around?

The LACP bond is what I tell all my fast networks/VLANs to connect through. But I have kept the XCP server on a separate ethernet so I do not lose connectivity as I played with the LACP networks.