Heute war es soweit, ich musste meine WordPress-Installation auf einen anderen Webserver umziehen – Und das war gar nicht so trivial wie es sich anhört.
Meinen Blog hatte ich vorher auf einem ASUSTOR NAS-Server gehosted, da dieser eine praktische Funktion für Webhosting eingebaut hatte. Dies lief auch über mehrere Jahre hinweg eigentlich sehr gut und würde wohl eigentlich auch weiterhin sehr gut laufen, wenn da nicht ein kleines Problemchen mit den Software-Updates wäre. ASUSTOR schafft es nämlich nicht, PHP auf die Version 8.X zu pushen und bleibt einfach auf Version 7 sitzen. WordPress drängelte mich schon seit längerer Zeit, ich solle doch endlich mal PHP updaten, da keine Sicherheitspatches mehr für die 7er-Version rauskommen würden etc, also entschied ich mich dazu, das gesamte Hosting auf einen separaten virtuellen Server zu verschieben.
Virtualisierung to the rescue
Da ich in meinem Homelab einen Proxmox-Server betreibe und eine OPNSense-Firewall mein Eigen nennen darf, habe ich eine neue virtuelle Maschine mit Ubuntu Server als Betriebssystem eingerichtet. Auf dieser VM habe ich dann die notwendigen Packages installiert (Apache2, PHP, einige PHP-Module…) und mich mit den Apache2 VirtualHosts befasst. Ansonsten ist auf dieser VM nicht viel drauf, denn umso weniger Packages installiert sind, desto weniger Sicherheitslücken können auftreten.. (in der Regel zumindest).
Anschließend habe ich die gesamte Dateistruktur von WordPress vom ASUSTOR zur VM rüberkopiert. Apache2 Webverzeichnisse sind i.d.R. in /var/www/<websitename> abgelegt. Mittels `sudo chown -R www-data:www-data .` im aktuellen Website-Verzeichnis habe ich alle Dateien und Ordner, sowie Unterordner dem Service-Benutzer www-data zugeordnet. Anschließend habe ich noch die Lese-, Schreib- und Ausführungsrechte mit `chmod` entsprechend eingeschränkt.
Im zweiten Schritt habe ich die Datenbank, die ebenfalls vorher auf ASUSTOR lag, auf einen separaten Datenbankserver kopiert. Auf dem neuen Datenbankserver habe ich dafür noch einen extra Benutzer und ein kompliziertes Passwortes erstellt und diesem die neue DB zugeordnet. Diese neuen Datenbankinformationen musste ich in der kopierten WordPress-Installation anpassen, welches in der Datei wp-config.php zu erledigen ist.
Und damit war der grundlegende Umzug schon erledigt.
Domain umleiten
Die eigentliche Domain „sp-dev.eu“ zeigt weiterhin auf das selbe Ziel. Jedoch ist innerhalb des Zielnetzwerkes nun ein anderer Rechner dafür verantwortlich die Website zu hosten. Für diesen Zweck nutze ich ein Plugin in OPNSense namens „HAProxy“. Damit kann ich einkommende Requests (in meinem Fall auf Port 443/HTTPS beschränkt) steuern und per definierter Regel auf dem neuen virtuellen Server zeigen lassen. Die gesamte HAProxy-Konfiguration ist noch etwas komplexer als das, vor allem wegen SSL-Zertifikatsmanagement, aber das würde jetzt hier den Rahmen sprengen.
Klingt eigentlich recht einfach, oder? HAProxy sagen, dass er statt ASUSTOR nun die VM nutzen soll. Aber trotzdem wollte WordPress am Ende nicht so recht mitspielen!
Der Blog sah nach dem Umzug komplett entstellt aus. Alle Blog-Artikel waren zwar vorhanden und lesbar, jedoch optisch eine Zumutung. Im Inspektor meines Webbrowsers fand ich heraus, dass die Aufrufe der Stylesheets (CSS-Dateien) und einigen Javascript-Dateien (JS-Dateien) blockiert wurden. Das hatte den Hintergrund, dass aus mir völlig unbegreiflichen Gründen versuchte wurde, diese Dateien via HTTP statt HTTPS zu laden. Da ich nur HTTPS-Anfragen durch die Firewall und durch HAProxy zulasse, sind diese Aufrufe natürlich zum scheitern verurteilt. Ab hier begab ich mich auf die Suche, warum HTTP genutzt wurde, statt HTTPS. Und ich wurde lange Zeit einfach nicht fündig, bis ich in den WordPress-PHP-Dateien die Funktion „is_ssl()“ fand. Diese Funktion prüft, ob die aktuelle Anfrage eine verschlüsselte (HTTPS) oder unverschlüsselte (HTTP) Anfrage ist und gibt entsprechend ein Wahr oder Falsch zurück. Und dieses Wahr oder Falsch machen sich andere Funktionen wiederum zu nutze, um dann entsprechend eine https-URL bzw http-URL anzuzeigen und/oder aufzurufen.
Im WordPress Developer-Blog wurde ich fündig: https://developer.wordpress.org/reference/functions/is_ssl/
Hier besagt der Beschreibungstext, das die is_ssl() Funktion fehlerhaft sein kann, wenn sie hinter Loadbalancern oder Reverse Proxies liegt – also auch hinter HAProxy! Eine Abhilfe dazu ist, ein Plugin zu installieren, dass eine SSL-Verbindung auf jeden Fall erzwingt. Also habe ich mir das Plugin in das WordPress-Plugin-Verzeichnis abgespeichert (wp-content/plugins/force-ssl/force-ssl.php) und anschließend über die WordPress-Administrationsoberfläche aktiviert.
Und schon funktionierts! Alle CSS-Dateien, Javascript-Dateien, etc. werden nun über HTTPS aufgerufen und können fortan korrekt angezeigt werden. Das war der letzte Schritt der WordPress-Migration auf die virtuelle Maschine und nun kann ich endlich das Webhosting auf dem alten ASUSTOR abschalten! Juhu!