mirror of https://github.com/Vateron-Media/XC_VM.git synced 2026-10-29 03:03:20 +01:00

Files

T

Divarion_D 55f6fcf206 feat(update): add per-server version rollback from the panel

Adds a "safety net" rollback so a server can be downgraded to an earlier
release without a manual redeploy, mirroring the existing update flow.

- GitHubReleases: getVersionFile() fetches a specific version's asset (not
  just latest); getPreviousVersions() lists the newest releases older than a
  given version, each flagged beta (GitHub prerelease). getReleases() now
  delegates to a shared getFilteredReleases() that keeps the prerelease flag.
- UpdateCommand: new `rollback <version>` case — validates the target is a
  real, strictly-older release; on MAIN takes an automatic DB backup first
  (aborting if it fails); downloads the exact version (main/lb_update asset),
  verifies MD5, and hands off to the same python `update` applier.
- RootSignalsCronJob: dispatch the `rollback` signal to `console.php update
  rollback <version>` (version regex-validated, escapeshellarg'd).
- api.php: `rollback_versions` (channel-aware list, optional per-server base
  version) and server `sub=rollback` (validates version, writes the signal).
- servers.php: per-server "Rollback Version" action (dropdown item + button)
  opening a modal to pick a version; beta builds show "(beta)". Works for
  MAIN and each LB independently.
- docs: rollback sections in server-update.md and update-system.md.

The downgrade reuses the version-agnostic python applier, so binaries,
config and user data are preserved. Migrations are forward-only and are not
rolled back; the automatic MAIN backup is the recovery path.

2026-08-26 19:27:29 +03:00

3.1 KiB

Raw Blame History

Updating a Server

Step-by-step guide to updating an XC_VM server. For the internals of the update process, see Update Mechanism.

💾 Before updating, it is recommended to create a backup.

Updating via the Panel

Step 1. Open the Servers section in the top menu of the panel.

Step 2. Select Manage Servers from the dropdown menu.

Step 3. Locate the target server in the servers table and click the menu button in the Actions column.

Step 4. Select Server Tools from the menu.

Step 5. In the Server Tools dialog, click Update Server.

Clicking the button inserts an update signal into the database. Within a minute, CRON picks it up and the update runs automatically: the panel is stopped, updated, and restarted. You can track progress via the server version in the Manage Servers table.

Manual Update (CLI)

sudo -u xc_vm /home/xc_vm/console.php update update

Downloads and applies the latest update from GitHub. Usually triggered automatically through the web panel.

Rolling Back a Server

If an update introduces a problem, you can roll a server back to an earlier release directly from the panel. Rollback works per-server, so both the MAIN panel and individual Load Balancers can be downgraded independently.

Step 1. Open the Servers section → Manage Servers.

Step 2. Locate the target server and open its Actions menu (the same menu used for updating).

Step 3. Click Rollback Version. A dialog opens listing earlier releases (newest first). Pre-release builds are tagged (beta).

Step 4. Select the version to roll back to and confirm.

Clicking Rollback inserts a rollback signal (carrying the chosen version) into the database. Within a minute CRON picks it up and the rollback runs automatically, reusing the same stop → replace → restart flow as an update. Track progress via the server version in the Manage Servers table.

💾 On the MAIN server a database backup is taken automatically before the rollback, saved to /home/xc_vm/backups/pre_rollback_<from>_to_<to>_<timestamp>.sql. Load balancers have no database, so this step is skipped.

The versions offered depend on the server's update channel: on the stable channel only stable releases are listed; on unstable you also see (beta) pre-releases.

⚠️ A rollback does not undo database migrations — they are forward-only. The schema is designed to stay backward-compatible, and the automatic backup is the recovery path if an older build cannot read newer data. Use rollback only as a recovery step.

Manual Rollback (CLI)

sudo -u xc_vm /home/xc_vm/console.php update rollback 2.4.0

Downloads the specified release from GitHub and applies it, with the same integrity checks and — on MAIN — the automatic database backup.

3.1 KiB Raw Blame History