Brauche Hilfe zur Korrektur eins Shellscripts zur Erstellung einer Datenbank mit User

cabriofahrer

Well-Known Member
Es handelt sich eigentlich um ein shellscript für Debian, aber da es sich um shellscript handelt, würde es sicherlich auch unter FreeBSD funktionieren und könnte darüber hinaus auch für alle hier interessant sein. Das Skript ist fehlerhaft, und diese Fehler müssen gefunden werden. Eventuell liegen auch Fehler in der Formatierung vor. OK, hier ist es:

Code:
#!/bin/bash
# Dieses Skript erstellt eine Datenbank und einen User mit Rechten.
# Defaults
DB_ROOT=""
DB_ROOT_PASS=""
DB_NAME=""
DB_USER=""
DB_PASS=""
 
# Wir nehmen den Input des Users auf
read -e -p " + Root User des mysql servers: " DB_ROOT
read -e -s -p " + Passwort für den Root User: " DB_ROOT_PASS; echo
read -e -p " + Nombre de la base de datosName der Datenbank (Ohne Abstände und Sonderzeichen): " DB_NAME
read -e -p " + Name des neuen mysql Users (oder einer, der schon existiert): " DB_USER
read -e -s -p " + Passwort des neuen Users: " DB_PASS;
echo
echo
# Wir schaffen einen neuen sql user
mysql -u ${DB_ROOT} -p${DB_ROOT_PASS} -e "CREATE USER '${DB_USER}'@'localhost' IDENTIFIED BY '${DB_PASS}'; GRANT USAGE ON * . * TO '${DB_USER}'@'localhost' IDENTIFIED BY '${DB_PASS}';"
 
# Wir checken Fehler
if [ $? == 0 ]; then
        echo " Der User ${DB_USER} ist erfolgreich erstellt worden."
 
        # Wir schaffen die neue Datenbank
        mysql -u ${DB_ROOT} -p${DB_ROOT_PASS} -e "CREATE DATABASE IF NOT EXISTS ${DB_NAME} DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL PRIVILEGES ON ${DB_NAME} . * TO '${DB_USER}'@'localhost';"
 
        # Wir checken Fehler
        if [ $? == 0 ]; then
                echo " Die Datenbank ${DB_NAME} ist erfolgreich erstellt worden."
                echo " Der User ${DB_USER} hat Rechte über die Datenbank ${DB_NAME}."
        else
                mysql -u ${DB_ROOT} -p${DB_ROOT_PASS} -e "DROP USER '${DB_USER}'@'localhost';"
                exit
        fi
 
else
        echo " Wenn mysql ERROR 1396 ausgibt, bedeutet das wahrscheinlich, dass der User bereits existiert."
        echo " Probiere einen anderen Usernamen aus."
        exit
fi
 
Erster Fehler ist die erste Zeile, typischer linux-/bash'ism. /bin/bash gibt es auf FreeBSD nicht. Entweder bash installieren und #!/usr/local/bin/bash da hin schreiben oder, besser, das script als portables posix (bourne) shellscript formulieren und #!/bin/sh verwenden.
 
Wie gesagt, dass Skript ist für Debian gedacht, von daher wird es kein Fehler sein. Aber trotzdem Danke für den Hinweis, den ich in Bezug auf Anpassung von Linux Skripten für FreeBSD sehr wichtig finde.

Mittlerweile ist mir in Zeile 12 am Ende ",echo" aufgefallen, das gibt wohl keinen Sinn, oder?

Und wie est es am Anfang mit diesem Teil hier:

Code:
DB_ROOT=""
DB_ROOT_PASS=""
DB_NAME=""
DB_USER=""
DB_PASS=""

Ist das so eine korrekte Definition der Variablen, die später benutzt werden?

Nach den beiden "echo" in Zeile 16 und 17 scheint einfach eine Ausgade zu fehlen oder sind die überflüssig?
Zur Klarstellung: Dieses Skript ist eine (m.E. gezielt fiese) Aufgabenstellung, die man lösen soll.
Der praktische Nutzen des Skripts ist jedoch, falls man es löst, auch nicht von der Hand zu weisen.
 
Das echo in Zeile 12 macht IMHO wirklich keinen sinn, sollte aber auch nicht stören. Da bash script zwischen ; und einem newline nicht unterscheiden sollte. Man sieht ggf besser die Trennung zwischen einer Passwort Eingabe ohne echo (-s) und dem DB_Namen das wars dann aber glaub auch schon.
In BASH ist es so weit ich weiss nicht nötig Variablen zu deklarieren. Anders als bei C z.B.. Es in dieses Script zu schreiben verfolgt wohl eher dem Ziel mögliche Umgebungsvariablen mit gleichem Namen lokal in diesem Script zu überschreiben. Damit keine Seiteneffekte auftreten.
echos sind logische Trenner da sie einfach nur ein entsprechendes Newline ausgeben. Ansonsten kämen die ausgaben der If abfrage sofort nach der Eingabe. Ist nicht schlimm sieht aber kacke aus
Ein üblicher verdächtiger wenn scripte nicht funktionieren wie sie sollen sind fehlerhafte escape sequenzen... Ich würde z.B. erwarten, das die einfachen Hochkommas ausserhalb eines Scripts zwar funktionieren, innerhalb des Scriptes dann nicht mehr... weil es dort ein \ braucht. Was auch noch gerne vorkommt, sind \n und \r also Newline und Carriage Return an Stellen wo sie nicht hin gehören.
Bash hat soweit ich weiss einen Debug modus, bei dem du erkennen könntest wie der Befehl aussieht wenn er übergeben wird... ich hab weder ein Bash am start noch ein mysql. Und mein letztes aufwendiges Debugging ist auch schon wieder 3 oder 4 Jahre her.
Man müsste am besten sehen wo der fehler genau entsteht... so würde ich nach dem ersten MySQL commando erstmal zu debug zwecken eine pause reinbringen (das erwartet dann ein return um fortzufahren) und wenn es diese pause erreicht hat erst mal auf der Datenbank prüfen ob der user angelegt wurde.
 
