Install XO from sources.

[acebmxer]

@AlexanderK

I just wanted my own script to install Xen Orchestra from sources with a few additional features not found in Ranivays script. Mine is built completely from scratch but with inspiration form his script.

If you wanted to give my script a try I would appropriate any feedback to any improvements. I would suggest creating a new vm as i have not test my script against an installation done by Ronivays script.

[AlexanderK]

@acebmxer
what have you added? what are the differences?
i will definetely try it.

[acebmxer]

@AlexanderK
The inter-active menu, The menu will show the running script commit against main commit along with showing Xen Orchestra installed commit vs master commit. The script should automatically self-update to latest version.

Just to name a few...

[AlexanderK]

@acebmxer i think that only the menu. the "old" script also auto updates....

[Greg_E]

@AlexanderK

The ronivay script requires you to select an option (#2 to update).

I look at things this way, it's good to have more people working on scripts like this.

[fatek]

Very nice job @acebmxer
Well done

[Vertux]

@AlexanderK said:

which is the difference with this?
https://github.com/ronivay/XenOrchestraInstallerUpdater

Using the above around 5-6 years with no issues at all

e.g. XenOrchestraInstallerUpdater does not support Debian 13 yet.

[acebmxer]

Made some updates to this project. Any existing users please see note. I have also updated the initial post.

️ Upgrading from an earlier version of this script? Read this first.
This version bumps the config schema to v2 (adds PUBLIC_URL and ENCRYPT_REDIS_CREDENTIALS) and corrects two config.toml generation bugs. Your xo-config.cfg is migrated automatically and non-destructively, but the corrected /etc/xo-server/config.toml is only written by --reconfigure.

Run --reconfigure once before resuming normal updates:

./install-xen-orchestra.sh --reconfigure
This regenerates config.toml with the fixes (your old file is backed up first; data in /var/lib/xo-server is untouched). It is strongly recommended if you set both REDIRECT_TO_HTTPS=true and REVERSE_PROXY_TRUST — that combination previously produced a duplicate [http] section and silently dropped one of the settings.

Afterwards, run --update as normal for routine XO updates — --update does not need to be preceded by --reconfigure again.

Also added option to adjust Xen Orchestras memory allocation. Useful if you are getting out of memory errors or added more memory to XO.

Update - Previous info was incorrect. I have removed and updated.
On fresh install Debian 13 with 8gb ram node -v 24.15.0.

==============================================
  Xen Orchestra Memory Allocation
==============================================

  Setting                       Value
  ----------------------------- -----------------------------------
  Total system RAM              7943 MB
  Current xo-server heap limit  ~2240 MB (node default, no --max-old-space-size set)
  Recommended heap limit        7431 MB

[poddingue]

This is a nice bit of community tooling, and thanks for keeping it updated and being upfront about the "use at your own risk" part.
On the naming point a few people raised, I think the distinction folks are drawing is fair: XOA is the Vates-built appliance, and anything you compile yourself is XO from sources.
The official docs cover that path at https://docs.xen-orchestra.com/xo5/installation#from-the-sources, including the note that there is no pro support for that method.
Hope the project keeps going well!

[acebmxer]

While looking into the following issue - https://xcp-ng.org/forum/topic/11976/trying-to-enable-v2v-and-difficulty-adding-nbdinfo-on-xo-6/10

I found a few issues with my install script... Looking for recommendations on the fix approach.

I am noticing that are some confusion or inconsistencies with the documentation. Areas it suggest to use root and/or a non root account. Part of these issues would not be if the account used was root or with root access.

The two failures
Reason 1 — privileges (SERVICE_USER=xo-service, non-root):
XO's button runs apt-get install ..., make install, and ldconfig with no sudo (confirmed in esxi.mjs source). As xo-service, those commands are permission-denied: it can't apt-install, can't write to /usr/local/..., can't run ldconfig. XO's own dependency checker even says V2V requires root (UID 0) — which is why your sample-xo-config.cfg:56 already warns "V2V import requires root."

So yes — your instinct is correct. With SERVICE_USER=xo-service, the button cannot succeed no matter what.

But Reason 2 — build tools absent:
Even if you set SERVICE_USER=root and click the button, it will then try apt-get install -y git dh-autoreconf pkg-config make libxml2-dev ocaml libc-bin and compile from GitLab. That will work if the box has internet and apt is healthy — but it's a multi-minute source compile pulling ~hundreds of MB (ocaml!) every time, done live inside the web request. Pre-staging those packages via the installer makes the button fast and reliable instead of a long live compile.

So, is the fix "just set SERVICE_USER=root"?
To make the button function: yes, that is the necessary fix. Pre-installing build deps is an optional reliability/speed improvement on top.

Given your answers, here's my refined proposal — minimal, docs-aligned:

Proposed changes

1. Add INSTALL_V2V_DEPS=false opt-in to sample-xo-config.cfg. When true, the installer pre-stages XO's exact build-dep list (git dh-autoreconf pkg-config make libxml2-dev ocaml libc-bin) on apt systems only, so the button compiles quickly instead of installing them live. Default false → no ocaml bloat on normal installs.

2. Root guard (your "Warn only" preference): When INSTALL_V2V_DEPS=true and SERVICE_USER is non-root, print a prominent warning:

"VMware V2V import requires xo-server to run as root (per XO docs). The in-XO 'install nbdinfo' button runs apt-get/make install without sudo and will fail as user '$SERVICE_USER'. Set SERVICE_USER=root to use V2V import."
…and continue (don't abort).

3. RHEL/dnf: if INSTALL_V2V_DEPS=true on a non-apt system, log "VMware V2V import is only officially supported on Debian 12/13 per XO docs — skipping V2V dependency setup." and do nothing.

4. Keep the existing /usr/local/lib/vddk dir creation (it's correct — XO untars VDDK there), and don't touch APT contrib/multiverse or pre-compile nbdkit (XO compiles from source itself; distro packages are never used by the button).

5. Docs: README row for INSTALL_V2V_DEPS + a sharpened note in sample-config that V2V needs SERVICE_USER=root, linking the official guide.

This stays strictly within what XO's own code does, scopes the heavy deps behind opt-in, and surfaces the real root-user requirement you correctly identified.

Shall I implement this? If yes, I'll make the edits and run shellcheck/bats afterward to verify nothing breaks. (I have not edited anything yet.)

Prior to looking into this issue. I was trying to work on switching from standard user to root but that broke alot of things and will need rework. Dont belive it would be an issue if root was used to initially deploy xo.