Cannot get connection to config DB.

[KurtS]

Hallo

Im Forum wimmelt es von Problemen mit den Befehlen

registerserver

registerfilestore

meistens mit dieser Fehlermeldung:

server could not be registered:
Server response:
 com.openexchange.admin.rmi.exceptions.PoolException: DBP-0001 Category=5 Message=Cannot get connection to config DB. exceptionID=-269700059-2

Ich habe alle Foren durchgeackert und habe festgestellt, dass es oft durch die Einträge im Hosts verursacht wird. Das ist bei mir definitiv nicht der Fall.

Ich bin genau der Installationsanleitung für Ubuntu 8.04 gefolgt, mit einem Unterschied: Ich habe alle Befehle mit sudo ausgeführt, denn dieser Zusatz wird in der Anleitung oft weggelassen, aber dann geht der Befehl nicht.

Nach über sechs Stunden üben und Fehlersuchen mit nochmaligem neu Aufsetzen vermute ich den Fehler hier:
Im Log steht irgendwo:

Caused by: java.sql.SQLException: Access denied for user 'openexchange'@'localhost' (using password: YES)

Offenbar wird also der registerserver-Befehl mit dem User openexchange ausgeführt und der hat in MySQL die entsprechenden Rechte nicht.

Was ist hier genau zu tun?

Der Fehler ist übrigens zu 100% reproduzierbar.

KurtS

[Martin Heiland]

Hallo KurtS,

diese Fehlermeldung deutet auf ein Konfigurationsproblem hin. Beim Aufsetzen der Datenbank (initconfigdb) wird versucht einen Datenbankbenutzer "openexchange" anzulegen. Dies funktioniert nur, wenn das MySQL "root" Passwort nicht gesetzt ist. Falls dieser Benutzer nicht existiert, schlagen natürlich weitere Kommandos fehl.

Schau bitte nach, ob das Schema "configdb" in deiner MySQL Datenbank existiert (show databases). Falls nicht, wurde das Kommando "initconfigdb" nicht erfolgreich ausgeführt, vermutlich weil der MySQL "root" account passwortgeschützt ist. Während der OX Installation musst du kurzzeitig das Passwort entfernen, oder den Benutzer "openexchange" von Hand anlegen.

In der Installationsanleitung ist das ja beschrieben: "Note: The -a parameter adds an administrative account to mysql, this administrative account is required for the creation of the oxdatabase database, you may find problems following the instructions of this tutorial if you either set a mysql root password or do not create this administrative account, if you have manually setup this administrative account, grant the permissions for database creation or you may find a problem in the context creation."

Gruß

[KurtS]

Danke für die Antwort. Ich kenne die Falle mit dem MySQL-Root-Passwort, deshalb habe ich keines gesetzt (auch nicht nachträglich gelöscht). Ich denke bereits initconfigdb wäre mit gesetztem Root-Passwort schief gelaufen.

configdb ist vorhanden, der openexchange-User ist ebenfalls vorhanden, einmal mit Permissions für "Hosts Any" und einmal mit Permissions für "localhost", je mit dem gleichen Passwort <db_password> gesichert.

Es muss etwas in den Scripts registerserver und registerfilestore schief laufen. Dies ist nicht mein erster OX, den ich mit Ubuntu aufsetze, bisher lief das immer. Dies ist nur eine schnellere Maschine.

Wurde an den Scripts was geändert seit der vorigen Version?

[KurtS]

Zusatztest

admin@server:~$ mysql -u openexchange -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 5.0.51a-3ubuntu5.5 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

Das funktioniert, also wäre der User openexchange mit dem <db_password> verifiziert.

[Martin Heiland]

Hallo,

die Skripte leiten lediglich die Parameter weiter, die eigentliche Logik dafür steckt in einem Teil vom OX.

Wurde das Schema angelegt? Ansonsten kannst du initconfigdb auch mehrfach aufrufen und schauen was schief geht. Die darauf folgenden Befehlen benötigen eine Datenbank und schlagen definitiv fehl falls initconfigdb nicht korrekt durchgelaufen ist.

Gruß

[KurtS]

Die configdb wurde sicher richtig angelegt mit dem Befehl:

sudo /opt/open-xchange/sbin/initconfigdb --configdb-pass=<db_password> –a

wobei ich anstelle <db_password> natürlich ein Passwort eingegeben habe, welches ich auch im nächsten Befehl verwende:

