MariaDB 10 und phpMyAdmin - Verbindungsproblem - LogIn zeigt mehr Optionen als erwartet

    VTS-872XT

    QTS 5.1.2.2533

    phpMyAdmin 5.2.1.1

    MariaDB 10 1.0.5.33


    Ich möchte auf dem NAS eine Datenbank einrichten, mit phpMyAdmin verwalten und im lokalen Netzwerk betreiben. Dabei kamen einige Probleme/Fragen auf, wäre für Unterstützung dankbar. Ich hatte beim Host meiner Website schon etwas mit phpMyAdmin gearbeitet, aber keine DB auf einem NAS aufgesetzt.


    1. Des öfteren lese ich die Empfehlung, die DB in einem Container aufzusetzen, da man auf diesem Wege nicht auf eine einzige DB beschränkt sei und Kompatibilitätsprobleme bei einem Update des QTS vermieden würden. Ich fand eine detaillierte Anleitung hierzu, die sich aber auf eine ältere QTS-Version bezog und mir dann letztlich doch zu viele Vorkenntnisse abverlangte.


    Ist es tatsächlich so, daß DB, die direkt auf dem NAS installiert sind, nach QTS-updates reihenweise zugrunde gehen? Kennt jemand eine Schritt-für-Schritt-Anleitung zur Installation einer Container-Version, die sich an Anfänger richtet?


    2. Hier habe ich gelernt, daß man die config.inc.php modifizieren soll, um mit MariaDB 10 arbeiten zu können. Nachdem ich die Empfehlung abgearbeitet habe, erscheint mir MariaDB 10 immer doppelt in der Anmeldung. Ich habe die Apps 5x neu installiert, verbunden mit Neustarts, Herrgott, immer wieder das selbe. Siehe Anhang.

    pasted-from-clipboard.png

    Was mache ich falsch?


    3. Die Zugangsdaten für die DB hinterlege ich in einer php-Datei. Der $servername wurde mir bei meinem Host vorgegeben. Hier verzweifle ich geradezu, da ich den Eindruck habe, daß die Verbindung aufgrund eines falschen $servername nicht hergestellt wird. Die php meldet keinen Fehler, zeigt aber auch keinen Erfolg an (echo: "erfolgreich hochgeladen..."), Die Seite bleibt einfach leer. Mit dem phpMyAdmin erkenne ich, daß nichts in die DB eingetragen wurde.


    Code
    $servername = "localhost";
