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

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

@sborrill I have a work-in-progress branch with a plugin for this: https://github.com/vatesfr/xen-orchestra/pull/4701

To test, you will need to checkout this branch, add a symlink to the packages/xo-server-auth-http plugin into the directory xo-server/node_modules and then to configure and unable the plugin from XO.

This will make basic authentication available with the path /signin/basic, note that you can make it the default authentication by overriding authentication.defaultSignInPage in your configuration file.

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

open WiP: feat(xo-server): support HTTP basic auth #4701

Done: https://github.com/vatesfr/xen-orchestra/commit/14f0cbaec6244d66266fe2ee47b0bfb5716c2f61

0 julien-f committed to vatesfr/xen-orchestra

fix(docs/from sources): no need to configure `/` mount point

@bill-gertz I've made the change, the documentation will update soon: https://github.com/vatesfr/xen-orchestra/commit/7b47e4024492d38bca6e928748490e0a4880264c

0 julien-f committed to vatesfr/xen-orchestra

fix(docs/from sources): dont use `.xo-server.toml`

@pdonias We only see the connection error between xo-server and xo-updater, we need to reproduce to figure out what's going on.

@Danp Perfect, thank you for your help

I think this may be an old issue that has become visible since https://github.com/vatesfr/xen-orchestra/issues/4497

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

closed Report backup as failed or skipped if already running #4497

@goorooj Please, try to run xo-server-recover-account with the same user as xo-server and keep me posted.

@karlisi I've been unable to reproduce the issue so far, can you tell me which version of XO has the issue and which one does not?

Also, if you could provide me with your job configuration it would be nice

There is probably a problem in XO regarding this because we have received multiple similar reports, we are investigating.

@Danp said in How to enable back up notification in community edition:

Are these even kept up-to-date?

No, they are not kept up-to-date, please install them from the sources

@S-Pam No way around it if the original reference snapshot has been deleted, we'll improve this in the new backup code (developed for the proxies).

Hi,

No known issues related to this, and no recent changes on the scheduling/job code, please make sure all your dependencies are up to date (especially xo-server/node-modules/@xen-orchestra/cron to 1.0.6).

Also, XO does (should) not start a job if it's already running, therefore I don't understand why it leads to errors.

@akurzawa xo-server is not explicitly multi-processed, but it uses async IO calls in Node which should lead to multi-threaded operations.

Anyway, we are currently working on reimplementing backups for the proxy and it will eventually lead to using multiple processes.

These changes will at the end be merged back to xo-server as well.

It's possible in the backend by adjusting independently copyRetention and exportRetention but it's not exposed in the UI.

@badrAZ @pdonias Do you think we should do it?

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

I had a proposal for this but never got any answers and it never got merged: https://github.com/vatesfr/xen-orchestra/issues/1655#issuecomment-327492894

mmartinWECHU created this issue in vatesfr/xen-orchestra

open LDAP creates new user is userNaME CaSe is DifFerent #1655