Posts by franc

    ...

    Ich betreibe auch seit vielen Jahren meinen eigenen Mailserver, und habe den gut im Griff. ...

    Eine Frage dazu, etwas OT: hast du Probleme, dass die Microsoft Mailserver deinen kleinen Mailserver als Spam bannen, ohne dass du irgendetwas falsch eingestellt hättest?

    Ich hab das nämlich und fülle dann immer wieder, alle paar Monate (manchmal nur Wochen) so ein dämliches Formular aus, dann antwortet ein Automat, ich zurück mit "Please unban!" und manchmal passiert es gleich, manchmal nach ein paar Mal dem Automat (oder einer/m ebenso dämlichen MA) antworten wird es dann wieder manuell "mitigated"also freigeschaltet, das hält dann wieder eine Weile.

    Hast du das Problem auch?

    Also mit ...@outlook.com, ...@hotmail.com (wer hat denn das noch???) oder wie sie alle heißen, die MS-Adressen.

    OK then, jetzt mit mehr Zeit :)

    Also mein Server ist ein Ubuntu 22.04 LTS, ich habe Postfix 3.6.4 im Einsatz (und Dovecot 2.3.21, was hier mit aber ja nichts zu tun hat).

    Ich hatte früher mal bind9 in Verwendung, da war ich aber noch bei Hosteurope, da hatte ich in der Zone als autoritativen ersten DNS meinen Server eingetragen und als zweiten DNS konnte ich einen von HostEurope nutzen. Dann bin ich mit der Domain zu Tecspace (und dem Server zu Netcup) aber bei tecspace kann man im Zonenintrag nur beide DNS von Tecpsace nehmen oder zwei eigene, aber nicht nur den zweiten von Tecspace (so hab ich mir das aufgeschrieben damals).

    Damals hatte ich auch mit eigenen dynamischen Domains (als Ersatz für dyn.com) herumprobiert, hatte aber nicht funktioniert (brauche ich auch nicht mehr, die myfritz DynDNS Dienste funktionieren zuverlässig).


    Mein Problem ist, dass ich mich nicht ständig mit dem Server befasse, sondern immer nur wenn was anliegt, dann forsche ich, stelle neu ein usw und dann ist wieder gut. Dann komme ich vielleicht mal ein, zwei Jahre später wieder ans selbe Thema und hab das meiste vergessen :( Klar, ich schreib mir auf was geht, aber geläufig ist es mir dann oft nicht mehr so.
    Die DNS Thematik habe ich auch nie vollumfänglich durchblickt, damit habe ich schon viel Zeit verbraten (zB wartend, dass eine Änderung endlich repliziert und es kommt nicht, weil ich was falsch eingetragen hatte, oder sogar auch mal weil Tecspace einen Fehler hatte).

    Resolver, nicht Autoritativer DNS Server...

    Den Unterschied begreife ich zB erst jetzt.

    Also muss ich meinen bind9 als Resolver, nicht als Autoritativen DNS Server nehmen (in der Zone meiner Domain stehen ja auch die NS von tecspace als autoritative NS und nicht mein Server).


    Also habe ich nach einer Anleitung gesucht, wie man auf Ubuntu 22.04 mit bind9 den lokalen DNS als Resolver nutzt und das gefunden:
    Set Up Local DNS Resolver on Ubuntu 22.04/20.04 with BIND9

    Danach bin ich also vorgegangen, also in die /etc/bind/named.conf.options unter options dazu:


    Code
     version "not currently available";
     recursion yes;
     allow-recursion { 127.0.0.1; };
     querylog yes;

    In /etc/systemd/resolved.conf hab ich rein:

    Code
    DNS=127.0.0.1

    Mit dem Befehl dann resolvconf angewiesen den lokalen zu nehmen:

    Code
    (echo 'nameserver 127.0.0.1' ; ) | sudo resolvconf -a eth0.manual

    und es scheint zu funktionieren:



    Ich hab dann den spamhaus Eintrag wieder entkommentiert in der main.cf von Postfix ([2..9] anstatten ..11 wg. PBL, siehe bei Heinlein:(


    Code
    ...
    smtpd_recipient_restrictions =
    reject_rbl_client zen.spamhaus.org=127.0.0.[2..9],
    ...

    und jetzt sehe ich im Maillog (/var/log/mail.log) nur noch solche (erwünschte) Spamhaus Einträge:


    Code
    ...
    
    Jul  1 14:14:48 example.org postfix/smtpd[2883345]: NOQUEUE: reject: RCPT from mout-xforward.gmx.net[82.165.159.41]: 554 5.7.1 Service unavailable; Client host [82.165.159.41] blocked using zen.spam
    haus.org; Listed by SBL, see https://check.spamhaus.org/sbl/query/SBL594404;
    ...


    Auf meinem Server selbst stehen aber immer noch in der resolv.conf am Schluss die Nameserver von Netcup drin:

    Code
    $ cat  /run/systemd/resolve/resolv.conf
    # ...
    nameserver 127.0.0.1
    nameserver 46.38.225.230
    nameserver 46.38.252.230
    search .

    Ich nehme aber an, das macht nichts.

    Resolver, nicht Autoritativer DNS Server -> da wo du dein Postfix hast, das ist der DNS Server, den Postfix benutzt um die Empfänger aufzulösen.


    Logfiles?

    Also es ist nicht angekommen, sehe ich mit Hilfe des Logs im Maileingang. Im Log lese ich:


    Code
    ...
    Jun 19 10:53:19 myserver postfix/smtpd[1899775]: connect from mout.gmx.net[212.227.15.19]
    Jun 19 10:53:19 myserver postfix/smtpd[1899775]: discarding EHLO keywords: DSN
    Jun 19 10:53:19 myserver postfix/smtpd[1899775]: Anonymous TLS connection established from mout.gmx.net[212.227.15.19]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDH
    E (P-256) myserver-signature RSA-PSS (2048 bits) myserver-digest SHA256
    Jun 19 10:53:19 myserver postfix/smtpd[1899775]: discarding EHLO keywords: DSN
    Jun 19 10:53:19 myserver postfix/smtpd[1899775]: NOQUEUE: reject: RCPT from mout.gmx.net[212.227.15.19]: 554 5.7.1 Service unavailable; Client host [212.227.15.19] blocked using zen.spamhaus.org; Error: open resolver; https://check.spamhaus.org/returnc/pub/46.38.225.230/; from=<sender@gmx.de> to=<recipient@mymyserver.org> proto=ESMTP helo=<mout.gmx.net>
    Jun 19 10:53:19 myserver postfix/smtpd[1899775]: disconnect from mout.gmx.net[212.227.15.19] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7
    ...

    Ich erinnere mich, dass ich früher bind9 im Einsatz hatte, aber ich glaube jetzt nicht mehr.

    Wie kann ich denn einen anderen DNS Server verwenden, damit ich spamhaus wieder verwenden kann?

    Ich hab das Problem seit gestern spät abends, da hat sich jemand beklagt, dass er diese Fehlermeldung bekommen hätte, als sie ein Mail zu einer Adresse meines Mailservers (postfix) schicken wollte.

    Ich weiß gar nicht, ob das Mail doch angekommen ist, oder ob es nur eine Fehlinterpretation des Mail-Clients war (wie "tab" in #16 vermutet).

    Jedenfalls hab ich erst mal spamhaus aus der main.cf auskommentiert, aber würde es natürlich lieber weiter verwenden.


    ...

    Wenn ihr einen eigenen Mailserver betreibt, empfiehlt es sich daher, wie bereits in diesem Thread benannt, einen eigenen DNS-Resolver (z.B. Unbound oder Bind 9) zu installieren und zu nutzen, was das Problem für euren Server lösen sollte.

    Ich hab als Domain Provider tecspace, also auch deren Nameserver, wo kann ich denn das umstellen auf einen eigenen DNS (mit bind9)?

    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!

    ...

    ldd /usr/sbin/dovecot

    Das sagt mir irgendwie nichts :(

    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:


    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.

    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

    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.

    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?

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

    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?


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


    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:


    und blkid ergbit:


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

    Code
    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=""

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