Beiträge von Sumeragi

    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.

    Micropython basiert auf Python3, ist nur reduziert und für Microcontroller, wie den ESP32, angepasst. Die Sprache an sich ist aber Python.

    Ich selbst habe mich nur grob mit Python beschäftigt. Gibt zum lernen aber etliche Docs und auch Apps. Python scheint aber sehr einsteigerfreundlich zu sein, was die derzeit hohe Beliebtheit zeigt.

    Wie einfach oder schwer eine Umsetzung von PHP auf Python ist hängt sicherlich sehr vom Code selbst ab...

    Ich erhalte auch keine Benachrichtigungen. Ab der 10ten Mail liest man diese eh nicht mehr. Wichtiger ist da eine regelmäßige Kontrolle, des Logs auf Fehler.


    Ein Melden von Angriffen habe ich nicht eingerichtet. Prinzipiell halte ich dies aber schon für sinnvoll, da so die eine oder andere kompromittierte Maschine aus dem Verkehr gezogen werden kann.


    Blocklisten wie blocklist.de oder abuseipdb.com bieten die Möglichkeit IPs zu überprüfen oder Komfortfunktionen wie eine Statistik zu den eigenen Meldungen. Wobei man dies auch selbst durch die Logs auswerten könnte.

    Ich denke nicht, dass für die Traffic Statistik ein einfaches "SELECT ... date < xxxx-xx-xx" ausgeführt wird. Die Queries werden etwas komplexer sein. Schließlich wird bei Aufruf der Traffic Seite einmal der gesamte Traffic nach Monaten, sowie der Traffic vom aktuellen und letzten Monate, sortiert nach Endkunden, aufgelistet. Beim Top 10 Button wird dies sicher noch komplexer sein.


    Bei xx Endkunden, ~700 Domains, ~1600 vhosts und über 1,2mio Zeilen in der Tabelle traffic_new kann natürlich die Verabreitung bei Seitenaufruf insgesamt einfach sehr lange dauern.

    Meine erste Vermutung ist, dass die DB Query zu lange benötigt, so dass es zu dem Timeout kommt. Während der Ausführung sollte man sich parallel die MySQL Prozessliste anscchauen. Vielleicht findet sich da eine sehr lang laufende Query. Diese kopiert man sich und kann sich die Query separat mit "explain" anschauen und analysieren. Eventuell lässt sich die Query so optimieren.


    Bei mir sind es nur rund 60.000 Einträge in der Tabelle traffic_new. Ich kann ein solches Verhalten nicht reproduzieren.