Beiträge von Sumeragi

    Die IPs aus den Beispielen stammen aus einem reservierten Netzbereich für Dokumentation. Das würde das Listing bei Spamhaus erklären. Ich würde daher sagen das ist Spam.


    Bei dem "passed thru" würde ich sagen, dass die Mail durchgelassen wird. Wenn es jedoch keine weitere Zustellung gibt und auch nichts in der Queue hängt, wird die Zustellung vermutlich doch abgelehnt worden sein. Bei mir konnte ich in den Logs keine derartigen Einträge finden. Kann dies somit nicht selber prüfen.

    Die Beschreibung ist ja, dass das Dashboard langsam sei und Untermenüs schnell gehen. Die Statistiken wären ja ein Untermenü.


    Auf dem Dashboard werden zwar Speicherplatzverbrauche angezeigt, dies geschieht aber nicht "live".

    Der Speicherplatzverbrauch für das Home Verzeichnis wird afaik aus /opt/pdadmin/tmp/du.txt ausgelesen. Die Datei wird per Cronjob aktualisiert. Die Mail Quota wird aus den dovecot Dateien ausgelesen. Also keine rechenintensiven Vorgänge.


    Ich konnte ein solches Verhalten bisher auch nicht beobachten. Da dies bisher kein anderer beobachten konnte, würde ich ein allgemeines Problem durch das Update ausschließen.

    Schön wäre es wenn man die genauen Schritte zur Reproduktion des Fehlers bekäme. Möglicherweise ist nicht jedem Nutzer bekannt was bei

    Wird das RCM-Update manuell via dem Shell-Skript im SE-Ordner gemacht

    zu tun ist. Dies erhöht somit die Schwierigkeit für helfende Nutzer und mindert gleichzeitig die Chance auf Hilfe 8)


    ERROR: SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client

    Der Fehler hängt mit MySQL 8 und der verwendeten PHP Version zusammen (kann man auch googlen). Daher taucht der Fehler auch nur bei Reihe 8 auf. Ich kann das Verhalten ebenfalls bei einem Update der Reihe 8 reproduzieren:



    Die Warning Meldung kann behoben werden, in dem man

    PHP: /usr/local/pd-admin2/htdocs/roundcubemail/config/config.inc.php
    'mime_types' => '/usr/local/pd-admin2/httpd-2.4/conf/mime.types'

    in das Array einfügt. Dies ist aber nicht ursächlich für die Fehlermeldung.


    Relevant sind bei dem Update die Zeilen 1447-1448 aus se-update.sh:

    Code
    $T1523594                                                                                                                                                                                        $T1524289

    Dabei werden lediglich die Skripte ticket-1523594.sh und ticket-1524289.sh aus dem SE Update Ordner ausgeführt. Relevant hierbei ist das erste Skript. Führt man dies manuell aus, erhält man die Fehlermeldung aus dem SE Update. In dem Skript wird in Zeile 39 (Update Funktion)

    Code
    ln -snf $INST/bin/php-7.3-cli ${RCM}/bin/php

    gesetzt. PHP 7.3 hat jedoch Probleme mit der Authentifizierungsmethode bei MySQL 8. Es muss hier PHP 7.4 verwendet werden. Also einfach die Zeile in

    Code
    ln -snf $INST/bin/php-7.4-cli ${RCM}/bin/php

    ändern und siehe da

    Bash
    $ ./ticket-1523594.sh
    mysql: [Warning] Using a password on the command line interface can be insecure.
    mysql: [Warning] Using a password on the command line interface can be insecure.
    What version are you upgrading from? Type '?' if you don't know.
    Executing database schema update.
    NOTICE: Update dependencies by running `php composer.phar update --no-dev`
    This instance of Roundcube is up-to-date.
    Have fun!
    mysql: [Warning] Using a password on the command line interface can be insecure.
    Ticket_2019102267002761 returned true

    Das Skript läuft durch.

    MPW=$(cat /opt/pdadmin/etc/mysql_rootpw.conf)

    /usr/local/pd-admin2/bin/mysql -e "set password for root@localhost=password('$MPW');"


    Hier muss dann mit "ALTER USER" das Passwort gesetzt werden, was dann auch schließlich klappt!

    Das stimmt so nicht. SET PASSWORD kann bei MySQL 8 verwendet werden. Die Empfehlung lautet aber ALTER USER zu verwenden.

    Bei der MySQL 5.7 Dokumentation wird angeführt, dass SET PASSWORD mit =PASSWORD('auth_string') in MySQL 8.0 entfernt wird und dann nicht mehr zulässig ist. Dies ist so auch im Manual für MySQL 8.0 angegeben und erklärt dann auch den Fehler. Die Zeile ist für ein Upgrade auf MySQL 5.7 geeignet, nicht aber für ein Upgrade auf MySQL 8.0. Daraus resultieren dann auch Folgefehler... Dies fiel bei mir nicht auf, da eben der Dienst nicht richtig startete und ich danach alle weiteren Schritte händisch gemacht hatte.


    Use of uninitialized value $exists in concatenation (.) or string at /root/mysql_privileges.pl line 121.

    vadmin localhost --

    -- create user 'vadmin'@'localhost' identified by 'fhajfh493^F*Yhvndkk-3i' --

    -- update mysql.user set Password=? where user=? and host=? --

    DBD::mysql::st execute failed: Unknown column 'Password' in 'field list' at /root/mysql_privileges.pl line 49.

    Schaut man sich einmal MySQL 8 an, gibt es in der mysql.user Tabelle keine Spalte mit Password mehr. Diese lautet nun authentication_string, was dann auch die Fehlermeldung erklärt :)


    Es scheinen mir eher kleine Anpassungen notwendig, um ein automatisiertes Upgrade auf MySQL 8.0 durchführen zu können. Im Zweifelsfall sollten manuelle Schritte (wie hier) aber auch gehen.

    In der httpd.conf finde ich aber keinen Hinweis auf die 0.0.0.0 Adresse.

    Die Adresse 0.0.0.0 bedeutet, dass der Dienst auf keinem spezifischen Interface lauscht. Also nicht an einer IP-Adresse gebunden ist.

    grep readproc

    567 ? S 0:09 readproctitle service errors: ...ort enabled. ELF support enabled. Mail files support enabled. OLE2 support enabled. PDF support enabled. SWF support enabled. HTML support enabled. XMLDOCS support enabled. HWP3 support enabled. Self checking every 600 seconds. ./run: line 12: test: : integer expression expected httpd: no process found rm: cannot remove '/usr/local/pd-admin2/httpd-2.4/logs/httpd.pid': No such file or directory

    Schaut man einmal in /service/apache24/run sieht man die Zeile

    Bash
    rm /usr/local/pd-admin2/httpd-2.4/logs/httpd.pid

    Zum Zeitpunkt der Ausführung war die Datei httpd.pid nicht vorhanden, was dann zu einem Fehler führt. Ist aber nichts bedenkliches.


    Die genaue Ursache für das Verhalten kann unterschiedliche Gründe haben. Oft ist es wenn z.B. KeepAlive On konfiguriert wurde. Dann bietet der Apache persistente Verbindungen für HTTP Anfragen an. Wenn dann noch KeepAliveTimeout hoch gesetzt wurde, kann dies das Beenden eines httpd-Prozesses verhindern/verzögern und somit den Neustart stören.

    Ich habe kürzlich das Upgrade von Reihe 6 auf 8 gemacht. Benutzt habe ich dazu das Skript


    http://download.pd-admin.de/mysql_upgrade.sh


    Es gab dabei nur ein paar Fallstricke.


    In meiner my.cnf war query cache konfiguriert. Dies ist in MySQL 8 entfernt worden. Durch die enthaltenen Zeilen startete der MySQL Dienst nicht, was wiederum das Skript bzw. SE Update abbrach. Nachdem das behoben war, habe ich die letzten Schritte manuell ausgeführt.


    Dann wurden die Passwörter der DB Nutzer nicht richtig gesetzt. Es war kein Login möglich. Auch hier hatte ich nachgebessert und einmal bei allen Nutzern die Passwörter neu gesetzt.


    Letztlich wurden roundcubemail und phpmyadmin bei mir noch mit PHP 7.3 ausgeführt. PHP 7.3 hat Probleme mit caching_sha2_password. Nach Umstellung auf 7.4 war alles ok.


    Abgesehen davon läuft alles andere absolut problemlos.

    Ich nehme an dies ist historisch bedingt, da es ja lange noch die Reihen 1-3 gab. Reihe 1 war noch mit MySQL 4.x. innodb wird erst seit MySQL 5.5 als Standard verwendet.


    myisam soll schneller sein als innodb und weniger Speicherplatz benötigen. Kann also durchaus von Vorteil sein.

    Offenbar ist auf dem Server die WAF aktiv. Dazu dann die Regeln für pd-admin, was letztlich zu dem Verhalten bzw. der Meldung führte. Eventuell sind die Regeln unter


    /usr/local/pd-admin2/httpd-2.4/conf/rules.d/002-pda-protect-customer-login.conf


    zu scharf oder ungenau definiert. Vermutlich hilft da erst einmal etwas testen mit geänderten Regeln.

    Ich hoffe ich poste bei den ganzen Keys die da als Ausgabe kommen, nichts sicherheitsrelevantes. Wenn ja, bitte löschen bzw. zensieren.

    Wenn man nicht weiß was man postet, sollte man es vielleicht auch nicht unbedacht posten ;) Mit dem Befehl wird der öffentliche Schlüssel des Zertifikats abgefragt. Da gibt es nichts sicherheitskritisches. Dies kann praktisch jeder machen, der den Hostnamen bzw. die IP des Servers hat.


    Es scheint jedenfalls überall das gleiche Zertifikat für HOSTNAME eingerichtet zu sein. Die Ausgaben von Port 25, 465 und 587 sind bei diesem Problem irrelevant, da es ja um ein Problem beim Abrufen von Mails geht.


    Es kommt das neue LE Root Zertifikat ISRG Root X1 zum Einsatz. Ist der Mail-Client oder das Betriebssystem vielleicht veraltet und unterstützt/kennt dieses Zertifikat nicht? (siehe Kompatibilität)

    Ansonsten käme mir noch das Stichwort "Internet Security Suite" in den Sinn. Manche dieser Anwendungen schalten sich, um Mails beim Abruf/Versand auf Gefahren zu prüfen, dazwischen. Das kann auch Fehler in Bezug auf das Zertifikat bzw. die Zertifikatskette verursachen.

    Zumindest deutet "Ergebnisse unvollständig" auf eine Unstimmigkeit hin. Das kann aber auch daran liegen, wenn das Zertifikat auf server01.domain1.de läuft, die Domain im MX mail.domain.de eingetragen hat. Ich meine dann bemängelt es ssl-tools.de ebenfalls.


    Was genau da fehlerhaft sei kann man aber nicht sagen. Auf dem Screenshot sieht man leider nur den mittleren Teil der Ausgabe von https://de.ssl-tools.net/mailservers/ - nämlich die Ausgabe welcher Server für eingehende Mails zuständig ist. Dabei darf man "eingehend" nicht mit "abrufen" verwechseln. Bei "eingehend" ist der qmail-smtpd Dienst auf Port 25 gemeint. Das Abrufen von Mails vom Server erfolgt jedoch über Dovecot. Hier sind also unterschiedliche Dienste zuständig. Bei qmail kann daher alles OK sein und bei Dovecot ein Problem vorliegen.


    Die Testseite bringt daher leider bei dem geschilderten Problem nichts.

    Es ist jetzt natürlich schwierig für Außenstehende das Problem korrekt zu analysieren. Auf welchem Port wurde denn da getestet? Da starttls verfügbar scheint, würde ich jetzt auf Port 25 tippen. Das hat nur gar nichts mit dem Abruf von Mails zu tun. Für POP3 wird 995 und IMAP 993 verwendet.


    Ich würde dies lieber auf der Shell testen:

    Code
    echo "" | openssl s_client -servername $server -connect $server:$port | openssl x509 -noout -dates -text

    Für $server den Hostnamen und für $port Port 993 oder 995 verwenden. Man kann auch Port 465 für den Versand damit prüfen.


    Der Vollständigkeit halber hier auch der Befehl für Port 25 oder 587. Dort muss im nur ein -starttls smtp hinzugefügt werden:

    Code
    echo "" | openssl s_client -servername $server -starttls smtp -connect $server:$port | openssl x509 -noout -dates -text

    Mir ist noch eine Abweichung aufgefallen: Beim Syntax Highlighting für Quellcode wird mir nur noch "Automatisch" und "Keine" angezeigt. Vor dem Update konnte man zwischen Sprachen wählen. Das Highlighting funktioniert soweit. Das Fehlen ist für mich daher eher ein "kosmetischer Fehler".

    Ich greife dieses Thema hier noch einmal auf:


    Bei Ausführung des Skriptes kam es bei mir immer zu einem Segmentation Fault. Ich habe mir den cordump dazu angeschaut und offenbar verursacht dies PHP 5.2. Da diese Version EOL ist, habe ich diese einfach im Skript ausgenommen.


    Des Weiteren tritt der Fehler

    Code
    Fatal error: Uncaught Error: Undefined constant "STDIN" in /usr/local/pd-admin2/php-8.0.16/lib/php/PEAR/Frontend/CLI.php:303

    bei allen PHP 8.x Versionen auf. Offenbar hat sich hier etwas gegenüber PHP < 8.x geändert. Was genau ist mir bisher nicht klar... Als workaround kann man

    Code
    define('STDIN',fopen("php://stdin","r"));

    in der CLI.php eintragen. Dann klappt eine Installation. Nur wird dieser workaround mit jedem PHP Update auch wieder verschwunden sein.