Was Claude hier wirklich tut

TCP- und UDP-Tests (iperf3) über die OpenVPN-Strecke zeigen einen deutlich asymmetrischen Durchsatz — rund 33 Mbit/s Upload gegenüber etwa 20 Mbit/s Download — sowie eine im Download gelegentlich instabile Verbindung mit kurzzeitigem Paketverlust. Ping/Traceroute bestätigen eine stabile Basis-Latenz um 30–40 ms mit vereinzelten Ausreißern.

Migrationsplan erstellt (Custom-Configs wie der Redis-/MySQL-Boot-Race-Fix und die maskierte ureadahead-Unit vorab gesichert, Fremd-Repos mit fester jammy-Bindung sauber deaktiviert/reaktiviert) und das do-release-upgrade von 22.04 auf 24.04.4 LTS durchgeführt. Nach dem Reboot alle Kerndienste (DHCP, DNS, VPN, LDAP, MySQL, Redis, Apache) sowie sämtliche Boot-Fixes verifiziert — keine fehlgeschlagenen Units.

Mehrere Dienste versuchten beim Systemstart Benutzer-/Gruppen-Lookups gegen den LDAP-Server, bevor dieser bereit war. Über systemds nss-user-lookup.target ordnen sich die betroffenen Dienste jetzt sauber hinter LDAP ein.

Beide Dienste banden beim Boot nur an 127.0.0.1 statt an ihre konfigurierten Netzwerk-Adressen — ein Wettlauf mit dem Netzwerkstart, der die Hausautomatisierung-Slaves nach jedem Reboot lahmgelegt hat. Per systemd-Ordering gefixt und über echte Testreboots verifiziert.

Ein instabiler SATA-Link auf der Backup-Platte wurde per Fehlerregister-Analyse eindeutig als Kabel-/Kontaktproblem identifiziert — nicht als Mediendefekt. Nach Kabeltausch mit Lasttest und SMART-Vergleich verifiziert.

Ein fehlendes Exit-Code-Check ließ das Backup-Skript bei ausgehängter Platte scheinbar erfolgreich, aber leer durchlaufen. Jetzt bricht es sichtbar mit Fehlermeldung ab, statt Erfolg vorzutäuschen.

Eine seit Jahren mitgeschleppte, bei jedem Boot fehlschlagende Unit wurde identifiziert und sauber maskiert — der System-State steht seither wieder durchgehend auf running.