Kuzz007
8daf1d844d
- Replace the mktemp+cp snapshot with a same-filesystem mv of bin/ aside: an unchecked mktemp failure previously made the very next line copy bin/'s contents into "/" (empty custom_bin_backup + trailing slash), and a silently-ignored cp failure (stderr redirected, exit code never checked) could leave a truncated custom geo file that gets "restored" as if it were intact. A rename is atomic and needs no extra disk space, removing both failure modes at once; if it fails, back off cleanly and say so instead of proceeding as if a backup exists. - Add a trap so an interrupted update (Ctrl-C, signal) between the backup and the restore doesn't leave the snapshot (which contains bin/config.json and every mtproto client's FakeTLS secret) sitting around indefinitely; the two exit-path cleanups this replaces are gone since the trap now covers those exits too. - Move the restore below the arm arch-rename/chmod block instead of before it, so xray-linux-arm32/mtg-linux-arm already exist under their final names and don't get needlessly restored-then-overwritten and misreported as "custom". - Exclude bin/config.json and bin/mtproto/*.toml from the restore: those are the panel's own generated runtime state (internal/xray/process.go, internal/mtproto/manager.go), not admin-placed files, and restoring a stale one only resurrects dead state or recreates bin/mtproto/ with the wrong (more permissive) directory mode. - Match symlinks in the restore's find, not just plain files -- cp -a already preserves them in the snapshot, but the restore loop was silently dropping them, which is exactly the failure mode (a geo file symlinked in from elsewhere) this PR set out to fix. - Quote the two new xui_folder expansions. - Extend the non-interactive smoke test to reinstall over an existing install with a sentinel file in bin/, asserting it survives and that the bundled geoip.dat is still the release's own copy -- the update path this PR touches had no CI coverage at all before this. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cloud deployment (unattended install)
Tooling to ship the 3x-ui panel via unattended install, with per-instance
credentials generated on first boot (never admin/admin, never a shared
session secret). Works on amd64 and arm64.
| Path | What it is | Use when |
|---|---|---|
cloud-init/ |
Generic cloud-init user-data (unattended install.sh) |
Any cloud, no image build |
marketplace/hetzner/ |
Hetzner Cloud notes | Hetzner deployments |
test/ |
Container smoke test | Verifying the install path |
How it works
install.sh runs unattended when XUI_NONINTERACTIVE=1 or stdin is not a TTY.
Each instance installs and configures itself with random credentials. See
cloud-init/README.md.
Unattended install knobs
install.sh reads these env vars in non-interactive mode (all optional; unset ⇒
secure random / default):
XUI_USERNAME, XUI_PASSWORD, XUI_PANEL_PORT, XUI_WEB_BASE_PATH,
XUI_SSL_MODE (none|ip|domain, default none), XUI_DOMAIN,
XUI_ACME_EMAIL, XUI_ACME_HTTP_PORT (ACME HTTP-01 listener port, default 80),
XUI_SSL_IPV6 (optional IPv6 address to add to an ip-mode cert),
XUI_SERVER_IP (fallback IP for the displayed access URL when auto-detection fails),
XUI_DB_TYPE (sqlite|postgres), XUI_DB_DSN.
The resulting credentials are written to /etc/x-ui/install-result.env (mode 600).