$username = "IhrBenutzername";
$password = "IhrPasswort";
$dbname = "IhreDatenbank";

    Welcher $servername ist hier anzugeben, um aus einer php-Datei, die sich in einem Unterordner des /web/ befindet, auf die DB auf dem NAS zugreifen zu können?


    Danke vorab,

    Zitat von BillBeaver

    Ist es tatsächlich so, daß DB, die direkt auf dem NAS installiert sind, nach QTS-updates reihenweise zugrunde gehen?

    Nein. Gerade ohne Kenntnisse von Containern und wenn "irgendeine Datenbank" reicht, würde ich einfach die angebotene Qnap-App nehmen. Das geht am einfachsten.


    Wenn das nicht reine Spielerei ist, sondern die Daten in der Datenbank einen gewissen Wert haben, solltest du aber ein regelmäßiges Backup machen. Das geht einfach mit mysqldump -u root -ppassword --force --all-databases >/pfad/zum/Ziel/dump.sql in einem Cron-Job, welcher dann einmal täglich oder wöchentlich ausgeführt wird, und der Pfad zum Ziel sollte auf eine Freigabe zeigen, die von HBS regelmäßig gesichert wird. Falls dann doch mal die Datenbank kaputt geht oder die Qnap-App nicht mehr gepflegt wird, kannst du die Datenbank schnell woanders aufsetzen.


    Nachteil der Qnap-App ist, dass du auf genau die dort angebotene Version von MariaDB angewiesen bist, und du hast keine Kontrolle über die Version der DB. Meistens ist das kein Problem, aber wenn doch, empfiehlt sich ein Container oder gleich eine Linux-VM. Ich mache letzteres. Die Datenbank nutze ich auch für Kundenprojekte, und dann muss sie schon mal dieselbe Version haben wie beim Kunden auch.


    Zitat von BillBeaver

    Welcher $servername ist hier anzugeben, um aus einer php-Datei, die sich in einem Unterordner des /web/ befindet, auf die DB auf dem NAS zugreifen zu können?

    Da muss der Name oder die IP vom NAS rein. Eine IP vermeidet Probleme bei der Namensauflösung, verlangt aber eine feste Adresse beim NAS, die nicht von DHCP vergeben wird. Bei Betrieb über Container oder VM muss entsprechend die IP vom Container oder der VM da rein.

    Danke, Anthrazite.

    Zitat von Anthracite

    mysqldump -u root -ppassword --force --all-databases >/pfad/zum/Ziel/dump.sql in einem Cron-Job,

    was ist ein Cron-Job? Gäbe es für diesen Sicherungsauftrag keine GUI oder meinst du damit ein Bordmittel/App?


    Zitat von Anthracite

    Falls dann doch mal die Datenbank kaputt geht oder die Qnap-App nicht mehr gepflegt wird, kannst du die Datenbank schnell woanders aufsetzen.

    Auf einem NAS mit einer älteren Firmware? Wie würde ich denn aus der Sicherung eine Datenbank herstellen, mit der ich dann weiterarbeite?

    Hallo Anthracite,

    ich habe eine Freigabeordner für den dump angelegt, vollen Zugriff haben alle Administratoren und ein Nutzer. Der Freigabeordner ist leer.

    Anschließend habe ich mich per SSH an dem NAS angemeldet und o.a. Befehl durchlaufen lassen.

    "pfad/zum/Ziel/" habe ich ersetzt durch "/Name des Freigabeordners/" oder "//IP des NAS/Name des Freigabeordners/", jeweils gefolgt durch "dump.sql".

    Ich bekomme immer die

    Code
    "no such file or directory"

    Fehlermeldung zurück.


    Bin für sachdienliche Hinweise verbunden, danke vorab.

    Einmal editiert, zuletzt von BillBeaver () aus folgendem Grund: Ein Beitrag von BillBeaver mit diesem Beitrag zusammengefügt.

    Zitat von BillBeaver

    was ist ein Cron-Job

    Ein Cron-Job ist ein zeitgesteuert aufgerufenes Programm bei allen Unix-artigen Betriebssystemen.

    Siehe hier

    Add items to crontab – QNAPedia

    wie du einen Eintrag auf dem NAS einfügst. Der dortige Link bei "Background" zu WIkipedia hilft, wenn du keine Ahnung hast, was Cron ist.


    Zitat von BillBeaver

    sachdienliche Hinweise

    Du musst den Unix-Dateinamen des Ordners angeben, nicht den SMB-Freigabenamen, denn der Zugriff erfolgt ohne SMB. Auf QNAP-NAS lautet der Name üblicherweise /share/Freigabe. Ich würde dann gleich noch einen Unterordner für das Backup anlegen, so dass der Name der Datei dann so lautet wie /share/Freigabe/DB-Backup/dump.sql.


    Zitat von BillBeaver

    Auf einem NAS mit einer älteren Firmware?

    Ja, geht. Es kommt nur auf die Datenbank drauf an, nicht auf das Betriebssystem. Das Dump kannst du auch auf dem Windows-PC, Mac oder Linux-Rechner einspielen. Du brauchst dort nur eine installierte MySQL- oder MariaDB-Datenbank. Das Dump ist eine reine Ascii-Datei und kann auch editiert werden, insbesondere können einzelne Statements daraus entnommen und in der DB eingespielt werden. Das ist praktisch, wenn man nicht die ganze Datenbank, sondern nur einzelne Daten kaputt gemacht hat, aber dann sollte man wissen, was man macht.

    Zitat von Anthracite

    Du musst den Unix-Dateinamen des Ordners angeben, nicht den SMB-Freigabenamen

    Bedankt. Leider greife ich jetzt wieder per VPN zu, da scheint der SSH-Zugang wohl nicht zu funktionieren. Ich werde versuchen, den Cron-Job einzurichten, wenn ich mich das nächste Mal im LAN bewege.

    Hallo Anthrazite,

    es ist mir gelungen, dem crontab die Anweisung

    Code
    40 5 * * * mysqldump -u root -ppassword --force --all-databases >/pfad/zum/Ziel/dump.sql

    hinzuzufügen.

    Wenn ich jetzt versuche, das daemon neuzustarten mit

    Code
    crontab /etc/config/crontab && /etc/init.d/crond.sh restart

    bekomme ich die Meldung

    Code
    "must be suid to work properly"

    zurück und es wird auch kein dump.sql angelegt. Internet hält sich bedeckt zu der Fehlermeldung. Ideen? Danke vorab.

    Ich habe noch einen. Anstatt die Aufforderung als Cronjob zu verpacken, habe ich erstmal versucht, sie unmittelbar auszuführen. Das endete damit, das mysqldump nicht erkannt wurde:

    Code
    mysqldump -user1 root –p --all-database > dump.sql
