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?
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)
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.
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.
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
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.