Jump to content
Froxlor Forum
  • 0
BooosesThaSnipper

Fehler beim anlegen neuer Datenbanken

Question

Hi Zusammen,

ich hab gerade Froxlor auf einem neuen Server gerade frisch installiert und soweit alles eingerichtet. Läuft auch bisher alles.

OS: Debian 9

Wollte jetzt einige Datenbanken für verschiedene Kunden anlegen was auch zu Beginn ohne Probleme funktioniert hat. Nun kommt auf einmal eine Fehlermeldung, dass es nichtmehr möglich wäre eine neue Datenbank anzulegen:

 
A database error occurred

SQLSTATE[42000]: Syntax error or access violation: 1044 Access denied for user 'root'@'127.0.0.1' to database 'xxxxxxxsql1'

Versuche ich es erneut erscheint folgende Meldung:

A database error occurred

SQLSTATE[HY000]: General error: 1007 Can't create database 'xxxxxxxsql1'; database exists

 

Habe mir die entsprechenden MariaDB Logs angeschaut und das sieht meiner Meinung nach auch soweit OK aus, aber als es noch funktioniert hat, sah es anders aus:

Ohne Funktion:

                  360 Query     CREATE DATABASE `xxxxxxxsql1`
                  360 Query     INSERT INTO `panel_syslog` SET
                                        `type` = '6',
                                        `date` = '1523526125',
                                        `action` = '10',
                                        `user` = 'xxxxxxx',
                                        `text` = 'created database \'xxxxxxxsql1\''
                  360 Query     GRANT ALL PRIVILEGES ON `xxxxxxxsql1`.*
                                TO 'xxxxxxxsql1'@'127.0.0.1' IDENTIFIED BY 'password'

Zu beginn als es noch funktioniert hat:

                 9818 Query     CREATE DATABASE `xxxxxxxsql1`
                 9818 Query     INSERT INTO `panel_syslog` SET
                                        `type` = '6',
                                        `date` = '1523522601',
                                        `action` = '10',
                                        `user` = 'xxxxxxx',
                                        `text` = 'created database \'xxxxxxxsql1\''
                 9818 Query     GRANT ALL PRIVILEGES ON `xxxxxxxsql1`.*
                                TO 'xxxxxxxsql1'@'127.0.0.1' IDENTIFIED BY 'password'
                 9818 Query     SET PASSWORD FOR 'xxxxxxxsql1'@'127.0.0.1' = PASSWORD('xxxxxxx')
                 9818 Query     GRANT ALL PRIVILEGES ON `xxxxxxxsql1`.*
                                TO 'xxxxxxxsql1'@'localhost' IDENTIFIED BY 'password'
                 9818 Query     SET PASSWORD FOR 'xxxxxxxsql1'@'localhost' = PASSWORD('xxxxxxx')
                 9818 Query     FLUSH PRIVILEGES
                 
                 9819 Query     INSERT INTO `panel_databases`
                                                (`customerid`, `databasename`, `description`, `dbserver`)
                                                VALUES ('2', 'xxxxxxxsql1', 'Beschreibung', '0')
                 9819 Query     UPDATE `panel_customers`
                                                SET `mysqls_used` = `mysqls_used` + 1, `mysql_lastaccountnumber` = `mysql_lastaccountnumber` + 1
                                                WHERE `customerid` = '2'

Ein Blick in die Datenbank zeigt, dass der User nicht wirklich angelegt wird:

MariaDB [mysql]> select Host,User,Password,authentication_string,password_expired from user where user.User = 'xxxxxxxsql1';
Empty set (0.00 sec)

Die Datenbank existiert aber, so dass ich sie für einen neuen Versuch erstmal löschen muss mittels "DROP DATABASE xxxxxxxsql1;"

 

Irgendwie scheint es, dass das SQL Statement nicht ganz abgearbeitet wird.

 

Hat jemand einen Tipp für mich, wie ich hier weiterkomme?

Sollten noch wichtige Infos Fehlen, geht einfach kurz Bescheid, dann liefere ich die benötigten Daten gerne weiter.

 

Grüße

Markus

 

 

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

Hallo Markus,

ich bin mir nicht ganz sicher, ob das wirklich so stimmt, aber ich hatte mal ein Problem damit, das die Benutzernamen für die Datenbank einfach zu lang waren.
Um das Problem zu umgehen hab ich den Suffix von "sql" auf "sq" gekürzt und seither gab es keine Probleme mehr.
Wobei das Problem auch erst auftrat, als die fortlaufende Numerierung 2-stellig wurde.

Gruss cardman

Share this post


Link to post
Share on other sites
  • 0

Hi Cardman,

halte ich für relativ unwahrscheinlich, da bereits Datenbanken anderer Kunden angelegt wurden, die einen längeren Kundennamen hatten und somit inkl Suffix deutlich länger sind.

Aber danke für den Denkanstoß.

 

Grüße

Markus

Share this post


Link to post
Share on other sites
  • 0