debug output per 'set -x'.
Neben den angesprochenen ' (und damit fehlende variablen expansion) sehe ich im SQL noch leerzeichen bei den GRANTs (* . *), das wird so auch nichts.
 
Unter Debian musst du dich nicht als Root bei MySQL(MariaDB) anmelden du kannst auch einfach folgendes verwenden:
Code:
mysql --defaults-extra-file=/etc/mysql/debian.cnf
Wenn du das öfters machen musst, dann würde ich dir Ansible ans Herz legen. Damit kann man solche Sachen sehr einfach einrichten:
Code:
- name: Create database user
  mysql_user:
    name: "{{ gitea_db_user }}"
    password: "{{ gitea_db_pass }}"
    priv: "{{ gitea_db_priv }}"
    state: present

- name: Create database gitea
  mysql_db:
    name: giteadb
    state: present
Gruss
 
Hat das echo jetzt einen Sinn? Hat es keinen? Wie könnte man nur rausfinden? Wenn doch nur die Manpage... oh Moment:

-s Silent mode. If input is coming from a terminal, characters are not echoed.

Da man hier ein Passwort abfragt, schaltet man natürlich die Ausgabe der eingegebenen Zeichen ab. Das heißt demnach, dass auch die Newline durch das bestätigende Return nicht ausgegeben wird. Damit sich das Interface zum User hin "natürlich" anfühlt, fügt man die Newline eben künstlich hinzu. Dasselbe passiert weiter unten bei DB_PASS.

Die Angabe der Datenbank bei GRANT könnte falsch sein. Da sind zu viele Leerzeichen. Statt
Code:
GRANT USAGE ON * . *
versuch
Code:
GRANT USAGE ON *.*

Desweiteren sind Hochkomma bei MySQL was anderes als Backticks. Ich weiß, dass manche Sachen durch Hochkomma keine gültigen Bezeichner für Tabellen und Datenbanken werden, mit Backticks aber schon. Versuch also, alle ' durch ` zu ersetzen, wo sie einen Tabellen-/User-/Datenbank-Namen einschließen. Dann aber darauf achten, das vor der Shell richtig zu escapen.

Edit: https://stackoverflow.com/questions...fference-between-a-backtick-and-an-apostrophe
 
Vielen Dank für Eure Hinweise. Jedoch glaube ich mittlerweile, dass das Skript vielleicht nicht fehlerhaft ist wie ursprünglich angenommen, sondern dass sich beim Copy und Paste (Das Skript wurde ursprünglich im .docx-Format zugänglich gemacht, ich habe es dann in pluma kopiert und dem Dokument eine .sh-Endung verpasst, um den Code in Farben anzuzeigen.) irgendwelche Fehler, z.B. Leerzeichen eingeschlichen haben. Deswegen will ich auch grundsätzlich mal fragen, ob das sein kann, dass man beim Kopieren von Code über das clipboard Probleme bekommen kann. Ich habe z.B. auch aus PDF-Dateien php-Beispiele kopiert und gemerkt, dass der Code dann im Zieldokument nicht richtig erscheint und korrigiert werden muss.

Ist dazu etwas bekannt? Ich habe im Internet mehrere Meldungen gefunden, dass es irgendwelche Probleme mit Copy und Paste geben kann, auch in Windows 10.

debug output per 'set -x'.

Also wenn ich "./skript.sh set +x" mache, ergibt sich kein anderer oder zusätzlicher Output. Ist das denn richtig so oder mache ich da etwas falsch?
 
.docx bzw eigentlich alles was von Microsoft kommt, kann Fehler verursachen. Diese Produkte sind nämlich sehr Autokorrektur freudig.
Aus einem ASCII doppelten Hochkomma (auch Quota genannt) wird da ganz schnell ein UTF8 oder 16 Anführungszeichen. Sachen die man klein braucht werden capitalized und eins weiter gesetzt weil sie hinter einem Punkt stehen und somit als Satzanfang interpretiert werden. Und neue Zeilen haben oft ein \r zu viel. Das kann auch PDF's betreffen, wenn ein solches Dokument zu Grunde lag.
Wir haben das Problem hauptsächlich bei Mails über Outlook

Ja du machst da was falsch... das set +x muss IN das script rein. Am besten direkt unter das #! (Shebang)
 
Zurück
Oben