Beiträge von Sumeragi

$ 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?

Zitat von tbc233

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.

Zitat von pumi

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.

Zitat von pumi

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.

$ /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

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:

Zitat von MariaDB 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?

Zitat von pumi

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

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

$ bash mysql_upgrade.sh 9

Zitat von pumi

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.

Zitat von pumi

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.

Zitat von pumi

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

Zitat von MariaDB Knowledge Base

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.

Zitat von pumi

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

Zitat von pumi

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.

Zitat von pumi

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.

Zitat von pumi

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.

Zitat von pumi

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.

Zitat von pumi

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?

Zitat von pumi

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?

Zitat von pumi

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.

Kann man nicht mit der gai.conf festlegen, dass ipv4 priorisiert wird?

... und was ist wenn nach dem SE Update noch einmal die Passwörter neu gesetzt werden?

Es scheint so, als wenn der vadmin und roundcube Nutzer sich nicht einloggen können. Klappt denn ein manueller Login nach dem Update? Wenn nicht würde ich nach dem Update noch einmal die Passwörter neu setzen. Eventuell hat sich da zwischen MariaDB 10.2 und 10.5 etwas verändert.

Die Schritte sind die gleichen wie im Skript. Diese wurden auch in einem älteren Thread aufgezeigt:

Beitrag

RE: Update von Reihe 4 auf 6

Die Migration ist leider nicht so einfach möglich. Da andere Projekte derzeit bei uns Priorität haben, wird es vorerst leider keine fertige Migrationsroutine geben. Es ist aber generell möglich, die Kundendatenbanken und Datenbank-Privilegien per Dump zu sichern und dann in ein leeres System zu übernehmen.
Vorgehensweise:

1. Privilegien inkl Passwoerter exportieren (mysql_privileges.pl export_data)
2. Dumps erstellen
3. Datenbank-Server runterfahren (svc -d /service/mysqld; killall mysqld)
4. /home/mysql

…

Daniel Bradler

5. Februar 2019

Welches Betriebssystem wird denn verwendet?

Die qmail Dateien können einfach geändert werden.

Aktuelle Dateien sollten

|/opt/pdadmin/bin/forward_filter

|/opt/pdadmin/bin/srs_forward.pl <Mail>

enthalten. Und SRS ist definitiv schon länger aktiv. Wenn man im News-Archiv schaut findet man z.B. zu PDA 4.26 (2016) eine entsprechende Ankündigung.

SRS ist schon länger implementiert. Eventuell sind die vorhandenen .qmail Dateien der Mailboxen bzw. Weiterleitungen schon älteren Datums. Dann können die noch alte Einträge enthalten. Würde ich einmal rein schauen und mit aktuellen Dateien vergleichen.

Zu 1. und 2. - DMARC wird nicht berücksichtigt.

Zu 3. - In spamassassin kann man einen Score für DKIM und SPF festlegen. Mit der SE 0.426 wurde

DKIM: roberto-netqmail-1.06.patch-2023.07.05

mit ausgeliefert. Die Signierung und Validierung der DKIM Signatur erfolgt somit in qmail. Es gibt aber keine weitere Aktion, außer eben der Signierung oder Validierung.

Es gibt wohl ein spamassassin Plugin von AskDNS, womit DMARC abgefragt werden und ein Score vergeben werden kann. Ich weiß aber nicht, wie sinnvoll das ist. Denn man kann auch einfach Scores für DKIM und SPF festlegen.