Download the package of your architecture from the release page, then:
sudo apt install ./warda_<version>_arm64.deb # or _amd64The package installs the warda service (systemd, unprivileged dynamic user,
data in /var/lib/warda) and starts it. Settings go in /etc/default/warda;
apply them with sudo systemctl restart warda. Ports 53, 80 and 443 must be
free: stop systemd-resolved's stub, dnsmasq, Pi-hole or a web server on the
same machine first.
Once Warda answers, the machine asks its own names to Warda too (the
Raspberry Pi image and the package, with NetworkManager, through
warda-system.service, once): 127.0.0.1 first, then the DNS servers of
the network if Warda does not answer within a second; the servers announced
over IPv6 are left out. Its traffic (lists, updates, time) then shows as the
device Warda, which stays with nobody and is never paused. Removing the
package gives the connection the DNS servers of its network back.
systemd watches Warda: a process that hangs for 30 seconds is restarted.
Each upgrade keeps the previous version (/usr/lib/warda/warda.previous);
if the new one fails to start 5 times in 15 minutes (StartLimitIntervalSec
of warda.service, long enough for starts that hang until their 2 minute
timeout), the previous one comes back by itself, provided it knows the
database of the new one (journalctl -u warda-rollback tells what
happened). The rollback acts only within a day of the upgrade (the date of
warda.previous): a service that fails weeks later, for example because
another program took port 53, is not the fault of its version. A version
never opens a database written by a newer one: an upgrade that changes the
database (0.5.4 does, the countries of the reports are now counted per
device) cannot be rolled back once the new version has started.