sudo /opt/open-xchange/sbin/oxinstaller --no-license \
--servername=oxserver --configdb-pass==<db_password> \
--master-pass=<admin_master_password> --ajp-bind-port=localhost

Was wird im MySQL mit <db_password> genau gemacht? Wie kann ich das prüfen?

Wird <db_password> dem openexchangeuser gegeben?

Gruss Kurt

[Martin Heiland]

Hallo Kurt,

korrekt - das db_password wird für den Benutzer "openexchange" verwendet, das ist der einzige Benutzer über den OX auf die Datenbank zugreift. MySQL "root" brauchen wir nur beim initialisieren der Datenbank - zu dem Zeitpunkt wird dann das Passwort gesetzt.

Gruß

[Adrian Badertscher]

Hallo Kurt,

korrekt - das db_password wird für den Benutzer "openexchange" verwendet, das ist der einzige Benutzer über den OX auf die Datenbank zugreift. MySQL "root" brauchen wir nur beim initialisieren der Datenbank - zu dem Zeitpunkt wird dann das Passwort gesetzt.

Gruß

Guten Abend Martin,

für die ox_* Datenbank, die für den Kontext angelegt wird, braucht Ihr aber einen weiteren Benutzer, wenn mich nicht alles täuscht?

Diese Datenbank wird über den Benutzer openexchange erstellt, deswegen braucht dieser ein alle Rechte auf den Datenbank Server, und nicht lediglich auf die eine Datenbank.

Weswegen aber werden eigentlich zwei 'openexchange' Benutzer angelegt, einer mit lokalenzugriff Rechten und einen mit 'weltweiten'? Wofür wird der Zweitere gebraucht, und wieso benötigt man dann noch den Ersteren?

Werde den Tipp bezüglich des Passworts noch umsetzen, vielen Dank dafür.

Gruss,

Adrian Badertscher

[Martin Heiland]

Hallo,

wir legen lediglich einen "openexchange" Datenbankbenutzer an, der sich per default nur von localhost einloggen kann. Möglicherweise wurden die Installationsscripte schon mehrfach und mit anderen Parametern aufgerufen?

OX greift über einen einzigen Datenbankbenutzer auf die Datenbank zu. Zuerst auf das Schema "configdb" dessen Zugangsdaten in der configdb.properties stehen. In der configdb stehen dann die Pfade und Zugangsdaten für die "echten" Datenbanken. Das ist etwas kompliziert aber sehr sinnvoll wenn man mit sehr vielen Datenbank Schema und MySQL Clustern zu tun hat.

Gruß

[KurtS]

Also ich habe mal getestet, was alles vorhanden ist:

$ mysql -u openexchange -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 69
Server version: 5.0.51a-3ubuntu5.5 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use configdb
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| configdb           |
| mysql              |
+--------------------+
3 rows in set (0.00 sec)

mysql> show tables;
+------------------------+
| Tables_in_configdb     |
+------------------------+
| configdb_sequence      |
| context                |
| context_server2db_pool |
| db_cluster             |
| db_pool                |
| filestore              |
| login2context          |
| reason_text            |
| server                 |
+------------------------+
9 rows in set (0.00 sec)

mysql> select * from server;
Empty set (0.00 sec)

mysql> select * from filestore;
Empty set (0.00 sec)

mysql> select * from context;
Empty set (0.00 sec)

mysql>

Also die configdb wurde errichtet.

Das anschliessende oxinstaller lief auch problemlos durch.

Aber registerserver scheitert dann mit

Access denied for user 'openexchange'@'localhost' (using password: YES)

Nun, in den obigen Tests verwende ich das korrekte <db_password> und kann auf configdb zugreifen.

Der oxinstaller verwendet ja als letzter das <db_password>, geht da was schief?

[KurtS]

Mit diesen Überlegungen habe ich nun ab hier alles wiederholt:

admin@server:~$ sudo /opt/open-xchange/sbin/oxinstaller --no-license --servername=oxserver --configdb-pass=<db_password> --master-pass=<admin_master_password> --ajp-bind-port=localhost

setting up groupware configuration /opt/open-xchange/etc/groupware
....
skipping configuration of URL in /opt/open-xchange/etc/groupware/configjump.properties
.............................................
groupware daemon must now be restarted if already running
setting up admin daemon configuration /opt/open-xchange/etc/admindaemon
......................
*** RMI authentication is enabled
using oxadminmaster as master account
admin daemon must now be restarted if already running

