Eine Woche Technik

Innerhalb der guten letzten Woche kamen hier einige Projekte im Technikumfeld zusammen, die gelöst werden wollten oder mussten. Das reichte von PHP2Shell über Stromversorgung, das Telefonbuch des Internets bis zu Terminal-Emulatoren.

PHP2Shell

Am 21. Oktober 2026 wurde die sogenannte PHP2Shell-Lücke bekannt. Meine Website läuft zwar nicht (mehr) mit PHP, aber so ein paar Dienste und Websites betreut man ja als IT-Mensch dann irgendwie doch und da war dann Updaten oder teilweise erstmal Abschalten angesagt, bis Updates verfügbar waren. Mittwochabend kurz vor Mitternacht war dann aber alles aktualisiert und mit Patches versorgt.

USV

Vor acht Jahren hatte ich mir eine unterbrechungsfreie Stromversorgung (USV) gekauft – eine APC Back-UPS BX950U-GR. Vorletztes Wochenende hatte ich Besuch, der bereits am Freitag bei mir zuhause war, während ich noch im Büro war. Nun rief mich der Besuch gegen Mittag an, dass es auf einmal laut piepen würde. Es stellte sich heraus, dass es meine USV war und „leider“ handelte es sich nicht um einen Stromausfall (dann piept die USV nämlich auch), sondern diesmal war es der Warnton, dass die Batterie langsam den Geist aufgibt, was nach acht Jahren auch fast schon überfällig ist. Nun hat der Hersteller leider bei dieser USV gar nicht vorgesehen, dass die Batterie getauscht wird. Im Internet gibt es zwar Anleitungen, wie man das Gehäuse aufhebeln und dann mit E-Technik-Kenntnissen die alte Batterie abklemmen und eine neue anschließen kann, aber diese Kenntnisse fehlen mir. Nicht, dass ich mir das nicht prinzipiell zutrauen würde nach Anleitung zu machen, aber die Gefahr, was passieren kann, wenn da doch etwas nicht so ganz 100%ig ist, war mir die Ersparnis von 80,- Euro dann irgendwie nicht wert. Jedenfalls habe ich mir jetzt eine neue USV gekauft, bei der End-Nutzer die Batterie auch wechseln können sollen und sie in Betrieb genommen. Da das alte Gerät all die Jahre gute Dienste geleistet hat, auch mal bei einem echten Stromausfall wie vorgesehen eingesprungen ist und sich das angeschlossene NAS selbstständig runtergefahren hat, habe ich mir das Neue vom selben Hersteller gekauft, diesmal die APC Back-Ups BE850G2-GR.

DNS

Ich hatte neulich in meinem LAN ein Projekt gecodet, bei dem am Ende ein Docker-Image rausfallen sollte, das dann mein lokales GitLab per Registry bereitstellt. Mein GitLab, wie viele andere lokale Dienste bei mir, haben eine eigene Domain, die lokal von meinem eigenen DNS-Server verwaltet wird. Damit das reibungslos im LAN klappt verteilt mein Router per DHCP auch gleich den DNS-Server mit, sodass alle Geräte mit ihrer IP-Konfiguration auch die Info mitbekommen, wo sie sich Domains in IPs auflösen lassen können. Außerdem nutze ich diese zentrale Netzwerkinfrastruktur auch gleich um für alle Geräte Werbung zu blockieren, ohne das jedes Gerät oder jede Software selbst einen Werbeblocker benötigt.

Das funktioniert meistens gut, war aber in den letzten Jahren hier und da mal etwas löchrig. Ich hatte immer vermutet, dass ja einige Software inzwischen selbst DNS-Konfigurationen mitbringt, so wie einige Browser inzwischen als Feature “Private DNS” (oder wie sie das nennen) aktivieren, was nichts anderes heißt, als dass diese Software ihre Auflösung über bestimmte DNS-Server des Herstellers macht.