-sh: mysqldump: command not found

    Dann fand ich das

    MariaDB dump


    Dem habe ich entnommen, das mysqldump durch mariadb-dump ersetzt wurde, aber da bekomme ich auch:

    Code
    [temp@872XT ~]$ mariadb-dump --databases
-sh: mariadb-dump: command not found

    Kurzum, ich bekomme es nicht hin, eine Sicherung unmittelbar anzustoßen, geschweige denn, einen Zeitplan dazu aufzusetzen.

    Einmal editiert, zuletzt von BillBeaver () aus folgendem Grund: Ein Beitrag von BillBeaver mit diesem Beitrag zusammengefügt.

    Zitat von BillBeaver

    bekomme ich die Meldung

    Code
    "must be suid to work properly"

    zurück und es wird auch kein dump.sql angelegt. Internet hält sich bedeckt zu der Fehlermeldung. Ideen? Danke vorab.

    Die Meldung bedeutet, dass der Befehl mit Super-User-ID ausgeführt werden muss - also mit dem root-Account (admin).

    Mod: Unnötiges Direktzitat entfernt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen


    Habe ich verstanden danke. Jetzt glaube ich, daß ich dem NAS noch irgendwie einen SQL-Pfad beibiegen muss, um die mysqldump - command not found Meldung zu überwinden.


    Gibt es keine einfachere Lösung, zB. mit Bordmitteln, um ein Alltagsproblem wie die regelmäßige Sicherung einer Datenbank zu organisieren?

    um Gottes Willen:


    ssh:


    /mnt/ext/opt/mariadb/bin/mysqldump -u root -ppassword --force --all-databases >dump.sql


    führt zu :


    Code
    mysqldump: Got error: 2002: "Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)" when trying to connect

    Einmal editiert, zuletzt von BillBeaver () aus folgendem Grund: Ein Beitrag von BillBeaver mit diesem Beitrag zusammengefügt.

    Bei der Nutzung von Cronjobs wird gerne vergessen, das der User, mit dem der Cronjob ausgeführt wird, nicht zwingend der User ist, der den Job erstellt und getestet hat.

    Ich habe mir deshalb angewöhnt, immer die vollständige Pfadangabe zur ausführbaren Datei mit anzugeben. Also so:

    Zitat von BillBeaver

    /mnt/ext/opt/mariadb/bin/mysqldump

    Zitat von BillBeaver

    -ppassword

    Da steht jetzt sicher nicht 'password', sondern dein richtiges Passwort?


    Die Fehlermeldung tritt aber üblicherweise auf, wenn der MySQL- oder MariaDB-Server (=Daemon) nicht gestartet ist. Siehe z. B. hier.


    Zitat von dr_mike

    Die Meldung bedeutet, dass der Befehl mit Super-User-ID ausgeführt werden muss - also mit dem root-Account (admin).

    Ein sudo vor dem Befehl tut's auch und ist das Gleiche. (Dr Mike weiß das sicherlich; das ist eine Info für BillBeaver.)

    Danke soweit. Nochmal zusammenfassend zum Verständnis:

    • Ich möchte MariaDB mittels PHPMyAdmin verwalten, was schon leidlich funktioniert.
    • Anthracite empfahl eine zeitgesteuerte Sicherung der Datenbank mittels Cronjob, um nach einem Firmwareupdate des NAS und möglichen Kompatibilitätsproblemen weiterhin Zugriff auf die DB zu haben,
    • Zunächst versuche ich, den Sicherungsbefehl direkt zu übermitteln, bevor ich daraus eine zeitgesteuerte Anweisung mache
    • /usr/local/mysql/bin/mysqldump -u [Name eines Nutzers der DB mit allen Rechten] -[Passwort dieses Nutzers] [Name der zu sichernden Datenbank] >dump.sql führt mich zu
    Code
    mysqldump: Got error: 2002: "Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)" when trying to connect
    • /mnt/ext/opt/mariadb/bin/mysqladmin -u root -p status führt mich zu "
    Code
    /mnt/ext/opt/mariadb/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/tmp/mysql.sock' exists!"
    • /mnt/ext/opt/mariadb/bin/mysqld start endet in
    Code
    231129  0:07:46 [Note] /mnt/ext/opt/mariadb/bin/mysqld (mysqld 5.5.57-MariaDB) starting as process 7148 ...
