Install XO from sources.

lem2405

@acebmxer Is there a way to make the update feature completely unattended so it can be configured to run as a cron job?

Regards

acebmxer

@lem2405 said:

@acebmxer Is there a way to make the update feature completely unattended so it can be configured to run as a cron job?

Regards

Sure... Make sure you configure xo-config.cfg correctly. ./install-xen-orchestra.sh --update. It would only prompt for sudo passwor d.

Available Functions

Function	CLI Flag	Description
Deploy	`--deploy`	Create a Debian VM on a XenServer/XCP-ng pool and install XO into it
Build Templates	`--build-templates`	Build cloud-init VM templates on a XenServer/XCP-ng pool
Install	`--install`	Fresh install of Xen Orchestra
Update	`--update`	Update existing installation (with backup)
Restore	`--restore`	Restore from a previous backup (verified for completeness first; add `--list-backups` to just list them)
Rebuild	`--rebuild`	Fresh clone + clean build, preserves settings
Reconfigure	`--reconfigure`	Apply config changes without rebuilding
XO Proxy	`--proxy`	Deploy XO Proxy to a Xen pool master
Adjust Memory	`--adjust-memory`	Raise the heap memory allocated to the `xo-server` process
Status	`--status`	Read-only health report: version, service, TLS cert, disk/swap, backups/snapshots, git state
Edit Config	(menu only)	Open `xo-config.cfg` in your preferred editor
Rename Config	(menu only)	Rename `sample-xo-config.cfg` to `xo-config.cfg`

Running without flags launches an interactive menu. All flags also work directly:

./install-xen-orchestra.sh           # interactive menu
./install-xen-orchestra.sh --update  # run update directly
./install-xen-orchestra.sh --help    # show all options

lem2405

@acebmxer Excellent! Thanks a lot!

acebmxer

@lem2405 said:

@acebmxer Excellent! Thanks a lot!

Welcome, enjoy.. Please let me know if you have any issues or suggestions to help improve.

acebmxer

install_xen_orchestra v0.9.0 — install optional server plugins with `--custom-plugins`

Since the v0.7.2 post there's been a safety-net release (v0.8.0) and a new feature (v0.9.0). Everything from v0.8.0 through v0.9.0, in one place.

v0.8.0: VM snapshots before update/rebuild, and every RHEL template is now buildable

--update and --rebuild now take a normal XO API snapshot of the XO VM itself before touching anything, on top of the existing file backup — it shows up in XO's own UI under the VM's Snapshots tab like any other. Old ones get pruned automatically (keeps 3, or 14 days, whichever you set) so they don't pile up and trip XO's own Health-view warnings. This only works when XO itself is a Xen guest; bare metal just keeps the file backup as before.

Also new: a --status command that gives a read-only summary — version, how far behind master, service state, TLS cert expiry, disk/swap, backup and snapshot counts — and a --list-backups to see what's there without going through a restore. TLS certs now get a warning once they're under 30 days from expiring, wherever that check would previously only surface as a failed connection.

Rocky Linux 8, 9 and 10 dropped their "Coming Soon..." tag and build now — same tpl_prep_rhel script the AlmaLinux and CentOS Stream rows already use, since it's the same family. Every row in the template catalogue builds something now.

Rest of v0.8.0 was a security hardening pass — checksum-verifying the Node.js download, no more passwords on the command line for the XO Proxy helper, tightened file permissions on config.toml and the swap file — worth a look at the CHANGELOG if you're running this on anything you care about.

v0.9.0: `--custom-plugins` — install optional xo-server plugins with one command

XO has a plugin system (xo-server-auth-ldap, xo-server-load-balancer, that kind of thing) but nothing installs one for you — you're expected to drop it under node_modules by hand and restart the service. --custom-plugins (new menu entry too) does that part: pick a plugin, it gets copied to /usr/local/lib/node_modules/<name> — outside /opt/xen-orchestra, so --update's rebuild never touches it — and xo-server restarts to pick it up. Run it again and anything already installed shows pre-checked; uncheck to remove, check something new to install, leave one checked to refresh it if this repo's copy has changed since. Configuration itself still happens the normal way, in XO's own Settings > Plugins.

Two plugins ship to start:

