@stormi Thank you very much. I didn't even look at the directory name while I was troubleshooting. It was /var/disablweb.. missed an e. All set now.

@olivierlambert said in Missing VMs from Restore:

Try to see after a new backup with this version We'll see then.

Thank you. I'll check it after tonight's run.

@stormi Thank you very much. I didn't even look at the directory name while I was troubleshooting. It was /var/disablweb.. missed an e. All set now.

@stormi Thank you for the instructions. It works great on most of our servers, but on one of them, we can no longer connect via xo. It gives a connection refused (ECONNREFUSED). I commented out the line in the conf file, and restarted the toolstack, and it connected fine... uncommented, and it went back to the connection refused. Other servers at other sites all work fine. Just this one is giving fits.

@olivierlambert There is a login form to spin up an instance of XO.. not sure if something can be injected there... but that was another bullet point on their list as well... the password field doesn't have autocompletion turned off. Both are low priority items, and I know the autocompletion css tag doesn't work across the board with all browsers.

We've got several xcp-ng servers stood up, across many sites. We recently had a security audit, in which we granted the audit machine to various vlans which normally wouldn't be open, after they found no issues on on the 3 vlans that we gave them access to initially. On all of our xcp-ng hosts, they found an issue with the "x-frame-options" returned by the built in web server (see below). Since these servers are on segregated vlans, which aren't accessible by any hosts other than our own, I'm not super worried about it, but have been asked to investigate. Is there a way to disable the built in web server on all of the hosts? Is this what's used for xo to talk to the hosts?

From the auditors:
The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions.

@olivierlambert said in Missing VMs from Restore:

Try to see after a new backup with this version We'll see then.

Thank you. I'll check it after tonight's run.

@olivierlambert Ok, running 5.113 commit fd2c7 now. Are you recommending that I see if the servers are listed now (because they're not) or wait for a backup to go and see if it shows up?

Thank you.

Running xo-server 5.110.0 commit 00a13.

Scheduled a backup for all VMs in the pool, and the backup job says it is successful, but when I try to restore, I do not see one particular VM. I then went to the overview, viewed the corresponding logs for the backup job, then viewed the details from last night's run. It indicates that the job was successful, but displays a warning stating "incorrect backup size in metadata" for both of the remotes that I have the job going to.

There is a snapshot on the server from last night. I am trying to restore that to a VM to see if I can restore the files I need, but it's quite large and will take a while to copy to the test server.

Any ideas on why that VM is not showing up in the restore screens?

Thanks,
Russ