admin@server:~$ sudo /etc/init.d/open-xchange-admin restart
Restarting Open-Xchange Admin Daemon: open-xchange-admin.

admin@server:~$ sudo /opt/open-xchange/sbin/registerserver -n oxserver -A oxadminmaster -P <admin_master_password>
server 2 registered

Zu meiner Verblüffung läuft es diesmal.

War es die obige Übung mit MySQL, welche was verändert hat??

Kurt

[KurtS]

OX läuft

Also, mein neuster OX läuft.

Ich habe in den Aufzeichnungen meiner früheren Installation nachgeschaut. Auch dort lief registerserver zuerst nicht und ich habe auch dort irgendwann mit mysql ein Login und einige Abfragen gemacht.

Interessanterweise schreibt MySQL ja am Ende des use configdb:

Database changed

Ich bin kein MySQL-Kenner, muss man hier zwingend irgend was tun, damit der Server beginnt zu arbeiten??

Kurt

[Adrian Badertscher]

Also, mein neuster OX läuft.

Ich habe in den Aufzeichnungen meiner früheren Installation nachgeschaut. Auch dort lief registerserver zuerst nicht und ich habe auch dort irgendwann mit mysql ein Login und einige Abfragen gemacht.

Interessanterweise schreibt MySQL ja am Ende des use configdb:

Database changed

Ich bin kein MySQL-Kenner, muss man hier zwingend irgend was tun, damit der Server beginnt zu arbeiten??

Kurt

Guten Morgen KurtS,

MySQL will damit lediglich sagen, dass das 'use <database>' zu einem Wechsel der Datenbank geführt hat, beziehungsweise dass Dein 'use' Befehl erfolgreich war.

Du hast aber komischerweise den '-p' Parameter nicht verwendet, der von Martin in meinem Strang geraten wurde - Ich bin etwas verwirrt.

Gruss,

Adrian Badertscher

[Adrian Badertscher]

Hallo,

wir legen lediglich einen "openexchange" Datenbankbenutzer an, der sich per default nur von localhost einloggen kann. Möglicherweise wurden die Installationsscripte schon mehrfach und mit anderen Parametern aufgerufen?

OX greift über einen einzigen Datenbankbenutzer auf die Datenbank zu. Zuerst auf das Schema "configdb" dessen Zugangsdaten in der configdb.properties stehen. In der configdb stehen dann die Pfade und Zugangsdaten für die "echten" Datenbanken. Das ist etwas kompliziert aber sehr sinnvoll wenn man mit sehr vielen Datenbank Schema und MySQL Clustern zu tun hat.

Gruß

Guten Morgen,

wie könnte Ihr denn Zugangsdaten für die 'echten' Datenbanken haben, wenn es gar keinen anderen Benutzer über MySQL gibt? Habt Ihr eine eigenen Authorisierungsalgorithmus geschrieben?

Gruss,
Adrian Badertscher

[Martin Heiland]

wie könnte Ihr denn Zugangsdaten für die 'echten' Datenbanken haben, wenn es gar keinen anderen Benutzer über MySQL gibt? Habt Ihr eine eigenen Authorisierungsalgorithmus geschrieben?

Hallo,

die configdb und die groupware Datenbanken liegen in der gleichen MySQL Installation. Der Benutzer "openexchange" hat standardmäßig Zugriff auf alle Datenbankschema in dieser Installation. Einmal greifen wir über die Daten in der configdb.properties Datei auf das Schema "configdb" zu. Darin stehen die Zugangsdaten für die groupware Datenbanken:

mysql> select * from db_pool \G;
*************************** 1. row ***************************
db_pool_id: 4
       url: jdbc:mysql://10.20.30.214/?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&useUnicode=true&useServerPrepStmts=false&useTimezone=true&serverTimezone=UTC&connectTimeout=15000&socketTimeout=15000
    driver: com.mysql.jdbc.Driver
     login: openexchange
  password: geheim
 hardlimit: 0
       max: 100
   initial: 2
      name: oxdatabase

configdb ist sozusagen die zentrale Anlaufstelle für alle OX Server in einem Cluster um weitere Konfigurationsdetails die global gültig sind zu bekommen. Das mag für eine Installation mit nur einem Server völliger overkill sein, stellt aber sicher dass wir auch mit 100 Servern in einem Cluster noch arbeiten können.

Gruß