xo-server-nanokvm — power control for a host fitted with a Sipeed NanoKVM, over its REST API.
xo-server-host-power-manager — powers an extra pool host on when CPU or memory gets tight, and powers it back off (evacuated first, same path as XO's own maintenance mode) once it isn't needed. Power-on can go through NanoKVM or XO's built-in iLO/DRAC/Wake-on-LAN.

Docs: docs/custom-plugins.md

The host-power-manager plugin got the most testing this round, and threw up a few real bugs against a live pool: saving its settings while it was already running silently killed every rule's timer until the next xo-server restart, its CPU/memory numbers disagreed with XO's own dashboard because it was excluding the managed host from the pool total, and there was no way to build a CPU-only or memory-only rule since both thresholds were required. All three are fixed, and power-off is now HA-aware — it defers to XAPI's own failover check and just leaves the host running and retries later rather than forcing an evacuation that would break your HA plan.

Repo: https://github.com/acebmxer/install_xen_orchestra

As always, let me know if you try either plugin out or hit anything.

acebmxer

Small update — I split the custom plugins out of this project into their own repo, for anyone who just wants the plugins without pulling in the whole install script:

https://github.com/acebmxer/xo-plugins

Same deal as always — use at your own risk, review the code before running it on anything that matters. The two plugins in there are also still shipped inside this install script's Custom Plugins menu, kept in sync automatically — this repo just exists for people who don't want the rest of the project.

xo-server-nanokvm

This one's probably the more useful of the two for a lot of people. If you've got a host with no iLO/DRAC/IPMI — most consumer/prosumer boards, a lot of homelab gear — and you've wired up a Sipeed NanoKVM to the power header, this plugin lets Xen Orchestra power that host back on through the NanoKVM's own API. Same interface the NanoKVM web UI itself uses to press the button, just done from XO.

On its own it doesn't decide when to turn a host on, it just gives XO a way to do it. Pairs with the other plugin below for that, or you could call it from your own automation if you wanted.

Worth knowing: it can only press the button, it has no way to know if the host is actually on or off, so it only handles power-on. Powering off goes through XO's normal shutdown, which is a clean OS shutdown and evacuates VMs first — no reason to route that through the NanoKVM.

Setup is a config entry per host: label, the NanoKVM's URL, a login, and which XO host it's wired to. Recommend making it a dedicated user-role account on the NanoKVM rather than admin — that role already has power/reset access without giving the plugin anything to storage/network settings on the KVM itself.

xo-server-host-power-manager

This is the one that actually decides when to act. Point it at an "extra" host in the pool and give it CPU and/or memory thresholds — when the rest of the pool is under pressure it powers that host on, and once things calm down for a while it powers it back off. Power-on can go through XO's built-in methods or through the NanoKVM plugin above, your choice per rule.

Powering off always goes through XO's own host shutdown — it evacuates the running VMs first, and if HA is on and doesn't have room to cover it, XAPI just refuses and the plugin backs off and tries again later rather than forcing anything.

It's deliberately quick to scale up and slow to scale down (needs both CPU and memory comfortable for a full cooldown period before it'll power a host off) so it's not flapping a host on and off over a short spike.

Both have a Test button in their config page that actually tells you something useful, unlike XO's own generic "test plugin" popup — check journalctl -u xo-server right after clicking it to see what it found.

As always, happy to hear feedback or find out I've broken something.

lem2405

@acebmxer Even with the credentials present in the configuration file, the process still prompts for sudo permissions, which will not be visible or actionable when running as a cron job.

acebmxer

@lem2405

Sorry for any confusion. Hope this clears it up.

The credentials in xo-config.cfg are only for logging into Xen Orchestra (the pre-update task check and VM snapshot). There is no setting for a sudo password, and the script won't run as root, so sudo will still ask.

To run it from cron, the account running the script needs passwordless sudo. Run this as that user:

echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/xo-cron
sudo chmod 440 /etc/sudoers.d/xo-cron
sudo visudo -c

Then add --non-interactive so it doesn't stop to ask anything:

0 3 * * * cd /path/to/install_xen_orchestra && ./install-xen-orchestra.sh --update --non-interactive

Keep in mind this gives that account full sudo with no password. Use at your own risk.

I've pushed this to the dev branch, including a new Scheduled Updates (cron) section in the README. To try it before it reaches main, switch your copy to dev:

cd /path/to/install_xen_orchestra
git fetch origin
git checkout dev

To go back later, run git checkout main.

Scheduled Updates (cron)

--update can run unattended from cron. Two things are needed:

Passwordless sudo for the account that runs the script. The script
refuses to run as root and calls sudo throughout, and there is no config
setting for a sudo password. Run this as that account:
```
echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/xo-cron
sudo chmod 440 /etc/sudoers.d/xo-cron
sudo visudo -c
```
This gives the account full sudo with no password.

--non-interactive, so the update never stops to ask anything:

0 3 * * * cd /path/to/install_xen_orchestra && ./install-xen-orchestra.sh --update --non-interactive >> "$HOME/xo-update.log" 2>&1

Set XO_API_TOKEN (or the user/password pair) in xo-config.cfg.
Without it, a non-interactive run skips the
running task check instead of
prompting for credentials.

lem2405

@acebmxer Thank you for your help and prompt response. I truly appreciate it!

acebmxer