MariaDB 10 - Passwort nicht akzeptiert

    Hallo


    Ich kann über phpAdmin auf die MariaDB zugreifen. Jedoch akzeptiert er im Browser das Passwort nicht.


    Die App "Kodi" welche auf einem Nvidia Shield läuft, kann sich die Daten holen. D.h. Kodi meldet sich erfolgreich an.

    Konkret heisst das, dass ich die Auswahl an Filmen erhalte, auf einem Film klicke und dieser startet.


    Im QNAP Gui die App für MariaDB 10 geöffnet. Das Stammpasswort zurück gesetzt.

    Danach auf Benutzerpasswörter geklickt. Er fragt nach dem Stammpasswort. Eingegeben. Falsch.


    Restart NAS. Dasselbe.


    Über Putty zugegriffen. Anmeldung nicht möglich.

    qnapo.jpg



    Die Software ist so buggy! Ich werde wohl oder übel auf "Datenbank: Neu initialisieren" klicken müssen... X(  :rolleyes:


    Grüsse an alle Foristen

    Einmal editiert, zuletzt von ral9004a ()

    Das liegt vermutlich an der Konfiguration. php greift über einen anderen Weg auf die Datenbank zu als das CLI-Tool.

    Das CLI-Tool möchte einen Zugriff über Unix Socket machen, kann diesen aber nicht finden.

    Das PHP und auch Kodi wird höchstwahrscheinlich einen Zugriff über TCP/IP machen.


    Zwei mögliche Lösungen: Lass das CLI-Tool über TCP/IP zugreifen. Oder prüf mal, was am Unix Socket nicht passt.

    Einmal editiert, zuletzt von Barungar ()

    Zitat von Barungar

    Das liegt vermutlich an der Konfiguration. php greift über einen anderen Weg auf die Datenbank zu als das CLI-Tool.

    Hallo Barungar


    Danke das Du am Silvester noch einen Text in das Forum stellst 🤗😀


    A:

    Du reduzierst das Problem auf Deine Sichtweise (Hammer sieht nur Nägel). Du übersiehst, wie komplex die Situation ist: Warum kann ich im GUI von QNAP mit der MairaDB 10 App die Passwörter nicht zurück setzen?


    B:

    Das Problem ist bekannt:

    https://medium.com/@alef.duart…-mysqld-sock-155d580f3a06

    https://stackoverflow.com/ques…ocket-var-run-mysqld-mysq

    etc.


    C:

    So wenig sich ein Santiär Fachmann freut, wenn er zu Hause sein Kloset jede Woche reparieren darf, so wenig aufregen finde ich Applikationen die rum zicken. Ich wollte nur noch kurz ein paar Daten in der Kodi Tabelle löschen, bevor ich für heute Abend in die Küche gehe. Und wie vor 2 Wochen zickt das Teil ohne einen Grund herum.

    Meine "MS Access 2013" Datenbanken (hatten meinen Kunden keine solchen Probleme bereitet.


    Ich habe mir schon überlegt, ein Adressbuch (offline) in QNAP abzulegen und danach am Abend oder WE die Daten auf die Endgeräte zu replizieren. Ich denke, dass eine CSV Datei oder ein Excelfile eine höhere Zugriffssicherheit bieten als die NAS Apps...


    Grüsse an alle Foristen

    Das ist nicht ganz richtig....


    Die MariaDB10 läuft aktuell parallel zur MariaDB5 in der Firmware. Und der eingebaute Apache und PHP greifen über den Socket /tmp/mysql.sock leider immer auf die MariaDB5 zu.


    Migration geht wie folgt:


    1. Alle Datenbanken aus der MariaDB5 exportieren:


    cd /usr/local/mysql/bin/mysqldump -u root -p --all-databases >/share/Public/mysql.sql


    2. MariaDB5 deinstallieren über Webinterface


    3. MariaDB10 anpassen:


    Code
    vi /share/CACHEDEV1_DATA/.qpkg/MariaDB10/etc/mariadb.conf

    Dort den Socket auf /tmp/mysql.sock ändern (3 mal). Und den Port von 3307 auf 3306.


    4. MariaDB10 neu starten:


    Code
    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/etc/init.d/mariadb10.sh stop
/share/CACHEDEV1_DATA/.qpkg/MariaDB10/etc/init.d/mariadb10.sh start

    5. Daten in MariaDB10 importieren:


    Code
    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysql -u root -p </share/Public/mysql.sql


    6. MariaDB10 neu starten wie unter 4. beschrieben.


    7. Internen Webserver neu starten:


    /etc/init.d/Qthttpd.sh restart


    8. Fertig!


    WIchtiger Hinweis:


    Da die Datenbanken - wie schon immer bei qnap - nicht automatisch gesichert werden, sollte immer ein Backup erstellt werden.

    Ich habe dazu ein Script angelegt, welches täglich um 2 Uhr in der Nacht einen Dump aller Datenbanken anlegt. Diesen Dump sichere ich dann über mein normales Backup mit weg.


    Das Script muss für jede Datenbank folgenden Befehl beinhalten:


    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysqldump -u root -pPASSWORT DATENBANKNAME >/PFAD_ZUR_FREIGABE/DATENBANKNAME.sql


    Falls eine versionierte Sicherung gewünscht ist, kann in den Dateiname auch noch das dumm mit %d eingebaut werden.

    Hallo lhsei


    Prolog

    Am 11. Dezember hast Du mich erfolgreich durch die Ochsentour geschleift. D.h. MariaDP 5 durch 10 ersetzt.


    Aktualisierung interne MariaDB 5.5.57 auf MariaDB 10.4.x mit Entware-std


    In diesen Tagen habe ich unzählige Male auf die MARIA DB zugegriffen. Sowohl über SSH als auch über phpAdmin.


    Heute wollte ich ein paar Tabellen bereinigen. Und die Datenbank verweigert den Zugriff.

    Vor drei Tagen genehmigte ich einen Update der QNAS Software. Möglicherweise hat dieser Update die Konfiguration zerschossen. Schöne Aussichten für die Zukunft!!


    Deine Lösung

    Du beschreibst das vorgehen, wenn ein Konflikt von MariaDB 5 und 10 vorliegt. Wie oben geschrieben ist das nicht der Fall. Ausgenommen der Update hat das Ei gelegt...


    Wieso kann ich mit der MariaDB 10 App in QNAP das Stammpasswort nicht setzen?


    Danke für das Backup Skript. Das habe noch nicht über einen Cron Job automatisiert. Funktioniert hat die Store Procedere am 13. Dez. D.h. die Daten sind zu 98% save.


    Die Konfigurationsdatei "mariadb.conf" sieht heute Abend so aus:


    Wie erreiche ich, dass ich sowohl über SSH als auch über phpAdmin wieder auf die MARIADB 10 zugreifen kann?

    Datenverlust spielt aktuell keine Rolle.


    Danke und schönes Silvester!


    Viele Grüsse

    ok. Dann muss natürlich neben der MariaDB5 auch die entware MariaDB10 beendet/deinstalliert werden.


    Vorher ein Backup der entware MariaDB10 machen über den mysqldump-Befehl.

    Hier noch mal mein vollständiges Script und die Anleitung zur Einbindung in die crontab:


    Code
    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysqldump --single-transaction -h localhost -u root -pPASSWORT DATENBANK1> /PFAD_ZUM_BACKUP/DATENBANK1-DB_`date +"%Y%m%d"`.sql
/share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysqldump --single-transaction -h localhost -u root -pPASSWORT DATENBANK2> /PFAD_ZUM_BACKUP/DATENBANK2-DB_`date +"%Y%m%d"`.sql

    Wobei DATENBANKx durch den Name der Datenbank ersetzt werden muss und PASSWORT durch das root-Passwort der MariaDB.

    ACHTUNG: Auch die Datenbank "mysql" muss gesichert werden - dort sind alle User und Passwörter gespeichert!


    Das Script als backup.sh in einem beliebigen Pfad auf dem NAS speichern, z.B. /share/Public/.


    Nun das Script mit chmod +x /share/Public/backup.sh (oder einem anderen Pfad) ausführbar machen.


    Danach eine Testsicherung vornehmen:


    /share/Public/backup.sh


    Nach korrekter Ausführung des Scripts muss für jede Datenbank im Sicherungspfad eine .sql-Datei erstellt worden sein.


    Nun muss das Script noch in den Cronjob eingebunden werden:


    crontab -e


    Folgender Eintrag muss als neue Zeile in der Crontab eingetragen werden, damit jede Nacht um 2 Uhr ein Dump aller Datenbanken erfolgt:


    0 2 * * * /share/Public/backup.sh


    Wobei /share/Public/ durch den Pfad zur backup.sh ersetzt werden muss.


    Damit die Änderungen reboot- und upgradesicher sind muss der Eintrag noch an anderer Stelle ergänzt werden:


    vi /mnt/HDA_ROOT/.config/crontab


    Nun muss nur noch sichergestellt sein, dass der Pfad mit den .sql-Dateien in das regelmäßige Backup eingebunden wird.

    Noch ein Hinweis:


    Wenn das Script so wie von mir empfohlen eingesetzt wird, muss man regelmäßig den Backup-Pfad von alten .sql-Dateien bereinigen.


    Wenn ein tägliches versioniertes externes Backup vorliegt, kann man auch den Dateiname ohne die Datums- und Zeitvariablen im Script verwenden, dann wird täglich das Vortagesbackup überschrieben.

    Das muss aber jeder für seine Backupsituation selbst abschätzen.

    Ein wichtiger Hinweis.


    Aktuell speichere ich (Gott sei Dank!) keine wichtigen Daten in der Datenbank.

    D.h. es reicht die Sicherung wöchentlich aus dem Share auf einen externen Datenträger zu kopieren.