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...

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.

Keine Ahnung, ob dieser Artikel nun wirklich für andere interessant ist. Ich beschreibe hier den Umzug meines Hubzilla Hub Whoville von einem Remote-Server zu einem anderen Remote-Server. Sowas ist natürlich auch immer ausgesprochen individuell und speziell, was die Voraussetzungen betrifft. Auf der anderen Seite beschreibe ich natürlich auch etliche Schritte und Überlegungen, die für vergleichbare Umzugspläne interessant sein könnten...

Keine Ahnung, ob dieser Artikel nun wirklich für andere interessant ist. Ich beschreibe hier den Umzug meines Hubzilla Hub Whoville von einem Remote-Server zu einem anderen Remote-Server. Sowas ist natürlich auch immer ausgesprochen individuell und speziell, was die Voraussetzungen betrifft. Auf der anderen Seite beschreibe ich natürlich auch etliche Schritte und Überlegungen, die für vergleichbare Umzugspläne interessant sein könnten.

Nun denn... die

Voraussetzungen

bei MIR...

Ich habe meinen Hub "Whoville" auf einem VPS bei meinem ungarischen Hoster betrieben. Aus bestimmten Gründen wollte ich ihn nun aber zu einem anderen VPS bei einem anderen Hoster umziehen.

VPS 1

Beim ursprünglichen Server, ich nenne ihn hier jetzt VPS 1, lief Hubzilla unter YunoHost. Allerdings – aus Gründen – nicht als YunoHost Hubzilla-App, sondern als manuelle Installation in einer YunoHost My_Webapp (weshalb, kann man hier nachlesen). Da der Hub nun schon recht lange lief, hat sich einiges an Daten angesammelt. So belegte er im Webroot 29.5 GB, wobei der Bärenanteil natürlich auf den Ordner "store" mit insgesamt 28.4 GB ging. Die Datenbank (MySQL) kam auf 16.3 GB. Und die letzte Backup-Datei (YunoHost Backup der My_Webapp) wog 32.4 GB.

VPS 2

Der neue Server, VPS 2, war noch recht "leer", aber bereits ebenfalls mit YunoHost "bestückt".

Selbstverständlich habe ich Zugriff auf die DNS-Einträge für die Domain "hubzilla.hu".

Ein großer Vorteil von YunoHost (neben etlichen anderen) ist, dass es Backup-Funktionen für die Apps gibt. Und ein Backup einer My_Webapp umfasst den kompletten Inhalt von Webroot, einen Datenbank-Dump (sofern es eine DB gibt), sowie System-Konfigurations-Dateien (was so unter /etc zu finden ist), die spezifisch für die Webapp sind und die geändert wurden. Damit hatte ich in dem großen tar-Archiv also eigentlich alles, was ich benötige.

Der Plan

1. Die Nutzer mit Accounts per Rundmail (Hubzilla bietet mit dem Addon "Hubwall" eine einfache Möglichkeit dafür an) über die geplante Downtime (ich habe mit mindestens drei Stunden gerechnet... es wurden sogar vier) informieren.

2. Eine index.html für eine Wartungs-Mitteilung erstellen.

3. Ein frisches Backup von My_Webapp auf VPS 1 erstellen.

4. Die DNS-Einträge für hubzilla.hu, vor allem aber für die Subdomain des Hub hub.hubzilla.hu von der IP des VPS 1 auf die IP des VPS 2 "umbiegen" und ein wenig warten.

5. Sobald die neue IP publik ist, dann die Domains mit YunoHost auf VPS 2 übernehmen und dafür sorgen, dass Let's Encrypt Zertifikate erstellt werden.

6. Danach auf VPS 2 eine My_Webapp unter der Domain hub.hubzilla.hu installieren und die index.html (mit dem Wartungshinweis) dort zunächst "servieren".

7. Nun die aktuelle Backup-Datei (tar) von VPS 1 auf VPS 2 übertragen.

8. Die Backup-Datei auf VPS 2 entpacken.

