{"type":"rich","html":"
\"PepeCyBs<\/a>PepeCyBs Welt<\/a> wrote the following post <\/a>Mon, 20 Apr 2026 16:24:35 +0200<\/span><\/span><\/div>
"Hast Du das Ding eigentlich mal aus- und wieder eingeschaltet?"<\/strong>
\"reboot.webp\"<\/a>

oder: Der Fluch des langj\u00e4hrigen Linux-Nutzers<\/h3>
Manche Dinge gew\u00f6hnt man sich so gr\u00fcndlich ab, dass sie ganz in Vergessenheit geraten. Diese Erkenntnis schlug gestern am sp\u00e4ten Abend bei mir ein.

Aber mal von Vorne:

Anl\u00e4sslich 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\u00e4ge auf die neue IP ge\u00e4ndert 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\u00f6nne kein Let's Encrypt Zertifikat erstellen, dann aber zeigte vor allem die notwendige Diagnose unter YH die Fehlermeldung, dass die Domain nicht von au\u00dferhalb 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\u00e4ter mal gucken.

Was steht noch an? Ja! Meinen Shorturl-Dienst muss ich auf jeden Fall auf dem neuen Server wieder verf\u00fcgbar machen (den habe ich in erster Linie nicht, um URLs k\u00fcrzer zu machen, sondern daf\u00fcr, 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\u00dfend dann in YH die Domain neu hinzuf\u00fcgen. Und?

N\u00fcscht war! Let's Encrypt brach ab (dem Log war zu entnehmen, dass es sich nicht signieren lie\u00df, weil die Domain nicht per http erreichbar sei) und in der Diagnose stand auch wieder diese verdammte Fehlermeldung, die Domain sei nicht \u00fcber http erreichbar.

Tats\u00e4chlich wurde ein http-Aufruf mit "302 Moved Temporarily" quittiert und dann auf https umgeleitet, was zum Admin-Portal meines YH f\u00fchrte (letzteres ist soweit normal, solange die Domain noch mit keiner App verkn\u00fcpft ist).

Da YH immer auch ein selbst signiertes Zertifikat f\u00fcr hinzugef\u00fcgte 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\u00fcpfen. Ich habe dann (begr\u00fcndet) erwartet, dass ich beim https-Aufruf der Domain und dem \u00dcbergehen 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\u00e4tigen und das Fehlverhalten war zu 100 % reproduzierbar.

Nur... bei allen anderen Domains, die ich bereits fr\u00fcher hinzugef\u00fcgt hatte, trat dieser Effekt nicht auf. Die Diagnose blieb auch unauff\u00e4llig f\u00fcr diese und die Aufrufe landeten nat\u00fcrlich bei der Anwendung f\u00fcr die jeweilige Domain.

Es traf also nur f\u00fcr die neu hinzugef\u00fcgte Domain zu.

Also habe ich noch einige andere Domains, die sowieso auf der eingangs erw\u00e4hnten Liste standen, probeweise hinzugef\u00fcgt. Und alle kackten genauso ab, wie die erste.

Ich konnte also gar keine Domain mehr erfolgreich hinzuf\u00fcgen. 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\u00fchlt. 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\u00fctzung Tests durchgef\u00fchrt... gef\u00fchlt 1.000mal die Domain entfernt (mit allen sch\u00e4bigen Resten, die im System bleiben und die man manuell entfernen muss) und wieder hinzugef\u00fcgt, Konfigurationsdateien ge\u00e4ndert, angepasst... und wieder zur\u00fcck und dies und das.

Schlie\u00dflich konnte ich ausschlie\u00dfen, 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\u00e4ndig) 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\u00fcgen 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\u00fcrbar l\u00e4nger dauerte, als ich es in Erinnerung hatte), lief alles wieder korrekt. Die nicht funktionierenden Domains waren aller in Ordnung, Let's Encrypt Zertifikate lie\u00dfen sich erstellen und es erfolgte keine ungewollte Umleitung mehr.

Reboot! Der \u00e4lteste aller L\u00f6sungsversuche!

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\u00e4ndig rebooten... damit selbst die einfachsten Installationen "abgeschlossen" werden k\u00f6nnen. Und mit Linux hat man sich dieses Zwangsverhalten dann abgew\u00f6hnt. Bei Linux ist ein Reboot (und selbst das nicht immer zwingend) notwendig, wenn man tief im System etwas ver\u00e4ndert (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\u00fchlen tief in YunoHost waren trotzdem nicht v\u00f6llig umsonst... ich habe auf jeden Fall etliches \u00fcber das System gelernt. Und den "Neustart" habe ich auch aus der hintersten Ecke meines Ged\u00e4chtnisses wieder ein wenig weiter nach vorne geholt.<\/div><\/div>
<\/div>","width":640,"height":426}