UCS Update 4.3-1 mysql access denied for user root

sokratonis · August 8, 2018, 8:15am

Hallo,

ich habe gestern mein UCS aktualisiert auf die Version 4.3-1 errata160. Im Anschluss konnte ich keine Verbindung zur Kopano Webapp herstellen. Daraufhin habe ich die Apps in der Reihenfolge deinstalliert:

-Kopano Z-Push
-Kopano Webapp
-Kopano Core

Im Anschluss habe ich die Reihenfolge von unten nach oben wieder installiert. Der Kopano-Server lässt sich dennoch nicht starten. Die Fehlermeldung im Log (var/log/kopano-server/server.log) lautet:

Log

Wed Aug  8 07:52:28 2018: [error  ] Coredumps will not be generated: kopano-server requires the fs.suid_dumpable sysctl to contain the value 2, not 0. See kopano-coredump(5) for details.
Wed Aug  8 07:52:28 2018: [error  ] KDatabase::Connect(): database access error Unknown error code (0x80000007), mysql error: Access denied for user 'root'@'localhost' (using password: YES)
Wed Aug  8 07:52:28 2018: [crit   ] Unable to connect to database: MYSQL not initialized
Wed Aug  8 07:52:28 2018: [=======] Server shutdown complete.
root@master:~#

Ich habe nun angenommen, dass Passwort in der mysql.secret sei nicht gesetzt. Doch dort steht eins drin. Wo könnte denn nun der Fehler liegen?

Viele Grüße

bytemine · August 8, 2018, 9:33am

Moin,

stimmen die Passwoerter aus /etc/mysql.secret und /etc/kopano/server.cfg ueberein? Funktioniert das Passwort bei mysql -p -u root?

sokratonis · August 8, 2018, 9:37am

Hallo bytemine,

ja, die Passwörter stimmen überein. Ich habe diese zur Sicherheit jetzt nochmal geprüft. Bei dem Befehl mit Eingabe vom Passwort, erhalte ich folgende Meldung:

root@master:~# mysql -p -u root
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

ahrnke · August 8, 2018, 10:05am

Das sollte eigentlich bei UCS nicht der Fall sein. Es sei denn, man hat es aus irgendwelchen Gründen umgestellt.
Defaults:

# ucr search --brief kopano/cfg/server/mysql
kopano/cfg/server/mysql_database: kopano
kopano/cfg/server/mysql_host: localhost
kopano/cfg/server/mysql_password: @&@/etc/kopano-mysql.secret@&@
kopano/cfg/server/mysql_port: 3306
kopano/cfg/server/mysql_user: kopanoDbUser

Das war schon mit der Zarafa-Integration so und wurde von der Migration auch übernommen.
Wenn aber schon der root-Zugang nicht geht - den man fehleingabetoleranter auch mit mysql -u root -p$(< /etc/mysql.secret) erhält - muß man sich den wohl erstmal mit den einschlägigen Methoden verschaffen und nachsehen, ob da überhaupt noch etwas ist.
Sinnvoll wäre auch, in /var/log/univention/updater.log und /var/log/apt/history.log nachzuschauen, was mit den MySQL/MariaDB-Paketen während des Updates passiert ist.

sokratonis · August 8, 2018, 10:22am

Hi,

wenn ich den Befehl ucr search --brief kopano/cfg/server/mysql eingeben, erhalte ich:

root@master:~# ucr search --brief kopano/cfg/server/mysql
kopano/cfg/server/mysql_database: kopano
kopano/cfg/server/mysql_host: localhost
kopano/cfg/server/mysql_password: (mein Passwort)
kopano/cfg/server/mysql_port: 3306
kopano/cfg/server/mysql_user: root

In /var/log/apt/history.log erhalte ich:

root@master:~# cat /var/log/apt/history.log
Start-Date: 2018-08-08  11:43:00
Commandline: apt-get -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-overwrite -o DPkg::Options::=--force-overwrite-dir install phpmyadmin
Install: php-gd:amd64 (1:7.0+49, automatic), php7.0-bz2:amd64 (7.0.27-0+deb9u1, automatic), php-phpseclib:amd64 (2.0.4-1, automatic), php5-gd:amd64 (5.6.33+dfsg-0+deb8u1, automatic), php7.0-gd:amd64 (7.0.27-0+deb9u1, automatic), php5-mcrypt:amd64 (5.6.33+dfsg-0+deb8u1, automatic), libvpx1:amd64 (1.3.0-3+deb8u1, automatic), phpmyadmin:amd64 (4:4.6.6-4), dbconfig-mysql:amd64 (2.0.8, automatic), php-tcpdf:amd64 (6.2.12+dfsg2-1, automatic), php-bz2:amd64 (1:7.0+49, automatic), dbconfig-common:amd64 (2.0.8, automatic), php-mysql:amd64 (1:7.0+49, automatic), libpng12-0:amd64 (1.2.50-2+deb8u3, automatic), php7.0-mysql:amd64 (7.0.27-0+deb9u1, automatic)
End-Date: 2018-08-08  11:43:46

