Datenbanken werden nicht angelegt

Aktuell führen wir noch einige Anpassungen durch, das Forum wurde jedoch bereits live geschaltet.
  • Naja was hat die bindung der ip damit zu tun? Die kann man ja selbst beeinflussen ;)


    Normal sollte der mysql egal bei welcher distro an 127.0.0.1 gebunden sein...



    Zumal das ganze meines wissens nach von dem script auch nur auf der localhost gemacht wird

  • Doch es liegt an der Maria:

    Bitte keinen Blödsinn verzapfen.


    Wenn eine Configdatei etwas anders ist, ist es eben so. Das ist jetzt kein "Problem". Das Binding solltest auch du umstellen können.


    Natürlich könnte es sein das es am Binding liegt, warum die Datenbanken nicht angelegt werden - Das will ich nicht in abrede stellen.
    Es wäre komisch wenn das Script nicht via localhost die Datenbanken erstellt. Gibts denn dazu nix im error Log?

  • Als das /home/skripte/web Skript regelt das anlegen von Datenbanken. Dort einfach mal reinsehen und den jeweiligen Befehl von Hand eingeben oder das Skript mit den richtigen Variablen ausführen.


    ./web dbcreate xxx dbnamexy dbuserxy dbpasswdxy


    Was folgt hier als Meldung?

    Bitte die Forumsuche und das Handbuch verwenden. Wenn die Suche erfolglos war, bitte ein Thema erstellen und das Problem ausführlich beschreiben. Dieser Ablauf spart Zeit und unnötige Fragen zu immer gleichen Problemen. Sie können aber auch im Kundenbereich ein Support-Ticket erstellen.


    Gefällt Ihnen TekLab? facebook-1.pngtwitter-1.pnglinkedin-1.png

  • Die config von Debian macht eine ip Bindung nach aussen:


    bind-adress = : : (0.0.0.0 ?!?)


    Wäre das bind-adress nicht in der my.cnf würde Maria nur auf dem localhost lauschen.
    Wenn das TB Script aber die DB's und DB-Benutzer via ssh/demon local auf dem Zielserver anlegen würde, dann muss es auch bei opensuse gehen da die mysql Befehle und der Aufruf der mysql Konsole, wie unter Debian auch, gleich ist.


    Wenn aber das ganze Remote geht, wovon ich jetzt mal ausgehe, dann ist das "bind-adress" mit der Schlüssel.


    Als das /home/skripte/web Skript regelt das anlegen von Datenbanken. Dort einfach mal reinsehen und den jeweiligen Befehl von Hand eingeben oder das Skript mit den richtigen Variablen ausführen.


    ./web dbcreate xxx dbnamexy dbuserxy dbpasswdxy


    Was folgt hier als Meldung?

    Teste ich gleich mal


    <Edit />


    Die Ausgabe ist wie folgt:


    Code
    '@'localhost' (using password: YES)or user 'root
    ID1


    Bitte keinen Blödsinn verzapfen.
    Wenn eine Configdatei etwas anders ist, ist es eben so. Das ist jetzt kein "Problem". Das Binding solltest auch du umstellen können.


    Natürlich könnte es sein das es am Binding liegt, warum die Datenbanken nicht angelegt werden - Das will ich nicht in abrede stellen.
    Es wäre komisch wenn das Script nicht via localhost die Datenbanken erstellt. Gibts denn dazu nix im error Log?


    Nein in den Logs ist nichts zu finden.

  • das ganze geht ja nicht remote, das wird auf der Console ausgeführt.



    Die Bind Adresse ist eigentlich per default bei MariaDB mittels # deaktiviert, da die zeile lautet # bind 0.0.0.0 in der default install



    Es sei denn du hast plesk denn plask entfernt die # davor das man mittels plesk eben auch auf der/den IP('s) verbinden kann


  • Ja hat CF ja auch bestätigt, also daß das Script lokal auf dem Zielserver ausgeführt wird.

  • So ein kleiner Erfolg:


    Durch Tante Google bin ich auf den Code gestoßen:



    Dieser Code Funktioniert so halb, die Berechtigungen werden hier nicht korrekt übergeben aber DB und Benutzer werden schon mal angelegt.


    Ausgeführt wird das ganze so:


    Code
    ./createdb DerDatenbankname DerDatenbankBenutzer DasDatenbankPaswort


    Das Script heisst im dem Fall createdb.


    Also so weit bin ich schon mal.

  • Ich habe wohl schon das Problem gefunden.


    Die Skripte werden alle über Sudo aufgerufen.
    Da kann es vorkommen das die Pfade nicht korrekt gesetzt werden // sind.
    Stichwort secure_path


    Generell wäre es viel Sinnvoller @CFrankenstein die Pfade mit anzugeben.


    mysql --user=$mysqlusr --password=$mysqlpwd -e "$SQL"


    Besser:


    MYSQL=`which mysql`
    sqlcreate=`$MYSQL --user=$mysqlusr --password=$mysqlpwd -e "$SQL"`


    Das sollte man eigentlich mit allen "Befehlen" machen. Ist sauberer.


  • Ja kann man machen, wird in PHP OOP auch so gemacht. Hier liegt es warscheinlich aber an den $VARS (also im TB web Script), die scheinen leer zu sein soweit bin ich aber noch nicht.


    "$mysqluser" und "$mysqlpwd" hingegen sind gefüllt.


    <Edit />


    Die ganzen


    könnte man auch mit den case switch Regeln.
    Nur so ne Idee, nur weiss ich noch nicht ob das auch in Bash Scripten geht.

    2 Mal editiert, zuletzt von BdMdesigN () aus folgendem Grund: Edit hinzugefügt

  • Ich prüf die Skripte morgen mal auf einem neuen VServer durch. Was wird übergeben wenn man auf DB erstellen klickt? Diese info steht bei /var/log/auth.log dort nach ./web dbcreate suchen und hier mal die Zeile posten.

    Bitte die Forumsuche und das Handbuch verwenden. Wenn die Suche erfolglos war, bitte ein Thema erstellen und das Problem ausführlich beschreiben. Dieser Ablauf spart Zeit und unnötige Fragen zu immer gleichen Problemen. Sie können aber auch im Kundenbereich ein Support-Ticket erstellen.


    Gefällt Ihnen TekLab? facebook-1.pngtwitter-1.pnglinkedin-1.png

  • Die auth.log gibt es nicht, die brauchen wir auch nicht wenn man sich eine "Debugmsg" baut.


    Das ist das was ich gerade Teste:



    Ich lasse mir also im Echo die Vars anzeigen und das kommt dabei raus:


    Code
    user-webi@v145:/home/skripte> ./web dbcreate KDN_5999 KDN_5999 DasZuErstellendeDatenbankpasswort
    '@'localhost' (using password: YES)or user 'root
    ERROR 1044 (42000) at line 1: Access denied for user ''@'localhost' to database 'KDN_5999'
    KDN_5999 KDN_5999 DasZuErstellendeDatenbankpasswort
    KDN_5999 KDN_5999 DasZuErstellendeDatenbankpasswort
     rootpasswort


    Es fällt auf, das der DBBenutzer nicht korret aus der VAR im Script gelesen wird: ERROR 1044 (42000) at line 1: Access denied for user '' Localhost to database 'KDN_5999'
    Zweitens, wird der User root so nicht korrekt übergeben, wie man an Zeile 6 schön sehen kann.

  • #Q1="CREATE DATABASE IF NOT EXISTS $VAR_C;"
    #Q2="GRANT ALL PRIVILEGES ON $VAR_C.* TO '$VAR_D'@'%' IDENTIFIED BY '$VAR_E' WITH GRANT OPTION;"


    in


    #Q1="CREATE DATABASE IF NOT EXISTS $VAR_C;"
    #Q2="GRANT ALL PRIVILEGES ON $VAR_C.* TO '$VAR_B'@'%' IDENTIFIED BY '$VAR_D' WITH GRANT OPTION;"

    Bitte die Forumsuche und das Handbuch verwenden. Wenn die Suche erfolglos war, bitte ein Thema erstellen und das Problem ausführlich beschreiben. Dieser Ablauf spart Zeit und unnötige Fragen zu immer gleichen Problemen. Sie können aber auch im Kundenbereich ein Support-Ticket erstellen.


    Gefällt Ihnen TekLab? facebook-1.pngtwitter-1.pnglinkedin-1.png

  • Ich hab den Fehler gefunden, schuld sind die beiden:


    Code
    mysqlusr=`cat /etc/mysql/settings.ini | grep -i login | awk '{print $2}'`
    mysqlpwd=`cat /etc/mysql/settings.ini | grep -i password | awk '{print $2}'`

    Die beissen sich.


    Wenn ich aber folegendes mache:

    Code
    mysqlusr="NameDesHauptafmin"
    mysqlpwd="PasswortDesHauptadmins"

    Wird der Benutzer und die Datenbank korrekt angelegt.


    ...



    #Q1="CREATE DATABASE IF NOT EXISTS $VAR_C;"
    #Q2="GRANT ALL PRIVILEGES ON $VAR_C.* TO '$VAR_B'@'%' IDENTIFIED BY '$VAR_D' WITH GRANT OPTION;"

    Auch das ist Falsch, wenn die Anweisung wie folgt lauten soll:


    Code
    ./web dbcreate HierDerDatenbankname HierDerDatenbankBenutzer HierDasDatenbankPasswort


    Dann müsste der Code so sein:

    Code
    Q1="CREATE DATABASE IF NOT EXISTS $VAR_B;"
    Q2="GRANT ALL PRIVILEGES ON $VAR_B.* TO $VAR_C@'%' IDENTIFIED BY '$VAR_D' WITH GRANT OPTION;"
    Q3="FLUSH PRIVILEGES;"
    SQL="${Q1}${Q2}${Q3}"


    Zur Erklärung:


    $VAR_A ist die Variable dbcreate
    $VAR_B dann die für dbname
    $VAR_C für dbuser
    $VAR_D dann für dbpass


    Und damit geht es dann.
    Nun muss ich mich mal wieder in die Arrays einfummeln, so das ich das Problem mit "mysqlusr" und "mysqlpwd" gelöst bekomme.

  • So fertig und es Funktioniert wie es soll.
    Ich habe auch ein Codecleanup gemacht.


    Zum Vergleich:


    Alt (kaputt):


    Neu und funktioniert:


    1. Änderung:


    Die folgenden Zeilen sind rausgeflogen, da diese Probleme machten:


    Code
    mysqlpwd=`cat /etc/mysql/settings.ini | grep -i password | awk '{print $2}'`
    mysqlusr=`cat /etc/mysql/settings.ini | grep -i login | awk '{print $2}'`

    Damit der DB Hauptadmin und sein PW korrekt ausgelsenen werden, habe ich die entfernten Zeilen durch Folgende ersetzt:

    Code
    mysqlusr=`cat /etc/mysql/settings.ini | awk '{print $1}'`
    mysqlpwd=`cat /etc/mysql/settings.ini | awk '{print $2}'`

    Nun die grep Anweisung benötigen wir nicht mehr.


    Die /mysql/settings.ini muss nun so aussehen:

    Code
    DBHauptadmin Hauptadminpasswort
    
    
    Beispiel:
    
    
    Holger IchBinEinTollesPasswort


    2. Änderung:



    Die ganzen IF Anweisungen sind einen Aufgeräumten case Statment gewichen.



    3. Änderung:


    Die Variablen sind nun korrekt zugeordnet.


    Für dbcreate lautet die Anweisung so:


    Code
    ./web dbcreate dbname dbuser dbpass


    Für dbdelete so:


    Code
    ./web dbdelete dbname dbuser


    Für dbrename (wird das überhaupt gebraucht?):


    Code
    ./web dbrename dbaltername dbneuername dbuser


    Und für dbpasswd:



    Code
    ./web dbpasswd dbuser dbneuespasswort



    Ich bitte Euch das gefixte Script zu Testen, ich werde es mit anhängen.
    Einfach die Datei web in /home/skripte, auf dem Zielserver der die DB's hat, mit der neuen ersetzen.


    Die alte Datei bitte vorher noch Backupen.


    Die im Anhang befindliche Datei muss vorher von web.txt in web umbenannt werden.

    Dateien

    • web.txt

      (2,24 kB, 148 Mal heruntergeladen, zuletzt: )

    Einmal editiert, zuletzt von BdMdesigN () aus folgendem Grund: Typo

  • Das ist soweit richtig das man die grep anweisung. Icht bräuchte ;)



    Irgendwas scheint wohl mit deiner alten settings.ini nicht funktioniert zu haben? Denn bei mir funktioniert die settings.ini 1a...

  • Das mit der Settings war so richtig. Die Variablen in der dbcreate war vertauscht Fix kommt heute. Danke für den Test. Ich hab den Code noch einmal geprüft. Welche TekBASE Version wird verwendet? Denn in der aktuellen wird


    ./web dbcreate kundexy dbnamexy dbuserxy passwdxy


    gesendet und ist dann auch im web Skript richtig. Da bei dir jedoch nur


    ./web dbcreate dbnamexy dbuserxy passwdxy


    gesendet wurde. Wird vielleicht eine alte Datei im TekBASE genutzt? Wurde zufällig geupdatet? Wenn ja von welcher Version?

    Bitte die Forumsuche und das Handbuch verwenden. Wenn die Suche erfolglos war, bitte ein Thema erstellen und das Problem ausführlich beschreiben. Dieser Ablauf spart Zeit und unnötige Fragen zu immer gleichen Problemen. Sie können aber auch im Kundenbereich ein Support-Ticket erstellen.


    Gefällt Ihnen TekLab? facebook-1.pngtwitter-1.pnglinkedin-1.png

    2 Mal editiert, zuletzt von CFrankenstein ()

  • Das ist soweit richtig das man die grep anweisung. Icht bräuchte ;)



    Irgendwas scheint wohl mit deiner alten settings.ini nicht funktioniert zu haben? Denn bei mir funktioniert die settings.ini 1a...

    Die ini war ok, habe sie per Hand ausgelesen, alles Top.
    Sobald aber "awk '{print $2}'`" ins Spiel kommt und 2 mal hintereinander mit der selben Variable, wird die Variable überschrieben.


    Das habe ich alles mit "Debug" Ausgaben getestet.
    Man könnte die Datein auch via Arrax auslesen und dann das Array verarbeiten, aber da das hier mein erstes Bash Script ist hätte das zu lange gedauert und irgend wann muss ich auch mal Pennen ^^


    Das mit der Settings.ini geht eben nicht, siehe oben.


    Die Version aus dem Install Paket mit dem 7.6.6 Update.
    Wenn jetzt Kunde noch davor ist, ist das ja kein Problem, dann wird die Var um ein verrückt.


    Aber so Funktioniert das Script, alles geht. Auch aus dem WCP.

    3 Mal editiert, zuletzt von BdMdesigN ()

  • Ich hebe eben nochmal paar Tests gemacht:


    Mit


    Code
    #Q1="CREATE DATABASE IF NOT EXISTS $VAR_C;"
    #Q2="GRANT ALL PRIVILEGES ON $VAR_C.* TO '$VAR_B'@'%' IDENTIFIED BY '$VAR_D' WITH GRANT OPTION;"


    Passiert folgendes:


    1. Datenbank KDN_1234 wird angelegt
    2. DBuser mit KDN wird angelegt


    Nun wenn der Kunde nun aber mehrere DB's auf dem Server hat und die alle nur dem Benutzer KDN zugeordnet sind, kann es beim Löschen von nur einer DB dazu führen das der DBuser KDN auch gelöscht wird.
    Das hat dann zur folge, das der Kunde nicht mehr an seine DB's ran kommt.



    Mit:

    Code
    Q1="CREATE DATABASE IF NOT EXISTS $VAR_B;"
    Q2="GRANT ALL PRIVILEGES ON $VAR_B.* TO $VAR_C@'%' IDENTIFIED BY '$VAR_D' WITH GRANT OPTION;"

    1. DB KDN wird angelegt
    2. DBuser KDN_1234 und KDN_1235, wenn man den Kunden mehrere DB's zuweist (in diesen Fall 2).



    Mit

    Code
    Q1="CREATE DATABASE IF NOT EXISTS $VAR_C;"
    Q2="GRANT ALL PRIVILEGES ON $VAR_C.* TO $VAR_D@'%' IDENTIFIED BY '$VAR_D' WITH GRANT OPTION;"

    1. DB KDN_3491 wird angelegt
    2. DBuser KDN_91037 wird angelegt


    Wie kommt es hier zum DBuser KDN_91037 ??



    Alle drei Szenarien haben zur Folge das A) das Kundenlogin in die DB nicht funktioniert und B) das löschen auch nicht oder nur halb.


    Mir ist es ein Rätsel, warum mein Code von heute morgen und meine Test vom selbiegen funktioniert hatten.


    Wenn ich alles per Hand mache und der DB User auch den Identischen Namen von der DB hat, klappt zumindest das Löschen aus dem WCP einwandfrei. Ich konnte mich auch mit phpMyAdmin als Kunde einloggen.


    Das geht so nun nicht mehr. Ich habe nun alles 3x geprüft.

    Einmal editiert, zuletzt von BdMdesigN () aus folgendem Grund: Typo