[gelöst] [Bullseye] mySQL Zugriffsfehler ( localhost und % Fehlermeldung )

[speefak]

Moin,

Ich habe aus versehen meinen mySQL Server fast ? einwenig ? ganzdolle ? kaputtgemacht. Passiert ist folgendes :

Ich habe ein Script geschrieben welches die Funktion von phpmyadmin "User anlegen/Datenbanker stellen/User alle Rechte auf Datenbank gewähren" über die mySQL Shell übernimmt. Jetzt hatte ich das Script noch in der Zwischenablage und habe den Code dummerweise in einer Rootshell auf meinem Server eingefügt. Dank der Zeilenumbrüche wurde auch jede Zeile ausgeführt. Ich dachte schon ich hab mir den ganzen Server zerschossen aber es scheint nur etwas kaputkonfiguriert worden zu sein. Einige Datenbankzugriffe laufen jetzt auch nicht mehr und der Fehler ist lt. phpmyadmin folgender :

Code: Alles auswählen

Ein Benutzerkonto, das beliebige Nutzer von „localhost“ aus erlaubt, ist vorhanden. Dies wird Benutzer vom Verbinden abhalten, falls der Host-Teil ihres Kontos eine Verbindung von jedem Host (%) erlaubt.

MySQL und ich werden wohl nie Freunde werden und bevor ich jetzt noch mehr "kaputtrepariere" die Frage was muß ich eingeben um den ursprünglichen default zustand des Server wiederherzustellen. Kein Reset, kein reconfigure etc.

Ich habe einen nach o.g. Aktion nun fehlerhaften user gelöscht und mit Localhost Zugriff neu angelegt und jetzt klappt der Datenbankzugriff auch wieder. Nur irgendwas wurde umgestellt was die Zugriffe der Wildcard und Localhost angeht.

Die betreffenden aktiven Zeilen aus dem Script sind folgende ( werte für Variablen waren leer )

Code: Alles auswählen

sudo mysql -e "CREATE USER '$NewUser'@'localhost' IDENTIFIED BY '$NewPass'"
sudo mysql -e "CREATE DATABASE $NewData"
sudo mysql -e "GRANT ALL PRIVILEGES ON $NewData.* TO '$NewUser'@'localhost'"

demnach wurde die Zeilen wohl so ausgeführt :

Code: Alles auswählen

sudo mysql -e "CREATE USER ''@'localhost' IDENTIFIED BY ''"
sudo mysql -e "CREATE DATABASE "
sudo mysql -e "GRANT ALL PRIVILEGES ON .* TO ''@'localhost'"

Das ganze Script : https://speefak.spdns.de/oss_lifestyle/mysql-befehle/

EDIT :

Kann es sein das der Eintrag den Fehler verursacht :

Code: Alles auswählen

sudo mysql -e "select * from information_schema.user_privileges"
+-----------------------------+---------------+--------------------------+--------------+
| GRANTEE                     | TABLE_CATALOG | PRIVILEGE_TYPE           | IS_GRANTABLE |
+-----------------------------+---------------+--------------------------+--------------+
| ''@'localhost'              | def           | USAGE                    | NO           |

wie bekomme ich den wieder weg ?

[heisenberg]

Kann es sein das der Eintrag den Fehler verursacht :

Ja.

information_schema.user_privileges ist aber nur eine view. Die tatsächlichen Daten stehen in der Tabelle mysql.user.

Schau Dir die Tabelle mysql.user mal an(select * from mysql.user \G) und lösche den Eintrag mit dem leeren Benutzernamen aus der Tabelle mysql.user(delete from mysql.user where ....).

Und im Zweifelsfall ist ein regelmässiges DB-Backup wirklich nicht schlecht. Denn so ein Oops ist schnell mal passiert. (Backup z. B. mit automysqlbackup). Und ein Backup ist nur ein Backup, wenn man es auch gelernt hat wiederherzustellen.

[speefak]

Fehler behoben Ich habe den Eintrag über phpmyadmin gelöscht. Ich wunderte mich schon, dass ein Login von der user shell mit mysql funktionierte. Vorher stand aber ein Backup an

Backups mache ich in regelmäßigen Abständen vom gesamten System ( dd / mit 15 - 20 GB ), Webseiten werden täglich gesichert. Nur wenn der Server den Zugriff verweigert ist das auch recht dumm gelaufen. und das Große dd Backup ist immer sehr umständlich ( dafür aber zu 100% vollständig )

