Fallstricke Migration Ubuntu 20.04 auf 24.04 mit Plesk

Eine ältere VM (Virtuozzo, lcx) soll auf eine neue VM (KVM) umgestellt werden. Die alte VM wird als Source, die neue als Target bezeichnet.  Zum Umzug wird PLESK verwendet (Plesk Obsidian 18.0.61, Admin-Edition auf beiden VMs).

 

Eine philosophische Betrachtung über Ubuntu und Snap erfolgt nicht, da der Server einfach nur stabil und möglichst bis zum Ende des neuen LTS laufen soll.

Auf Quell- und Zielsystem sind dieselben Major-Release von MariaDB, Apache, php … vorhanden. Beim Datenbankdienst werden durch Einfügen der Zeile „innodb_strict_mode=OFF“ in der my.cnf unötige Schwierigkeiten im Vorfeld minimiert. Nicht benutzte Module und Extensions schaltet man auf beiden Systemen ebenfalls vorher ab.

Den Migrationsassistent startet man auf dem Target gestartet, er verbindet sich dann per ssh auf den Source. Die eigentliche Arbeit (Backups, rsync…) wird auf dem Source ausgeführt.

Folgende Fallstricke sind mit begegnet:

Beim ersten Versuch kam die Meldung, dass nicht genügend Speicherplatz auf dem Source zur Verfügung stand. Der Migrationsassistent benötigt hier ein temporäres Verzeichnis, in das er die mysql-dumps usw. legen kann. Deshalb habe ich ein per NFS freigegebenes Verzeichnisse von einem dritten Server (30-Tage-Test, prinzipiell ginge auch der Target) als temporäres Verzeichnis eingestellt und den Vorgang nochmal gestartet. Und nach einiger Zeit wieder abgebrochen. NFS ist bei sowas quälend langsam.

Deshalb wurde der Mount sshfs gemacht, weil scp hier wesentlich flotter geht und das Verzeichnis auch nicht durch ein Locking sperrt, wenn man dem Fortschritt auf der Konsole zuschauen will.

Der Assistent macht dann erstmal einen Vorbereitungslauf. Da kam es bei mit sofort zu einem Parser-Fehler im Skript database_utils.py auf dem Source. Dieser konnte schnell behoben werden, indem die Zeilen 450 und 2006 im Datenbankskript auf dem Source angepasst und die Methoden mit Klammern versehen wurden. Ist in neueren Version von Plesk wahrscheinlich schon angepasst.

450: if server.host() == ‚localhost‘ and server.port() == 3306:

 

Nächster Versuch, nächster Fehler:

command: mysql –defaults-file=/mnt/plesk/plesk_migrator-4iy5ebz7jxfuotryw35m5ewk3k8nwiwh/my_localhost_secure_auth_check.cnf –silent –skip-column-names -h localhost -P 3306 -e ‚SHOW VARIABLES LIKE ‚“‚“‚innodb_strict_mode’“‚““ exit code: 2 stdout: stderr: mysql: unknown option ‚–“

Das mysql-Programm sagt hier vordergründig, dass es die erste Option „-defaults-file..“ nicht kennt. Laut Doku gibt es diese aber in der verwendeten MariaDB-Version. Die Lösung war, dass das im Datenbankskript database_utils.py aufgerufenen mysql-Programm nicht auf die von dem unter root laufenden Plesk-Prozess angelegte Datei  my_localhost_secure_auth_check.cnf zugreifen konnte. (Rechte rw-,—,—).

Ich hätte also vor dem Aufruf noch ein chmod ins Python-Skript einbauen müssen, habe mich aber stattdessen für eine sehr großzügige umask beim Mount entschieden. Wer weiß, was da sonst noch alles schiefgehen kann…

# umount /mnt/plesk

sshfs -o umask=000 root@hilfsserver.expample:/var/share_for_plesk /mnt/plesk

Dadurch werden im nächsten Versuch alle Dateien vom Migrators im temporären Verzeichnis mit den Rechten 777 angelegt. Was aber nicht gefährlich ist, da das Verzeichnis ja nicht anderweitig freigegeben ist und auf dem Hilfsserver nichts anderes lief.

Nach ein paar Stunden war das Ganze dann aber erfreulicherweise fehlerfrei durchgelaufen.

Beim Umstellen der DNS-Einträge von der IP des Source auf die des Target sollte ggf. mal der Hotspot am Handy eingeschaltet werden, weil Router und Betriebssystem gerne IPs chachen.

Ein letzter Stolperstein: Nach einiger Zeit konnte ich den neuen Server nur noch pingen, aber keine Dienste erreichen. Die Firewall hatte ich zu dem Zeitpunkt aber noch gar nicht aktiviert. Im Notfallsystem des Hosters war er auch per Konsole erreichbar, ebenso über den Hotspot. Lösung: Plesk hatte sich auf dem Target durch meine ganzen Konfigurationsarbeiten wohl belästigt gefühlt und meine IP in die Banned-Liste aufgenommen. Meine Güte!

Ein einfacher Umzug geht irgendwie anders… aber ganz unkomplex ist das ja nun auch nicht. Insofern keine schlechte Software, dieser Migrationsassistent.