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)

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:

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):

Trigger: täglich 04:17 UTC (cron) · manuell (Actions → Run workflow, mit force-Option) · bei Push auf den Workflow.
Holt die neueste NetBird-Version von der GitHub-API.
Existiert dafür schon ein Gitea-Release? → fertig (idempotent, kein Doppel-Release).
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

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.