Ich habe mir automysqlbackup mal angeschaut. Besser als nichts aber mein Script hat dann doch mehr Funktionen :

- Backup nach Tagen / Wochen / Monaten ( letzten 12 Monate, letzten 4 Wochen, letzten 7 Tage, automatischen löschen alter Backups )
- Dateipfade wie Webseitenpfade der Apache Dateien werden mit gesichert
- Pfad exclude möglich ( Daten Verzeichnis von Nextcloud z.B. )
- Direktes Erstellen eines Restorescriptes im Backupverzeichnis ( ./restore.sh stellt Backup wieder her )

Script => pastebin/?mode=view&s=41307

[heisenberg]

Ich habe mir automysqlbackup mal angeschaut. Besser als nichts aber mein Script hat dann doch mehr Funktionen :

Das hört sich erst mal gut an.

Ein laufendes DBMS wie z. B. mysql mit einer Dateisicherung zu sichern hilft Dir im Zweifelsfall aber nichts, weil es nicht konsistent ist. Zusätzlich ist es bei der Wiederherstellung so, dass das funktionieren kann, aber nicht muss. Wenn dann noch andere Probleme dazu kommen, (z. B. Festplattenlesefehler), dann ist's recht schnell schon mal duster.

Für ein DBMS brauchst Du entweder ein logisches Backup(Backup der Inhalte in Form von SQL-Befehlen, die wieder eingespielt werden können, also per mysqldump(d. h. was auch automysqlbackup nutzt)) oder ein konsistentes physisches Backup der DB-Dateien. D. h. also entweder DBMS vor der Dateisicherung herunterfahren oder ein spezielles Hot-Backup verwenden. Letzeres macht u. a. Percona XtraBackup(für mysql) oder mariabackup(für mariadb). Physische Hot-Backups sind etwas aufwändiger in der Handhabung, sind aber bei sehr großen Datenbanken wesentlich schneller bei der Wiederherstellung. Darüberhinaus sind alle physischen Backups nur mit der gleichen Version (und ggf. auch Konfiguration) des DBMS lauffähig.

Ich mache das so, dass ich täglich ein eigenes mysqldump-basiertes Script laufen lasse, dass die Datenbanken logisch exportiert. Diese Exports werden dann in der normalen Dateisicherung miterfasst.

Zusätzlich sind manchmal noch die MySQL-Binary Logs sinnvoll. Diese müsste man einschalten, wenn man das haben möchte. Diese Binary Logs speichern jede MySQL-Transaktion ab. Bei einem Absturz oder Defekt der Datenbank hat man dann nicht nur z. B. das tägliche Backup, sondern kann direkt bis zum Punkt des Absturzes alle Datentransaktionen nachfahren. Dazu ist es natürlich wichtig, dass diese Binary Logs auch extern gespeichert werden. Diese sog. Point-in-Time Recovery ist z. B. bei Online-Shops wichtig, wo ständig neue Bestellungen oder Bestellverarbeitungen anfallen. Da möchte man nicht mal ebenen mehrere Stunden an Änderungen verlieren.

Siehe auch:
https://wiki.ubuntuusers.de/MySQL/Backup/

[speefak]

Code: Alles auswählen

mysqldump --user=$DATABASEUSER --password=$DATABASEPASS --databases $DATABASENAME > $BACKUP_TEMP_DIR/$DATABASENAME.sql 

= DB Lock

Ich hatte das Script vor Jahren mal geschrieben weil es bis dato nichts einfaches gab, Deine Argumente bezüglich der Aktualität des Backups sind berechtigt, kommen aber eher für große Webshops und Datenbanken zum tragen. Eine weitere Möglichkeit wäre die Backups via Borgbackup inkrementell zu sichern um Speicherplatz zu sparen.

Danke für die Tipps mit mariabackup und den hotbackups, für meine Seiten reicht o.g. Script.

PS: Es handelt sich um mariadb, MySQL gibt es ja schon so gut wie nicht mehr im default Zweig von Debian.

[heisenberg]

Ja. Ich habe die anderen Optionen nur mal so dazu erwähnt. Ich denke, dass für die meisten privaten Anwendungen ein simpler täglicher/wöchentlicher Dump reicht.