9. Den Inhalt des Backups auf VPS 2 anpassen (.htconfig.php, Nginx- und PHP-Konfigirationsdateien).

10. Die noch fehlenden Pakete (gemäß der Installationsanleitung von Hubzilla) installieren.

11. Den Datenbank-Dump aus dem Backup in die neue, noch leere DB von My_Webapp auf VPS 2 importieren.

12. Den Webroot-Inhalt des entpackten Backups nun ins neue Webroot der My_Webapp auf VPS 2 verschieben.

13. Die Konfigurationsdateien für Nginx und PHP an die entsprechenden Orte unter /etc bei VPS 2 verschieben.

14. Dienste neu starten und überprüfen, ob sie ordentlich laufen (Nginx und php-fpm) und checken, ob sie fehlerfrei gestartet wurden und laufen.

15. Wichtig! Den Cronjob einrichten.

16. Eigentlich nicht notwendig, weil Dienste ja neu gestartet, aber aus Sicherheitsgründen: Reboot von VPS 2.

17. Finger überkreuzen, Stoßgebet gen Himmel, Whoville im Browser aufrufen.

Vorüberlegungen / Vorbereitung

Die Rundmail war schnell rausgeschickt. Ich hatte mir die Nacht von Ostersonntag auf Ostermontag für den Umzug vorgesehen, weil da am wenigsten Traffic und Zugriffe auf meinen Hub zu erwarten waren. Und auch die index.html war rasch erstellt.



Für die Übertragung der doch recht großen Backup-Datei wollte ich nicht darauf zurückgreifen, sie zunächst auf meinen lokalen Rechner zu laden und anschließend von dort aus auf den neuen Server wieder hochzuladen. Das dauert auch bei guter Anbindung erstens ziemlich lange und erzeugt zusätzliche vermeidbare Fehlerquellen (Fehler bei der Datenübertragung). Klar war also, dass ich die Datei direkt von VPS 1 zu VPS 2 übertragen wollte. Da entstand natürlich die Frage, ob mit sFTP, per SSH mit scp oder der SSH mittels rsync. Welche Vor- und Nachteile ergeben sich für meinen speziellen Zweck bei den einzelnen Methoden?

Und hier nun mein Geständnis: Selbst wenn ich bei solchen Dingen schon eigene Ideen habe, frage ich gerne die "KI" (also ein LLM). In der Frage halte ich mich dann mit meinen eigenen Gedanken zurück, um sie nicht zu beeinflussen. Und damit hole ich mir quasi eine "zweite Meinung" ein. Ich habe in der Vergangenheit die Erfahrung gemacht, dass ich auf diese Weise bestimmte Ansichten zu solchen Sachen bekomme, die mir sonst nicht so präsent waren. Das kann bei der Entscheidungsfindung durchaus helfen. Bis jetzt bin ich damit immer sehr gut gefahren. Aber das "dicke Ende" kommt noch... ich habe dafür Grok verwendet... also die "KI" von dem pöhsen Pupen, dessen Namen man nicht laut aussprechen darf (alle, die das verwerflich finden, dürfen mich gerne mal dort, wo die Sonne nie scheint und anschließend an ihrer Moral ersticken 😉😁). Ich habe in der Vergangenheit einfach die besten Erfahrungen mit genau diesem Dienst gemacht.

Für eine Übertragung mit FTP hätte ich mich erstmal wieder frisch einlesen müssen... in die Nutzung auf der Kommandozeile. Im täglichen Betrieb nutze ich ja nur Filezilla (und selten Dolphin) für solche Übertragungen. Das geht remote aber nicht einfach so. Ich hätte scp bevorzugt. Grok empfahl mir aber, mir doch einmal die Methode mit rsync via SSH anzuschauen. Und das Argument war überzeugend... während scp nämlich nicht "resumable" ist, also bei einem Verbindungsabbruch die Datenübertragung diese nicht wieder aufnehmen kann, ist das bei rsync der Fall. Hat mich überzeugt! Und mit dem Parameter "--progress" habe ich auch ein visuelles Feedback über den Fortschritt der Übertragung, ohne andere Tools dafür einsetzen zu müssen.

