From 90fed8160fbfaf20e778ec8981be315949089b9f Mon Sep 17 00:00:00 2001 From: catborise Date: Fri, 6 Nov 2026 09:11:58 +0300 Subject: [PATCH] docs(readme): moving to a new machine works with a SECRET_KEY from the compose file A panel that takes SECRET_KEY from its environment has no data/secret_key, so its backup has none. The Docker moving steps copied it unconditionally: the copy failed after the database had already been replaced, and the chain stopped before node_id, the SSH keys and `up -d`. The copy is now skipped when the backup has no key, and the section says to set the same value on the new machine. It also says to stop the old panel first when both use one PostgreSQL database: the moved worker id would let both workers take each other's lease and jobs. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 770655c0..70479317 100644 --- a/README.md +++ b/README.md @@ -719,7 +719,7 @@ A version from before v3.0.0 has no worker: `systemctl disable --now webvirt-wor ### Moving to a new machine -A [backup](#backups) moves the panel to a new machine, or back onto lost volumes: the database, the secret key (signed-in users stay signed in), the worker's id and the SSH keys and TLS certificates the computes accept. Install the panel there first, the same version or a newer one, then copy the backup directory over and set `b` to it. The backup does not hold `docker-compose.override.yml`, the nginx config or `/etc/default/webvirtcloud`: bring your own lines over yourself. Users sign in with their passwords from the backup; the new installation's `data/admin_password` no longer applies. +A [backup](#backups) moves the panel to a new machine, or back onto lost volumes: the database, the secret key (signed-in users stay signed in), the worker's id and the SSH keys and TLS certificates the computes accept. Install the panel there first, the same version or a newer one, then copy the backup directory over and set `b` to it. The backup does not hold `docker-compose.override.yml`, the nginx config or `/etc/default/webvirtcloud`: bring your own lines over yourself. Users sign in with their passwords from the backup; the new installation's `data/admin_password` no longer applies. A `SECRET_KEY` set in the compose file has no `secret_key` in the backup: set the same value on the new machine. With PostgreSQL, stop the old panel before the new one starts: both would run the jobs of the one database. Docker, in the directory you installed from: @@ -728,7 +728,7 @@ b=../webvirtcloud-backup-YYYYMMDD-HHMMSS && docker compose stop -t 95 && docker compose run --rm --no-deps -T --entrypoint /srv/webvirtcloud/venv/bin/python3 webvirtcloud \ -c "import os,sqlite3,sys,tempfile; t=tempfile.mktemp(); open(t,'wb').write(sys.stdin.buffer.read()); [os.remove(p) for p in ('data/db.sqlite3-journal','data/db.sqlite3-wal','data/db.sqlite3-shm') if os.path.exists(p)]; sqlite3.connect(t).backup(sqlite3.connect('data/db.sqlite3'))" < "$b/db.sqlite3" && -docker compose cp "$b/secret_key" webvirtcloud:/srv/webvirtcloud/data/ && +{ [ ! -f "$b/secret_key" ] || docker compose cp "$b/secret_key" webvirtcloud:/srv/webvirtcloud/data/; } && docker compose cp "$b/node_id" webvirtcloud:/srv/webvirtcloud/data/ && { [ ! -d "$b/ssh" ] || docker compose cp "$b/ssh/." webvirtcloud:/var/www/.ssh/; } && { [ ! -d "$b/pki" ] || docker compose cp "$b/pki/." webvirtcloud:/var/www/.pki/; } &&