README: NetBird-Deploy + CI/CD-Pipeline

README.md

@@ -1,3 +1,83 @@
-# netbird-slate7
+# NetBird-Deploy für GL.iNet Slate 7 (GL-BE3600)
 
-NetBird-Deploy fuer GL.iNet Slate 7 (auto-mirror + Installer)
+Bindet den Slate 7 als Peer in das self-hosted NetBird (`https://nb.digiflo.at:443`) ein —
+reboot- und firmware-upgrade-fest, **ohne Custom-Firmware**.
+
+Dieses Repo ist gleichzeitig die **CI/CD-Pipeline**: ein Gitea-Actions-Workflow prüft täglich
+auf neue NetBird-Versionen und spiegelt das aarch64-Binary automatisch als **Release**, von dem
+der Router per Ein-Zeiler installiert/upgradet.
+
+---
+
+## Installieren / Upgraden (auf dem Router, als root)
+
+```sh
+wget -qO- https://gitea.digiflo.at/digiflo/netbird-slate7/raw/branch/main/install-netbird-slate7.sh | sh
+```
+
+Das zieht das jeweils **neueste Release** (= neueste getestete NetBird-Version) aus Gitea,
+prüft die SHA256, tauscht das Binary und startet den Dienst neu. Schon enrollt? → bleibt enrollt
+(Profil/Key liegen persistent in `/etc/netbird/`). **Genau dieser Befehl ist auch das Upgrade.**
+
+### Erstinstallation inkl. Enrollment
+
+Setup-Key im NetBird-Dashboard erzeugen (*Setup Keys → Create*, optional Tag `slate7`), dann:
+
+```sh
+wget -qO /tmp/nb.sh https://gitea.digiflo.at/digiflo/netbird-slate7/raw/branch/main/install-netbird-slate7.sh
+sh /tmp/nb.sh DEIN-SETUP-KEY
+```
+
+`netbird status` muss danach „Management: Connected" und eine `100.116.x.x`-IP zeigen.
+
+---
+
+## Wie die Automatik funktioniert
+
+`.gitea/workflows/release.yml` (Runner `ct117-docker`):
+
+1. **Trigger:** täglich 04:17 UTC (cron) · manuell (*Actions → Run workflow*, mit `force`-Option) ·
+   bei Push auf den Workflow.
+2. Holt die neueste NetBird-Version von der GitHub-API.
+3. Existiert dafür schon ein Gitea-Release? → **fertig** (idempotent, kein Doppel-Release).
+4. Sonst: lädt `netbird_<ver>_linux_arm64.tar.gz`, bildet die SHA256 und legt ein
+   **Gitea-Release `v<ver>`** mit Binary + Prüfsumme an.
+
+→ Bei jeder neuen NetBird-Version erscheint hier automatisch ein neues Release. Auf „Watch"
+stellen = Mail-Benachrichtigung. Der Router holt es sich beim nächsten Lauf des Ein-Zeilers.
+
+**Manuell auslösen / Version sofort ziehen:** in Gitea unter *Actions* den Workflow
+`netbird-slate7-release` mit *Run workflow* starten (oder `force=true`, um ein Release neu zu bauen).
+
+---
+
+## Bedienung am Router
+
+```sh
+netbird status                         # Verbindungsstatus
+netbird status -d                      # Details (Peers/Routen)
+/etc/init.d/netbird restart            # Dienst neu starten
+sh /tmp/nb.sh status                   # Versions-/Statuscheck
+sh /tmp/nb.sh uninstall                # restlos entfernen
+```
+
+---
+
+## Technische Eckpunkte
+
+- **Statisches Go-Binary** (von NetBird-Releases) → kein musl-Problem mit der GL-Firmware.
+- **procd-Dienst** `/etc/init.d/netbird`, Interface `wt0`, Kernel-WireGuard.
+- **Persistenz:** Profil/Key in `/etc/netbird/` → übersteht Reboot **und** Firmware-Upgrade
+  (`/etc` bleibt bei `sysupgrade` erhalten). NICHT bei Werks-Reset.
+- **Quelle:** primär das Gitea-Release (SHA256-verifiziert), Fallback direkt GitHub, falls Gitea
+  mal nicht erreichbar ist.
+- **Warum kein Custom-Firmware-Image?** Brick-Risiko, blockiert GL.iNet-OTA-Updates, müsste pro
+  GL-Release neu gebaut werden. Das Modul/Skript ist upgrade-sicher und in Sekunden zurücknehmbar.
+
+## Caveats
+
+- **Werks-Reset** (nicht Reboot/Upgrade) löscht `/etc/netbird/` → danach Ein-Zeiler erneut mit Key.
+- **LAN-Routing:** Soll das LAN hinter dem Slate 7 über NetBird erreichbar sein → im Dashboard eine
+  *Network Route* mit diesem Peer anlegen (+ ggf. `wt0` in eine Firewall-Zone).
+- Das Repo ist **public** (enthält keine Secrets — NetBird-Binaries sind OSS, Setup-Keys liegen nie
+  im Repo), damit der Router die Releases ohne Token ziehen kann.