4
Website nach geändertem MySQL Passwort für user root nicht erreichbar
Hallo,
ich betreibe einen Ubuntu 16.04 Server. Auf dem Server läuft ein MySQL-Server, Version 5.7.31. Wegen interner Querelen musste ich das MySQL root Passwort ändern. Hierbei bin ich wie folgt vorgegangen:
$~: sudo su
$~: service mysql stop
anderer Tab:
$~: sudo mysqld_safe --skip-grant-tables &
$~: mysql -uroot
use mysql;
update user set authentication_string=password('YOURSUPERSECRETPASSWORD') where user='root';
flush privileges;
exit
$~: sudo /etc/init.d/mysql start
Check:
$~: sudo /etc/init.d/mysql status
Status OK
Ansschließend rufe ich die Website im neuen privaten Browserfenster auf. Die Website wird fehlerfrei angezeigt. Nach ca. einer Minute mach ich einen page reload und bekomme folgende Fehlermeldung:
PDOException: SQLSTATE[HY000] [2002] No such file or directory in lock_may_be_available() (line 167 of /var/www/webroot/includes/lock.inc) // screenshot weiß
Die Funktion in der "lock.inc" zeigt der screenshot schwarz.
Im Anschluss setze ich den Server auf den letzten snapshot zurück, beginne von vorn, bekomme aber nach ein bis zwei Minuten dasselbe Resultat. Mittlerweile habe ich das Ganze fünf mal absolviert.
Für Tipps bin ich dankbar.
ich betreibe einen Ubuntu 16.04 Server. Auf dem Server läuft ein MySQL-Server, Version 5.7.31. Wegen interner Querelen musste ich das MySQL root Passwort ändern. Hierbei bin ich wie folgt vorgegangen:
$~: sudo su
$~: service mysql stop
anderer Tab:
$~: sudo mysqld_safe --skip-grant-tables &
$~: mysql -uroot
use mysql;
update user set authentication_string=password('YOURSUPERSECRETPASSWORD') where user='root';
flush privileges;
exit
$~: sudo /etc/init.d/mysql start
Check:
$~: sudo /etc/init.d/mysql status
Status OK
Ansschließend rufe ich die Website im neuen privaten Browserfenster auf. Die Website wird fehlerfrei angezeigt. Nach ca. einer Minute mach ich einen page reload und bekomme folgende Fehlermeldung:
PDOException: SQLSTATE[HY000] [2002] No such file or directory in lock_may_be_available() (line 167 of /var/www/webroot/includes/lock.inc) // screenshot weiß
Die Funktion in der "lock.inc" zeigt der screenshot schwarz.
Im Anschluss setze ich den Server auf den letzten snapshot zurück, beginne von vorn, bekomme aber nach ein bis zwei Minuten dasselbe Resultat. Mittlerweile habe ich das Ganze fünf mal absolviert.
Für Tipps bin ich dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 616908
Url: https://administrator.de/forum/website-nach-geaendertem-mysql-passwort-fuer-user-root-nicht-erreichbar-616908.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
4 Kommentare
Neuester Kommentar
Moin,
du musst in deiner Seite noch das MySQL-Passwort anpassen... Allerdings solltest du gleich die Chance nutzen und das ganze NICHT mit root machen, das ist die dümmste Idee die es gibt. Lege dafür einen User an der eben Vollzugriff auf die Tabelle hat die deine Seite braucht - aber KEINEN Zugriff auf die System-Tabellen. Es wäre doch blöd wenn ich deine Seite hacke und erst mal lustig User anlegen kann, oder?
Das man sowas erst auf nem Testsystem ausprobieren sollte und auch nen Backup vorher macht braucht man ja nicht zu erwähnen, oder?
du musst in deiner Seite noch das MySQL-Passwort anpassen... Allerdings solltest du gleich die Chance nutzen und das ganze NICHT mit root machen, das ist die dümmste Idee die es gibt. Lege dafür einen User an der eben Vollzugriff auf die Tabelle hat die deine Seite braucht - aber KEINEN Zugriff auf die System-Tabellen. Es wäre doch blöd wenn ich deine Seite hacke und erst mal lustig User anlegen kann, oder?
Das man sowas erst auf nem Testsystem ausprobieren sollte und auch nen Backup vorher macht braucht man ja nicht zu erwähnen, oder?
Die Website läuft mit separatem db user, ohne root-Rechte. Das root pw hab ich nur angepasst, da der bisherige Betreuer 'verschwunden' ist. Eben fiel mir ein, dass ja die Website, die nicht mehr angezeigt wird, nur ein Ergebnis ist, nicht aber die Ursache. Der MySQL-Server schaltet sich ab.
Die Site ist live. Ich hab nicht viel Spielraum, da sonst die Schulleitung stresst. Blöderweise hab ich den Server grad wieder zurückgesetzt. Will aber gleich nach dem nächsten Crash ins logfile schauen. Randnotiz: ich bin Lehrer, soll heissen, ich mach das nebenbei.
Die Site ist live. Ich hab nicht viel Spielraum, da sonst die Schulleitung stresst. Blöderweise hab ich den Server grad wieder zurückgesetzt. Will aber gleich nach dem nächsten Crash ins logfile schauen. Randnotiz: ich bin Lehrer, soll heissen, ich mach das nebenbei.
Nun - die Tatsache das du das "nebenbei" machst tut "nebenbei" ja nich viel zur Sache... bei uns is es halt immer "wers kaputt macht muss es auch wieder heile machen".
Du kannst aber ja mal in die Logs gucken (bzw. wenn der MySQL crasht mit nem journalctl -xe )schauen warum der wegballert... das kann durchaus sein das du irgendwo in den Configs ja noch das alte Passwort drin hast.
Und zum Schluss: Dann lass die Schulleitung stress machen... bei uns heissts immer "Da gehts um nix" - das ist ja dann keine Konzern-Seite bei der jede Minute 1000de Euros wegfallen sondern maximal ne kleine Unbequemlichkeit. Wenn die sowas nicht wollen gibt es die Möglichkeit das an ein prof. Unternehmen auszulagern (die nehmen halt die komischen Euro-Scheine, und teils nich wenige) ODER das du das am Wochenende machst (was aber vermutlich wg. Überstunden usw. nicht gern gesehen wird). Wenn beides also nicht gewollt ist dann muss man das Risiko halt hinnehmen das es eben auch mal ausfällt...
Du kannst aber ja mal in die Logs gucken (bzw. wenn der MySQL crasht mit nem journalctl -xe )schauen warum der wegballert... das kann durchaus sein das du irgendwo in den Configs ja noch das alte Passwort drin hast.
Und zum Schluss: Dann lass die Schulleitung stress machen... bei uns heissts immer "Da gehts um nix" - das ist ja dann keine Konzern-Seite bei der jede Minute 1000de Euros wegfallen sondern maximal ne kleine Unbequemlichkeit. Wenn die sowas nicht wollen gibt es die Möglichkeit das an ein prof. Unternehmen auszulagern (die nehmen halt die komischen Euro-Scheine, und teils nich wenige) ODER das du das am Wochenende machst (was aber vermutlich wg. Überstunden usw. nicht gern gesehen wird). Wenn beides also nicht gewollt ist dann muss man das Risiko halt hinnehmen das es eben auch mal ausfällt...
wenn du das ganze bereits zurückgesetzt hast würde ich folgendes machen:
1) Root-User darf sich nur von localhost anmelden (wenn dann der ehemalige Berater keinen Shell-Zugriff hat is das Passwort egal)
2) Falls nötig einen weiteren Full-Admin anlegen der einen anderen Usernamen hat und von aussen verwendet wird (nur wenn wirklich nötig, nicht nur weil bequemer!)
3) Für JEDE Tabelle einzelne User anlegen und die verwenden - wenn z.B. die Schulleitung meint die möchte ne Tabelle für die Noten haben wird die angelegt und denen z.B. im ODBC-Treiber (oder welche Verbindung du auch hast) dieser User eingetragen. Das schützt dich auch davor das nen Schüler ggf. doch mal Zugriff auf die Tabellen erhält weil wieder der Lehrer der 5b nen Schüler an sein Laptop gelassen hat um das Mailprogramm zu reparieren und der kurz Daten kopiert hat (würde ja nie ein Schüler machen...)
Damit wäre dann dein DB-Server gleich noch "ganz nebenbei" deutlich besser abgesichert - grad die Admin-Accounts brauchen für gewöhnlich nicht von aussen erreichhbar sein. Nen SSH-Zugriff und ggf. port-forwarding (ssh -L 3306:127.0.0.1:3306 deinuser@deinserver) reicht da völlig...
1) Root-User darf sich nur von localhost anmelden (wenn dann der ehemalige Berater keinen Shell-Zugriff hat is das Passwort egal)
2) Falls nötig einen weiteren Full-Admin anlegen der einen anderen Usernamen hat und von aussen verwendet wird (nur wenn wirklich nötig, nicht nur weil bequemer!)
3) Für JEDE Tabelle einzelne User anlegen und die verwenden - wenn z.B. die Schulleitung meint die möchte ne Tabelle für die Noten haben wird die angelegt und denen z.B. im ODBC-Treiber (oder welche Verbindung du auch hast) dieser User eingetragen. Das schützt dich auch davor das nen Schüler ggf. doch mal Zugriff auf die Tabellen erhält weil wieder der Lehrer der 5b nen Schüler an sein Laptop gelassen hat um das Mailprogramm zu reparieren und der kurz Daten kopiert hat (würde ja nie ein Schüler machen...)
Damit wäre dann dein DB-Server gleich noch "ganz nebenbei" deutlich besser abgesichert - grad die Admin-Accounts brauchen für gewöhnlich nicht von aussen erreichhbar sein. Nen SSH-Zugriff und ggf. port-forwarding (ssh -L 3306:127.0.0.1:3306 deinuser@deinserver) reicht da völlig...
