Rename the CLI package to tsunagi and its executable to tsng

The command line package is now `tsunagi` and builds the `tsng` executable,
which the packages, the unit, the installers and the workflows install and
run. The core library package becomes `tsunagi-core`, keeping the library name
`tsunagi`, so no code changes `use tsunagi::...`. Directories follow
(crates/tsunagi-core, crates/tsunagi). Every command shown to a person is now
`tsng ...`.

Co-Authored-By: Claude <noreply@anthropic.com>

dist/arch/README.md

@@ -6,7 +6,7 @@ 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
+It drops a static, dependency-free binary at `/usr/bin/tsng`, a systemd
 service, and a polkit rule, and creates a dedicated system user `tsunagi` the
 service runs as.
 
@@ -21,8 +21,8 @@ user; `sudo` reaches it with no extra flags, because the CLI finds the running
 service's socket at `/run/tsunagi/agent.sock`):
 
 ```sh
-sudo tsunagi status
-sudo tsunagi join <network-name> <tsn1…secret>
+sudo tsng status
+sudo tsng join <network-name> <tsn1…secret>
 ```
 
 ## How it runs
@@ -39,7 +39,7 @@ creates and owns its directories:
 
 Installing the package enables and starts the service, and adds the user who ran
 pacman to the `tsunagi` group (log out and in again for it to apply). The
-control socket is open to that group, so members can run `tsunagi status`, the
+control socket is open to that group, so members can run `tsng status`, the
 CLI and the tray GUI without sudo; anyone else adds themselves with `sudo
 usermod -aG tsunagi "$USER"`. The group also lets its members configure
 systemd-resolved for the overlay zones through the polkit rule.

dist/arch/build-pkg.sh

@@ -31,10 +31,10 @@ pkgrel=1
 
 # Payload. Arch keeps units under /usr/lib/systemd/system and installs to
 # /usr/bin, so the service's ExecStart is rewritten to match.
-install -D -m 0755 "$binary" "$root/usr/bin/tsunagi"
+install -D -m 0755 "$binary" "$root/usr/bin/tsng"
 
 mkdir -p "$root/usr/lib/systemd/system"
-sed 's#/usr/local/bin/tsunagi#/usr/bin/tsunagi#' \
+sed 's#/usr/local/bin/tsng#/usr/bin/tsng#' \
     "$here/../linux/tsunagi.service" > "$root/usr/lib/systemd/system/tsunagi.service"
 chmod 0644 "$root/usr/lib/systemd/system/tsunagi.service"
 

dist/deb/build-deb.sh

@@ -25,10 +25,10 @@ trap 'rm -rf "$root"' EXIT
 # Payload. Debian installs to /usr/bin (not /usr/local), so the service's
 # ExecStart is rewritten to match; the source unit targets /usr/local/bin for
 # the tarball installer.
-install -D -m 0755 "$binary" "$root/usr/bin/tsunagi"
+install -D -m 0755 "$binary" "$root/usr/bin/tsng"
 
 mkdir -p "$root/lib/systemd/system"
-sed 's#/usr/local/bin/tsunagi#/usr/bin/tsunagi#' \
+sed 's#/usr/local/bin/tsng#/usr/bin/tsng#' \
     "$here/../linux/tsunagi.service" > "$root/lib/systemd/system/tsunagi.service"
 chmod 0644 "$root/lib/systemd/system/tsunagi.service"
 
@@ -43,7 +43,7 @@ desc_gui=""
 if [ -n "$tray" ]; then
     pkgname=tsunagi-gui
     # The GUI package is a superset of the headless one and must not coexist
-    # with it (both ship /usr/bin/tsunagi).
+    # with it (both ship /usr/bin/tsng).
     extra_control=$'Conflicts: tsunagi\nReplaces: tsunagi\nProvides: tsunagi\n'
     # What the tray and its window load at run time.
     extra_control+=$'Depends: libgtk-3-0 | libgtk-3-0t64, libayatana-appindicator3-1 | libappindicator3-1, libxdo3, libxkbcommon0, libwayland-client0, libx11-6, libgl1\n'

dist/linux/README.md

@@ -27,27 +27,27 @@ group, so after `sudo usermod -aG tsunagi "$USER"` (and logging in again) no
 `sudo` is needed:
 
 ```sh
-sudo tsunagi status
-sudo tsunagi join <network-name> <tsn1…secret>
+sudo tsng status
+sudo tsng join <network-name> <tsn1…secret>
 ```
 
 ## As your own user — one capability, no service
 
 ```sh
-sudo install -m 0755 tsunagi /usr/local/bin/tsunagi
-sudo setcap cap_net_admin,cap_net_bind_service+p /usr/local/bin/tsunagi
+sudo install -m 0755 tsunagi /usr/local/bin/tsng
+sudo setcap cap_net_admin,cap_net_bind_service+p /usr/local/bin/tsng
 sudo usermod -aG tsunagi "$USER"   # so the resolver works; log in again after
-tsunagi up
+tsng up
 ```
 
 Nothing runs as root. The capability is lost on every rebuild or copy of the
 binary, so re-run `setcap` after replacing it. The agent uses your per-user
-state directory and socket, so plain `tsunagi status` (no sudo) reaches it.
+state directory and socket, so plain `tsng status` (no sudo) reaches it.
 
 ## Without touching the OS
 
 ```sh
-tsunagi up --no-tun
+tsng up --no-tun
 ```
 
 Tunnels form and handshake between agents, but no interface, address or route is

dist/linux/install.sh

@@ -18,7 +18,7 @@ fi
 
 echo "Installing tsunagi to ${PREFIX}/bin"
 install -d "${PREFIX}/bin"
