Files
tsunagi/dist/arch
UltradesuandClaude Opus 4.8 f63343a6a0
Release / tsunagi-linux-aarch64 (push) Failing after 2m40s
Release / tsunagi-linux-x86_64 (push) Failing after 2m40s
Release / tsunagi-macos-aarch64 (push) Canceled after 0s
Release / tsunagi-windows-x86_64 (push) Canceled after 0s
Release / Publish release (push) Canceled after 0s
CI: ship the tray GUI — in the archives and as tsunagi-gui deb/zst
Adds the tray application to the release:

- Every target's archive now also contains the tsunagi-tray binary. On Linux it
  is built against an old glibc baseline (via cargo-zigbuild) rather than static
  musl, because a GUI must dlopen libGL/X11/Wayland at runtime and a static musl
  binary cannot; the agent stays static musl. macOS and Windows build the tray
  natively.
- New GUI package variants for Linux: `tsunagi-gui` .deb and .pkg.tar.zst, built
  by the existing scripts with an extra tray argument. They install the agent
  (service, polkit, user — same as the headless packages) plus the tray binary,
  a desktop launcher (dist/linux/tsunagi-tray.desktop) and an icon
  (dist/linux/tsunagi.svg), so the GUI appears in the applications menu. The GUI
  package conflicts/replaces/provides the headless tsunagi so the two do not
  coexist.
- The tray finds the system service with no configuration: the library's default
  control-socket path now prefers /run/tsunagi/agent.sock when present (both the
  tray and CLI use this), falling back to the per-user path.

No control-protocol change. Builds, fmt and clippy clean on macOS; the Linux GUI
cross-build and the packages are exercised only by a real CI run.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-10-02 16:26:45 +01:00
..

Running tsunagi on Arch Linux

Install the package built for your architecture:

sudo pacman -U tsunagi-*-x86_64.pkg.tar.zst

It drops a static, dependency-free binary at /usr/bin/tsunagi, a systemd service, and a polkit rule, and creates a dedicated system user tsunagi the service runs as.

Start it:

sudo systemctl enable --now tsunagi

Control it with sudo (the agent's control socket is private to the service user; sudo reaches it with no extra flags, because the CLI finds the running service's socket at /run/tsunagi/agent.sock):

sudo tsunagi status
sudo tsunagi join <network-name> <tsn1…secret>

How it runs

The service runs as the unprivileged tsunagi user with just two capabilities (CAP_NET_ADMIN, CAP_NET_BIND_SERVICE) granted by systemd — no root. systemd creates and owns its directories:

what path
state /var/lib/tsunagi
cache /var/cache/tsunagi
control socket /run/tsunagi/agent.sock

The polkit rule lets anyone in the tsunagi group configure systemd-resolved for the overlay zones (the service user is in that group). To run the agent as your own user as well, add yourself to the group: sudo usermod -aG tsunagi "$USER".

Removal

sudo pacman -R tsunagi

stops and disables the service. The tsunagi user and /var/lib/tsunagi are left in place; remove them by hand if you want them gone.