Updates

With the Debian package (and the Raspberry Pi image), Warda updates itself: once a night between 02:00 and 05:00 (each machine at its own time), it installs the latest stable release, unless an administrator turned automatic updates off on the System page. The same page tells the last result and checks or updates at once. Only a release whose SHA256SUMS is signed by the release key built into Warda (Ed25519) is installed, and the package must match its checksum. The service itself never installs anything: it writes a request that warda-update.service (root, run by warda-update.timer and warda-update.path) carries out; journalctl -u warda-update tells what happened, sudo warda update updates by hand and warda update -check only looks. With a data directory other than /var/lib/warda, a request waits for the next run of the timer (5 minutes).

• The package is installed with dpkg --force-confdef --force-confold: an /etc/default/warda changed by an administrator is kept, and nothing is asked.
• A dpkg locked by another one (apt, unattended-upgrades) is waited for, up to 10 minutes. That failure, like a full disk, is not held against the version: it is tried again at the next run.
• After installing, the updater waits up to 3 minutes for the new version to run 30 seconds in a row. If it does not, the updater puts the previous version back itself (/usr/lib/warda/rollback), without waiting for systemd to give up.
• A version that did not stay up is not installed again at night; an administrator can still install it. The rollback, whoever starts it, writes the version it took away in /var/cache/warda/update/rolled-back, which the next run of the updater reads.
• The nightly attempt counts once the list of the releases could be read: when the release server does not answer, it is tried again at the next run (every 5 minutes in the window).
• Only an https:// update server is accepted (http:// only on the machine itself, localhost or a loopback address), for the list and for the package. The list of the releases is read with limit=20.
• The helper units (warda-update.timer, warda-update.path, warda-backup-usb.timer, warda-system.path) are turned on once, the first time the package brings them, also on upgrade; the units already turned on are listed in /usr/lib/warda/units-enabled. A unit an administrator disabled stays disabled.
• warda-update.service runs as root with a writable file system (dpkg writes /usr and /etc), and is otherwise closed: private /tmp, no home directories, no kernel modules, kernel logs, control groups, clock or host name changes, only IPv4, IPv6 and Unix sockets, no namespaces, no real-time scheduling, native system calls only.

The releases come from the public repository warda-dns/releases of https://gitea.tips-of-mine.com (WARDA_UPDATE_SERVER and WARDA_UPDATE_REPO in /etc/default/warda to change it). The public repository must hold at least one commit (a README): the CI creates the tags of the releases on its default branch.

The Docker image and the archive are never updated by Warda. When Check every day for a new version is on (the same setting as the nightly updates, on by default), Warda checks once a day, the first time 1 to 61 minutes after it starts, for a new signed stable release, and shows it on the System page and in the summary of the services, with the command to run in the folder of the compose file: docker compose pull && docker compose up -d. Check now checks at once. Only the list of the releases, SHA256SUMS and its signature are downloaded; nothing is installed. warda update -check works there too; warda update refuses to install outside the Debian package.