-install -m 0755 "${here}/tsunagi" "${PREFIX}/bin/tsunagi"
+install -m 0755 "${here}/tsng" "${PREFIX}/bin/tsng"
 
 # The dedicated system user the service runs as (works with either shadow's
 # useradd or Debian's adduser).
@@ -47,19 +47,19 @@ Done. Start the agent with:
 
 Control it with sudo (the CLI finds the service's socket automatically):
 
-    sudo tsunagi status
-    sudo tsunagi join <network-name> <tsn1…secret>
+    sudo tsng status
+    sudo tsng join <network-name> <tsn1…secret>
 EOF
 else
     cat <<EOF
 
 Installed the binary; no systemd found, so no service was set up. Either:
 
-  * run it as root:            sudo ${PREFIX}/bin/tsunagi up
-  * or as your own user:       sudo setcap cap_net_admin,cap_net_bind_service+p ${PREFIX}/bin/tsunagi
-                               tsunagi up
+  * run it as root:            sudo ${PREFIX}/bin/tsng up
+  * or as your own user:       sudo setcap cap_net_admin,cap_net_bind_service+p ${PREFIX}/bin/tsng
+                               tsng up
     (add yourself to the tsunagi group so the resolver works:
      sudo usermod -aG tsunagi "\$USER")
-  * or without touching the OS: tsunagi up --no-tun
+  * or without touching the OS: tsng up --no-tun
 EOF
 fi

dist/linux/tsunagi.service

@@ -30,7 +30,7 @@ Environment=TSUNAGI_CONTROL_GROUP=tsunagi
 
 # The tarball installer puts the binary here; the deb and the Arch package
 # rewrite this to /usr/bin where they install it.
-ExecStart=/usr/local/bin/tsunagi up
+ExecStart=/usr/local/bin/tsng up
 Restart=on-failure
 RestartSec=5
 

dist/macos/README.md

@@ -7,15 +7,15 @@ Linux. There are two ways to run it.
 ## Quick start — `sudo`
 
 ```sh
-sudo tsunagi up
+sudo tsng up
 ```
 
 In another terminal, the control commands talk to it over the system control
 socket and do **not** need `sudo`:
 
 ```sh
-tsunagi status
-tsunagi join <network-name> <tsn1…secret>
+tsng status
+tsng join <network-name> <tsn1…secret>
 ```
 
 The agent uses fixed system paths, so the commands find it regardless of whose
@@ -34,7 +34,7 @@ For an always-on agent that starts at boot, install the bundled
 
 ```sh
 # Put the binary where the plist expects it (edit the plist for another path).
-sudo install -m 0755 target/release/tsunagi /usr/local/bin/tsunagi
+sudo install -m 0755 target/release/tsng /usr/local/bin/tsng
 
 # Install the daemon. launchd refuses a daemon plist that is not owned by
 # root:wheel or that is group/world-writable.
@@ -56,7 +56,7 @@ tail -f /var/log/tsunagi.log                          # logs
 ```
 
 The control commands (`status`, `join`, `network`, `dns`) work the same against
-the daemon as against a `sudo tsunagi up`, over the same socket.
+the daemon as against a `sudo tsng up`, over the same socket.
 
 ## What the agent does to the system
 
@@ -74,7 +74,7 @@ off, or the agent stops:
   it wrote, never one you created by hand.
 - while broadcast is on, a `255.255.255.255` **route** through the overlay
   interface. The matching inbound-UDP firewall allowance is **not** implemented
-  yet (it needs a `pf` anchor); `tsunagi status` reports that half as incomplete
+  yet (it needs a `pf` anchor); `tsng status` reports that half as incomplete
   and names what to allow by hand if your host firewall drops discovery replies.
 
 Nothing taken from a remote peer ever becomes a path, a command argument or an

dist/macos/cy.hexor.tsunagi.plist

@@ -10,7 +10,7 @@
   root:wheel with mode 0644 — launchd refuses a daemon plist that is
   group- or world-writable. See README.md in this directory.
 
-  Edit the binary path if tsunagi is not at /usr/local/bin/tsunagi.
+  Edit the binary path if tsng is not at /usr/local/bin/tsng.
 -->
 <plist version="1.0">
 <dict>
@@ -22,7 +22,7 @@
          must not daemonise itself. -->
     <key>ProgramArguments</key>
     <array>
-        <string>/usr/local/bin/tsunagi</string>
+        <string>/usr/local/bin/tsng</string>
         <string>up</string>
     </array>
 

dist/windows/README.md

@@ -1,18 +1,18 @@
 # Running tsunagi on Windows
 
-This archive holds `tsunagi.exe`. The overlay interface is a Wintun adapter, so
+This archive holds `tsng.exe`. The overlay interface is a Wintun adapter, so
 the agent needs two things to carry real traffic:
 
 1. **`wintun.dll` beside the executable.** Download it from
    <https://www.wintun.net>, take the DLL for your architecture (`amd64`), and
-   put it in the same folder as `tsunagi.exe`.
+   put it in the same folder as `tsng.exe`.
 2. **An elevated process.** Creating the adapter requires Administrator rights.
 
 Open PowerShell or Command Prompt with **Run as administrator** and start the
 agent there:
 
 ```powershell
-.\tsunagi.exe up
+.\tsng.exe up
 ```
 
 Run the commands that control it (`join`, `status`, `dns`, `network`) as the
@@ -23,7 +23,7 @@ regardless of which account started the agent.
 ## Without touching the OS
 
 ```powershell
-.\tsunagi.exe up --no-tun
+.\tsng.exe up --no-tun
 ```
 
 Tunnels form and handshake between agents, but no adapter, address or route is