Beiträge von franc

Ich hab es gefunden!!!

Mein Fehler natürlich.

Im ganzen Installieren, Deinstallieren habe ich nicht gemerkt, dass dovecot-imapd (und dovecot-pop3d) noch gar nicht installiert waren.

Daher auch keine Fehler und kein offner Port. So einfach eigentlich.

Also ich denke mal, die ursprüngliche, alte Version hatte diesen OpenSSL3 Fehler, dann hatte ich ja die Quellen geändert und die alte Version deinstalliert und erst die Paketquelle von Dovecot genommen, ging ja immer noch nicht (warum weiß ich jetzt nicht mehr) und dann die Ubuntu Quellen genommen, also dovecot-core/focal dabei dann aber das dovecot-pop3d/focal nicht explizit installiert, ich dachte das wird mit core einfach mit installiert.

Im Aptitude (GUI) habe ich es dann gesehen, da stand das auf C (konfiguriert aber nicht installiert). Installiert und ging gleich.

Kamen erst mal ein Satz Mails in meine Clients rein

Ich werde jetzt die anderen Programme angehen, die noch nicht laufen, fail2ban zB, das ist bitter nötig, so viel Bruteforce Versuche, wie da ständig auf den Server (Dovecot zB) einprasseln.

Vielen Dank für eure Hilfe!

Zitat von eripek

...

ldd /usr/sbin/dovecot

#ldd /usr/sbin/dovecot
linux-vdso.so.1 (0x00007fffffbd7000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fd4f8447000)
libdovecot.so.0 => /usr/lib/dovecot/libdovecot.so.0 (0x00007fd4f826b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd4f8043000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fd4f8018000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fd4f7f49000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd4f7f27000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fd4f7f1c000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fd4f7dde000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd4f8536000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd4f7dd9000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fd4f7db3000)

Das sagt mir irgendwie nichts

Zitat von m_ueberall

Nein, es liegt am Wechsel von OpenSSL v1.a.b auf v3.x.y und betrifft nicht nur Dovecot (siehe hier für einen Workaround; übrigens eine der ersten Fundstellen, wenn man bei Google nach der Fehlermeldung sucht).

Das hatte ich auch so ziemlich am Anfang auch probiert, half leider nichts

Die Fehlermeldung habe ich auch nicht mehr, nach Aktualisierung von Dovecot (nach der Dovecot Paketquellenanleitung) und auch nicht mehr nach dem Downgrade (mit den 22.04 Paketquellen).

Ich muss jetzt mal im Thunderbird Protokoll untersuchen, warum ich da gar nicht drauf komme, obwohl ich im dovecot-debug.log unzählige Loginversuche von irgendwelchen Bruteforcern habe...

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

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.

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

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.

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?

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?

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

So, überfällig ist die Aktualisierung auf 22.04. Aber das in einem eigenen Thread:

Root Server Systemupdate - Ubuntu 18.04 auf 22.04 updaten

Auf der SCP > Medien Seite steht bei mir auch: "Es ist eine intensive Speicher-Optimierung notwendig. Diese kann bis zu 6 Stunden 36 Minuten andauern."

Speichernutzung: 260 GiB von 312 GiB belegt

Ist es sinnvoll diese zuerst zu machen, bevor ich mal umschalte, oder hat das miteinander nichts zu tun?

#df
Dateisystem                1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf
udev                         6124224         0   6124224    0% /dev
tmpfs                        1229620       776   1228844    1% /run
/dev/vda2                  320938096  92113616 212499324   31% /
tmpfs                        6148096         0   6148096    0% /dev/shm
tmpfs                           5120         4      5116    1% /run/lock
tmpfs                        6148096         0   6148096    0% /sys/fs/cgroup
12.34.56.78:/voln12345a1 262144000 216090176  46053824   83% /mnt/storagespace
tmpfs                        1229616         0   1229616    0% /run/user/0

Zitat von SCD

Besser sind die UUIDS:

# blkid

Code

/dev/sda1: UUID="12b31a3c-ec0d-4b7d-be81-dd452fc3105e" TYPE="ext4" PARTUUID="a88deea1-01"
/dev/sda2: UUID="da056ebe-49fe-412d-83e2-1436dec92676" TYPE="swap" PARTUUID="a88deea1-02"

Wird zu:

Code

# /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>
UUID=12b31a3c-ec0d-4b7d-be81-dd452fc3105e       /               ext4    usrquota,grpquota,errors=remount-ro     0       1
UUID=da056ebe-49fe-412d-83e2-1436dec92676       none            swap    sw                                      0       0

Wenn das System danach nicht startet kann man einfach wieder auf VIRTIO zurückstellen.

Alles anzeigen

Ich wollte schon einen neuen Thread mit der selben Frage erstellen, da hab ich meinen alten Thread wieder gefunden.

