Nach einer manuellen Bearbeitung der mysql Benutzer direkt über mysql konnt das Upgrade auf Reihe 7 erfolgreich durchgeführt werden.
Folgendes musst vor dem Upgrade durchgeführt werden:
update user set authentication_string = password;Und dies musst nach dem Upgrade noch durchgeführt werden:
set password for 'root'@'::1'=password('XXXXXXXXXXXX');
delete from global_priv where User = 'builduser';
delete from global_priv where User = '';
flush privileges;Nach einer endlich erfolgreichen Umstellung von Reihe 7 auf Reihe 9 ist nur noch TLSv1.2 und 1.3 verfügbar.
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
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.
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.
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?
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...
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:
/service/qmail-smtpSd/log
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Konnte auch nach 60 Sekunden nicht mit der MySQL-Datenbank verbinden.
DBI connect('database=vadmin;host=localhost;','vadmin',...) failed: Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2) at /opt/pdadmin/bin/httpd_vhosts.pl line 70
can't connect! at /opt/pdadmin/bin/httpd_vhosts.pl line 70.
|
| MySQL fix privileges/MySQL shutdown/restart (MySQL 4.1/5.0)
| mysql_upgrade (MySQL 5.1)
|
skipping mysql_fix_privilege_tables (MySQL 4.0/5.0)
skipping mysql_upgrade (MySQL 5.1)
|
| mysqlcheck --all-databases --repair
|
/usr/local/pd-admin2/bin/mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2) when trying to connect
mysqld: no process found
---------------------------------
| ROUNDCUBEMAIL wird upgegradet.
|
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)
|
| phpMyAdmin < 4.8.4 and phpPgAdmin no longer available, use $hostname/adminer
|
|
| DKIM activated
|
|
| timezone-Daten werden in MySQL registriert, falls erforderlich
|
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Kann nicht zur Datenbank verbinden!
Konnte auch nach 60 Sekunden nicht mit der MySQL-Datenbank verbinden.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)
trying to install time zone data from /usr/share/zoneinfo
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)
|
| se-update.sh doneWenn 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?
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....:
/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 directoryHab 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!
Ich denke ich habe die Ursache für die "fehlenden" Passwörter im exportfile mysql_user.yaml gefunden.
In der Tabelle mysql.user gibt es die Spalte password und die Spalte authentication_string.
In der Spalte password sind alle Kennwörter vorhanden - in der Spalte authentication_string fehlen ein paar und offensichtlich werden beim Export die Kennwöter aus der Spalte authentication_string verwendet.
Warum die Fehlen, verstehe ich nicht - es gibt sogar 2 Benutzer die von kurzem auf dieselbe Art (Customer - Datenbanken - Datenbankkonten - Neues Konto) eingerichtet wurden - bei einem ist die Spalte authentication_string leer beim andern steht derselbe Strin wie in der Spalte password - Komisch!
Nachdem ich das korrigiert habe sind alle Kennwörter im Exportfile vorhanden.
Leider scheitert das Upgrade über das Script "/mysql_upgrade.sh 9" trotzdem noch.
Bis zum Bereich "Entferne einige .pdu-Dateien ..." scheint noch alles zu passen. Beim Verschieben von /usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm nach /home/mysql/mysql/ kommt wieder No such file or directory...
Arbeitsverzeichnis wird gelöscht ...Fertig
|
| Entferne einige .pdu-Dateien ...
|
/usr/local/pd-admin2/var/mysql/mysql/db.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/db.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/user.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/user.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/tables_priv.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/tables_priv.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/func.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/func.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/host.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/host.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/columns_priv.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/columns_priv.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_leap_seconds.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_leap_seconds.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_name.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_name.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition.MY[ID].pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition.frm.pdu-*
/usr/local/pd-admin2/var/mysql/mysql/time_zone_transition_type.MY[ID].pdu-*
/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
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/columns_priv.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/column_stats.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/column_stats.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/column_stats.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/db.opt' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/event.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/event.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/event.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/func.frm' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/func.MAD' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/func.MAI' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/general_log.CSM' to '/home/mysql/mysql/': No such file or directory
mv: cannot move '/usr/local/pd-admin2/var/mysql/mysql/general_log.CSV' to '/home/mysql/mysql/': No such file or directoryAlles anzeigenSo ganz scheint mein Vorgehen noch nicht zu passen.
Ich habe jetzt mal ein manuelles Upgrade von mysql Reihe 7 auf Reihe 9 mit der SE-Version 0438 durchgeführt.
Mit dem zusätzlichen Setzen der Passwörter für vadmin und dem Roundcubemailuser schein auch alles zu funktionieren.
Danach habe ich im File /usr/local/pd-admin2/UPDATE.INF/SERIES die Serie von 7 auf 9 geändert und ein Update der SE auf 0439 angestoßen.
Leider funktioniert die nicht! Ursache dafür sind Fehlschlagende mysqlzugriffe mit vadmin und dem Roundcubemail User.
------
DBI connect('database=vadmin;host=localhost;','vadmin',...) failed: Access denied for user 'vadmin'@'localhost' (using password: YES) at /opt/pdadmin/bin/httpd_vhosts.pl line 70
can't connect! at /opt/pdadmin/bin/httpd_vhosts.pl line 70.
------
ERROR: SQLSTATE[HY000] [1045] Access denied for user 'rcmXPJm6'@'localhost' (using password: YES)
ERROR: Failed to connect to database
------
ERROR 1045 (28000): Access denied for user 'vadmin'@'localhost' (using password: YES)
Ich hoffe jemand kann mir sagen, woran das liegen kann.
Welche Zugangsdaten werden beim Update verwendet?
Ich hab doch am 06.03.2024 detailliert beschrieben, was ich wie gemacht habe und was passiert ist, inkl. Fehlermeldungen...
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 hab das script ./mysql_privileges.pl export_data ausgeführt - auch damit fehlen einige Passwörter im mysql_user.yaml file.
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?
Das hab ich getestet! Es scheint al würden die Kennwörter beim se-update wieder zurückgesetzt.
Die Unterschiede sind mir auch Aufgefallen - leider finde ich nicht raus woran es liegt.
In den Dumps, die in /home/mysqldump-for-upgrade/ gespeichert werden ist nichts von Usern oder Passwörtern zu finden.
Ich denke die Berechtigungen werden nicht in diesen Dumps gespeichert sondern im File ~/mysql_user.yaml.
Darin fehlen tatsächlich für ein paar User die Passwortstrings (u.a. auch für den Roundcube User) - warum auch immer?!
Diese Fehler gehören alle zum Upgrade mit dem script mysql_upgrade.sh - wurde clean für diesen Beitrag gemacht.
Ein "flush privileges;" wird wärend dem scriptdurchlauf gemacht - ist im Consolenaoutput zu sehen.
Die letzte Feststellugn stimmt so leider nicht!
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.
Hallo Herr Bradler,
hab das Upgrade mit mysql_upgrade.sh 9 erneut versucht und die mysq.user vor und nach dem Update hochgeladen.
root hat nach dem Update kein Kennwort gesetzt.
Woher kommen denn die Kennwörter die für das Update verwendet werden?
crazydad Vielen Dank für diesen konstruktiven Beitrag!
Ich weiß nicht, wie du zu diesen Annahmen kommst, aber offensichtlich gibt es auch hier in diesem Forum Mitglieder, die anstelle objektiv Behilflich zu sein nur sinnlose Kommentare abgeben. Schade!
Nur zur Info:
Ich habe von längerer Zeit eine Neuinstallation mit der damals aktuellen REIHE 7 inkl. kompletter Datenmigration gemacht.
Seither habe ich penibel so gut wie jedes erschienene Update (pd-admin wie auch seu) innerhalb weniger Tage nach Erscheinung gemacht.
Fehlermeldungen hab nie welche missachtet oder ignoriert, geschweige etwas herumgepfuscht.
Jetzt möchte ich ein Upgrade von Reihe 7 auf 9 machen - wobei es von Anfang an zu Problemen kam und meine händischen Rumpfuschereien nur zum Troubleshooting dienen...
Also dein spontaner Spruch ist alles andere als Angebracht!
Diese ganzen Fehler kommen ja bereits während dem se-update, also muss ich davon ausgehen, dass das Update nicht vollständig gemacht wurde.
Und nach jedem se-update die Kennwörter neu setzten liegt bestimmt auch nicht im Sinne des Erfinders.
Hab es jetzt probiert - beim roundcube User klappt es und das Roundcubemail scheint dann auch zu funktionieren.
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!
Nach dem manuellen Update von mysql nach der Anleitung funktioniert sogut wie nichts mehr.
Die Ursache dafür ist der Verweigerte Zugriff auf mysql mit vadmin und roundcube User.
Nach dem enu setzten der Kennwörter im msql für diese Benutzer funktioniert alles wieder.
Wenn ich danach ein se-update mache bekomme ich oben genannte Fehler.
Also wurden ja die Passwörter vor dem Update neu gesetzt.
So ganz scheint mein Vorgehen noch nicht zu passen.
Ich habe jetzt mal ein manuelles Upgrade von mysql Reihe 7 auf Reihe 9 mit der SE-Version 0438 durchgeführt.
Mit dem zusätzlichen Setzen der Passwörter für vadmin und dem Roundcubemailuser schein auch alles zu funktionieren.
Danach habe ich im File /usr/local/pd-admin2/UPDATE.INF/SERIES die Serie von 7 auf 9 geändert und ein Update der SE auf 0439 angestoßen.
Leider funktioniert die nicht! Ursache dafür sind Fehlschlagende mysqlzugriffe mit vadmin und dem Roundcubemail User.
------
DBI connect('database=vadmin;host=localhost;','vadmin',...) failed: Access denied for user 'vadmin'@'localhost' (using password: YES) at /opt/pdadmin/bin/httpd_vhosts.pl line 70
can't connect! at /opt/pdadmin/bin/httpd_vhosts.pl line 70.
------
ERROR: SQLSTATE[HY000] [1045] Access denied for user 'rcmXPJm6'@'localhost' (using password: YES)
ERROR: Failed to connect to database
------
ERROR 1045 (28000): Access denied for user 'vadmin'@'localhost' (using password: YES)
Ich hoffe jemand kann mir sagen, woran das liegen kann.
Welche Zugangsdaten werden beim Update verwendet?
Vielen Dank, das hat mir schon mal sehr viel weitergeholfen!
Ich denke ich bin dem Problem auf der Spur.
Die manuelle Migration verursacht dasselbe Problem, ich konnt jetzt aber die Ursache finden.
Offensichtlich werden die mysql Berechtigungen nicht richtig gesetzt.
Wenn ich das Passwort für den vadmin und den roundcubemail-user händisch setzte laufen die Dienste wieder.
Kann es sein, dass dies in den Skripten nicht oder falsch berücksichtigt ist?
Gibt es vielleicht eine Anleitung, wie man diese Umstellung händisch machen kann?