ahrnke · August 8, 2018, 11:05am

Die Verfahrensweise, anstelle des applikationsspezifischen Zugangs den root-Zugang für die Datenbank zu nehmen und in den UCR-Variablen updatesicher zu verankern, ist zumindest aus der Ferne gesehen machbar und sollte nicht zu Zugangsproblemen führen.

In der Liste der Updates sehe ich sowohl php-myadmin als auch dbconfig-mysql. Diese sind offensichtlich manuell nachinstalliert. Ich habe leider keine Erfahrung, ob diese Nebenwirkungen haben.
Vorhin vergaß ich, auch auf /var/log/apt/term.log hinzuweisen. Die Ausgaben dort sind eventuell auch interessant.

sokratonis · August 8, 2018, 11:45am

Hey ahrnke,

phpmyadmin habe ich erst vorhin installiert. Die dbconfig-mysql allerdings nicht. Die muss wohl schon länger auf meinem System sein.

Ich habe nun mittels mysqld_safe --skip-grant-tables & das Passwort für den Benutzer root angepasst. Ich kann mich nun auch als dieser wieder im mysql (mysql -uroot -p) mit Passwort anmelden. Allerdings startet er den Kopano-Server dennoch nicht. Die Meldung lautet aktuell:

Wed Aug  8 13:22:49 2018: [=======] Starting kopano-server version 8.6.2 (pid 1423)
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'server_max_keep_alive_requests' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'sync_log_all_changes' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'plugin_path' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'thread_stacksize' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'client_update_enabled' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'client_update_path' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'client_update_log_level' is not used anymore.
Wed Aug  8 13:22:49 2018: [warning] Config warning: Option 'client_update_log_path' is not used anymore.
Wed Aug  8 13:22:49 2018: [error  ] Coredumps will not be generated: kopano-server requires the fs.suid_dumpable sysctl to contain the value 2, not 0. See kopano-coredump(5) for details.
Wed Aug  8 11:23:11 2018: [error  ] SQL [00000003] Failed: Duplicate entry '2' for key 'gni', Query Size: 170, Query: "ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`"
Wed Aug  8 11:23:11 2018: [error  ] KDatabase::I_Update() query failed: "Duplicate entry '2' for key 'gni'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Wed Aug  8 11:23:11 2018: [error  ] K-1216: Cannot update to schema v69, because the "names" table contains unexpected rows. Certain prior versions of the server erroneously allowed these duplicates to be added (KC-1108).
Wed Aug  8 11:23:11 2018: [error  ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Wed Aug  8 11:23:11 2018: [error  ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Wed Aug  8 11:23:11 2018: [warning] WARNING: Unable to upgrade database from version 8.4.5.2152005632.66 to 8.6.2.0.70
Wed Aug  8 11:23:11 2018: [warning]    You can force the server to start with --ignore-database-version-conflict
Wed Aug  8 11:23:11 2018: [warning]    Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Wed Aug  8 11:23:11 2018: [=======] Server shutdown complete.

Im Anschluss habe ich die geforderte kopano-dbadm k-1216 mittels

systemctl stop kopano-server
/usr/sbin/kopano-dbadm k-1216
systemctl start kopano-server

ausgeführt. Jetzt lässt sich der Kopano-Server starten, der Zugriff auf MYSQL funktioniert auch und die Webapp geht ebenfalls wieder.

Danke trotzdem für die Hinweise.

ahrnke · August 8, 2018, 12:19pm

Der Vollständigkeit halber möchte ich hiermit auch andere Leser dieses Threads darauf hinweisen, dass Kopano Core 8.5.7 einen Security-Fix mitbringt, der die manuelle Ausführung des o.g. Befehls kopano-dbadm k-1216 erfordert. Mehr Details sind in der Kopano-Wiki (derzeit auch auf der Wiki-Startseite). Eine Abhängigkeit zum oben diskutierten Zugangsproblem für mysql sehe ich im Moment nicht.