
oder: Der Fluch des langjährigen Linux-Nutzers
Manche Dinge gewöhnt man sich so gründlich ab, dass sie ganz in Vergessenheit geraten. Diese Erkenntnis schlug gestern am späten Abend bei mir ein.
Aber mal von Vorne:
Anlässlich meines Hoster-Wechsels stand vor ein paar Tagen an, etliche von mir registrierte Domains auf meinen Server bei meinem neuen Provider umzustellen. Ich bin da ganz systematisch nach Liste vorgegangen, habe die Zonen-Einträge auf die neue IP geändert und wollte dann damit beginnen, die Domains nacheinander in das YunoHost-System (YH) auf meinen neuen Server einzubinden.
Das ging aber schief! Schon bei der ersten Domain. Erst meckerte YH, es könne kein Let's Encrypt Zertifikat erstellen, dann aber zeigte vor allem die notwendige Diagnose unter YH die Fehlermeldung, dass die Domain nicht von außerhalb via http zu erreichen sei.
Gnaaah!
Ok, erstmal wieder rausgeschmissen, die Domain... vielleicht habe ich bei der DNS-Verwaltung ja was falsch eingetragen... muss ich später mal gucken.
Was steht noch an? Ja! Meinen Shorturl-Dienst muss ich auf jeden Fall auf dem neuen Server wieder verfügbar machen (den habe ich in erster Linie nicht, um URLs kürzer zu machen, sondern dafür, Links auf bestimmte Seiten zu "entkoppeln"). Also habe ich eine neue Subdomain zur Hauptdomain meines Servers (die also in YH schon drin war und perfekt funktionierte... auch mit zwei weiteren Subdomains) in der Zone eingetragen. Anschließend dann in YH die Domain neu hinzufügen. Und?
Nüscht war! Let's Encrypt brach ab (dem Log war zu entnehmen, dass es sich nicht signieren ließ, weil die Domain nicht per http erreichbar sei) und in der Diagnose stand auch wieder diese verdammte Fehlermeldung, die Domain sei nicht über http erreichbar.
Tatsächlich wurde ein http-Aufruf mit "302 Moved Temporarily" quittiert und dann auf https umgeleitet, was zum Admin-Portal meines YH führte (letzteres ist soweit normal, solange die Domain noch mit keiner App verknüpft ist).
Da YH immer auch ein selbst signiertes Zertifikat für hinzugefügte Domains erstellt, habe ich einfach einmal eine My Webapp (ohne Beilage... also ohne PHP und Datenbank) unter der Domain erstellt, um die Domain mit einer App zu verknüpfen. Ich habe dann (begründet) erwartet, dass ich beim https-Aufruf der Domain und dem Übergehen der Sicherheitswarnung im Browser wegen des selbst signierten Zertifikats auf der Platzhalter-index.html von einer frischen My Webapp lande.
Pustekuchen!
Ich landete wieder beim Login des Admin-Portals meines YH. Ebenso verhielt es sich beim http-Aufruf. Auch wieder das Portal.
Mit curl konnte ich das auch bestätigen und das Fehlverhalten war zu 100 % reproduzierbar.
Nur... bei allen anderen Domains, die ich bereits früher hinzugefügt hatte, trat dieser Effekt nicht auf. Die Diagnose blieb auch unauffällig für diese und die Aufrufe landeten natürlich bei der Anwendung für die jeweilige Domain.
Es traf also nur für die neu hinzugefügte Domain zu.
Also habe ich noch einige andere Domains, die sowieso auf der eingangs erwähnten Liste standen, probeweise hinzugefügt. Und alle kackten genauso ab, wie die erste.
Ich konnte also gar keine Domain mehr erfolgreich hinzufügen. What the fuck...?
Und dann ging sie los, die Fehlersuche. Ich habe mich geschlagene drei Tage (Tag und Nacht) mit kurzen Unterbrechungen durch die nginx-Konfigurationen auf dem Server durchgewühlt. Habe verglichen (die Konfigurationen der alten, funktionierenden Domains mit der neuen, nicht funktionierenden Domain), "gedifft" irgendwann zwischendrin ein Pythonskript gebaut, das mir in einer Baumansicht rekursiv zeigt, welche Konfigurationsdateien an welcher Stelle letztlich von der Haupt-Konfiguration aus (/etc/nginx/nginx.conf) eingebunden werden.
Mit KI-Unterstützung Tests durchgeführt... gefühlt 1.000mal die Domain entfernt (mit allen schäbigen Resten, die im System bleiben und die man manuell entfernen muss) und wieder hinzugefügt, Konfigurationsdateien geändert, angepasst... und wieder zurück und dies und das.
Schließlich konnte ich ausschließen, dass es etwas mit den Konfigurationsdateien (nginx) zu tun hat. Es gab schlicht keine Unterschiede zwischen den der alten und denen der neuen Domains. Nur... die alten funktionierten, die neuen eben nicht. Das ist doch nicht normal... spukt es in meinem Server?
Und dann kam ich auf den entscheidenden Trichter. YunoHost speichert seine interne Konfiguration nicht (vollständig) in einzelnen Dateien oder Datenbankdateien, sondern in einer In-Memory-Datenbank (redis). Und genau DA muss irgendwas schiefgegangen sein.
Vermutlich(!) bei der letzten Aktion, bevor ich irgendwann wieder Domains hinzufügen wollte, muss diese Datenbank korrumpiert worden sein.
Diese Datenbank musste also irgendwie neu initialisiert werden, in der Hoffnung, dass die Fehler dann da raus sind. Und wie am besten? Na ganz einfach: Reboot!
Und was soll ich sagen? Nach dem Reboot (das spürbar länger dauerte, als ich es in Erinnerung hatte), lief alles wieder korrekt. Die nicht funktionierenden Domains waren aller in Ordnung, Let's Encrypt Zertifikate ließen sich erstellen und es erfolgte keine ungewollte Umleitung mehr.
Reboot! Der älteste aller Lösungsversuche!
Auf die Idee bin ich schlicht gar nicht gekommen. Seit Mitte der 80er Jahre bin ich von Windows weg und nur noch mit Linux unterwegs. Unter Windows musste man ständig rebooten... damit selbst die einfachsten Installationen "abgeschlossen" werden können. Und mit Linux hat man sich dieses Zwangsverhalten dann abgewöhnt. Bei Linux ist ein Reboot (und selbst das nicht immer zwingend) notwendig, wenn man tief im System etwas verändert (z.B. durch Updates). Ansonsten kann man sich das klemmen... vielleicht ist mal der Neustart eines einzelnen Dienstes erforderlich, aber die Aus-Einschalt-Orgie kennt man nicht.
Und das ist inzwischen so tief in mir verwurzelt, dass ich gar nicht auf diese simple Idee gekommen bin.
Die drei Tage Wühlen tief in YunoHost waren trotzdem nicht völlig umsonst... ich habe auf jeden Fall etliches über das System gelernt. Und den "Neustart" habe ich auch aus der hintersten Ecke meines Gedächtnisses wieder ein wenig weiter nach vorne geholt.