Ein Pi, der einfach läuft, sammelt still Sicherheitsupdates an

Der Raspberry Pi mit Pi-hole und Unbound hat genau eine Aufgabe, und die erledigt er so unauffällig, dass ich ihn wochenlang nicht angefasst habe. Genau das war das Problem: 49 ausstehende Pakete, darunter glibc und OpenSSL. Ein Dienst, der „einfach läuft", ist der blinde Fleck jeder Update-Routine.

Die Wartung selbst war unspektakulär: Upgrade nicht-interaktiv, Konfigdateien behalten, Exit 0. Unbound als neues Container-Image gezogen — 1.25.2 auf 1.26.0 — und die Auflösung direkt am Resolver und über Pi-hole geprüft. Dann der Reboot wegen glibc und Firmware: SSH nach 30 Sekunden zurück, DNS nach 53 Sekunden. Für 53 Sekunden hatte kein Gerät im Haus einen Resolver. Das ist der Preis eines einzelnen DNS-Servers, und er ist der Grund für die wichtigste Entscheidung des Tages.

unattended-upgrades, aber nur Security, kein Auto-Reboot. Sicherheitsupdates laufen ab jetzt täglich von selbst. Neustarts bleiben manuell — ein unbeaufsichtigter Reboot würde alle Clients für rund eine Minute ohne DNS lassen, und das passiert dann garantiert, während jemand ein Meeting hat. Ungenutzte Abhängigkeiten werden entfernt, Autoclean nach sieben Tagen.

Zwei Fallen unterwegs. Erstens: Origins-Pattern in apt.conf.d ist eine Liste, und spätere Dateien hängen an, sie ersetzen nicht. Wer „nur Security" will und die Standarddatei stehen lässt, bekommt trotzdem alles. Es braucht #clear. Zweitens, Pi-hole v6: Zusätzliche dnsmasq-Zeilen per Umgebungsvariable sind im laufenden Container read-only — Änderungen daran heißen Compose-Edit plus Recreate, nicht Klick in der Oberfläche.

Offen bleibt ein Kandidat: Pi-hole und Unbound laufen mit latest-Tags. Das funktioniert, verschleiert aber, was läuft. Feste Tags pinnen und Updates bewusst ziehen wäre ehrlicher — steht auf der Liste.

Und ein Nebenbefund, der nichts mit DNS zu tun hatte: Eine Streaming-Störung auf dem Fernseher, die ich reflexartig dem Resolver zuschrieb, war ein Failover auf Anbieterseite. DNS, TLS und Erreichbarkeit aller beteiligten Hosts aus dem LAN waren in Ordnung. Nicht jede Störung im Haus ist der DNS-Server — auch wenn er der Verdächtige Nummer eins bleibt.