# Reboot- und Reconnect-Probe fuer pinix (Intent Schritt 6) Vorbereitet und Probe A gelaufen am 12.09.2026. **Probe A (Reboot) ist bestanden** -- Ergebnis unten. **Probe B (Reconnect) steht aus** und braucht eine Handlung am Nokia. Aufbau und Abnahmekriterien stehen hier, damit eine Wiederholung ohne Improvisation laeuft. ## Warum das der eigentliche Torwaechter ist Der [Intent](intent/pinix-ipv6-traefik-webserver.md) nennt Schritt 6 als letzten offenen Punkt, und die [Traefik-Uebergabe](session-2026-09-12-pinix-traefik.md) begruendet, warum selbst gehosteter DNS bis dahin zurueckgestellt bleibt: ein autoritativer Nameserver braucht einen zuverlaessig erreichbaren Host, und genau diese Eigenschaft ist fuer pinix nicht nachgewiesen. Die Fehlerfolgen sind asymmetrisch -- HTTP-01 kaputt kostet ein Zertifikat, autoritativer DNS kaputt kostet die Aufloesung von `0ff.space` samt Mail, XMPP-Foederation und ActivityPub. Deshalb vor jeder Delegation diese Probe. ## Was konkret noch nie getestet wurde `/run/booted-system` zeigt auf Generation 240 (`s6fdkprawpswx27pdap5qbwqw146fkcx`), `/run/current-system` auf 242 (`2fwsvih9vkwlc7whq41dhd2lbz394gmj`). Beide BIND-Generationen (241, 242) sind ausschliesslich per `switch` aktiviert worden. **BIND hat also noch keinen Bootvorgang erlebt.** Die Hauptvermutung, die die Probe pruefen soll, ist der Resolver. `hosts/pinix/localServices/bind.nix` setzt `networking.resolvconf.useLocalResolver = lib.mkForce false`, weil das BIND-Modul sonst localhost als Resolver eintraegt. Beim laufenden `switch` war `/etc/resolv.conf` schon korrekt und blieb es. Beim **Boot** wird resolvconf neu erzeugt. Gewinnt dort der localhost-Eintrag, hat pinix keinen funktionierenden Resolver mehr: BIND ist autoritativ und rekursiert nicht, der Uplink ist IPv6-only ueber Mangos DNS64. Folge waeren stillschweigend kaputtes ACME, kaputte Updates und ein fehlschlagender `mango-dns`-Timer -- bei laufendem, scheinbar gesundem System. Der Diff dieser Session beruehrt weder Bootloader noch Kernel, initrd oder Dateisysteme, sondern nur Dienste und zwei Firewall-Ports. Ein "bootet nicht" ist damit unwahrscheinlich; erwartbar sind Dienst- und Netzwerkfehler nach dem Boot. ## Rueckweg, vor dem Start bekannt Nach Prioritaet: 1. **LAN-Zugang von tnix.** `ssh drone@192.168.8.244` bzw. die ULA `fdee:3c40:44f0:0:dea6:32ff:fe48:c6c8`. Dieser Weg haengt **nicht** am Mobilfunk-Uplink, nicht am Nokia und nicht an Tailscale -- Ethernet ins Mango-LAN genuegt. Er muss vor dem Start gesteckt und geprueft sein. Damit ist ein Rueckbau auf Generation 240 moeglich: ```bash sudo /nix/var/nix/profiles/system-240-link/bin/switch-to-configuration switch ``` 2. **pinix bootet, Netz kaputt.** Dann bleibt nur Konsole am Geraet (HDMI und Tastatur) oder der SD-Karten-Weg. 3. **pinix bootet nicht.** SD-Karte in eine andere Maschine und in `/boot/extlinux/extlinux.conf` die erste Zeile von `DEFAULT nixos-default` auf `DEFAULT nixos-240-default` aendern. Die Generationen 233 bis 242 liegen dort als `LABEL` vor. Eine Auswahl **beim Boot** gibt es headless nicht -- U-Boot/extlinux nimmt ohne Konsole den Default. Das ist der Grund, warum Schritt 1 vorher stehen und funktionieren muss. Mango-Firewall-Backups liegen auf dem Router unter `/root/ipv6-*-firewall-backup.*/firewall` bzw. `/root/pinix-dns-firewall-backup.*/firewall`. Beim Zuruecklegen keine spaeteren Firewall-Aenderungen ueberschreiben. ## Ablauf Zwei **getrennte** Proben, damit ein Fehlschlag zuordenbar bleibt. Reboot zuerst, weil er lokal vollstaendig reparierbar ist. ```bash # 0. Rueckweg sichern: Ethernet steckt, LAN-Zugang beweisen ssh -o HostKeyAlias=pinix drone@192.168.8.244 'echo LAN ok' # 1. Ausgangszustand ./scripts/pinix-reachability-probe.sh vorher > /tmp/probe-vorher.txt # 2a. Probe A -- Reboot von pinix ssh -o HostKeyAlias=pinix drone@192.168.8.244 'sudo reboot' # ... warten, bis SSH wieder antwortet ./scripts/pinix-reachability-probe.sh nachher-reboot > /tmp/probe-reboot.txt diff -u /tmp/probe-vorher.txt /tmp/probe-reboot.txt # 2b. Probe B -- Nokia-Reconnect (Praefixwechsel), separat # Nokia neu verbinden, dann mindestens 60 s fuer den mango-dns-Timer ./scripts/pinix-reachability-probe.sh nachher-reconnect > /tmp/probe-reconnect.txt diff -u /tmp/probe-vorher.txt /tmp/probe-reconnect.txt ``` `scripts/pinix-reachability-probe.sh` ist rein lesend, hat pro Schritt ein Timeout und laeuft absichtlich ohne `set -e` durch -- ein Fehlschlag ist das Messergebnis. Die externen Tests gehen zwingend ueber `--interface wlan0`, weil tnix gleichzeitig im Mango-LAN haengt und die DNAT-Regeln `reflection=0` tragen; ein Test ohne Interface-Bindung nimmt den LAN-Weg und meldet einen Fehlschlag, der keiner ist. ## Abnahmekriterien | Pruefung | Erwartung | |---|---| | `booted` vs `current` | **identisch**, beide Generation 242 | | `is-system-running` | `running` bzw. `degraded` nur wegen `tailscaled-autoconnect` (siehe unten); kein anderer Fehler | | `/etc/resolv.conf` | Mango (`192.168.8.1`), **nicht** `127.0.0.1` | | stabile SLAAC-ULA | `…:dea6:32ff:fe48:c6c8` vorhanden | | IPv6-Default-Route | per `proto ra` auf `end0` vorhanden | | `bind` / `traefik` | active, BIND liefert SOA ueber `::1` | | Mango-Weiterleitungen | `pinix_web_*`, `pinix_ssh` weiter `DNAT` | | extern | `https=200`, `http=301`, `ssh2222=offen` | | Cloudflare-AAAA | stimmt mit der tatsaechlichen Adresse ueberein | ## Was im Diff legitim abweicht Nicht jede Abweichung ist ein Fehler: - Zeitstempel in der Kopfzeile. - Die Quelladresse von tnix' `wlan0` (Privacy Extensions). - Bei Probe B die oeffentliche Mango-Adresse -- **aber** dann muss der Cloudflare-AAAA innerhalb einer Timer-Periode nachziehen. Tut er das nicht, hat `mango-dns` sein Ziel verfehlt und der Punkt ist ein Fehler. - `pinix_dns=FEHLT`, solange `scripts/configure-mango-dns.sh` nicht gelaufen ist, und entsprechend der DNS-Timeout im externen Test. Seit dem 12.09.2026 ist die Regel gesetzt, das sollte also nicht mehr auftreten. - `degraded` mit fehlgeschlagenem `tailscaled-autoconnect.service`: ein bestehender, von BIND unabhaengiger Fehler, unten erklaert. Erst wenn eine *andere* Unit auftaucht, ist es ein Befund. ## Bekannter Nebenbefund Die Probe liest auch Aussteller und Restlaufzeit des Zertifikats. Aktuell `issuer=CN=YR1`, `notAfter=Dec 11 12:20:18 2026 GMT` -- das ist die aus der Traefik-Uebergabe bekannte Kette ueber `ISRG Root YR`, die auf Clients mit aelterem CA-Bundle scheitert. Die Entscheidung ueber `preferredChain` steht weiterhin aus und ist **nicht** Teil dieser Probe. ## Ergebnis Probe A (Reboot), 12.09.2026 **Bestanden.** `systemctl reboot` um 17:50:09, SSH nach etwa 25 s wieder da, neue `boot_id` (`97119559…` -> `13253402…`), also ein echter Neustart. Der Diff der beiden Aufnahmen enthaelt genau zwei Abweichungen. Die erwuenschte: `booted` entspricht jetzt `current`, beide Generation 242 (`2fwsvih9…`). **BIND hat damit seinen ersten Bootvorgang ueberlebt.** Unveraendert und damit bestanden: `bind`, `traefik`, `mango-dns.timer` und `tailscaled` aktiv, stabile SLAAC-ULA vorhanden, RA-Default-Route auf `end0` vorhanden, BIND antwortet autoritativ, alle Mango-Regeln inklusive `pinix_dns` und `dport 53` persistent, Cloudflare-AAAA deckt sich mit der tatsaechlichen Adresse, extern `https=200`, `http=301`, Port 2222 offen, DNS-SOA von aussen beantwortet, Zertifikat unveraendert (`notAfter=Dec 11`) -- der ACME-Zustand in `/var/lib/traefik` hat den Neustart also ueberlebt. **Die Hauptvermutung hat sich nicht bestaetigt, und das ist die gute Nachricht:** `/etc/resolv.conf` zeigt auch nach dem Boot auf Mango und nicht auf localhost. `networking.resolvconf.useLocalResolver = lib.mkForce false` haelt also nicht nur beim `switch`, sondern auch beim Neuaufbau durch resolvconf im Boot. ### Der eine echte Fund: pinix ist aus dem Tailnet gefallen Die zweite Abweichung ist `running` -> `degraded` mit fehlgeschlagenem `tailscaled-autoconnect.service`. Das ist **nicht** von BIND verursacht -- die Unit war bereits am Anfang dieser Sitzung auf der Generation vor BIND fehlgeschlagen. Der Boot hat den Fehler nur wieder sichtbar gemacht, inklusive 90 s Timeout, die `multi-user.target` aufhalten. Die Ursache ist strukturell und hat mit Tailscale selbst wenig zu tun: ``` You are logged out. The last login error was: fetch control key: Get "https://head.0ff.space/key?v=142": dial tcp 23.88.33.137:443: connect: network is unreachable ``` pinix hat **keine IPv4-Default-Route** und erreicht `23.88.33.137` (blunix, der Headscale-Host) nicht. Dass blunix ausschliesslich per IPv4 erreichbar ist, ist am selben Tag unabhaengig aufgefallen: der Host hat ueberhaupt keine oeffentliche IPv6, nur die Tailnet-ULA. Bemerkenswert ist, dass NAT64 den Fall eigentlich abdeckt -- `getent hosts head.0ff.space` liefert `64:ff9b::1758:2189`. Tailscale loest aber selbst auf, nimmt den A-Eintrag und waehlt die IPv4-Adresse direkt, womit es an DNS64 vorbeilaeuft. Zwei Folgerungen: 1. **Das Tailnet ist kein Rueckweg zu pinix.** Der Abschnitt oben nennt den LAN-Zugang als Weg 1 -- das war richtig, aber aus einem schwaecheren Grund als dem tatsaechlichen. Es bleiben LAN und die oeffentliche DNAT-Weiterleitung. 2. **blunix eine oeffentliche IPv6 geben** ist der saubere Fix, nicht eine Sonderbehandlung in Tailscale: dann bekommt `head.0ff.space` einen echten AAAA, pinix verbindet sich native, die Unit hoert auf zu scheitern und der Boot verliert 90 s Verzoegerung. Das haengt mit der Frage nach einem Sekundaeren fuer die Zone zusammen -- siehe [pinix-bind.md](pinix-bind.md). ### Noch offen: Probe B (Reconnect) Nicht gelaufen. Ein Praefixwechsel setzt voraus, dass sich das Nokia neu am Mobilfunknetz anmeldet; das Bouncen des Mango-Uplinks erzwingt kein neues Praefix und pruefte daher die eigentliche Frage nicht. Diese Probe braucht also eine Handlung am Nokia.