Linux im Untergang

Eine Ära geht zu Ende.

Ich hatte doch schon einige Male beschrieben, welche absurden Probleme ich längst mit Ubuntu habe.

Einige Zeit hat es mich gekostet, einzukreisen, dass der NetworkManager, der in den Desktop-Versionen von Ubuntu die Netzwerkkonfiguration betreibt, in Zusammenhang mit einer FritzBox wegen deren eigenwilliger Routing-Advertisements falsche IPv6-Routen setzt, aber as so subtil, dass man es oft nicht merkt und das Netzwerk zwar funktioniert, aber viel zu langsam, weil Pakete zwischen zwei Maschinen im LAN nicht direkt über den Switch miteinander reden, sondern über die Fritzbox routen. Funktioniert, aber ist natürlich drastisch langsamer. AVM will das nicht ändern, weil sie nicht abschätzen können, welche Wirkungen das sonst so hat. Alle meine anderen Rechner (Ubuntu Server, Debian, Chrome, Mac,…) haben damit alle kein Problem, die setzen das alle richtig, nur die Ubuntu Desktop-Versionen mit NetworkManager setzen es falsch, und man kann es ihnen nicht erklären, weil ausgerechnet die, die da die Netzwerk- und Routingsoftware schreiben, das Routing nicht kapiert haben und den Unterschied zwischen einer Geräte- und einer Interface-Route nicht kapieren. Als ob man mit jemandem, der direkt neben einem steht, spricht, indem man für jedes Wort einen neuen Handy-Anruf tätigt, statt mit ihm direkt zu reden.

Schon vor einiger Zeit war ich einem anderen Fehler auf der Schliche. Ich weiß schon gar nicht mehr, was es war, so ein geht / geht nicht / geht / geht nicht ,und nach einiger Zeit bin ich dahinter gekommen, was das Problem ist. Der Linux-Kernel bennent Netzwerkinterfaces seit einigen Versionen nicht mehr klassisch, sondern nach einem neuen Namensschema, um zu eindeutigen Namen zu kommen, und dann heißt das Interface eben sowas wie enp4s0. Beim Booten aber laufen unter Ubuntu verschiedene Regeln ab, die das erst in den klassischen Namen eth0 und dann wieder nach enp4s0 umbenennen. Weil das alles aber inzwischen nicht mehr eins nach dem anderen über initd gesteuert wird, sondern über systemd, der versucht, alles gleichzeitig zu machen, hängt es vom Zufall ab, ob das Ding gerade eth0 oder enp4s0 heißt, wenn andere Programme laufen. Es gibt immer wieder Bootprozesse, die mittendrin für ein, zwei Minuten hängen bleiben, weil da drin irgendwas abläuft, was keine Sau mehr durchblickt, und niemand kümmert sich drum.

Neulich hatte ich wieder so ein Problem. Der Linux-Kernel unterstützt seit einiger Zeit besondere Interfaces eines Typs namens macvlan, der wie eine kleine, statische Bridge funktioniert und dadurch viel schneller und effektiver ist als die normalen bridge-Interfaces. Und weil man genau das in der Virtualisierung bei Docker und LXD braucht, und das von Vorteil ist, wenn das einfacher und schneller geht, unterstützen Docker, Podman und LXD den Gebrauch von macvlan-Interfaces. Aber, ach. Man hat im Kernel die Dokumentation dazu vergessen, und man muss sich die Informationen aus anderen Quellen zusammensuchen. Es gibt dabei ein Problem: Mit der normalen Konfiguration funktioniert das prima, nur eines funktioniert daran nicht: Der Host kann dann nicht mit seinen eigenen Guests kommunizieren, nur die anderen Maschinen im Netz. Dafür gibt es einen bestimmten Modus, den bridge-mode, der genau dazu da ist, das zu ermöglichen, geht aber nicht. Des Rätsels undokumentierte Lösung: Das funktioniert nur, wenn auch das Interface des Hosts selbst im macvlan-mode betrieben wird. Dann ist alles gut. Geht nur nicht, weil man unter Ubuntu selbst in der Server-Version ohne den Network-Manager einen zusammengemurksten Mischmasch aus systemd und netplan verwendet. Jedes für sich schon katastrophal, weil von der Idee her nicht schlecht, aber lausig umgesetzt. Beides zusammen führt aber zu undokumentierten Verschränkungen und Zusammenhängen, die es schier unmöglich machen, das sauber zu konfigurieren. Insobesondere dann, wenn das künstliche macvlan-Adresse dieselbe MAC-Adresse wie das physikalische Interface haben soll. Das braucht man nämlich, damit wake-on-lan richtig funktioniert. Weil Router das nicht können oder durcheinander kommen, wenn das Gerät im ein- und ausgeschalteten Zustand verschiedene MAC-Adressen hat. Kapieren die aber nicht. Dieses netplan-Dings wird anscheinend seit einiger Zeit nicht mehr weiter entwickelt, Weil die irgendwie nicht mehr können. Zu doof.