Steht bei mir immer noch auf VIRTIO (statt SCSI). Es steht mal wieder ein do-release-upgrade an, dieses Mal auf 22.04 LTS.

Kann ich denn mal testweise im SCP auf SCSI umstellen und neu starten, oder kann ich dann nicht mehr zurück?
Also kann ich dann, wenn das System nicht mehr startet, einfach wieder auf VIRTIO zurück stellen und dann startet es wieder?

Oder das eine Einwegumstellung?

Ich hab mal in meine fstab rein geschaut:

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

und blkid ergbit:

#blkid
/dev/vda1: UUID="12b072a2-0d6c-4395-ba64-773226745b8f" TYPE="swap" PARTUUID="000bf157-01"
/dev/vda2: UUID="9f8a5461-c328-43bb-8b75-c43182c1433a" TYPE="ext4" PARTUUID="000bf157-02"

/etc/default/grub hat (ohne Kommentare):

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

Zitat von whoami0501

fstrim -a sollte da die Lösung sein.

Ich hatte im SCP die Speicheroptimierung durchgeführt, dauerte ca. 40 Minuten, danach war das System wieder "schlank"
Danach das do-release-upgrade, das lief auch eine Weile, wobei man dabei sitzen muss und immer wieder die bestehenden Konfigurationsdateien erhalten (mit "N") und dann ging alles noch.

Ubuntu 18.04 jetzt

Im Moment bin ich an PHP dran, will die 7.4 haben, Ubuntu 18.04 kommt mit der 7.2. Ein Kunde hätte aber gerne die 7.4 (obwohl es eigentlich egal ist, weil die 7.2 ja auch noch eine Weile gepflegt wird, siehe LTS).

Zitat von franc

So, heute abend gegen 20 Uhr ist es geplant, das do-release-upgrade auf 18.04 von 16.04 aus.

Zuerst dann wieder Systemoptimierung durchführen, bin bei 159 von 312 GB belegt:

df zeigt allerdings nur belegte 54 G an:

#df -h
Dateisystem                Größe Benutzt Verf. Verw% Eingehängt auf
udev                        5,9G       0  5,9G    0% /dev
tmpfs                       1,2G    121M  1,1G   11% /run
/dev/vda2                   307G     54G  237G   19% /
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
cgmfs                       100K       0  100K    0% /run/cgmanager/fs
46.47.47.210:/voln12345a6  250G    104G  147G   42% /mnt/storagespace
tmpfs                       1,2G       0  1,2G    0% /run/user/0

Zitat von m_ueberall

In diesem Fall kann man natürlich beide Schritte kombinieren: Neuen Server anmieten (geht ja auch monatsweise), Snapshot-Abbild mit 14.04-Image transferieren, auf neuem Server alles unter 18.04 zum Laufen bringen (da die neue IP-Adresse nicht im DNS hinterlegt ist, stört das den laufenden Betrieb nicht), und danach DNS-Einträge anpassen. In der Zwischenzeit aufgelaufene Änderungen sind anwendungsspezifisch zu synchronisieren. Dieser Vorgang reduziert eine für Kunden sichtbare Ausfallzeit auf ein Minimum.

So, heute abend gegen 20 Uhr ist es geplant, das do-release-upgrade auf 18.04 von 16.04 aus.

Zuerst dann wieder Systemoptimierung durchführen, bin bei 159 von 312 GB belegt:

Zitat

Es ist eine intensive Speicher-Optimierung notwendig. Diese kann bis zu 54 Minuten andauern.

#systemctl enable rpc.statd
Failed to execute operation: No such file or directory

Hm. Ich glaube ich muss erst mal verstehen, was das ist, "rpc.statd".

Ich habe in der Zwischenzeit in fstab den Parameter eingefügt:

1.2.3.4:/voln12345a1      /mnt/storagespace       nfs     rw,suid,dev,exec,auto,nouser,async,nolock       0       0

also indem ich defaults durch rw,suid,dev,exec,auto,nouser,async,nolock ersetzt habe, also das nolock angehängt habe.

Vermutlich hätte ich das nolock auch ans defaults anhängen können, wollte aber nicht so viel experimentieren, immerhin ist es ein "Produktivserver"

Scheint aber zu gehen - nach Neustart ist er noch da, der storagespace, bis jetzt.

Nach dem netcup letzte Woche die Server runter gefahren hatte geht es wieder nicht.

Was kann ich denn tun, um den storagespace dauerhaft eingebunden zu lassen?

Die eigene Dummheit auch noch bezahlen lassen

Der hat auch zügig geantwortet und geschrieben, dass meine Quota im CCP noch auf 100 GB stünde.

Sowas.

Ich hatte es sicher umgestellt, anscheinend wurde das nicht übernommen, möglicherweise meinem Browser geschuldet.

Jedenfalls habe ich es also noch mal (auf einem anderen Rechner) auf 250 GB gestellt und Zack! geht es auf Anhieb.

df -h zeigt mir 250 GB