231129  0:07:46 [Warning] Can't create test file /mnt/ext/opt/mariadb/data/872XT.lower-test
/mnt/ext/opt/mariadb/bin/mysqld: Can't change dir to '/mnt/ext/opt/mariadb/data/' (Errcode: 2)
231129  0:07:46 [ERROR] Aborting
231129  0:07:46 [Note] /mnt/ext/opt/mariadb/bin/mysqld: Shutdown complete
    • Die Statusabfrage und das mysqld start habe ich versucht nach allem, was ich auf der von Athracite verlinkten Seite gelesen hatte.
    • Aber ist es nicht so, daß der Datenbankserver laufen muss, wenn die App auf dem NAS läuft? Siehe Abbildung
    • eine Idee noch: Die Statusabfrage sucht /tmp/mysql.sock,; die MariaDB 10 App gibt dagegen an "Domänen-Socket: /var/run/mariadb10.sock"; wie übergebe ich denn das der Statusabfrage?
    Zitat von BillBeaver

    /usr/local/mysql/bin/mysqldump -u [Name eines Nutzers der DB mit allen Rechten] -[Passwort dieses Nutzers] [Name der zu sichernden Datenbank] >dump.sql führt mich zu

    Der Dump sollte nicht mit irgendeinem Benutzer erstellt werden, sondern immer mit root, da andere Benutzer üblicherweise nicht auf alle Datenbankobjekte zugreifen dürfen, und dann fällt der Dump auf die Nase. Aber nicht das ist die Ursache für deine Fehlermeldung, sondern dass der Datenbank-Daemon nicht läuft.


    root hat übrigens eine Besonderheit gegenüber anderen DB-Zugängen: Die Anmeldung kann idR. nur lokal erfolgen. Wenn du dich mit ssh am NAS angemeldet hast und greifst da auf die DB zu, dann ist das der Fall, nicht aber, wenn du auf dem PC ein Programm startest, das auf die DB zugreift.

    Zitat von BillBeaver

    /mnt/ext/opt/mariadb/bin/mysqld start endet in

    Setz mal ein sudo davor, damit admin der User ist, der die DB startet. Das könnte deine nachfolgende Fehlermeldung erklären. Dein normaler User hat möglicherweise keinen Zugriff auf irgendwelche MariaDB-Verzeichnisse oder Dateien.


    Wenn nicht, schau mal, ob es das Verzeichnis

    Zitat von BillBeaver
    Code
    Can't change dir to '/mnt/ext/opt/mariadb/data/' (Errcode: 2)

    überhaupt gibt. (Ich habe MariaDB nicht als Qnap-Package installiert, sondern in einer VM, und da mögen die Pfade anders sein.)

    Zitat von BillBeaver

    Aber ist es nicht so, daß der Datenbankserver laufen muss, wenn die App auf dem NAS läuft?

    Im Prinzip schon, nicht aber, wenn der Start des Daemons aus irgendwelchen Gründen scheitert. App stoppen (nicht deinstallieren!) und wieder starten kann auch dazu führen, dass der MariaDB-Daemon wieder läuft.

    Zitat von Anthracite

    schau mal, ob es das Verzeichnis

    ... überhaupt gibt.


    Wie geht das? DIR kennt es nicht. Ich vermute, über das GUI des QTS kann ich diese Verzeichnisse nicht durchsuchen.


    Hat es denn keine fertigen Lösungen für Allerweltsaufgaben wie regelmäßige Datensicherung? Das kommandozeilenorientierte Herangehen überfordert mich offenbar.

    Zitat von BillBeaver

    Wie geht das? DIR kennt es nicht.

    ls -l ist dein Freund.


    Eine Liste der wichtigsten Befehle gib t es hier bei Ionos (wobei die Liste schon etwas lang ist; da sind auch einige Befehle dabei, die ich noch nie benutzt oder gebraucht habe).

    Zitat von BillBeaver

    Hat es denn keine fertigen Lösungen für Allerweltsaufgaben wie regelmäßige Datensicherung?

    In dem Falle handelt es sich um einen Backupmechanismus eines Drittproduktes. Die MariaDB-App müsste dieses Backup in ihr GUI integrieren.


    Aber dein erstes Problem ist, dass der MariaDB-Daemon scheinbar nicht läuft.


    Hast du mysqld start mit vorangestelltem sudo probiert? Was ist das Ergebnis?

    Code
    Can't change dir to '/mnt/ext/opt/mariadb/data/' (Errcode: 2)

    Das Verzeichnis /data existierte nicht. Ich habe es mit mkdir angelegt. Warum, weiß ich nicht.


    Zitat von Anthracite

    Hast du mysqld start mit vorangestelltem sudo probiert?

    Ja, Ergebnis nunmehr:

    Code
    231202  2:20:13 [Note] /mnt/ext/opt/mariadb/bin/mysqld (mysqld 5.5.57-MariaDB) starting as process 9627 ...
