Beiträge von Sumeragi

    AFAIK wird DKIM nur für die eingetragene Hauptdomain konfiguriert. Wenn man später über eine Subdomain Mails empfanden, senden und mit der Subdomain als Domain signieren möchte, muss domain.de als TLD und sub.domain.de als Domain bei einem Endkunden eingetragen werden.


    Einziger "Fallstrick" ist hier Lets Encrypt. Für Hauptdomains werden immer Zertifikate für http://www.domain.de und domain.de erzeugt. Bei Nutzung einer Subdomain als Hauptdomain muss es im DNS somit einen A-Record für http://www.sub.domain.de und sub.domain.de geben.

    Es ist schwer zu verstehen, was genau hier das Problem/Ziel ist. Der Titel "... vs ... vs ..." ist auch irgendwie irritierend. Ich denke, dass es hier Verständnisprobleme gibt.

    ich habe pd-admin auf einer Subdomain laufen: sub.example.org

    Es handelt sich dabei dann um einen Full Qualified Domain Name [FQDN]. Dies ist empfohlen für die Nutzung von pd-admin.

    Was mich primär irritiert ist der "leere" Return-Path der Reject Nachricht: Return-Path: <"<>"@sub.example.org>.

    Wie kann ich hier einen sinnvollen Return-Path setzen?

    Bei der Mail handelt es sich um einen Mail-Rückläufer (Bounce Mail). Dieser wird von qmail selbst erzeugt. Der Return-Path, auch Envelope-Sender genannt, ist die Angabe des Absenders während des SMTP-Handshakes. Bei einem Mail-Rückläufer ist der Envelope-Sender immer "leer" bzw. "<>" [Bounce Message]. Dies soll Loops verhindern. Hier ist somit alles korrekt.

    Die ursprüngliche Mail wurde aufgrund der DMARC Richtlinie abgelehnt und kam zurück. Jedoch gibt es keine Mailbox zu dem Absender postmaster@ und es kam zu dem Fehler "Sorry, no mailbox here by that name.". Die ursprüngliche Mail wurde von dem Nutzer mit der UID 1020 erzeugt. War

    Subject: Rejected: Some Subject

    der original Betreff? Ist dies eine Test-Mail gewesen? Oder Spam?

    Und wie handhabt ihr das mit DMARC bei Nutzung der Subdomain?

    Gar nicht. Wozu auch? DMARC nutzt DKIM und SPF. Bei SPF wird die Domain des Envelope-Sender geprüft, bei DKIM wird die Mail signiert. Dies hilft bei der Erkennung von Manipulation der Mail und Authentifizierung des Absenders. DMARC erweitert dies um Richtlinien und Berichte. Ein guter Artikel dazu findet sich auf easydmarc.com.


    Das Einzige was ich bisher festgestellt habe, was relevant ist, ist ein SPF für den Hostnamen von pd-admin. Bei Weiterleitungen wird durch SRS der Envelope-Sender angepasst. Dann steht dort @sub.example.org. Der Empfänger prüft bei SPF dann diese sub.example.org. Bei Weiterleitungen an zum Beispiel Gmail macht ein fehlender SPF dann Probleme. Lösen lässt sich dies durch Setzen von sub IN TXT v=spf1 a -all in der Zone von example.org.

    Kann ich die Subdomain (sub.example.org), die ich für die pd-admin Installation nutze ("Hostname für pd-admin") selbst regulär in pd-admin anlegen und verwalten?

    Falls JA würde ich einen separaten DKIM Eintrag für sub.example.org erzeugen und nutzen (sofern die Mail Daemon Mails signiert auch werden!?).

    Falls NEIN kann ich ja nur die Subdomain bei DMARC ignorieren, also alles erlauben.

    Was genau soll denn erreicht werden? Ich weiß gar nicht, ob man sub.example.org anlegen kann. Vermutlich schon. Ich gehe aber davon aus, dass dies eher zu (neuen) Problemen führen würde. Bounce Mails werden nicht signiert. Die DKIM Signierung erfolgt durch qmail-remote, welches für die Zustellung von Mails an externe Hosts ist.

    Mich wundert dass das noch niemand sonst aufgefallen ist.

    Ich hab auf einem Rocky 8 Server nachgeschaut. Dort tritt das Problem auch nicht auf. Scheint mir erst einmal ein Rocky 9 Problem zu sein.


    Mit der curl Version aus der Serverumgebung sollte dies nicht auftreten. Da die Version auch immer aktuell ist, würde ich als workaround vorschlagen /usr/local/pd-admin2/bin mit vorne in die PATH Variable aufzunehmen. Dann funktioniert curl korrekt.

    Bash
    $ ls -al /etc/pki/tls/certs/ca-bundle.crt
    lrwxrwxrwx. 1 root root 49 20. Sep 2023  /etc/pki/tls/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    $ ls -al /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    -r--r--r--. 1 root root 222082 28. Sep 11:52 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

    Bei mir wird die gleiche Datei verwendet. Und diese wurde zuletzt am 28.09.2023 geändert. Auch bei mir wird der gleiche Cronjob jede Woche ausgeführt. Ist jetzt die Frage wieso bei Ihnen die Datei angerührt wird 🤔 Ändert sich auch der Inhalt darin? Was ist vorher und nachher enthalten?

    Ich kann es mir nur so erklären dass das Setup der ca-certificates bei rocky/alma halt ein anderes ist als bei Oracle.

    Wenn man curl mit -v ausführt wird der Pfad von CAfile angezeigt. Ich nehme an bei Ihrem Test wird die curl Version der Distribution verwendet. Bei der curl Binary aus der Serverumgebung wird


    CAfile: /usr/local/pd-admin2/share/curl/curl-ca-bundle.crt


    verwendet. Bei der curl Binary aus der Distribution wird bei mir


    CAfile: /etc/pki/tls/certs/ca-bundle.crt


    verwendet. Dies wird wohl der Grund sein, weshalb es bei mir keine Probleme gibt.

    unter mysql 10.2 ist bei einigen Usern kein authentication_string vorhanden - OBWOHL zwei solcher Benutzer kurz nacheinander über pdadmin angelgt wurden!

    Mangels ausreichender informationen kann man dies nicht beantworten... Wie zuvor schon angeführt, wird ab MariaDB 10.2.19 sowohl das password Feld, als auch das authentication_string Feld bei bestimmten Aktionen gesetzt. Da wird es einen Zusammenhang geben.

    Wenn es OK ist, dass es User ohne authentication_strin gibt, sollte im Upgrade Script aber die Tabelle password anstelle von authentication_string verwendet werden - um den Fehler zu vermeiden der bei meinem Upgrade passiert - leere Passwörter

    Wenn man sich das Skript einmal anschaut, macht es auch genau das. Bei MariaDB 10.2 wird das password Feld ausgelesen. Vor der Fehlerbehebung wurde authentication_string ausgelesen, was zu leeren Passwörtern geführt hat. Denn der vadmin und roundcoundmail Bneutzer haben per Default nur das password Feld gefüllt.

    Ich nutze Oracle Linux 8.

    Code
    $ /usr/local/pd-admin2/bin/curl -sI https://github.com | head -1
    HTTP/2 200
    
    $ /usr/bin/curl -sI https://github.com |head -1
    HTTP/2 200
    
    $ ls -al /etc/ssl/cert.pem
    -rw-r--r--. 1 root root 1827 19. Mär 04:04 /etc/ssl/cert.pem

    Weder curl aus der Distribution, noch aus der Serverumgebung hat Probleme wenn die Datei ersetzt wurde. Stellt sich mir die Frage, wenn es an der Datei liegen sollte, wieso tritt das Verhalten nicht auch bei mir auf?

    Funktioniert etwas nicht? Gibt es Fehler nach dem Upgrade? Oder woher kommt die Annahme, das Fehlen von authentication_string sei kritisch?


    Schaut man sich einmal die mysql.user Tabelle bei MariaDB an


    mysql.user Table
    User access and global privileges.
    mariadb.com


    hat authentication_string also Default Wert "NULL". Also keinen Inhalt. Ein leeres Feld ist also durchaus normal. Woher kommen dann Einträge? Auch das findet sich in der Knowledge Base:

    Starting with MariaDB 10.2.19 and MariaDB 10.3.11, CREATE USER, ALTER USER, GRANT, and SET PASSWORD will set both columns whenever an account's password is changed.

    Wenn also einige Nutzer etwas im Feld stehen haben und andere nicht, liegt es sehr wahrscheinlich daran wann die Nutzer erstellt oder aktualisiert wurden.

    Die Änderung betraf mysql_privileges.pl, nicht mysql_upgrade.sh. Dort wurde der Passwort String falsch ausgelesen. Die Änderungen ist Skript, welches heruntergeladen wird drin. Lag vielleicht die alte Version des Skripts schon im gleichen Verzeichnis?

    Auf welche Art hat du denn das Upgrade durchgeführt?

    Ich habe einfach das mysql_upgrade.sh Skript ausgeführt. Also

    Bash
    $ bash mysql_upgrade.sh 9


    Wenn ich die "cannot move", "cannot access", "ln: failed" Fehler ignoriere, kommt es nach dem Starten der Dienste zu folgenden Fehlern:

    Die sind alles Meldungen aus dem SE Update. Das SE Update führt an einigen Stellen z.B. die httpd_vhosts.pl aus. Da zum Zeitpunkt des Upgrades aber der MySQL Dienst nicht verfügbar ist, kommt es zu den Fehlern. Das SE Update Skript ist nicht für das Upgrade geschrieben worden.


    Wenn ich mich mit dem mysql Client "/usr/local/pd-admin2/bin/mysql" verbinde, benötige ich kein root Passwort und die tabelle mysql.user sieht auch nicht richtig aus!

    * bei root@localhost und root@127.0.0.1 unterscheiden sich die Passwörter

    Ich nehme an, dass die root Nutzer ohne Passwort die "default" Nutzer nach einer Neuinstallation von MariaDB sind. Diese sollten gelöscht werden. Die root Nutzer mit den Passwörtern sollten die importierten Nutzer sein und auch alle notwendigen Berechtigungen haben. Sind in der yaml Datei denn auch mehrere root Nutzer mit unterschiedlichen Passwort Strings? Dann wurden dies nämlich so übernommen.


    * es gibt einen zusätzlichen User mariadb.sys ohne Password

    In MariaDB 10.4 and later, the mysql.global_priv table has replaced the mysql.user table, and mysql.user should be considered obsolete. It is now a view into mysql.global_priv created for compatibility with older applications and monitoring scripts. New tools are supposed to use INFORMATION_SCHEMA tables. From MariaDB 10.4.13, the dedicated mariadb.sys user is created as the definer of the view. Previously, root was the definer, which resulted in privilege problems when this username was changed (MDEV-19650).

    Dies ist ein separater Nutzer bei MariaDB. Hier kann man auch sehen, welche Berechtigungen der Nutzer haben sollte: https://mariadb.com/kb/en/acci…deleted-mariadb-sys-user/ - Dass dieser existiert ist also korrekt.


    * ein weiterer neuer User builduser hat in password und authentication_string "invalid" stehen

    Zu dem Nutzer habe ich nichts gefunden. Im Zweifelsfall einmal ein beliebiges Passwort setzen und darauf achten, ob es irgendwo Probleme gibt. Unter MySQL gibt es diesen Nutzer nicht. Für PDA ist er nicht relevant.


    Mit dem User vadmin und dem roundcubmail User kann ich mich mit dem richtigen Passwort anmelden

    Auf die Webfrontends customer, administrator, roundcubemail und phpmyadmin kann ich mich aber verbinden.

    Ist das Upgrade jetzt OK und kann ich alle Fehler ignorieren oder laufe ich gefahr, dass beim nächsten se Update nichts funktioniert?

    Ja, das Upgrade sollte damit OK sein. Einzige was auch meiner Sicht noch zu tun ist, sind die root Logins aufzuräumen.

    Ich habe dies einmal mit einer frischen Reihe 7 Installation auf Rocky Linux 8 durchgeführt und bei mir hat das Upgrade auf Reihe 9 geklappt. An den Fehlermeldungen bezüglich des Verschiebens darf man sich nicht irritieren lassen. Denn das Upgrade Skript führt ein SE Update durch. Das SE Update Skript wiederum verschiebt den MySQL Ordner. Oder versucht es eben. Da aber durch das Upgrade der Ordner nicht vorhanden ist, kommt es zu den Meldungen. Die Datenbanken werden dann ja im Nachhinein durch das Upgrade Skript importiert. Wenn es auch mit der Korrektur nicht klappt, muss der Fehler woanders liegen.

    Ich hab das script ./mysql_privileges.pl export_data ausgeführt - auch damit fehlen einige Passwörter im mysql_user.yaml file.

    Da müsste man sich jetzt das Skript anschauen und die verantwortliche Zeile/Query heraus suchen. Eventuell auch einmal manuell dumpen.

    Es scheint al würden die Kennwörter beim se-update wieder zurückgesetzt

    "Es scheint" klingt jetzt nicht danach, dass dies genau geprüft wurde. Wie sieht denn die Tabelle nach einem SE Update aus? Konkret bei den Nutzern wo es Probleme gibt.

    Darin fehlen tatsächlich für ein paar User die Passwortstrings (u.a. auch für den Roundcube User) - warum auch immer?!

    Da müsste man sich weiter das Skript anschauen und die Zeile mit dem Dump identifizieren. Diese dann am besten einmal manuell ausführen und schauen.

    Ich habe ja die Kennwörter manuell gesetzt - danach scheint alles zu funktionieren.

    Mein Problem ist es ja, dass beim nächsten se-update die Kennwörter wieder nicht stimmen

    Ich wüsste jetzt nicht an welcher Stelle bei einem SE Update Passwörter angerührt würden. Ist das jetzt nur eine Vermutung oder wurde das getestet?

    Vergleicht man einmal die beiden Dateien sieht man, dass der Roundcubemail Benutzer kein Passwort String in der Spalte "Password" hat. Die Datenbanken werden mit dem "dump_databases_for_upgrade.sh" Skript gesichert und unter /home/mysqldump-for-upgrade/ gespeichert. Ist in den Dumps ein Passwort String enthalten?

    Beim vadmin bekomme ich den Fehler ERROR 1133 (28000): Can't find any matching row in the user table

    Sieht aus, als würde der Benutzer beim Update gelöscht!

    Wie in beiden Dateien zu sehen, ist der vadmin Nuter in beiden enthalten. Auch mit einem Passwort String. Der Fehler " ERROR 1133 (28000): Can't find any matching row in the user table" kann auftreten, wenn ein Nutzer angelegt wurde, anschließend aber kein "flush privileges;" ausgeführt wurde. Trat der Fehler bei Nutzung des Skripts auf oder beim manuellen Versuch?

    Und nach jedem se-update die Kennwörter neu setzten liegt bestimmt auch nicht im Sinne des Erfinders.

    Wenn nach dem Upgrade der Reihe einmal die Passwörter gesetzt wurden, ist die bei den Folgeupdates der Serverumgebung nicht notwendig. Dann sind diese ja gesetzt. Ich würde das Upgrade der Reihe noch einmal durchführen, schauen wo es knallt und das dann korrigieren.