Bis vor einigen Jahren hatte man einfache Skriptsysteme wie init und /etc/networks, die zwar altmodisch waren, aber zuverlässig das getan haben, was man wollte, und vor allem ordentlich nachvollziehbar. Dann wollte man unbedingt auf den vermaledeiten systemd umstellen, der zwar auf einer guten Idee beruht, aber undurchsichtig ist, teils äußerst schwer zu debuggen, nur oberflächlich dokumentiert und vor allem von einem unbelehrbaren Sturkopf geschrieben wird, der sich um den Rest der Welt nicht kümmert. Und seitdem ist das fehleranfällig, undurchsichtig und schwer zu debuggen.

Kennt Ihr Zeroconf / Bonjour / Avahi?

Ein System, mit dem sich Rechner gegenseitig und ihre Dienste wie Drucker finden, ohne einen zentralen Server zu verwenden. Das läuft über multicast-DNS-Anfragen. Will man mit einem Rechner namens willi kommunizieren, schickt der Rechner im Prinzip eine DNS-Anfrage raus, aber per Multicast an alle Rechner im LAN. Und wenn ein Rechner weiß, welche IP-Adresse willi hat (in der Regel, weil er selbst willi ist) antwortet der mit einer DNS-Antwort. Und das Problem ist gelöst. Ich habe das vor 15 Jahren schon mal verwendet, hat tadellos funktioniert.

Dann lange Zeit nicht mehr oder kaum noch. Wenn man beispielsweise einen Drucker einrichtet, kann der Rechner die Drucker im Netz oder auch Scanner, Digitalkameras und sowas damit finden. Das kommt schon ab und zu mal vor. Aber normalerweise hat meinen einen DHCP-Server, der mit einem DNS-Server gekoppelt ist und die angemeldeten Rechner per DNS beauskunftet.

Neulich aber hing ich (andere Wohnung) an einem Router von Huawei. Der macht zwar DHCP, bietet aber keine DNS-Einträge dazu an. Da können die Rechner zwar das Internet nutzen, aber sich gegenseitig nicht finden.

Nun, dachte ich, kein Problem. Schalten wir halt mal wieder Bonjour/Avahi zu. Genau die richtige Lösung.

Ich dachte, ich werde wahnsinnig. Nichts funktioniert mehr zuverlässig. Manchmal brauchen die Rechner mehrere Minuten, um zu antworten oder sich gegenseitig zu finden. Manchmal reagieren die gar nicht.

Viel Zeit in Debugging gesteckt. Die Server sind veraltet, die kommen nicht damit klar, dass Rechner mehrere Interfaces haben, weil sie die für die Virtualisierung brauchen. Heißt ein Rechner beispielsweise willi, dann sorgt die Software dafür, dass sich der Rechner nicht einfach willi nennt, ohne zu prüfen, ob es schon einen willi gibt. Schickt also erst mal eine Anfrage raus, ob einer auf willi antwortet, was ja nicht passieren sollte. Merkt dann aber nicht, dass sich der Server selbst antwortet und auf einer Bridge seine eigenen Pakete empfängt. Dann denkt er, ach, willi gibt es schon, nennen wir uns willi1. Selbes Spiel. Weiter mit willi2, willi3,… willi5000,…