/mnt/ext/opt/mariadb/bin/mysqld: Please consult the Knowledge Base to find out how to run mysqld as root!
231202  2:20:13 [ERROR] Aborting
231202  2:20:13 [Note] /mnt/ext/opt/mariadb/bin/mysqld: Shutdown complete
    Zitat von BillBeaver

    Please consult the Knowledge Base to find out how to run mysqld as root!

    Und? Hast du das gemacht?


    Dann wärst du z. B. hierauf gestoßen. Der Daemon will nicht als root/admin gestartet werden. sudo war also ein Irrweg. Oft liegen solche Probleme an falschen Rechten, dann hilft ein sudo weiter. Hier waren's aber nciht die Rechte, sondern das Verzeichnis hat gefehlt. Mit dem manuell angelegten Verzeichnis solltest du den Daemon noch mal normal starten, d. h. ohne sudo. Klappt das jetzt? Wenn nein, bitte erst einmal selbst nach der Fehlermeldung googlen,

    • weiteres Administratorenkonto auf dem NAS erstellt
    • Zugriff auf Freigabeordner "Web" gewährt (da liegt das PHPMyAdmin)
    • mit dem neuen Nutzer per ssh angemeldet
    • /mnt/ext/opt/mariadb/bin/mysqld start
    • Ergebnis:
    Code
    231205  0:16:18 [Note] /mnt/ext/opt/mariadb/bin/mysqld (mysqld 5.5.57-MariaDB) starting as process 14431 ...
