docs: sicheren Installationsweg nach vorne (erst laden, dann ausfuehren)

This commit is contained in:
mm committed 2026-09-14 10:23:01 +02:00
1 parent 906da69481
commit d11849b6d9
1 file changed
+40
+40
View File
@@ -5,6 +5,46 @@ Der Ausgang läuft über den **NetBird-Reverse-Proxy** (`imac-prometheus.x05.idx
mit **Bearer-Token** — dadurch funktioniert der Installer auch auf Maschinen, die **kein NetBird-Peer** sind
(Büro-LAN, Kundenlaptop, CGNAT, VM ohne Client).
## Installation — der sichere Weg
```sh
# Empfohlen: erst herunterladen, dann ausführen
curl -fsSL <raw>/install.sh -o /tmp/netbird-install.sh
sudo sh /tmp/netbird-install.sh --name <node> --token <TOKEN>
```
**Warum nicht direkt `curl … | sh`?** Bei einer Pipe ist **stdin das Skript
selbst**. Jeder Unterbefehl, der stdin liest, kann es wegräumen — und der
Installer ruft Paketmanager auf (`apt-get`), die genau das tun. Auf Ubuntu
startet dabei `needrestart`:
```
Scanning processes...
Scanning linux images...
```
Danach setzt die Shell mitten im **Quelltext** fort statt im Skript — sichtbar
an Ausgaben wie `; then`, `fi` oder Kommentarzeilen. Der Lauf bricht ab, die
Node ist halb konfiguriert. **Auf Nodes mit bereits installiertem Telegraf
passiert das nicht**, weil dann kein Paketmanager läuft — dort funktioniert
`curl … | sh` scheinbar problemlos.
Ab **1.4.0** schützt sich der Installer selbst: erkennt er eine echte Pipe,
lädt er sich frisch von der Quelle, startet sich mit `stdin </dev/null` neu und
meldet das:
```
[netbird-telegraf] Selbstschutz: Skript laeuft jetzt von /tmp/… (stdin frei).
```
Fehlen `curl`/`wget` auf einem frischen System, meldet er das ausdrücklich
(`HINWEIS: kein curl/wget fuer den Selbstschutz`) — dann ist der Download-Weg
oben die sichere Wahl.
**Der Fehler ist reproduzierbar:** `x14` brach genau so ab. Der Installer lief
bis `Node=… Apache=1`, dann kamen `Scanning processes…`-Zeilen, danach
Quelltext-Ausgaben, und `apache.conf` fehlte am Ende.
## Diagnose: „Logs kommen nicht an"
Ein Befehl zeigt, warum: