hostname-Problem gefunden

Das hat mich Zeit gekostet.

Ich hatte es ja gestern schon erwähnt. Ich hatte das Problem, dass sich eine widerspenstige Linux-Kiste nicht zähmen ließ. Ich habe den Hostname geändert (/etc/hostname geändert, hostnamectl verwendet) und die Maschine hat einen neuen Hostnamen, aber nach dem nächsten Reboot hat sie plötzlich wieder den alten Hostnamen, obwohl dmesg und kernel.log sagen, den neuen gesetzt zu haben.

Ich hatte erst den systemd-resolver und systemd-hostnamed in Verdacht, denn letzterer ist extra dafür da, den hostname zu ändern. Meine Vermutung war, dass der DHCP-Server den Hostnamen noch im Cache hat und der dämliche systemd den Hostnamen über DHCP/DNS bezieht und setzt.

War’s aber nicht, jedenfalls nicht nur. Denn auch im recovery mode kam die Maschine mit dem alten Hostnamen an, obwohl das Netzwerk noch gar nicht initialisiert war.

Kuriose Zufallsbeobachtung: Mir ist etwas passiert, was einem IT-Admin eigentlich gar nicht passieren darf. Ich hatte die Maschine zum Anschließen eines Bildschirms auf den Tisch gestellt, das Netzkabel aber nicht richtig fest reingedrückt und beim Ziehen des Netzwerkkabels (um sicherzustellen, dass da kein DHCP mehr dazwischengurkt) versehentlich das Netzkabel etwas bewegt und mit rausgezogen, weil es locker saß, und der Maschine dadurch einen ganz harten Absturz verpasst. Danach kam sie mit dem neuen Hostnamen hoch, beim nächsten Boot aber wieder mit dem alten, obwohl völlig vom Netz getrennt, und obwohl ich sichergestellt habe, dass der alte Hostname in ganz /etc nicht mehr steht.

Lösung:

Die von Ubuntu angebotenen Installationsimages sind inzwischen sehr seltsam. Über lange Jahre habe ich die gar nicht verwendet, weil ich bevorzugt über PXE installiert habe, das Ubuntu PXE-Image ist nämlich viel besser als die CD-/USB-Stick-Images und macht alles genau so, wie ich es haben will. Mit dem war ich völlig zufrieden. Mit modernen UEFI-Maschinen klappt die PXE-Installation aber nicht (irgendwie geht’s schon, aber ich habe meinen PXE-Server noch nicht umgestellt, um was anzubieten, was mit UEFI zusammenarbeitet, und manche BIOSse weigern sich einfach, über PXE zu booten, wenn man auf UEFI stellt). Ich hatte jetzt nicht die Zeit, daran auch noch zu basteln, und auch keine Lust, die besagte Maschine auf Legacy-Boot umzustellen, und deshalb einfach mal das Server-Installations-Image von Ubuntu 18.04 ausprobiert. Und zwar nur auf dieser einen Maschine.

Das Server-Installations-Image hat aber aus irgendwelchen Gründen, die mir nicht völlig durcheinleuchten, weil es ja eigentlich für physische Maschinen gedacht ist, cloud-init.

cloud-init ist ein Stückchen Software, das gerade groß boomt, weil für Cloud Computing sehr wichtig. Die ganzen Cloud-Anbieter bieten einem ja normalerweise keine leere Maschine mit BIOS-Prompt, sondern die Auswahl, welches Linux-Image (Ubuntu, Debian, CentOS, RHEL,..) man haben will. Da wird das Image dann einfach reinkopiert.

Dann braucht man aber noch Anpassungen. Das, was der Provider vorgibt (Router, IP-Adressen, DNS, aufpumpen auf Plattengröße…) und das, was der Kunde will (Account, Passwort, Hostname, Pakete installieren, Installer starten und so’n Kram). Normalerweise gibt man also einem installierten Image zwei Dateien mit, eine vom Provider, eine vom Kunden, in der jeder beschreibt, was er braucht, damit die Maschine überhaupt richtig hochkommt und man sich mal einloggen kann.

Das heißt, dass beim ersten Booten cloud-init dafür zuständig ist, im Linux-Image zu setzen, was da vorgegeben ist, damit es läuft.

Aus irgendwelchen Gründen, womöglich um doppelte Softwarearbeit zu sparen, hat auch das normale Server-Image von Ubuntu dieses cloud-init mit drin. Die Eingabemasken beim Installieren der Maschine sehen zwar aus wie früher, aber anscheinend konfigurieren sie die Maschine nicht mehr direkt, sondern erstellen nur diese Datei user-data, als ginge es darum, eine virtuelle Maschine in der Cloud zu starten, und überlässt es dem Linux (wie bei einem Image in der Cloud) sich beim ersten Booten an die mitgegebenen Parameter anzupassen.

Wäre OK.

Aber aus irgenwelchen Gründen, zu denen ich mich noch nicht ganz durchdebuggt habe, läuft das Ding bei jedem Boot, und setzt nicht nur diese user-data jedesmal neu um, sondern scheint sie auch immer wieder mal neu zu erzeugen. Obwohl ich die Maschine schon vor einigen Wochen installiert habe, war die Datei erst ein paar Stunden alt. Es scheint, als solle hostnamectl über den dbus auch diese Datei ändern und es funktioniert nicht so, wie es soll. Die Datei wird anscheinend zwar neu erzeugt, aber der hostname nicht geändert. Und weil das Ding wohl bei jedem Boot (außer nach dem harten Absturz wegen des gezogenen Netzkabels) die Konfiguration neu laufen lässt, hat das Ding immer nach dem Booten zuerst den von mir neu gesetzten Hostnamen in /etc/hostname gesetzt, das geloggt, und dann kommentarlos den alten Hostname aus der user-data wieder gesetzt.

Es war zwar jetzt nicht direkt der systemd, aber zumindest indirekt, denn dadurch kann man den Hostnamen nicht mehr einfach so ändern, und das Debugging wird ziemlich schwierig und umständlich.

Ich habe da noch mit vielen weiteren Problemen des systemd zu kämpfen:

• Ich habe es aktuell nicht geprüft, aber zumindest bis vor kurzem war Ubuntu 18.04 wegen systemd nicht in der Lage, im recovery mode das Netzwerk hochzufahren (obwohl das Auswahlmenü das anbietet), weil man kein schnödes ifconfig mehr verwendet, sondern NetworkManager und netplan, die wiederum dbus benötigen, den systemd im recovery mode nicht hochbekommt, weil die Abhängigkeiten widersprüchlich und zirkulär sind.
• Immer wieder werden Programme zu früh gestartet (postfix, dnsmasq), bevor alle Netzwerkinterfaces oben sind, weshalb sie interfaces ignorieren oder gar nicht erst starten.
• Noch so eine Scheiß-Konstruktion, die mir schon Probleme bereitete:

  /etc/resolv.conf ist keine Datei mehr, sondern ein symlink auf /run/systemd/resolve/stub-resolv.conf . Diese Datei existiert aber zum Zeitpunkt der recovery-Sitzung noch gar nicht. Dadurch ist der link ein dangling link, also ein symlink, der auf etwas zeigt, was es (noch) nicht gibt. Sowas darf es eigentlich gar nicht geben. Und viele Programme können damit nicht umgehen. Wenn /etc/resolv.conf fehlte, wäre das kein Problem, damit können die Programme umgehen. Aber dass die Datei „existiert” und dann beim Öffnen Lesefehler produziert, wird meist nicht abgefangen. So eine Scheiß-Konstruktion, die auf Symlinks beruht, die ins Leere zeigen, baut man einfach nicht. Wer denkt sich so einen Murks aus?

Ich habe zwar den Eindruck, dass im Moment ein paar Sachen auch wieder besser werden (gerade auch weil Cloud-Computing boomt und da manche Sachen einfach laufen müssen, sonst gibt’s Ärger und Verdruss), aber die Anbieter ihre Distributionen in vielen Bereichen nicht mehr im Griff haben.

Ich hatte ja neulich mal gebloggt, dass ich beim Upgrade eines Arbeitsplatzrechners auf 18.04 das Problem hatte, dass der X11-Treiber das Bild nicht mehr auf Display-Port, sondern nur noch auf HDMI ausgibt, da aber nur noch FullHD schafft (der Monitor hat 2560). Ich hab’s als Bug gemeldet und dann meldete sich einer, der sich zwar Mühe gab und mir die Hardware-Beschreibung des Rechners raussuchte um mir zu erzählen, das ginge gar nicht (komisch, einen Tag vorher mit 17.10 und 17.04 und 16.10 ging’s noch), aber das Problem erst gar nicht verstand. Es ging mehr so darum, dass ich mich doch einfach daran gewöhnen sollte, dass es nicht geht, statt zu grübeln, warum es nicht geht. Dafür bekam ich dann sofort einen Rüffel, weil meine Ausdrucksweise nicht deren Vorstellungen von respektvollem Umgang entspräche. Ich dürfte ihm nämlich nicht sagen, dass er das Problem nicht verstanden hätte und mir mit nutzlosem Blabla die Zeit stiehlt. Das wäre frustrierend und ausgrenzend. Gender und Code of Conduct und so.

Die Leute haben ihre eigenen Distributionen nicht mehr im Griff.

Und systemd ist inzwischen auch deutlich außer Kontrolle – und soweit ich weiß, wie das Ding bein Red Hat gebraut.

Nachtrag: Noch so’n Mist. Ich habe wieder das alte Problem, dass ein Start Job lange hängt, aber systemd nicht sagt, welcher, sondern nur „A start job is running for Wait for Network to be configured”, was ständig ausgegeben wird, weil es nicht reicht, das einmal auszugeben. Es muss sich ja unbedingt vorne ein roter Punkt hin- und herbewegen, die Zeile also immer wieder neu augegeben werden. Die Debug-Console, mit der man sowas eigentlich analysieren kann, ist nicht zu gebrauchen, weil systemd die Zeile da auch ständig ausgibt und man weder sieht, was man eingibt, noch die Ausgaben sehen kann.

systemd ist an so vielen Stellen so schlampig und hirnlos programmiert.

Eigentlich nicht mehr produktionsfähig, weil es keine sauberen debugging-Prozesse mehr gibt.