Dann kommt sich das Ding noch mit systemd-resolved ins Gehege, weil es zwei konkurrierende Dienste gibt, nämlich den systemd-resolved und den avahid. Welcher von beiden laufen sollte und wer das sagen haben sollte, wem der Port gehört? Keine Ahnung, weiß keiner. Jeder kann was, was der andere nicht kann, aber keiner weiß, welcher der richtige ist. Brüller: Beide sind vom selben Mann geschrieben, Lennart Poettering. Der kommt nicht nur mit seiner Umwelt nicht klar. Der kann sich nicht mal mit sich selbst einigen, was er will.

Fehlermeldungen?

Sinnlos.

Die Tage hatte ich ja gerade berichtet, wie es mir bei Ubuntu wegen eines UEFI-Fehlers in Lubuntu 22.04.2 ging: Erste Reaktion auf meinen Bug-Report: Das sei kein Bug, das werde in eine Frage umgewandelt. Antwort auf die Frage: Dafür solltest Du einen Bug eröffnen. Nur noch Verarsche.

Dazu schreibt mir nun ein Leser, warum die bei netplan/Ubuntu so am Rad drehen. Die seien mit anderen Sachen beschäftigt, als die Software in Ordnung zu bringen. Ich solle doch mal diese Datei anschauen.

Hä!?

Will mich da jemand verarschen? Verspäteter Aprilscherz?

Nochmal langsam und im Detail für Insider:

git clone https://github.com/canonical/netplan

cd netplan

less .woke.yaml

Sind die noch ganz knusper?

Was ist denn das für eine Scheiße?

Macht mal

fgrep -r -i woke

Jede Menge Kommentare wie

# wokeignore:rule=master

Dazu der Leserhinweis auf diesen Kommentar. Ich habe noch das hier gefunden: https://docs.getwoke.tech/usage/

Einen Linter.

Es gibt so ein uraltes Tool, lint, zum prüfen von Quelltexten auf Fehler und ordentliche Formatierungen, etwa ob das richtig eingerückt ist, ob die Namen ordentlich gewählt sind, sauber deklariert ist und all so ein Zeugs. Und dafür hat mal wohl ein Modul geschrieben, das den Quelltext beim Compilieren und Einchecken prüft, ob es frei von „non-inklusiver“ Sprache ist.

Neulich ist ja schon irgendwo ein Server für Stunden stecken geblieben, weil man die Begriffe gewoked hat, also Master in Main geändert und sowas, und es dann hinterher nicht mehr zusammenpasste. Der blanke Schwachsinn.

Statt also die Software in Ordnung zu bringen, oder wenigstens mal die eigene Software noch zu verstehen, kümmern die sich darum, dass der Quelltext woke ist und automatisiert geprüft wird, dass kein politisch unerwünschtes Wort drin vorkommt.

Das war das dann wohl mit Linux. Oder zumindest mit Ubuntu.

Wenn man für so einen Mist Zeit hat, aber nicht mehr in der Lage ist, die Fehler rauszumachen, oder Fehlerberichte und die Funktion der Software überhaupt noch zu verstehen, wenn Software nur noch zum linken Sozialalibi verkommt, dann war es dann einfach. Dann ist das einfach am Ende und tot.

Und dann können wir uns auch die IT-Sicherheit komplett schenken.

Epilog:

Hinter Ubuntu steht ja auch die kommerzielle Firma hinter Ubuntu. Ich hatte vor ein paar Tagen dort ein Paper runtergeladen, für das man seine Anschrift angeben muss. Prompt meldete sich gestern Ubuntu/Canonical bei mir, ob man in Sachen Kubernetes etwas für mich tun könnte. (Gewerblich, versteht sich.) Weil sie doch zeigen wollen, dass sie Kubernetes besser können als andere.

Wenn aber nicht mal so elementare Dinge wie die Netzwerkkonfiguration sauber funktionieren, wie soll ich denen denn dann noch ein Kubernetes anvertrauen können, was um einiges komplexer und komplizierter ist?