@olivierlambert
I ran your statement though Claude on my Install script and this is what it came back with.
Credential Encryption Review — install-xen-orchestra.sh
Notes from reviewing our installer's handling of ENCRYPT_REDIS_CREDENTIALS, and what (if anything) belongs in the Vates forum thread.
1. What's already there
ENCRYPT_REDIS_CREDENTIALS is a first-class config key:
Behavior
Location
Defaulted and validated as a boolean
install-xen-orchestra.sh:419, :479-481
Auto-migrated into existing xo-config.cfg files as part of the v1→v2 schema bump
install-xen-orchestra.sh:547-565
Emits encryptCredentialDatabase = true under [redis] in the generated config.toml
install-xen-orchestra.sh:1713-1718
Preflight warns when systemd-detect-virt isn't xen
install-xen-orchestra.sh:1623-1642
Token flush treats non-JSON Redis values as possibly-encrypted and preserves them rather than misclassifying them
install-xen-orchestra.sh:1086-1100
The part that isn't in Vates' doc at all
With a non-root SERVICE_USER, /dev/xen/xenbus is root-only 0600, so xo-server can't reach XenStore and drops into degraded mode.
configure_xenstore_access() handles this: it creates a xenstore group, adds the service user, installs a udev rule, and chgrp/chmods the live device — so it works without a reboot and without running XO as root.
That's a real gap-fill.
2. Documentation gaps
The docs (README.md:345-353, sample-xo-config.cfg:174-195) explain what the flag does, the XCP-ng-only constraint, and the root/non-root XenStore story. What's missing:
2.1 The "why"
The actual question in that thread. Nothing anywhere says the credential must be reversible because xo-server replays it to XAPI on every connect — so plaintext-by-default is expected behavior, not a bug, and the real perimeter is localhost-bound Redis plus root on the VM.
Someone reading the README sees a security-flavored flag defaulting to false with no explanation of why that default is defensible.
2.2 Remote Redis is offered with no warning
sample-xo-config.cfg:167-172 gives this as an example:
REDIS_URI=redis://redis.company.lan:6379/42
That sends XAPI root credentials over the network in cleartext, to a Redis that is by definition not localhost-bound. There's no note about it, and the installer never checks or hardens bind/protected-mode — setup_redis() only starts the service and pings it.
2.3 The key-loss caveat is absent, and backups don't cover the key
This is the sharpest one.
"If you lose one half while encryption is on, do not restart" appears nowhere. Worse:
create_backup() copies only $INSTALL_DIR
/var/lib/xo-server/data/xo-encryption-key is never captured
neither is the XenStore half
So --backup/--restore is not a recovery path for an encrypted database, and nothing says so.
2.4 Config export requires a passphrase once encryption is on
Not mentioned.
2.5 The preflight checks virt type, not tooling
It never verifies xenstore-read/xenstore-write exist (i.e. that xen-guest-utilities is installed). A Xen guest without them passes the check and then fails at xo-server startup. The binaries are named only in comments and generated config text (install-xen-orchestra.sh:563, :1716).
2.6 --uninstall destroys the on-disk key half silently
install-xen-orchestra.sh:6004-6008 does rm -rf /var/lib/xo-server with no encryption-specific note that this permanently destroys the on-disk key half. Defensible for a full uninstall, but worth stating.
3. Should any of this go to Vates?
Almost all of it is on us
Their page already covers the two caveats flagged as undocumented in our repo — verbatim:
If either key half is lost while encryption is enabled, do not restart xo-server: at startup, XO treats a missing key half as a fresh setup, generates two new halves (overwriting the one that survived) and re-runs the encryption migration, which skips records that are already encrypted. Those records become permanently undecryptable.
When credential encryption is enabled, exporting the XO configuration requires a passphrase.
So gaps 2.1, 2.3, 2.4, 2.5, 2.6 aren't Vates' problem — they're ours, for surfacing an option whose failure modes we don't repeat locally.
Gap 2.3 in particular is squarely ours: we ship a --backup/--restore that never captures /var/lib/xo-server/data/xo-encryption-key, so a restore silently produces exactly the "permanently undecryptable" state their doc warns about. That's our bug, not a doc issue.
One thing is genuinely worth relaying
Their entire treatment of non-root is a single clause:
This requires running xo-server as root or granting it access to the xenstored socket.
The "or" branch is unspecified — no device path, no group, no udev rule. That matters more than it looks, because their own install-from-sources guide recommends running non-root. Follow both docs and you get a broken install with no explanation.
We had to work out:
/dev/xen/xenbus being root:root 0600
the xen!xenbus udev sysname encoding
the group + rule to fix it (install-xen-orchestra.sh:1861-1923)
That's the concrete content their clause is missing, and it's reusable by anyone doing a source install.
That thread is a good place for it. The answer you quoted says "xo-server needs access to the xenstored socket (root, typically)" — the parenthetical is the exact spot the detail belongs, so a reply reads as filling in a known gap rather than a drive-by critique.
4. Verify before posting
Our claim that a non-root xo-server without XenStore access "enters degraded mode and logins are rejected" (install-xen-orchestra.sh:1854-1855) traces only to our own script comments — not to XO source or an observed run.
If you're asserting a specific failure mode to the people who wrote the code: confirm it first, or soften it to what you actually saw. If the startup error doesn't name XenStore as the cause, that's a second, separately useful report for them.
5. Next steps
Draft the forum reply — scoped to the permission finding, the udev rule, and a question about the startup error text. You post it yourself.
Fix the backup gap on our side, regardless of what upstream does.
