Beiträge von Sumeragi

    Bei mir sieht es so aus:

    Code
    $ grep backup_dir /opt/pdadmin/etc/pdadmin.conf
    $backup_dir = '/home/backup';

    Vielleicht hilft dies ja mehr weiter.

    Bei mir gab es nach dem Update ein Fehler beim Starten von dovecot:

    Code
    Mar 25 19:00:31 xyz dovecot: imap-login: Fatal: Unknown ssl_protocols setting: Unrecognized protocol 'SSLv2'
    Mar 25 19:00:31 xyz dovecot: master: Error: service(imap-login): command startup failed, throttling for 32 secs

    Ursache war folgende Zeile in der Datei /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/conf.d/10-ssl.conf:

    Code
    ssl_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1

    SSLv2 wird mit der neuen openssl Version nicht mehr unterstützt. Das Problem ist einfach zu lösen, in dem man !SSLv2 aus der Zeile entfernt.


    Ansonsten kam es zu keinen Problemen nach dem Update. Verwendet wird die SE 6 mit Apache 2.4 auf CentOS 7.

    Wenn man in die man page von ulimit schaut:

    Code
    -u The maximum number of processes available to a single user.

    Dies sollte somit das Prozesslimit aus dem Angebot des Nutzers sein. Das Limit 64 ist imho schon sehr hoch. 256 wäre extrem hoch. 32 sollte als Standardwert ausreichend sein. Sind den ausreichend Ressourcen für ein derart hohes Limit vorhanden? Ein höheres Limit bedingt nicht eine höhere/bessere Performance.


    Oder laufen bei dem Nutzer tatsächlich mehr als 64 Prozesse? Wenn nicht, wird das Prozesslimit nicht die Ursache gewesen sein.

    Der MySQL 5.5 Ordner wird umbenannt (Schritt 4.), dann die neue Version kopiert und die Dumps eingespielt. Sollte dabei etwas schief gehen, kann man /home/mysql löschen und den gesichterten MySQL Ordner zurück umbenennen.

    Sonst wird ja nichts weiter verändert. Unter /services/mysql bleibt alles identisch und innerhalb der SE sind die Verweise auf MySQL Symlinks auf /home/mysql

    Lediglich die my.cnf bleibt innerhalb der SE. Da musste ich dann noch den strict mode (sql-mode="") deaktivieren. Ansonsten sind die Schritte eigentlich ziemlich simpel und in meinem Augen eine sichere Sache. Für Endnutzer kann es lediglich zu einer längeren Ausfallzeit kommen, abhängig von der Anzahl und Größe der einzuspielenden Dumps.

    Nur wird nicht jedes Mal ein neuer Account erstellt. Oder zumindest habe ich dazu kein Hinweis gefunden. Dies passiert nur bei initialer Ausführung.

    Unter /etc/letsencrypt/accounts finden sich bei mir auch nicht unzählige Accounts, sondern nur ein Account.

    Ich frage mich ja, welche Probleme in Bezug auf die Stabilität erwartet/befürchtet werden... In Bezug auf den Updateprozess oder dem Betrieb von MySQL 5.7? Letzteres ist als Reihe schon lange verfügbar. Beim Updateprozess wird lediglich der MySQL Dienst neu installiert und die Daten eingespielt. Der Rest der Serverumgebung bleibt ja identisch.

    Die Informationen sind leider dürftig, um mehr dazu sagen zu können. Hilfreich wäre die vollständige Mail mit dem Fehler. Allein anhand der Fehlermeldung lässt sich das nicht genau sagen.


    Da die Meldung auf ein Problem hinweist, sollten die Meldungen nicht einfach abgestellt werden, sondern besser das Problem analysiert und angegangen werden.

    Der Vorgang ist stark abhängig vom Prozessor. Bei mir sind es gut 4 Minuten für die komplette Ausführung mit einem 4096bit Schlüssel:

    Bash
    $ time /var/qmail/bin/update_tmprsadh 
    [...]
    237,14s user 2,32s system 99% cpu 4:01,68 total
    Bash
    $ find /var/qmail -type l -exec ls -al {} \;
    lrwxrwxrwx. 1 root root 30 30. Mär 2017 /var/qmail/bin -> /usr/local/pd-admin2/qmail/bin
    lrwxrwxrwx. 1 root root 31 30. Mär 2017 /var/qmail/boot -> /usr/local/pd-admin2/qmail/boot
    lrwxrwxrwx. 1 root root 33 30. Mär 2017 /var/qmail/owners -> /usr/local/pd-admin2/qmail/owners

    zumindest einige Ordner sind Symlinks zur Serverumgebung. Also würde ich davon ausgehen, dass diese auch geändert werden (können).

    Ich hatte vor langer Zeit schon das update_tmprsadh angepasst. Möglicherweise wurde es daher bei einem SE Update nicht angerührt? Kann ich aber gerade nicht genau sagen. Aber gut zu wissen, dass die Standardeinstellung nun 4096 Bit zu sein sein.

    Der Fehler hier ist diese Zeile:

    Zitat von nitram70

    Feb 21 09:22:30 raru sendmail[10655]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1

    Der Diffie-Hellman Schlüssel ist zu klein. Der Schlüssel wird für den Handshake benötigt. Da zu klein schlägt dieser fehl.

    Bei qmail in pd-admin wird DH Schlüssel mit 512 und 1024 Bit verwendet. Die Dateien liegen unter /var/qmail/control und heißen z.B. dh1024.pem

    qmail verwendet jedoch nur die beiden Dateien. Eine Datei mit dh2048.pem würde nicht beachtet. Als workaround kann man jedoch in der dh1204.pem einfach ein Schlüssel mit 2048 Bit hinterlegen. Dazu muss in der Datei /var/qmail/bin/update_tmprsadh der Schlüssel statt mit 1024 mit 2048 erzeugt werden. Der Dateiname bleibt gleich.


    Ansonsten kann ich anhand des Logs kein Hinweis auf die unterschiedlichen Ciphers sehen... Und glaube das geht auch am Thread Thema vorbei.


    SSL != TLS


    SSLv3 sollte nicht verwendet werden, da es als unsicher gilt. Siehe z.B. openssl Wiki. Wobei dort noch zu TLS1.0 und TLS1.1 geraten wird. Beide gelten jedoch auch schon nicht mehr als sicher.

    Der Befehl liefert keine Ausgabe. Er bleibt hängen, aber in /var/log/messages zeigt er folgendes an:

    Führt man svscanboot aus erhält man auch keine Ausgabe. Der Service wird in dem Moment aber ausgeführt:

    Bash
    [root@localhost ~]# /command/svscanboot
    ^C
    [root@localhost ~]#

    Sie haben offenbar die Ausführung abgebrochen und dann pstree ausgeführt. Entsprechend ist der Prozess dann nicht mehr vorhanden. Anders sieht dies aus wenn man den Prozess im Hintergrund startet:

    svscanboot wird üblicherweise bei CentOS 7 & 8 per systemd gestartet (siehe pstree im vorherigen Post). Dies ist bei Ihnen nicht der Fall. Stattdessen werden der httpd und mysql_safe direkt von systemd gestartet. Hier würde ich ja glatt vermuten, dass diese als reguläre Dienste (vor-)installiert sind und laufen. Dies stört natürlich dann auch die Dienste, welche von daemontools gestartet werden.

    Was sagt bei Ihnen denn

    Bash
    systemctl status daemontools

    Bei meinem lokalen Testsystem ist nach einem Neustart folgendes aufgetreten:

    Mit journalctl -xe findet sich folgender Eintrag:

    Code
    Feb 18 03:02:40 localhost.localdomain systemd[1751]: daemontools.service: Failed to execute command: Permission denied
    Feb 18 03:02:40 localhost.localdomain systemd[1751]: daemontools.service: Failed at step EXEC spawning /command/svscanboot: Permission denied

    Ursache des Ganzen ist selinux. Dieses lässt den Start von daemontools nicht zu. Deaktiviert man selinux starten die Dienste regulär:

    Ich vermute jetzt einmal, dass dies ebenfalls bei Ihnen die Ursache sein wird.

    In den Log Zeilen ist kein Fehler enthalten. Dies hilft daher leider nicht weiter.


    Ich habe nun auch CentOS 8 bei mir lokal mit VirtualBox installiert. Verwendet wurde das CentOS 8 Boot Image mit der "Minimal Installation". Dort habe ich dann noch folgende Pakete installiert

    Bash
    yum -y install epel-release
    yum -y update
    yum -y install wget patch groff-base make gcc gcc-c++ glibc-devel libstdc++-devel zlib-devel zlib.i686 libgcc.i686 ncurses-libs.i686 glibc.i686 ImageMagick rrdtool net-tools iptables-services libnsl libnsl.i686 libxcrypt libxcrypt.i686 screen unzip psmisc nmap unzip

    und anschließend die pd-admin Installation durchgeführt:

    Bash
    screen -L ./install-all.sh --unattended --email mail@domain.de -s 8

    Die Installation führe ich mit "screen -L" aus, da ich so die komplette Bildschirmausgabe in einer Datei loggen und ggf. nach Fehlern durchsuchen kann. Aber auch hier kommt es bei mir zu keinerlei Problemen. Die Dienste starten ganz normal. Auch in den Logs sind keine Fehler zu finden.

    Wenn spam_passthru=no gesetzt wird bedeutet dies, als spam erkannte Mails werden nicht an den Nutzer durchgelassen. Bei no wird bei Erreichen des in spamassssin konfigurierten Scores geblockt. Daher muss dies auf yes stehen.


    Da spam_hits nicht in simscan enthalten ist und bei mir auch nicht in simcontrol enthalten war, wird dies nichts aktiv sein.


    Die Version 1.4.0 ist wohl die aktuellste Version.

    Auch wenn das Thema schon was älter ist greife ich es noch einmal auf :)

    Wie ist den die in den aktuellen Versionen korrekte Einstellung für genau diesen Wunsch? In der Standardauslieferung ist ja spam_passthru=yes generell erlaubt.


    Hat hier jemand dir richtige Konfiguration raus gefunden, oder geht das so gar nicht?

    Setzt man spam_passthru=no, werden Mails mit einem Score von 4.9 oder höher abgelehnt.


    Es gibt kein implizites spam_passthru=yes. Sprich wenn man dies weglässt, werden Mails ebenfalls abgelehnt. Man muss spam_passthru=yes setzen, damit Mails zwischen 4.9 und 10.0 noch durchgelassen werden. Am Beispiel sollte dies dann so aussehen:


    :clam=yes,spam=yes,spam_passthru=yes,spam_hits=10.0


    Bei mir sieht dies so aus:


    :clam=yes,spam=yes,spam_passthru=yes,spam_hits=9.5,attach=.vbs:.lnk:.scr:.wsh:.hta:.pif


    Ich war leider etwas vorschnell... Offenbar ist das Flag "spam_hits" nicht aktiviert. Ich habe ein wenig weiter getestet:

    Bash
    $ env QMAILQUEUE=/var/qmail/bin/simscan SIMSCAN_DEBUG=4 /var/qmail/bin/qmail-inject info@domain.de < testmail.txt simscan: cdb looking up
    simscan: cdb for found clam=yes,spam=yes,spam_hits=15.0
    simscan: pelookup clam = yes
    simscan: pelookup spam = yes
    simscan: pelookup spam_hits = 15.0
    simscan: unimplemented flag spam_hits = 15.0
    simscan: starting: work dir: /var/qmail/simscan/1581692945.275873.4589
    [...]

    Offenbar muss simscan mit --enable-spam-hits kompiliert werden. Das müsste ich mir erst einmal genauer anschauen.

    Ich habe die bekannte Liste an Paketen verwendet, welche auch für CentOS 7 angegeben wird. Lediglich groff musste angepasst werden und die beiden genannten Libs zusätzlich installiert werden.


    Nur weiß ich eben nicht, ob es nicht doch Unterschiede ziwschen dem B&K Image und Ihrem Image gibt. Ich hatte den Eindruck, dass bei Ihrem Image das epel Repository nicht installiert/aktiviert war da Sie schrieben dies gäbe es unter CentOS 8 nicht mehr.