In meinem WhatsApp-Status habt ihr schon davon erfahren: Es stand ein Upgrade meines Servers an. Demjenigen, der diese Website hier ausliefert. Und diese Art von Upgrade hat seit Anbeginn dieses Blogs (genau genommen also seit 2018) alle 1,5 Jahre, ganz im Releasezyklus von Suse Leap, immer einwandfrei als „in-place-upgrade“ funktioniert. Also als Upgrade des laufenden Systems, ohne Neuinstallation. Sollte also nicht allzu kompliziert werden, dachte ich…

Alles wie immer

Ich habe für derart Aktionen meist einen Fahrplan. Grob sieht das so aus:

• Alle aktuellen Updates des „alten“ Release installieren
• Backup machen und in Sicherheit bringen (externe Platte)
• Reboot
• Alle Dienste stoppen: nginx, php-fpm, mysql, fail2ban, Docker Container
• Upgrade starten
• Wichtigste Einstellungen prüfen (Firewall, ssh-Zugang, …)
• Reboot
• Logfiles prüfen
• Kleinere Nacharbeiten

So war der Plan. Allerdings hat Suse Leap beim Sprung auf Version 16.0 einiges am Unterbau geändert. Das wusste ich zwar grob, aber über mögliche Auswirkungen habe ich mir dennoch keine allzu große Sorgen gemacht. Hätte ich mal lieber!

Es fing schon damit an, dass Suse den Aufbau der Software-Repositories umgestellt hat und ein Migrationstool zur Verfügung stellt, um das System in die neue Welt zu bringen. Allerdings hat sich dieses Tool „verschluckt“ und zunächst kein Upgrade durchgeführt. Schritt 1: Repositories manuell bereinigen – Neustart.

Im zweiten Anlauf wurden ca. 3.000 Softwarepakete erfolgreich aktualisiert und nach einem Check der Firewall und der Konfiguration des SSH Zugangs konnte der Reboot kommen. Kam auch. Lief auch.

Nix wie immer

Doch dann gings los. Zunächst wurde der Blog aufgerufen: Lief. Sah gut aus. Super. Erleichterung. Dann der Aufruf der Nextcloud. Die läuft auch hier und speichert ein paar wichtige Daten wie das Adressbuch, Terminkalender und alle Bilder, die die Handies und Tablets machen -> Internal Server Error. Was?

Schnell habe ich mich via ssh auf den Rechner verbunden und Logfiles durchsucht. Aber es gab keinen echten Hinweis auf das mögliche Problem. Also dann, Google Suche. Und dort war tatsächlich ein Hinweis zu finden: Möglicherweise ist der für Nextcloud essenzielle REDIS Server, eine In-Memory Datenbank zur Ablage von Laufzeit-Informationen, Variablen und z.B. Informationen über geöffnete und gesperrte Dateien, nicht verfügbar.

Tatsache, lief nicht. Also erst mal die Konfiguration angepasst, den Dienst wieder sauber konfiguriert und dann neu gestartet. Ergebnis: Nextcloud funktionierte. Puh….

NGINX

Im Rahmen der Fehlersuche bin ich durch verschiedene Logfiles geturnt und habe dabei auch einen Hinweis entdeckt: Die neue Suse Version kommt mit einer neuen Version des Webservers nginx und DER braucht jetzt neue Angaben in der Konfiguration. Zum Glück bin ich schon vor Monaten über entsprechende Hinweise gestolpert und hatte mir in der Konfiguration ein paar Vermerke darüber gemacht, was ich gegebenenfalls anpassen müsste.

Gesagt, getan, Webserver neu gestartet: Fehler weg. Super. Aber warum stehen da eigentlich hunderte Zugriffe im Logfile? Alle von einer Handvoll fremder Rechner die versuchen, unerlaubte Zugriffe auszuführen? Und WARUM werden die nicht nach dem zweiten Versuch gesperrt? Dafür ist doch Fail2ban da!

Fail2ban

Über Fail2ban habe ich neulich erst geschrieben und damals habe ich die entsprechenden regulären Ausdrücke, mit denen die Logfiles durchsucht werden, angepasst. Tja, mit dem neuen Release wurden diese Dateien auch ausgetauscht und meine Änderungen waren erst mal weg. Selbst schuld, hätte ich halt eigene Kopien erstellt und umbenannt. Das wurde also bei der Gelegenheit nachgeholt und läuft jetzt wieder.

Zeit, sich mal die Anwendungen „von innen“ anzuschauen. Also in WordPress angemeldet und die Systemmeldungen durch geschaut. Und siehe da, es wird sich über fehlende PHP-Module beschwert. Spannend ist, das die Mehrheit davon eigentlich schon installiert ist. Also in der Softwareverwaltung nochmal neu installiert und siehe da: Meldungen weg.

Office

Weiter ging’s zur Nextcloud. Die hat im Hintergrund einen Docker-Container laufen, in dem eine Art von „Web-Office“ installiert ist. Ähnlich wie Google-Docs – nur eben lokal. So kann man Dateien in der Nextcloud im Browser editieren. Dazu muss in der Konfiguration der Nextcloud angegeben werden, wie dieser Docker-Container erreichbar ist. Eigentlich wurde da nichts geändert. Und dennoch: Nextcloud warf einen Fehler darüber, dass diese Komponente nicht erreichbar sei. In den Logfiles waren wenig hilfreiche Hinweise zu finden.

Also wie immer: Doctor Google fragen. Und siehe da, in einem kleinen, wenig beachteten Unterforum schlummerte ein Hinweis über die am wenigsten intuitive Lösung für solch ein Problem: Einfach auf der Konfigurationsseite, OHNE irgendeine Änderung vor zu nehmen, noch einmal auf „speichern“ klicken. Was soll ich sagen: Nachdem ich das mittelprächtig ungläubig gemacht habe war der Fehler weg.

Unterm Strich

Und so hat mich diese ganze Umstellung bisher gute 5 Stunden Zeit gekostet. Nach jetzigem Anschein läuft soweit alles, auch wenn es immer mal wieder noch zu kleineren Holprigkeiten kommt. Gerade wollte Eva ihren 11 GB großen Bilder-Ordner neu Synchronisieren, was zwei mal mit Hinweis auf eine wenig hilfreiche Fehlermeldung verweigert wurde. Beim dritten Mal ging es dann doch. So gehe ich immer mal wieder die Logfiles durch und versuche, etwaige Hinweise umzusetzen und Problemchen aus zu räumen. Auch ein paar Optimierungspotentiale wollen noch realisiert werden, den oben genannten REDIS Server will ich von der etwas langsameren IP-Schnittstelle auf eine Prozess-zu-Prozess Kommunikation umstellen, einen sogenannten „Socket“.

Viel Arbeit, aber ehrlich gesagt gibt es dazu ja auch keine Alternative. Die alte SUSE Version wird bald keine Updates mehr bekommen und Softwarekomponenten entwickeln sich nun mal weiter. Is halt so…

Bloke