cdnca
Browse all docs

Restart, upgrade, uninstall and migrate

Restart, logs, upgrades, backups, node uninstall and control-plane migration for cdnca.

Restart, logs, upgrades, backups, uninstall and migration for the control plane and nodes. Run the commands as root on the relevant server.

Restart

Control plane:

systemctl restart cdnca-control-api cdnca-agent-gateway cdnca-control-nats cdnca-control-web

Node:

systemctl restart cdnca-edge-agent

There is no separate OpenResty service on the node: cdnca-edge-agent starts and manages OpenResty. Restarting cdnca-edge-agent does not restart OpenResty and keeps active connections; if OpenResty is not running, the Agent starts it when it comes up.

Logs

journalctl -u cdnca-control-api -n 200 --no-pager

On a node use cdnca-edge-agent instead. The full install output is in /var/log/cdnca-install-control-*.log and /var/log/cdnca-install-node-*.log.

Upgrade

Upgrade only from "System → Maintenance & upgrade → System upgrade" in the console (a version can be pinned). Nodes are upgraded from "Node upgrade" on the same page, with a log per node. Never replace binaries by hand.

If an upgrade shows "upgrade failed, rolled back", the system is back on the previous version. Use "View logs" to note the reason and contact support rather than retrying again and again.

Backup

Under "System → Maintenance & upgrade → Maintenance actions", in "Control backup and migration":

  1. Click "Back up now". The backup stops control-api, the gateway and the upgrader, so the console is unavailable for a few minutes and then comes back; nodes keep serving.
  2. Under "Scheduled backups" choose days and time and how many copies to keep locally and off-site, then "Save settings".
  3. Under "Off-site storage" add S3/RustFS or SFTP, click "Test" and save once it reports the connection is OK. The test uses what you have typed; you do not need to save first.
  4. Click "Export recovery key" and set a recovery passphrase of at least 12 characters. If the control plane is lost entirely, you need the key file and the passphrase to open off-site backups. The passphrase is not stored; keep it apart from the file.

Check each backup's time, size and signature status in the backup list and run history. Record the backup signing fingerprint separately; it confirms on restore that a backup came from this control plane.

Uninstall a node

/usr/libexec/cdnca-edge-agent/uninstall.sh

Add --purge to also delete the node identity and local state (asks for confirmation):

/usr/libexec/cdnca-edge-agent/uninstall.sh --purge

Disable or delete the node in the console first and make sure it no longer carries site traffic.

Uninstall the control plane

There is no uninstall script for the control plane. Reinstall the OS to remove it completely.

Move the control plane to a new server

Migration moves the whole control plane to a fresh server: install matching dependencies there → freeze and encrypt a backup on the old one → transfer → restore and verify on the new one.

Prepare:

  1. A freshly installed new server.
  2. In the licence centre open the licence details and set the new server's public IP under "Migration download IP", so the new server can download the packages within the validity period. The migration keeps the existing installation and needs no new install command; once it is done, use "Change master IP" to switch to the new server.

Option 1, from the old console: in "Maintenance actions → Migrate control plane" enter the new server's IP or domain, SSH port, user and sign-in method, click "Fetch fingerprint" and check the host key, type the new address to confirm and click "Start migration". The old console stops immediately; check the result on the new one.

Option 2, on the new server; the installer fetches an encrypted backup from the old server over SSH, restores it and waits for nodes to reconnect:

bash install-control.sh migrate-from root@旧主控IP --ssh-port 22 --wait-nodes 10m

Afterwards:

  • Point the console and gateway domains at the new server; nodes reconnect by themselves.
  • Shut down the old server only after you can sign in, nodes are online and sites work on the new one. The old server stays frozen after migration so the two never write at the same time.
  • To roll back, point DNS back to the old server and unfreeze it on its maintenance page.