Ich habe dann die anderen geplanten Schritte auch noch mit Grok "durchgesprochen". Insgesamt wurde mein Plan generell "abgenickt" und als erfolgversprechend gewertet.

Umzug

1. und 2. waren ja schon erledigt...

3. War auch rasch getan ("rasch" ist relativ... das Erstellen der Backup-Datei dauerte bei der Größe auch immer schon knapp 20 Minuten auf dem alten, etwas schwachbrüstigen VPS 1). Nun lag die Datei "20260405-225032.tar" im Backupverzeichnis meines VPS 1.

4. Dann habe ich ab kurz vor 01:00 Uhr nachts die DNS-Einträge vom alten auf das neue VPS umgebogen. Ab diesem Augenblick lag Whoville also im Koma (ich hatte unmittelbar zuvor die index.php auf VPS 1, also dem alten VPS, in _index.php umbenannt, damit in der Zeit, bis die neue IP bekannt war, nicht noch irgendwelche Aktivitäten stattfinden konnten.

5. Als die Sache dann erledigt war, habe ich die beiden Domains bei YunoHost auf VPS 2 übernommen. Let's Encrypt Zertifikate inklusive.

6. Das Installieren der My_Webapp (mit PHP und MySQL-Datenbank) war rasch erledigt. Während Whoville auf VPS 1 noch mit php8.2 lief, habe ich bei der My_Webapp php8.4 ausgewählt. Die index.html hochgeladen und nun wurde der Wartungshinweis angezeigt, wenn man Whoville aufgerufen hat.

7. Dann habe ich die Backup-Datei von VPS 1 nach VPS 2 übertragen. Dafür habe ich dann, aufgrund des Hinweises und der Emofehlung von Grok rsync via SSH verwendet. Schema:

rsync -av --progress /pfad/zum/backup/backup-datei.tar.gz \
      deinuser@DOMAIN-BEI-VPS2:/pfad/wohin/auf/vps2/

Nach der Übertragung, die knapp 40 Minuten gedauert hat, habe ich auf VPS 2 die Backup-Datei vom Eingangsverzeichnis ins Webroot der frisch installierten My_Webapp verschoben.

8. Anschließend habe ich die Backup-Datei an Ort und Stelle entpackt. Das erzeugte ein Verzeichnis "apps" unter welchem dann die ganzen Daten strukturiert lagen.

tar -xvf 20260405-225032.tar

Auch dazu habe ich wieder einmal Grok konsultiert. Mir stellte sich nämlich die Frage, wie es denn mit der Eigentümer-Eigenschaft und den Rechten aussehen mag. Auch wenn es auf VPS 2 mit YunoHost die Benutzer/Gruppen "my_webapp_1" und "www-data" gibt, so unterscheiden sich doch die Benutzer- und Gruppen-Id's wahrscheinlich. Also zumindest für "my_webapp_1". Wie könnte ich denn sichergehen, dass die korrekten Eigentümer bei den entpackten Dateien und Verzeichnissen gesetzt sind. Grok meinte, dass wahrscheinlich Probleme wegen unterschiedelicher numerischer Id's auftreten könnte und empfahl rekursiv die Eigentümer zu setzen.

Es kam aber anders (angenehmer), als befürchtet. Ich nutze ja sehr gerne und quasi schon immer den Midnight Commander (mc) für die bequeme Dateiverwaltung auf der Konsole. Das hatte ich auf VPS 2 natürlich auch installiert. Und mc zeigte mir für die entpackten Daten tatsächlich auch die ursprünglichen Besitzer an. Aber stimmen denn nun die numerischen Id's auch überein? Tatsache! Dem war so. Beim Entpacken wurden also offensichtlich die Id's (also nur die von "my_webapp_1", die Id für "www-data" war bei beiden VPS ohnehin identisch) der Dateien und Verzeichnisse auf die aktuellen Id's von VPS 2 gesetzt. Also Benutzer sind ok. Ebenso waren die Rechte sauber übernommen. Da brauchte ich nichts zu ändern.

9. Nun ging es ans Anpassen der Konfiguration. BTW: Grok ist sehr gesprächig. Es hat mit immer wieder auch gesagt, was ich denn wie anpassen müsste. Ok... das habe ich dann überlesen, denn das wusste ich ohnehin.

Zunächst war die .htconfig.php dran. Hier musste ich das Datenbank-Passwort aktualisieren. DB-Name und DB-Benutzername waren gleich geblieben, weil ich bei beiden VPS die My_Webapp als my_webapp_1 installiert hatte.

Außerdem habe ich noch den Pfad zu PHP anpassen müssen, weil ich nun ja von php8.2 auf php8.4 umgestiegen bin:

// Location of PHP command line processor
App::$config['system']['php_path'] = '/usr/bin/php8.4';

Ebenfalls mussten die beiden Dateien /etc/nginx/conf.d/hub.hubzilla.hu/my_webapp.conf und /etc/nginx/conf.d/hub.hubzilla.hu/my_webapp.d/php.conf jeweils von /var/run/php/php[b]8.2[/b]-fpm-my_webapp.sock auf /var/run/php/php[b]8.4[/b]-fpm-my_webapp.sock geändert werden.

10. Wie auch bei der ursprünglichen Installation von Hubzilla in eine My_Webapp mussten noch einige Pakete installiert werden, weil sie nicht in einer Standard-Installation vorhanden waren. Der INSTALL.txt aus der Hubzilla-Distribution kann man entnehmen, was notwendig ist. Auch das habe ich rasch erledigt.

11. Nun musste nur noch die Datenbank mit dem Dump aus dem Bckup "Bevölkert" werden.

pv db.sql | mysql -u my_webapp -p my_webapp

Dank "pv" mit Fortschrittsbalken... hat bei der Größe neun Minuten gedauert.

12. Dann habe ich den Inhalt des Backup-Webroot ins Webroot der neuen My_Webapp auf VPS 2 verschoben. Aus Bequemlichkeit mit dem Midnight Commander. Und nochmal die Besitzer und Rechte überprüft... alles ok.

13. Danach die geänderten Konfigurationsdateien (Punkt 9.) an die entsprechenden Stellen verschoben.

14. Nun die Dienste (Nginx und PHP-fpm) neu gestartet

yunohost service restart nginx
yunohost service restart php8.4-fpm

und ihren Status überprüft

yunohost service status nginx
yunohost service status php8.4-fpm

Alles im grünen Bereich!

15. Nun mit crontab -e den Cronjob eingerichtet:

*/10 * * * * cd /var/www/my_webapp/www && /usr/bin/php8.4 Zotlabs/Daemon/Master.php Cron > /dev/null 2>&1

Und überprüft: crontab -l

16. Nachdem nun alles ordentlich aussah und ich auch keine Fehler oder Störungen feststellen konnte, habe ich die _index.php zurück in index.php umbenannt, den Ordner "apps" mit den Resten des entpackten Backups, und, um wirklich sicherzugehen, dass alles mit den aktuellen Konfigurationen läuft, VPS 2 rebootet.

17. Es war inzwischen 04:30 Uhr geworden... und ich habe Whoville im Webbrowser aufgerufen...

Jawoll! Er war da! Und ich habe herumprobiert, auch ein Testposting abgesetzt und von einem anderen Dienst (Mastodon), wo es angekommen war (Zustellungsbericht war auch ok) kommentiert, was auch wieder sauber ankam.


Ich habe bis jetzt keine Probleme festgestellt. Es ist extrem geschmeidig gelaufen.

Sicherlich habe ich einiges unnötig umständlich gemacht, aber ich war halt an verschiedenen Stellen extrem vorsichtig und "mit dem Arsch an der Wand", weil mir ein gelungener Umzug mit meinem Haupt-Hub wirklich wichtig war.

---

Titelbild von Moondance auf Pixabay