Root Server Systemupdate - Ubuntu 18.04 auf 22.04 updaten

Hallo

morgen abend (Samstag, 25.11.2023 um 2030) ist es so weit: ich will endlich und überfällig meinen Rootserver von dem schon seit Juni abgelaufenen (EOL) Ubuntu 18.04 auf 20.04 und dann gleich auf 22.04 aktualisieren. Ich hatte das Update von 14.04 auf 18.04 hier schon mal dokumentiert.

Damals ging das, obwohl auch schon abgelaufen das 14.04, relativ glimpflich durch. Jetzt habe ich etwas mehr Befürchtungen, u.a. wg. solchen Threads: How to upgrade ubuntu 18.04 to ubuntu 20.04 ?

Aber mein PHP geht schon nicht mehr, weil die Ondrej PPAs auf abgelaufenen Systemen gar nicht mehr verfügbar sind: unable to install php8.1 on 18.04

Ich habe unlängst, nämlich bevor das 18.04 abgelaufen war, ESM aktiviert, kriege also seither wenigstens die Sicherheitsupdates, auch noch eine Weile lang, aber ohne aktuelles PHP komme ich dennoch nicht weiter mit 18.04

Ich hatte es ja sogar noch installiert, 8.1 und 8.2 (im Moment ist 8.0 drauf) aber dann wollte ich auf 8.1 umschalten gestern, da hat eigentlich nur ein Paket gefehlt (mbstrings), aber da komme ich partout nicht mehr dran. Die Ondrej Sury PPAs werden scheints auch nicht irgendwo in ein Archiv verschoben, einfach weg!

Daher muss ich also jetzt den ganzen Server aktualisieren... (bald mehr)...

Die Probleme fangen schon im SCP an:

Zitat

Speichernutzung: vda: 250 GiB von 312 GiB belegt

Aber df zeigt:

#sudo df -h
Dateisystem                Größe Benutzt Verf. Verw% Eingehängt auf
udev                        5,9G       0  5,9G    0% /dev
tmpfs                       1,2G    1,1M  1,2G    1% /run
/dev/vda2                   307G    106G  186G   37% /
tmpfs                       5,9G       0  5,9G    0% /dev/shm
tmpfs                       5,0M    4,0K  5,0M    1% /run/lock
tmpfs                       5,9G       0  5,9G    0% /sys/fs/cgroup
/dev/loop0                  9,7M    9,7M     0  100% /snap/canonical-livepatch/246
/dev/loop1                  106M    106M     0  100% /snap/core/16202
/dev/loop3                   74M     74M     0  100% /snap/core22/864
/dev/loop4                  9,9M    9,9M     0  100% /snap/canonical-livepatch/248
/dev/loop2                  106M    106M     0  100% /snap/core/16091
46.38.248.210:/voln62135a3  250G    212G   39G   85% /mnt/storagespace
tmpfs                       1,2G       0  1,2G    0% /run/user/0

Also /dev/vda2 ist eigentlich nur zu 37% belegt. Jetzt habe ich natürlich 'Server stoppen und Speicherplatz optimieren' (unter: Speicher optimieren) geklickt, aber das ändert nichts. Der Server wird dann gestzoppt/runtergefahren, der Speicher wird dann unmittelbar (vermutlich nicht) optimiert, ist also sofort fertig und nichts hat sich nach Reboot geändert. Ich hab das dann gleich noch mal gemacht, hat sich aber nichts geändert.

Treiber steht immer noch auf "Virtio" aber das wird damit nichts zu tun haben, war beim letzten Update ja auch schon.

Unter Snapshots sind keine angelegt, dort kann ich auch keinen anlegen (was für mich die Grundvorraussetzung für das Upgrade wäre), weil:

Zitat

Der minimal notwendige Speicherplatz zur Erstellung eines Snapshots wurde unterschritten, daher kann kein weiteres Abbild angelegt werden. Damit Sie einen Snapshot anlegen können, muss die Größe des freien Speicherplates ebenso groß wie der durch Ihre Daten belegte Speicherplatz, oder größer, sein. In machen Fällen ist eine Optimierung notwendig um Speicher freizugeben.

Wie kriege ich meine (offenbar virtuelle) Festplatte denn jetzt geshrinkt? Ich hab ja auch keinen Zugriff auf die VM-Verwaltung, also was da der Fehler ist, dass es nicht shrinkt und offenbar sofort abbricht.

Gibt da noch Tricks? Den Support fragen?

Zitat von Patrick0815

Soweit ich franc verstanden habe sind sein Problem die 250GiB im Servercontrolpanel vs. der 106G auf /dev/vda2, hier sollte ein fstrim ausreichen.

Die weiteren Methoden reduzieren zusätzlich die Daten in /

/#sudo fstrim /
fstrim: /: Verwerfungsvorgang wird nicht unterstützt.

Geht nicht. Was ist das denn nun?

Kann ich das einfach umschalten von "Virtio" auf "SCSI (empfohlen)"?
Die Warnung schreckt mich ja ab:

Zitat

Änderungen am Festplatten Treiber sind gefährlich! Im schlimmsten Fall bootet der Server nach einem Reboot nicht mehr. Bitte nutzen Sie nur den empfohlenen Treiber, alle anderen speziell SATA und IDE sorgen dafür, dass die Snapshots nicht mehr sauber funktionieren.

