XO Team

@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.

Hi,

Thank you for your report.

Indeed, there is an issue with the display of Disk (Used/Total).

The fix for this issue is under validation, it will be merged ASAP.

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