Upgrade von Reihe 7 auf Reihe 9

  • Hab jetzt auch noch versucht das "manuelle" Update versucht. Vorher hab ich natürlich die Passwörter im mysql richtig gestellt (Spalte password und authentication_string gleich)

    Der Import der Privilegien (mysql_privileges.pl import_data) scheitert mit zugriff verweigert.

    Nach dem manuellen setzten des root Passworts klappt es.

    Die Ausgabe von "select host,user,password,authentication_string from mysql.user;" irritiert mich aber.

    In der Spalte authentication_string passen die Passwörter in der Spalte password steht abgesehen vom Benutzer root überall derselbe Wert - keiner aus dem Exportfile!

  • Im mysql_user.yaml file sind jetzt alle Passwörter vorhanden.

    Nach dem Import stehen in der spalte password alle Passwörter drin, in der Spalte authentication_sting ist alles leer - weiß nicht ob das richtig ist.

    Leider funktioniert das Update noch immer nicht.

    Es scheiter nach wie vor beim Bereich cannot move....:

    Code
    /usr/local/pd-admin2/var/mysql/mysql/time_zone_transition_type.frm.pdu-*
    (2) MYSQLDATADIR = </home/mysql>
    mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm' to '/home/mysql/mysql/': No such file or directory
  • 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.

  • Sumeragi - vielen Dank für deine Mühe!

    Gut zu wissen, dass diese "cannot move" Fehler kein Problem sein müssen.

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

    Ich habe es jetzt noch mal mit dem "mysql_upgrade.sh 9" versucht.

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

    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

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

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

    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?

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

  • OK, das bringt ja mal massig Licht ins Dunkel! Danke!

    In der mysql_user.yaml sind alle password strings richtig enthalten!

    Der root benutzer mit dem falschen Kennwort ist der für ipv6 - hab ich jetzt geändert.

    Dann werd ich jetzt nochmal meinen Testserver auf diese Weise upgraden und gehe davon aus, dass einem Upgrade meines Produktiv Servers nichts im Wege steht...

  • Hab jetzt erneut ein sauberes Upgrade mittels "mysql_uprade.sh 9" durchgeführt.

    Leider habe ich jetzt bemerkt, dass das für den roundcubemail User und einen anderen mysqluser wieder kein Password gesetzt ist.

    Kann es sein, dass in diesem Upgradescript mysql_uprade.sh die Anpassung von Hr. Bradler nicht drin ist?

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

  • Nein es lag / liegt nirgends eine andere Version der mysql_privileges.pl am System.

    Hbs erneut versucht - ich denke das Problem liegt an der unvolständigen mysql.user im aktuellen System.

    Dort fehlen ja in der Spalte aufhentication_sting schon diese Passwörter - in der Spalte password sind sie aber vorhanden.

    Woran kann das liegen - es betrifft sogar 2 User die kuz nacheinander über das selbe Vorgehen angelegt wurden (im customer frontend) - einer hat einen authetication_string der andere nicht.

    Wenn ich vor dem Update die authentication_string's in der mysql.user korrigiere - sind sie auch nach dem Update korret gesetzt.

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

  • Wei gesagt, wenn ich ein upgrade mache ohne voherige manuelle Änderungen, an der mysql.user Tabelle, funktioneirt es nicht - es fehlen Passwörter in der neuen mysql.global_priv Tabelle.

    Wenn ich vor dem Upgrade alle Passwörter in der mysql.user von der Spalte password in die Spalte authentication_string übertrage, sind nach dem Upgrade alle wichtigen Passwörter in der mysql.global_priv OK.

    Ausnahmen sind folgende User

    • 'root'@'::1' - das setzte ich nachträglich (dürfte ein default PW sein)
    • 'builduser'@'localhost' - hat kein Passwort und wissen wir nicht woher er kommt, bzw. ob er benötigt wird
    • ''@'localhost' - also ein Eintrag ohne Usernamen für localhost - diesen lösche ich.

    Für mich ist dieses Vorgehen jetzt OK - ich warte auf das nächste SE Update - wenn die Installation positiv verläuft, mach ich das upgrade am produktiv Server.

    Folgende Punkte kommen mir aber strange vor - sollten sich angesehen werden - ob wirklich alles korrekt ist.

    • unter mysql 10.2 ist bei einigen Usern kein authentication_string vorhanden - OBWOHL zwei solcher Benutzer kurz nacheinander über pdadmin angelgt wurden!
    • 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.
  • 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.