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:

    Quote

    Speichernutzung: vda: 250 GiB von 312 GiB belegt

    Aber df zeigt:

    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:

    Quote

    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?

    Eine Möglichkeit zum Speicherplatz erweitern wäre sonst ein Storage Space um ein paar Euro im Monat, den kannst du dann zum Server mounten, habe selbst einen Storage Space, kann dir dazu aber kaum aus Erfahrung berichten, da ich den Fall noch nicht hatte. Mein Storage Space ist gemountet und dient nur als externer Speicher.

    Boote in ein Rescue System (wichtig wäre ein möglichst aktueller Kernel, du kannst z.B. ein up-to-date GRML ISO hochladen) und lass ein fstrim über das Dateisystem laufen, damit die ungenutzten Blöcke auch im Host freigegeben werden.


    Mit SCSI als Storagetreiber würde es auch unter Ubuntu 18.04 funktionieren. Wie ich kürzlich von anderen Usern hier lernen durfte, geht's mit neueren Kerneln auch mit virtio. Unter Ubuntu 18.04 höchstwahrscheinlich dann noch nicht.

    fstrim schon ausgeführt?


    apt clean schon gemacht?


    du -sh | sort -h gibt auf der Konsole auch Auskunft darüber, wo sich die größeren Dateien versammeln.


    Oder man sucht sie gezielt:


    find / -size +500M


    Wenn Docker läuft, auch mal mit dafür geeigneten Kommandos dort aufräumen.


    snap ist auch ein Speicherfresser unter ubuntu.

    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 /

    Quote from 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 /

    Code
    /#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:

    Quote

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

    Quote from franc

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

    Mit Vorsicht. Wenn Dein /etc/fstab UUIDs mountet und keine Devicepfade, wir es wohl klappen, wenn der Kernel es unterstützt. Dein Ubuntu 18.04 sollte dafür jung genug sein.


    Hast Du hingegen bspw /dev/sda7 oder /dev/vda7 in der fstab stehen, gibt es etwa das Root-FS nicht mehr, weil das Device nach der Umstellung nicht mehr existiert (es heißt ja dann anders). Der Server bootet dann aber in aller Regel wieder, wenn Du ohne sonstige Änderungen zurück auf vda umstellst.


    In so einem Fall solltest Du zuerst Deine fstab auf UUIDs umstellen. https://linuxopsys.com/topics/…tions-using-uuid-in-linux


    lvm wäre davon übrigens auch nicht betroffen.

    Außer das im schlimmsten Fall die HD beim booten nicht gefunden wird sollte nichts passieren.

    Im dem Fall zurückstellen und gut.

    Ein anderer Festplattencontroller löscht ja nicht automatisch die angeschlossen Festplatten.


    Dennoch Backup hilft.

    OK, das müsste dann ja gehen:


    Ich stells gleich mal um...

    ... OK, hat geklappt.

    fstrim /

    hat den Server dann neu gestartet und jetzt lese ich:


    Quote

    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:


    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:

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

    franc : Kommt hier die Standardversion aus dem Canonical-Repository von dovecot zum Einsatz oder die Upstream-Version von https://repo.dovecot.org/ (hier gibt es leider immer noch keine Jammy-Pakete, aber die Focal-Pakete sollten laufen)?

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

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