Beiträge von Sumeragi

    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.

    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:


    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.

    Ach, da habe ich mich verlesen. Ich dachte es werde ein Wechsel von Reihe 8 auf 9 durchgeführt.


    Ich würde bei dem Upgrade Skript einmal das "set -x" setzen (ist aus kommentiert) und dann Mal schauen an welcher Stelle vom Skript es zu dem Fehler kommt.

    Das funktioniert nicht mit FPM. Bei FPM startet ein Masters-Prozess. Dieser lädt einmalig die php.ini. Davon werden dann immer Kind-Prozesse geforkt. Diese übernehmen dann die Konfiguration.


    Das Laden einer php.ini je Subdomain geht nur mit cgiwrap. Dort kann dann in der .htaccess Datei

    Code
    SetENV PHPRC /home/bla/blub/pfad/php.ini

    eintragen, um eine eigene php.ini zu laden.