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
The patch is finally here
Sorry for the delay
How to test?
latestchannel on your XO appliance
Scheduled for Step 2 at the end of the month.
Thank you for your feedbacks
shelloption is used, no shell interpreter (Bash,
cmd.exe, etc.) is used, so shell features such as variables substitution (
echo $PATH) are not allowed.
spawn which does not do any arguments parsing, those are passed verbatim to the underlying command (probably via a call to
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
@normanghenderson I'm currently working on this feature, I had hoped to be able to release this for the September release but due to last minute issue it will likely be postponed for the end of October.
Note that this will ship in the proxy first before making its way to regular backups.
The problem is likely related to quotes and the shell syntax.
Unfortunately, I'm not familiar with it and cannot help you a lot.
I read somewhere that you should be able to escape quotes by doubling them, that may be worth a try:
@nodesocket You can override this setting in your config file: https://github.com/vatesfr/xen-orchestra/blob/c4d96fbc492c86d7d0365efcbe13bd0b6dd2f9a0/packages/xo-server/config.toml#L132
@RKENS Good question, during the replication, a new VM is created with the same settings as the original one, and this at every run. Therefore that's perfectly normal that this property reappears.
I don't see how that's a problem because, as you said it yourself, the start operation is disabled by the replication job.
I think it makes sense that the auto start is set like on the original VM so you can simply start the replication when necessary without having to think about enabling it.