OK, das müsste dann ja gehen:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda2 during installation
UUID=9f8a5461-c328-43bb-8b75-c43182c1433a /               ext4    discard,relatime,errors=remount-ro 0       1
# swap was on /dev/vda1 during installation
UUID=12b072a2-0d6c-4395-ba64-773226745b8f none            swap    sw              0       0
# fcw: 2016-02-23: storagespace dauerhaft einbinden:
# 46.38.248.199:/vol-62135-2    /mnt/storagespace.old   nfs     defaults        0       0
# fcw: 2017-07-25: neuen storagespace-Typ gebucht und hier eingebunden, alter (s.o.) verfallt Ende Juli 17
# fcw: 2019-07-31: nolock dazu, defaults ersetzt
46.38.248.210:/voln12345a1      /mnt/storagespace       nfs     rw,suid,dev,exec,auto,nouser,async,nolock       0       0

Ich stells gleich mal um...

... OK, hat geklappt.

fstrim /

hat den Server dann neu gestartet und jetzt lese ich:

Zitat

Speichernutzung: vda: 114 GiB von 312 GiB belegt

So, bisher hat es geklappt. Ist jetzt auf 20.04

Ich hab bei der Installation die bisherigen Konfigurationsdateien beibehalten, aber bei /etc/default/postfwd gab es einen Fehler:

Job for postfwd.service failed because the control process exited with error code.
See "systemctl status postfwd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript postfwd, action "start" failed.
● postfwd.service - Postfix firewall daemon
Loaded: loaded (/lib/systemd/system/postfwd.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2023-11-25 22:29:29 CET; 10ms ago
Process: 30490 ExecStart=/usr/sbin/postfwd $ARGS --daemon --file $CONF --interface $INET --port $PORT --user $RUNAS --group $RUNAS --pidfile $PIDFILE (code=exited, status=25)


Nov 25 22:29:29 ew6.org postfwd2/master[30490]: postfwd2 1.35 starting
Nov 25 22:29:29 ew6.org postfwd[30490]: Pid_file already exists for running process (1250)... aborting
Nov 25 22:29:29 ew6.org systemd[1]: postfwd.service: Control process exited, code=exited, status=25/n/a
Nov 25 22:29:29 ew6.org postfwd2/cache[1251]: 2023/11/25-22:29:29 Server closing!
Nov 25 22:29:29 ew6.org postfwd2/policy[1252]: 2023/11/25-22:29:29 Server closing!
Nov 25 22:29:29 ew6.org postfwd2/master[1250]: warning: Use of uninitialized value $send in scalar chomp at /usr/sbin/postfwd line 367.?
Nov 25 22:29:29 ew6.org postfwd2/master[1250]: warning: can not open socket to 127.0.0.1:10040: 'Connection refused' 'IO::Socket::INET: connect: Connection refused'?
Nov 25 22:29:29 ew6.org postfwd2/master[1250]: postfwd2 1.35 terminating...
Nov 25 22:29:29 ew6.org systemd[1]: postfwd.service: Failed with result 'exit-code'.
Nov 25 22:29:29 ew6.org systemd[1]: Failed to start Postfix firewall daemon.

Muss ich mir noch genauer anschauen. PHP lauft noch auf 8.0 also hat einfach beibehalten, werde ich dann auf 8.1 setzen.

Ach und Dovecot ist nicht von alleine gestartet, das muss ich auch noch erforschen. Aber manuell gestartet lief er dann.

Dann lösche ich den Snapshot von 18.04 und mache einen von jetzt mit 20.04 und gehe gleich auf 22.04...

Das lief auch wieder durch, dieses Mal aber mehr Fehler, erst mal proftpd (nicht sofort wichtig) aber auch Dovecot, dort steht im dovecot.log:

Nov 26 00:49:26 imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): error:25066067:DSO support routines:dlfcn_load:could not load the shared library: filename(libproviders.so): libproviders.so: cannot open shared object file: No such file or directory, error:25070067:DSO support routines:DSO_load:could not load the shared library, error:0E07506E:configuration file routines:module_load_dso:error loading dso: module=providers, path=providers, error:0E076071:configuration file routines:module_run:unknown module name: module=providers: user=<>, rip=75.2.93.42, lip=1.2.3.4

Und ich kann auch keine Mails abholen. Senden (Postfix) geht immerhin. Apache und PHP (immer noch 8.0) auch.

Ich hatte in der Zwischenzeit schon in einem anderen Forum, das ich für Dovecot eher passend wähnte gefragt:
dovecot 2.3.21 - Fehler nach Ubuntu Update auf 22.04: Error: Failed to initialize SSL server context

Leider bisher ohne Lösung

Ich bin schon die halbe Nacht und den ganzen Tag am probieren, morgen muss E-Mail aber wieder laufen, ein Kunde nutzt das für sein Büro sehr intensiv.

Wenn ich jetzt den Snapshot von heute Nacht nach dem Update auf 20.04 zurück spiele, dann gehen sicher einige Mails von heute verloren, nicht so toll.

Kann es vielleicht am Postfix firewall daemon (postfwd) liegen? Da hatte ich ja eine Fehlermeldung...