231205  0:16:18 [Warning] Can't create test file /mnt/ext/opt/mariadb/data/XXXX.lower-test
231205  0:16:18 [ERROR] mysqld: File './mysql-bin.index' not found (Errcode: 13)
231205  0:16:18 [ERROR] Aborting
231205  0:16:18 [Note] /mnt/ext/opt/mariadb/bin/mysqld: Shutdown complete
    • Die Suche nach mysql-bin.index ( find / -dateiname) mit dem neuen Admin blieb erfolglos (permission denied in allen Verzeichnissen)
    • Die selbe Suche mit sudo war erfolgreich:
    • /share/CE_CACHEDEV1_DATA/.mariadb10/data/mysql-bin.index
    • Ich habe nach Möglichkeiten gesucht, dem neuen Administrator Rechte zuzuweisen (chmod irgendwas?), wüsste aber nicht, welche Verzeichnisse das umfassen müsste und wie der Befehl dann im Einzelnen aussieht.

    Vermutlich war schon das hier

    Zitat von BillBeaver

    Das Verzeichnis /data existierte nicht. Ich habe es mit mkdir angelegt. Warum, weiß ich nicht.

    der Fehler. Das Verzeichnis data existierte schon, aber an einer anderen Stelle. Entweder ist die Konfiguration in my.cnf fehlerhaft oder es ist ein Link verloren gegangen (warum auch immer, hatte ich aber auch schon mal nach einem qts-Uptade).


    Den Link kannst du anlegen mit

    Code
    cd /mnt/ext/opt/mariadb
ln -s /share/CE_CACHEDEV1_DATA/.mariadb10/data data

    Das Verzeichnis /mnt/ext/opt/mariadb/dump muss gegebenenfalls vorher entfernt werden (mit rm und rmdir oder mit mv umbenennen), falls es noch existiert.


    Rechteprobleme, wenn sie auftreten sollten, kannst du mit chmod lösen. Auf einem privaten NAS, welches nicht von außen erreichbar ist, kannst du großzügig sein, z. B. chmod 777 Datei-oder-Verzeichnis (aber bitte nicht auf einem Firmen-NAS).

    • [/mnt/ext/opt/mariadb/data/] - data mit rmdir entfernt
    • [/mnt/ext/opt/mariadb/dump] - Verzeichnis "dump" nicht vorhanden
    • [ln -s /share/CE_CACHEDEV1_DATA/.mariadb10/data data] ausgeführt, danach erschien in dem Verzeichnis ein "data@"
    • im Wurzelverzeichnis [sudo chmod -R 777 mnt/ ] ausgeführt, ohne Fehlermeldung, bekomme aber nach

      /mnt/ext/opt/mariadb/bin/mysqld start 
    • wieder folgendes zurück:
    Code
    Warning: World-writable config file '/etc/my.cnf' is ignored
231205 23:54:23 [Note] /mnt/ext/opt/mariadb/bin/mysqld (mysqld 5.5.57-MariaDB) starting as process 15857 ...
231205 23:54:23 [Warning] Can't create test file /mnt/ext/opt/mariadb/data/XXXXX.lower-test
/mnt/ext/opt/mariadb/bin/mysqld: Can't change dir to '/mnt/ext/opt/mariadb/data/' (Errcode: 13)
231205 23:54:23 [ERROR] Aborting
231205 23:54:23 [Note] /mnt/ext/opt/mariadb/bin/mysqld: Shutdown complete
    Zitat von BillBeaver
    Code
    Warning: World-writable config file '/etc/my.cnf' is ignored

    chmod 777 auf das File war falsch, mag der sql daemon wohl nicht.

    chmod 700 /etc/my.cnf

    oder

    chmod 644 /etc/my.cnf

    sollten passen