Hi Markus,

dann hätte ich vielleicht noch einen weiteren Denkanstoss:
es kann auch zu problemen kommen, wenn verschiedene Sonderzeichen im Passwort enthalten sind. Ganz ungünstig wäre z.B. ein ' im Passwort, aber auch bei anderen Sonderzeichen hatte ich schon meine Probleme.

 

Gruss cardman

Share this post


Link to post
Share on other sites
  • 0

Hi,

mein weiteres vorgehen wäre dann testweise den Benutzer über die console direkt in der Datenbank anlegen und schauen, ob da vielleicht ein hilfreicher Fehler ausgegeben wird, bzw den generierten SQL-Code aus der Log-Datei direkt testen.
Und noch eine Frage: wurden eventuell Berechtigungen des Users "root" in der Datenbank geändert? Vielleicht hat er einfach keine Berechtigung mehr einen Benutzer anzulegen.

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, BooosesThaSnipper said:

A database error occurred SQLSTATE[42000]: Syntax error or access violation: 1044 Access denied for user 'root'@'127.0.0.1' to database 'xxxxxxxsql1'

das sagt doch halt schon alles...warum sollte es auch ansatzweise funktionieren wenn er sich als root (der die rechte zum anlegen von DBs und auch den Benutzern hat) nicht anmelden kann?

Share this post


Link to post
Share on other sites
  • 0
3 minutes ago, d00p said:

das sagt doch halt schon alles...warum sollte es auch ansatzweise funktionieren wenn er sich als root (der die rechte zum anlegen von DBs und auch den Benutzern hat) nicht anmelden kann?

So einfach ist das Problem nicht! Er kommt ja sogar soweit, die Datenbank anzulegen und diese Rechte hat nur der Root User, als kommt er rein, er macht nur nicht weiter....

Hab auch gerade nochmals die Credentials versucht die in der "userdata.inc.php" hinterlegt sind und diese funktionieren ohne Probleme.

 

CREATE DATABASE `xxxxxxsql1`;
                                       
GRANT ALL PRIVILEGES ON `xxxxxxsql1`.* TO 'xxxxxxsql1'@'127.0.0.1' IDENTIFIED BY 'password';
SET PASSWORD FOR 'xxxxxxsql1'@'127.0.0.1' = PASSWORD('xxxxxxxxxxxxxxxxxx');

GRANT ALL PRIVILEGES ON `xxxxxxsql1`.* TO 'xxxxxxsql1'@'localhost' IDENTIFIED BY 'password';
SET PASSWORD FOR 'xxxxxxsql1'@'localhost' = PASSWORD('xxxxxxxxxxxxxxxxxx');

FLUSH PRIVILEGES

INSERT INTO `panel_databases` (`customerid`, `databasename`, `description`, `dbserver`) VALUES ('10', 'xxxxxxsql1', 'Beschreibung', '0');

UPDATE `panel_customers` SET `mysqls_used` = `mysqls_used` + 1, `mysql_lastaccountnumber` = `mysql_lastaccountnumber` + 1 WHERE `customerid` = '10';

 

Manuell funktioniert es ohne Probleme...

 

Share this post


Link to post
Share on other sites
  • 0

shell != php-script...das sind für mysql unterschiedliche zugriffswege...debian 9 hat per default den root zugriff auf die shell beschränkt, das hatten wir hier auch schon 2-3x im forum...teste zudem auch unterschied 127.0.0.1 und "localhost"

Share this post


Link to post
Share on other sites
  • 0

HI,

root Zugriff und Shell hatte ich schon für die Installation anpassen müssen, da sich froxlor sonst nicht hätte installieren lassen. Ist ja die Geschichte mit Plugin Type und den Rechten.

 

Hab gerade nochmal folgendes Gemacht:

GRANT ALL ON *.* TO 'root'@'127.0.0.1';
GRANT ALL ON *.* TO 'root'@'localhost';
FLUSH PRIVILEGES;


MariaDB [mysql]> select Host,User,plugin,password_expired from user where User = 'root';
+-----------+------+--------+------------------+
| Host      | User | plugin | password_expired |
+-----------+------+--------+------------------+
| localhost | root |        | N                |
| 127.0.0.1 | root |        | N                |
+-----------+------+--------+------------------+
2 rows in set (0.00 sec)

 

Keine Besserung... bin irgendwie ratlos...

Share this post


Link to post
Share on other sites
  • 0

Hm, okay, also ich hatte da bisher keinerlei probleme auf debian 9 und wüsste auch keine änderung die darauf bezogen was "kaputt"gemacht hätte

Share this post


Link to post
Share on other sites
  • 0

Ist zwar ein paar Tage her, aber hier ein kleines Feedback:

Habe sämtliche Rechte in der Datenbank für root nochmals gelöscht und frisch angelegt. Die werte sind exakt die gleichen (output mittels diff überprüft) aber nun geht es.

Es scheint als hätte sich da irgendwas beim anlegen verschluckt.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×