Zurück zur Docker-Registry von GitLab. Irgendwie wollte es nicht klappen, dass ich vom NAS das Docker-Image von GitLab beziehen konnte. Er fand die Registry nicht. Auch hier hatte ich geprüft, ob der DNS korrekt hinterlegt war, aber das war nicht das Problem. Um es kurz zu machen: Beim Debuggen bin ich auf einen alten Fehler in meinem Setup gestoßen. Das war nämlich hauptsächlich auf IPv4 ausgelegt bzw. damit eingerichtet, denn ich habe diese Konfiguration hier schon zig Jahre und IPv6 ist zwar selbst schon alt, hat aber lange gebraucht überall die vorherrschende Technik zu werden bzw. bevorzugt vor IPv4 benutzt zu werden. Der erste Fehler war, dass mein Router für IPv6-Anfragen gar nicht per DHCP meinen DNS-Server anbot und dann lauschte mein DNS-Server auch nicht auf IPv6-Anfragen. Nachdem das beides aktiviert war ging es nun.

Fast.

Hier kommt die USV-Geschichte ins Spiel. Da ich letztes Wochenende verreist war, wollte ich nicht die USV eingeschaltet hier zurücklassen, vor allem wegen der Gefahr meine Nachbarinnen und Nachbarn tage- und nächtelang mit einem Piepton zu nerven. Als ich am Sonntag wieder kam nahm ich alles in Betrieb – ohne USV, bis die neue ankommen würde – und musste feststellen: kein Internet. Also nicht so ganz. Der Router hatte Internet, aber es fand keinerlei DNS-Auflösung statt, was aus Consumer-Sicht fast das selbe ist wie „kein Internet“. Um es auch hier kurz zu machen: Ich hatte mir einen schönen DNS-Loop gebaut, der erst nach dem Neustart aller Geräte auffiel, weil dann alle einmal neue Infos per DHCP bekamen. Was war los? Mein Router verteilte die IP meines DNS-Servers an alle Geräte im Netzwerk, so auch an meinen DNS-Server. Die Resolvconf schrieb pflichtbewusst die erhaltenen Daten als zusätzliche Config in meinen Unbound-DNS-Server, der jetzt anfing sich selbst zu befragen, bis ein Timeout erreicht war. Die Lösung war dann einfach: die ungewollte Config-Datei löschen und Resolvconf daran hindern, diese Config bei nächster Gelegenheit wieder zu schreiben. Seitdem schnurrt mein DNS-Setup allerdings besser als vorher, denn für die löchrige Funktion der letzten Jahre war schlicht die Ausbreitung von IPv6 verantwortlich und dass mein DNS-Server sich für IPv6 nicht zuständig fühlte.

Ghostty Terminfo

Mein Terminal-Emulator ist Ghostty und da bin ich auch prinzipiell mit zufrieden, aber immer wenn ich per SSH auf anderen Geräten einloggte musste ich feststellen, dass die Benutzung doch stark eingeschränkt war. Wenn ich mehr machte, als einfach nur zu tippen, verhielt sich das Terminal komisch. Häufig war der Effekt, dass mir die aktuelle Zeile zigfach erneut ausgegeben wurde. Das war nervig. Nach etwas Recherche hatte ich herausgefunden, dass Ghostty als TERM den Wert xterm-ghostty übermittelt. Terminfo ist dafür da einem Zielsystem (z.B. bei einer SSH-Verbindung) mitzuteilen, welches Terminal verbunden ist und welche Steuerzeichen es sendet etc. – also welche Funktionen es hat. Nun ist das Problem, dass Zielsysteme häufig Ghostty noch nicht kennen und dann in eine Art rudimentären Kompatibilätsmodus verfallen – das was ich zuvor beobachtet hatte, als ich zwar prinzipiell arbeiten konnte, aber bloß nichts „spezielles“ machen sollte, wie eine History-Suche. Der Fix war jetzt einfach manuell den Term-Wert auf den weitverbreiteten Standard xterm-256color zu setzen und das hat sofort funktioniert. Klar, dass damit ein paar Ghostty-Features nicht gehen, aber besser als vorher war es allemal. Alternativ hätte ich auch die Ghostty-Terminfo-Datei auf jedes Zielsystem kopieren können, aber das war mir dann doch etwas zu mühsehlig, da ich auch manchmal mit Docker-Containern arbeite und da immer wieder diese Datei hinzukopieren empfand ich als umständlich auf Dauer. Im jüngsten Update von Ghostty wurde dieser Prozess aber nun automatisiert, sodass Ghostty mit seiner SSH-Integration ghostty +ssh das Kopieren selbst übernimmt.