Thank you for this constructive argument

Have a nice day.

@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils is installed on the system, something that is present on our doc but might be missing in some install scripts.

We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues

Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome

FYI, this feature has been released

Hey everyone!

The patch is finally here

Sorry for the delay

How to test?

1. Select the latest channel on your XO appliance
2. Upgrade to Xen Orchestra 5.43.2
3. Go to the Proxies page and either Deploy a proxy or upgrade the appliance of your existing ones

What's here?

• Full Backup
• Disaster Recovery

Known limitations/issues

Scheduled for Step 2 at the end of the month.

• Network configuration for the proxy appliance
• Delta Backup
• Continuous Replication
• Detailed logs, they are currently empty
• Restoring backups
  Work-around: create a normal remote (not linked to the proxy) connected to the same storage and import via the XO appliance

Thank you for your feedbacks

Indeed, there is a major issue with the fix, I'm on it.

Sorry for this

Answered on the XO forum, thank you

That sounds feasible indeed

Unless the shell option is used, no shell interpreter (Bash, cmd.exe, etc.) is used, so shell features such as variables substitution (echo $PATH) are not allowed.

-- https://github.com/sindresorhus/execa#execafile-arguments-options

AFAIU, execa use spawn which does not do any arguments parsing, those are passed verbatim to the underlying command (probably via a call to execvp).

If we would have used the shell option, this command would indeed run a shell which would have parsed the command line and therefore be susceptible to injection, but we are not using this

@jefftee Hi, this is a display issue related to with memory backups, for more information, take a look at this issue: https://github.com/vatesfr/xen-orchestra/issues/5089

julien-f created this issue in vatesfr/xen-orchestra

open [Backup] suspend_VDI should not be taken in consideration for full qualification #5089

@polyaks FYI, it looks like a corrupted (truncated) file issue.

You can take a look at this post where I explain succinctly how to check XO backup files

That sounds feasible indeed

Yep, that's the best solution

Have a nice day.

@DeOccultist You can run xo-server with this flag:

> which xo-server
/usr/local/bin/xo-server
> node --tls-min-v1.0 /usr/local/bin/xo-server

FYI, an extremely basic command line to encode passwords:

> node -e 'process.stdin.on("data", _ => {console.log(encodeURIComponent(_.toString().trim())); process.exit()}); process.stdout.write("Password: ")'
Password: foo@bar
foo%40bar

Special characters in a URI component should be encoded using percent-encoding, in your case, @ becomes %40.

@BeDazzleMe It's JSON-RPC 2.0 over WebSocket on the path /api.

You can call the method system.getMethodsInfo to see which methods are available.

You can use xo-lib if you want to use JavaScript.

@Andre said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:

Would it be "stupid" to use the hash of the user's (asking for the export) password to encrypt "by default" the export?

No, because:

1. XO does not the password of the user, just a hash
2. The hash cannot be used because it can be regenerated for various reasons (e.g. a change of security settings such as the used algo)

@BeDazzleMe xo-cli is an advanced tool, mainly for the developers of XO, but useful for advanced users well

There is no guide of commands, it uses introspection to get the available commands from xo-server:

xo-cli --list-commands

For more information, take a look at the documentation.

Unless the shell option is used, no shell interpreter (Bash, cmd.exe, etc.) is used, so shell features such as variables substitution (echo $PATH) are not allowed.

-- https://github.com/sindresorhus/execa#execafile-arguments-options

AFAIU, execa use spawn which does not do any arguments parsing, those are passed verbatim to the underlying command (probably via a call to execvp).

If we would have used the shell option, this command would indeed run a shell which would have parsed the command line and therefore be susceptible to injection, but we are not using this

Hi,

XO can use sudo mount: https://github.com/vatesfr/xen-orchestra/blob/bf763d2cf474293e5a0fa1f3a06fd1733a495b34/packages/xo-server/config.toml#L114

I don't believe command injection is possible because mount is called directly, no shell is used to parse the command line.