Wie geht's mit dem Zarafa Package weiter?

catweazle71 · 14. Mai 2018

Für heute habe ich nun k4s erstmal einfach wieder komplett deinstalliert und einen Reboot durchgeführt.
Danach wurde wieder automatisch auf Port 8000/1 gewechselt und die obige Fehlermeldung ist weg.

Sehr komisch. Leider habe ich auch mit z4h nun keinen Connect mehr mit Outlook über EAS, obwohl das Profil nicht verändert wurde.

Für heute mache ich Schluss .... ich schaue morgen weiter

Anzeige · 19. Mai 2015

Hallo hilton_syn,

Bücher und Hardware zum Thema gibt es bei Amazon: Wie geht's mit dem Zarafa Package weiter?

Andy+ · 14. Mai 2018

Dann kommt jetzt alles in einen Karton, dann gehts ....

Andy+ · 14. Mai 2018

Was soll ich sagen, gleicher Gedanke und Deinstallation über CLI

synopkg uninstall Kopano4s

dann Reboot und alles läuft wieder wie zuvor, DSM, alle Services usw. Eine Test-DS ist einfach Gold wert ......

Tosoboso · 14. Mai 2018

Andy+ schrieb:
Aus meinen Tests mit VMM-Versionen mit Kopano wurde klar, dass ab v8.6.x eine direkte Verwendung der Datenbank aus Z4H nicht mehr geht. Diese muss importiert oder portiert werden. Ich nehme mal an, dass diese Funktionen das übernehmen, auch wenn die Datenbank die Anhänge gespeichert hat. Versuchte ich das in einer VMM-Version, bekam ich z.B. die Fehlermeldung
"Unable to Upgrade database from version 7.2.6.10.64 to version 8.6.80.0.70"
Ich nehme an, dieser Umstand verbleibt auch bei K4S.

Hi Andy, danke für den Hinweis und ja das Problem wird auch kei K4S entstehen, siehe hier: https://forum.kopano.io/topic/736/upgrade-from-zarafa-db-schema-is-59-and-older-than-v63
Das ist unabhängig davon, ob man die Anhänge in der Datenbank hat, oder auf dem Filesystem. Man benötigt also ein Kopano 8.4(.2.0) vom Nov 2017 aus dem Supported Archiv zum Migrieren von ZCP 7.2 und dann Update auf die neuste KC Version; das ist doooof.
Alternativ könnte man das Kopano-Backup nehmen, das sich zum Backup gegen Z4h Port 236/7 verbindet und danach Restore nach K4S. Das setzt aber vorraus, dass man ein minimales Kopano_Backup Image baut oder K4S auf anderen Ports startet... Grrrübel..
-TosoBoso

Andy+ · 14. Mai 2018

Das ist zwar vlt. komisch, lässt sich ggf. aber über die Zusammenhänge klären. Daher tippe ich auf den Reverse-Proxy, da dieser ins System eingreift, zudem im Gegensatz zum RP des Z4h auf HTTPS setzt. Nun, ggf. kann Tosoboso was dazu sagen, denn ohne seine Hilfe kommen wir da wahrscheinlich nicht weiter.

Andy+ · 14. Mai 2018

Tosoboso schrieb:
.............ein Kopano 8.4(.2.0) vom Nov 2017 aus dem Supported Archiv zum Migrieren von ZCP 7.2 und dann Update auf die neuste KC Version; das ist doooof............

Da wurde doch sicherlich auch nur ein Upgratescript verwendet, um während des Updates von v8.4.x auf > v8.5.x auf die neuste Datenbankversion zu portieren. Wäre es da nicht möglich, eine Erkennroutine einzubauen und das Upgratescript laufen zu lassen?

FricklerAtHome · 14. Mai 2018

Weiter Install-Probleme K4S auf DS3615xs

Hallo Mädels und Jungs

ich habe jetzt 20 Install-Versuche mit allen mir bekannten Möglichkeiten auf meiner DS durch. Auf der lief bisher Z4H wunderbar. Jetzt keinerlei Erfolg. Docker Container / Kopano4S stürzen ab. Lediglich im Docker-Log findet sich folgendes:

2018-05-14T20:20:06+02:00 O51-NASBLUE docker[24200]: WARN[0000] could not change group /var/run/docker.sock to docker: group docker not found
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: ERRO[0001] AUFS is not supported over btrfs
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support kernel memory limit
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup cfs period
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup cfs quotas
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup rt period
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup rt runtime
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup blkio weight
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup blkio weight_device
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup blkio throttle.read_bps_device
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup blkio throttle.write_bps_device
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup blkio throttle.read_iops_device
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Your kernel does not support cgroup blkio throttle.write_iops_device
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] mountpoint for pids not found
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Running modprobe nf_nat failed with message: ``, error: exit status 1
2018-05-14T20:20:07+02:00 O51-NASBLUE docker[24200]: WARN[0001] Running modprobe xt_conntrack failed with message: ``, error: exit status 1
2018-05-14T20:20:08+02:00 O51-NASBLUE docker[24200]: WARN[0002] Could not load necessary modules for IPSEC rules: Running modprobe xfrm_user failed with message: ``, error: exit status 1
2018-05-14T20:20:08+02:00 O51-NASBLUE docker[24200]: WARN[0002] Could not load necessary modules for Conntrack: Running modprobe nf_conntrack failed with message: ``, error: exit status 1
2018-05-14T20:20:08+02:00 O51-NASBLUE docker[24200]: WARN[0002] Could not get operating system name: Error opening /usr/lib/os-release: open /usr/lib/os-release: no such file or directory

Werde jetzt gleich nochmal ZARAFA installieren. Mal sehen ob das noch klappt.

Gruss der FricklerAtHome

Andy+ · 14. Mai 2018

Das hätte ich jetzt bei der DS nicht erwartet (Bromolow), eher von der DS3617xs und die geht dann vlt. sogar noch. Z4h geht da wieder, weshalb auch nicht.

FricklerAtHome · 14. Mai 2018

Leider klappt auch der Versuch mit Zarafa4H nicht mehr auf dieser Syno.
Auf einer exakt gleichen Maschine (DSM Version auch gleich) läuft beim Nachbarn Z4H Ver. 0.7.1 seit Monaten ohne Probleme. Meine heutigen Versuche einer Neuinstallation mit K4S oder Z4H (keine Migration) scheitern. Und dass obwohl ich besonders bei Z4H kein Anfänger bin. Hier startet der Docker auch zwar ohne die obigen Fehlermeldungen, aber letzlich startet er dann doch nicht.
Da ich auf keiner der Maschinen BRTFS ausschalten werde, und ich die vorhandenen Netzwerkanschlüsse immer als BOND einsetzen muss, kann ich andere Scenarien nicht testen.

--- Da bin ich mit meiner aktuellen VM als Produktiv-System in meinem Scenario deutlich besser aufgehoben. Auch was Backup, Migration, Updates etc. betrifft. Hatte mir gestern (war ja schlechtes Wetter) den neusten Nightly Community Core auf das Produktiv-System gezogen! Und, Murphys Law, etwas falsch gemacht. Nichts ging mehr. BRTFS-VM Snapshot zurückgespielt, keine 4 Minuten später war aller Spuk vorbei. Das geht mit den SPK's leider nicht so.

Ich werde also sporatisch den weiteren Verlauf beobachten, einen Durchbruch für meine Anwendungen sehe ich leider noch nicht.

Gruss der FricklerAtHome

Andy+ · 14. Mai 2018

Das kann unterschiedliche Ursachen haben. DBuser passt nicht zum Passwort, oder die DBrücksicherung ist unvollständig, server.cfg passt nicht. Usw., das geht bestimmt wieder.

Andy+ · 15. Mai 2018

FricklerAtHome schrieb:
...........Versuche einer Neuinstallation mit K4S oder Z4H (keine Migration) scheitern. Und dass obwohl ich besonders bei Z4H kein Anfänger bin...................

Dass Z4h nicht gehen soll, kann ja nicht sein. Bedenke, dass bei einer Neuinstallation von Z4h alle Parameter neu angelegt werden. Und das Paket startet definitiv nicht, wenn u.a. in der server.cfg folgende Einträge nicht passen:

##############################################################
# MYSQL SETTINGS (for database_engine = mysql)

# MySQL hostname to connect to for database access
mysql_host = localhost

# MySQL port to connect with (usually 3306)
#mysql_port = 3306
mysql_port = 3307

# The user under which we connect with MySQL
mysql_user = zarafa4h

# The password for the user (leave empty for no password)
mysql_password = ***** (wird von Z4h bei der Installation vergeben und wird in der Datenbank beim Benutzer zarafa4h hinterlegt)

# Override the default MySQL socket to access mysql locally
# Works only if the mysql_host value is empty or 'localhost'
#mysql_socket = /run/mysqld/mysqld.sock
mysql_socket = /run/mysqld/mysqld10.sock

# Database to connect to
mysql_database = zarafa4h

# Where to place attachments. Value can be 'database', 'files' or 's3'
attachment_storage = database

##############################################################

Das sind nun meine Einstellungen. Wenn ich z.B. beim Umstellen von MariaDB5 auf MariaDB10 schon mal vergessen habe den Benutzer samt Passwort durch Export und Import zu übertragen, geht nichts mehr.

@Tosoboso, die Frage wäre, was passiert beim Migrationsprozess, wenn Z4h bereits auf MariaDB10 läuft?

Andy+ · 15. Mai 2018

Ich habe nun Z4h v0.7.5 installiert, die EOL mit Berücksichtigung der Migration auf K4s. Mir ist allerdings nicht klar, wie diese Berücksichtigung aussieht und sich funktional greifen lässt.

Jack_77 · 15. Mai 2018

Wie versprochen, hier meine Erkenntnisse zur Migration von einer DS214Play (Debian Chroot) zur DS718+ (Docker).
- zarafa-backup auf ext. HDD/PC sichern
- zarafa share auf ext. HDD/PC sichern
- backup der sql db mit Sypex Dumper und download auf ext. HDD/PC (nur zur SIcherheit, im Normalfall wird dieses Backup nicht benötigt)
- zarafa db, zarafa share und zarafa Paket löschen/deinstallieren
- REBOOT Diskstation
- Docker installieren
- Zarafa installieren
- Über Winscp gesicherte backups aus dem ehemaligen share ins neue kopieren
- Über ssh zarafa-backup restore <timestamp> ausführen
- zarafa-postfix reset
- zarafa-postfix restart
- zarafa-postfix relay [smtp.strato.de]:587 <email> <password>
- zarafa-fetchmail add z-user <email> <password> imap.strato.de imap 993 ssl INBOX
- Bei Version 0.7.4 beta geht Z-Push nicht. Einfach die Rechte von Ordner z-push rekrusiv unter /usr/syno/etc/packages/Zarafa4home/zarafa auf Besitzer=http, Gruppe=root, Oktal=0775 -> Hatte da zum Glück schon vorher einen Post von Andy+ hierzu gesehen, Danke Andy

Tosoboso · 15. Mai 2018

Esel08 schrieb:
Kurze Frage kann man das spk noch für die DS214 play nehmen ?? Die Zarafa4homeX86-075.spk wird diese noch angeboten bzw. befindet sie sich mit drin im neuen Kopano4S, v0.8.1 ??

Hi und kurze Antwort: nein DS214play ist nicht mit K4S kompatibel,
HIntergrund: Die Architektur ist zwar auf noarch gesetzt, aber die Paket-Ahängigkeit Docker sorgt dafür, dass nur Synos mit X64 Architektur und Docker installiert das Paket bekommen.
Wie schon angelündigt ist die K4S rein mit Docker-Unterstützung gebaut, denn das Pflegen beider Codestränge Docker / Debiian-Chroot wird zu aufwendig und fehleranfällig.Dank der Paket-Ahängigkeit passiert es nun aber nicht mehr, daß ein Docker-Update den laufenden K4S Container schrottet, denn der wird zwingend während dem Update gestoppt. Genauso wird Docker gestoppt bei K4s Upgrade. -Man kann nicht alles haben..
-TosoBoso

Andy+ · 15. Mai 2018

Ich habe nun K4s v0.8.1 nochmal neu installiert, da nach der gestrigen Installation der DSM und alle damit zusammenhängenden Dienste nicht mehr ging. Verdacht: der mit installierte Reverse-Proxy. Daher habe ich heute auf der letzten Seite zur Installationsroutine aus den beiden Punkten

- SSL-Oportunistic SMTP (war bislang bei Z4h auch nicht angehakt)
- Reverse-Proxy (s.o.)

die standardmässig sichtbaren Haken herausgenommen. Die Installation funktionierte danach und nach einem Reboot war auch der DSM verfügbar und alles scheint normal. Wie das nun mit der Datenbankübertragung weitergeht, mal sehen.

Andy+ · 15. Mai 2018

UPDATE :

K4s bleibt nicht stabil aktiv. Das Paket und der Dockercontainer stoppt (2h Zeitversatz):

2018-05-15 07:07:02 stdout Tue May 15 07:07:00 2018: [=======] Server shutdown complete.
2018-05-15 07:07:02 stdout Tue May 15 07:07:00 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
2018-05-15 07:07:02 stdout Tue May 15 07:07:00 2018: [warning] You can force the server to start with --ignore-database-version-conflict
2018-05-15 07:07:02 stdout Tue May 15 07:07:00 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
2018-05-15 07:07:02 stdout exiting as server stopped; if non-grace shutdown see last entry from /var/log/kopano4h/server.log and consider kopano-init container or re-install
2018-05-15 07:07:02 stdout staying alive while kopano service is running..
2018-05-15 07:07:02 stdout Starting nginx: nginx.
2018-05-15 07:07:02 stdout Starting Kopano web ...
2018-05-15 07:07:02 stdout Starting Postfix Mail Transport Agent: postfix.
2018-05-15 07:07:02 stdout Starting Kopano mail ...
2018-05-15 07:07:02 stdout Starting ical gateway: kopano-ical.
2018-05-15 07:07:01 stdout Starting gateway: kopano-gateway.
2018-05-15 07:07:01 stdout Starting enhanced syslogd: rsyslogd.
2018-05-15 07:07:01 stdout Starting search: kopano-search failed!
2018-05-15 07:07:01 stdout Starting LMTP dagent: kopano-dagent.
2018-05-15 07:07:00 stdout Starting spooler: kopano-spooler.
2018-05-15 07:07:00 stdout Starting server: kopano-server.
2018-05-15 07:07:00 stdout Starting Kopano core ...
2018-05-15 07:06:22 stdout Tue May 15 07:06:15 2018: [=======] Server shutdown complete.
2018-05-15 07:06:22 stdout Tue May 15 07:06:15 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
2018-05-15 07:06:22 stdout Tue May 15 07:06:15 2018: [warning] You can force the server to start with --ignore-database-version-conflict
2018-05-15 07:06:22 stdout Tue May 15 07:06:15 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
2018-05-15 07:06:22 stdout exiting as server stopped; if non-grace shutdown see last entry from /var/log/kopano4h/server.log and consider kopano-init container or re-install
2018-05-15 07:06:22 stdout staying alive while kopano service is running..
2018-05-15 07:06:20 stdout Starting nginx: nginx.
2018-05-15 07:06:20 stdout Starting Kopano web ...
2018-05-15 07:06:20 stdout Starting Postfix Mail Transport Agent: postfix.
2018-05-15 07:06:18 stdout Starting Kopano mail ...
2018-05-15 07:06:18 stdout Starting ical gateway: kopano-ical.
2018-05-15 07:06:18 stdout Starting gateway: kopano-gateway.
2018-05-15 07:06:18 stdout Starting enhanced syslogd: rsyslogd.
2018-05-15 07:06:16 stdout Starting search: kopano-search failed!
2018-05-15 07:06:15 stdout Starting LMTP dagent: kopano-dagent.
2018-05-15 07:06:15 stdout Starting spooler: kopano-spooler.
2018-05-15 07:06:14 stdout Starting server: kopano-server.
2018-05-15 07:06:13 stdout Starting Kopano core ...
2018-05-15 06:55:02 stdout Tue May 15 06:54:53 2018: [=======] Server shutdown complete.
2018-05-15 06:55:02 stdout Tue May 15 06:54:53 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
2018-05-15 06:55:02 stdout Tue May 15 06:54:53 2018: [warning] You can force the server to start with --ignore-database-version-conflict
2018-05-15 06:55:02 stdout Tue May 15 06:54:53 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
2018-05-15 06:55:02 stdout exiting as server stopped; if non-grace shutdown see last entry from /var/log/kopano4h/server.log and consider kopano-init container or re-install
2018-05-15 06:54:52 stdout staying alive while kopano service is running..
2018-05-15 06:54:52 stdout Starting nginx: nginx.
2018-05-15 06:54:52 stdout Starting Kopano web ...
2018-05-15 06:54:52 stdout Starting Postfix Mail Transport Agent: postfix.
2018-05-15 06:54:52 stdout Starting Kopano mail ...
2018-05-15 06:54:52 stdout Starting ical gateway: kopano-ical.
2018-05-15 06:54:51 stdout Starting gateway: kopano-gateway.
2018-05-15 06:54:51 stdout Starting enhanced syslogd: rsyslogd.
2018-05-15 06:54:51 stdout Starting search: kopano-search failed!
2018-05-15 06:54:51 stdout Starting LMTP dagent: kopano-dagent.
2018-05-15 06:54:50 stdout Starting spooler: kopano-spooler.
2018-05-15 06:54:50 stdout Starting server: kopano-server.
2018-05-15 06:54:49 stdout Starting Kopano core ...
2018-05-15 06:54:49 stdout Active services: kopano-server kopano-spooler kopano-dagent kopano-search rsyslog kopano-gateway kopano-ical postfix nginx php7.0-fpm
2018-05-15 06:54:11 stdout setting acl, ssl, encryption shared secrets
2018-05-15 06:54:11 stderr Generation complete.
2018-05-15 06:54:11 stderr done
2018-05-15 06:54:11 stderr en_US.UTF-8...locale alias file `/usr/share/locale/locale.alias' not found: No such file or directory
2018-05-15 06:54:09 stderr done
2018-05-15 06:54:09 stderr de_DE.UTF-8...locale alias file `/usr/share/locale/locale.alias' not found: No such file or directory
2018-05-15 06:54:07 stderr Generating locales (this might take a while)...
2018-05-15 06:54:03 stdout increasing php upload_max_filesize to 15M..
2018-05-15 06:54:03 stdout increasing file-limits for user kopano running sockets..
2018-05-15 06:54:03 stderr usermod: no changes
2018-05-15 06:54:03 stdout modifying kopano user and group ids (1053 / 65553) plus file limits ..
2018-05-15 06:54:02 stdout initializing virtual aliases and pwd e.g. for proxy..
2018-05-15 06:54:01 stdout image intializing UID, GID, etc-cfg, log, ssl, post-build

In der /var/log/kopano4h/server.log steht dazu:

Andy+ · 15. Mai 2018

Tue May 15 06:13:30 2018: [=======] Starting kopano-server version 8.6.80 (pid 3581)
Tue May 15 06:13:30 2018: [error ] SQL [00000004] Failed: Duplicate entry 'IMAddress2' for key 'gns', 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`"
Tue May 15 06:13:30 2018: [error ] KDatabase::I_Update() query failed: "Duplicate entry 'IMAddress2' for key 'gns'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Tue May 15 06:13:30 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).
Tue May 15 06:13:30 2018: [error ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Tue May 15 06:13:30 2018: [error ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Tue May 15 06:13:30 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
Tue May 15 06:13:30 2018: [warning] You can force the server to start with --ignore-database-version-conflict
Tue May 15 06:13:30 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Tue May 15 06:13:30 2018: [=======] Server shutdown complete.
Tue May 15 06:22:43 2018: [=======] Starting kopano-server version 8.6.80 (pid 28)
Tue May 15 06:22:44 2018: [error ] SQL [00000028] Failed: Duplicate entry 'IMAddress2' for key 'gns', 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`"
Tue May 15 06:22:44 2018: [error ] KDatabase::I_Update() query failed: "Duplicate entry 'IMAddress2' for key 'gns'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Tue May 15 06:22:44 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).
Tue May 15 06:22:44 2018: [error ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Tue May 15 06:22:44 2018: [error ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Tue May 15 06:22:44 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
Tue May 15 06:22:44 2018: [warning] You can force the server to start with --ignore-database-version-conflict
Tue May 15 06:22:44 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Tue May 15 06:22:44 2018: [=======] Server shutdown complete.
Tue May 15 06:52:22 2018: [=======] Starting kopano-server version 8.6.80 (pid 32)
Tue May 15 06:52:23 2018: [error ] SQL [00000043] Failed: Duplicate entry 'IMAddress2' for key 'gns', 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`"
Tue May 15 06:52:23 2018: [error ] KDatabase::I_Update() query failed: "Duplicate entry 'IMAddress2' for key 'gns'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Tue May 15 06:52:23 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).
Tue May 15 06:52:23 2018: [error ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Tue May 15 06:52:23 2018: [error ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Tue May 15 06:52:23 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
Tue May 15 06:52:23 2018: [warning] You can force the server to start with --ignore-database-version-conflict
Tue May 15 06:52:23 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Tue May 15 06:52:23 2018: [=======] Server shutdown complete.
Tue May 15 06:54:50 2018: [=======] Starting kopano-server version 8.6.80 (pid 3557)
Tue May 15 06:54:53 2018: [error ] SQL [00000045] Failed: Duplicate entry 'IMAddress2' for key 'gns', 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`"
Tue May 15 06:54:53 2018: [error ] KDatabase::I_Update() query failed: "Duplicate entry 'IMAddress2' for key 'gns'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Tue May 15 06:54:53 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).
Tue May 15 06:54:53 2018: [error ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Tue May 15 06:54:53 2018: [error ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Tue May 15 06:54:53 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
Tue May 15 06:54:53 2018: [warning] You can force the server to start with --ignore-database-version-conflict
Tue May 15 06:54:53 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Tue May 15 06:54:53 2018: [=======] Server shutdown complete.
Tue May 15 07:06:14 2018: [=======] Starting kopano-server version 8.6.80 (pid 28)
Tue May 15 07:06:15 2018: [error ] SQL [00000055] Failed: Duplicate entry 'IMAddress2' for key 'gns', 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`"
Tue May 15 07:06:15 2018: [error ] KDatabase::I_Update() query failed: "Duplicate entry 'IMAddress2' for key 'gns'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Tue May 15 07:06:15 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).
Tue May 15 07:06:15 2018: [error ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Tue May 15 07:06:15 2018: [error ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Tue May 15 07:06:15 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
Tue May 15 07:06:15 2018: [warning] You can force the server to start with --ignore-database-version-conflict
Tue May 15 07:06:15 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Tue May 15 07:06:15 2018: [=======] Server shutdown complete.
Tue May 15 07:07:00 2018: [=======] Starting kopano-server version 8.6.80 (pid 28)
Tue May 15 07:07:00 2018: [error ] SQL [00000057] Failed: Duplicate entry 'IMAddress2' for key 'gns', 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`"
Tue May 15 07:07:00 2018: [error ] KDatabase::I_Update() query failed: "Duplicate entry 'IMAddress2' for key 'gns'", query: ALTER TABLE `names` ADD UNIQUE INDEX `gni` (`guid`(16), `nameid`), ADD UNIQUE INDEX `gns` (`guid`(16), `namestring`), DROP INDEX `guidnameid`, DROP INDEX `guidnamestring`
Tue May 15 07:07:00 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).
Tue May 15 07:07:00 2018: [error ] K-1220: To fix the excess rows, use `kopano-dbadm k-1216`. Consult the manpage and preferably make a backup first.
Tue May 15 07:07:00 2018: [error ] K-1221: Alternatively, the server may be started with --ignore-da to forego the schema update.
Tue May 15 07:07:00 2018: [warning] WARNING: Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70
Tue May 15 07:07:00 2018: [warning] You can force the server to start with --ignore-database-version-conflict
Tue May 15 07:07:00 2018: [warning] Warning, you can lose data! If you don't know what you're doing, you shouldn't be using this option!
Tue May 15 07:07:00 2018: [=======] Server shutdown complete.

Andy+ · 15. Mai 2018

Allerdings muss ich sagen, in den Protokollen sind Details enthalten, die ich bei der VMM-Version auch schon gesehen habe.

Andy+ · 15. Mai 2018

Andy+ schrieb:
Aus meinen Tests mit VMM-Versionen mit Kopano wurde klar, dass ab v8.6.x eine direkte Verwendung der Datenbank aus Z4H nicht mehr geht. Diese muss importiert oder portiert werden. Ich nehme mal an, dass diese Funktionen das übernehmen, auch wenn die Datenbank die Anhänge gespeichert hat. Versuchte ich das in einer VMM-Version, bekam ich z.B. die Fehlermeldung

"Unable to Upgrade database from version 7.2.6.10.64 to version 8.6.80.0.70"

Ich nehme an, dieser Umstand verbleibt auch bei K4S.

Den obigen Kommentar habe ich aus der VMM-Version. Jetzt habe ich in den Logs zu K4s das :

Unable to upgrade database from version 8.6.80.0.68 to 8.6.80.0.70

und dabei habe ich eine quasi "jungfräuliche" K4s-Installation vorgenommen, welche dann also eine Datenbank v8.6.80.0.68 installiert....

.... Klar, dass dann schon deshalb das Paket und der Container nicht mehr startet, was alles direkt nach der Installation und vor einem Reboot noch funktionierte.

Dufooy · 15. Mai 2018

@Andy+

Hab es nun mal angehend so wie Du eingerichtet, sprich ohne Auswahl von

- SSL-Oportunistic SMTP (war bislang bei Z4h auch nicht angehakt)
- Reverse-Proxy (s.o.)

Hab im server.log nur dieses stehen:

Code:

Tue May 15 07:57:30 2018: [=======] Starting kopano-server version 8.6.80 (pid 3582)
Tue May 15 07:57:30 2018: [error  ] KDatabase::Connect(): database missing -2147483616
Tue May 15 08:09:35 2018: [error  ] Error while connecting to search on "file:///var/run/kopano/search.sock"
Tue May 15 08:18:59 2018: [=======] Starting kopano-server version 8.6.80 (pid 27)

Verbindung zur Datenbank beste auch wenn es im Log anders aussieht, habe gerade mal User angelegt.

Hier die das Protokol vom Conatinaer start.

Code:

2018-05-15 08:19:03	stderr	Logfile "/var/log/zarafa/fetchmail.log" does not exist, ignoring logfile option.
2018-05-15 08:19:03	stdout	staying alive while kopano service is running..
2018-05-15 08:19:03	stdout	Starting nginx: nginx.
2018-05-15 08:19:03	stdout	Starting Kopano web ...
2018-05-15 08:19:03	stdout	Starting mail retriever agent: fetchmail.
2018-05-15 08:19:03	stdout	Starting Postfix Mail Transport Agent: postfix.
2018-05-15 08:19:01	stdout	Starting Kopano mail ...
2018-05-15 08:19:01	stdout	Starting ical gateway: kopano-ical.
2018-05-15 08:19:01	stdout	Starting gateway: kopano-gateway.
2018-05-15 08:19:01	stdout	Starting enhanced syslogd: rsyslogd.
2018-05-15 08:19:01	stdout	Starting search: kopano-search failed!
2018-05-15 08:18:59	stdout	Starting LMTP dagent: kopano-dagent.
2018-05-15 08:18:59	stdout	Starting spooler: kopano-spooler.
2018-05-15 08:18:59	stdout	Starting server: kopano-server.
2018-05-15 08:18:59	stdout	Starting Kopano core ...
2018-05-15 08:17:21	stdout	Tue May 15 08:09:35 2018: [error  ] Error while connecting to search on "file:///var/run/kopano/search.sock"
2018-05-15 08:17:21	stdout	Tue May 15 07:57:30 2018: [error  ] KDatabase::Connect(): database missing -2147483616
2018-05-15 08:17:21	stdout	Tue May 15 07:57:30 2018: [=======] Starting kopano-server version 8.6.80 (pid 3582)
2018-05-15 08:17:21	stdout	exiting as server stopped; if non-grace shutdown see last entry from /var/log/kopano4h/server.log and consider kopano-init container or re-install
2018-05-15 07:57:59	stdout	staying alive while kopano service is running..
2018-05-15 07:57:56	stdout	Starting nginx: nginx.
2018-05-15 07:57:56	stdout	Starting Kopano web ...
2018-05-15 07:57:56	stdout	Starting Postfix Mail Transport Agent: postfix.
2018-05-15 07:57:55	stdout	Starting Kopano mail ...
2018-05-15 07:57:55	stdout	Starting ical gateway: kopano-ical.
2018-05-15 07:57:55	stdout	Starting gateway: kopano-gateway.
2018-05-15 07:57:55	stdout	Starting enhanced syslogd: rsyslogd.
2018-05-15 07:57:55	stdout	Starting search: kopano-search failed!
2018-05-15 07:57:53	stdout	Starting LMTP dagent: kopano-dagent.
2018-05-15 07:57:53	stdout	Starting spooler: kopano-spooler.
2018-05-15 07:57:52	stdout	Starting server: kopano-server.
2018-05-15 07:57:29	stdout	Starting Kopano core ...
2018-05-15 07:57:29	stdout	Active services: kopano-server kopano-spooler kopano-dagent kopano-search rsyslog kopano-gateway kopano-ical postfix nginx php7.0-fpm
2018-05-15 07:56:50	stdout	setting acl, ssl, encryption shared secrets
2018-05-15 07:56:49	stderr	Generation complete.
2018-05-15 07:56:49	stderr	 done
2018-05-15 07:56:49	stderr	  en_US.UTF-8...locale alias file `/usr/share/locale/locale.alias' not found: No such file or directory
2018-05-15 07:56:48	stderr	 done
2018-05-15 07:56:48	stderr	  de_DE.UTF-8...locale alias file `/usr/share/locale/locale.alias' not found: No such file or directory
2018-05-15 07:56:46	stderr	Generating locales (this might take a while)...
2018-05-15 07:56:43	stdout	increasing php upload_max_filesize to 15M..
2018-05-15 07:56:43	stdout	increasing file-limits for user kopano running sockets..
2018-05-15 07:56:42	stderr	usermod: no changes
2018-05-15 07:56:41	stdout	modifying kopano user and group ids (1038 / 65537) plus file limits ..
2018-05-15 07:56:40	stdout	initializing virtual aliases and pwd e.g. for proxy.. 
2018-05-15 07:56:40	stdout	image intializing UID, GID, etc-cfg, log, ssl, post-build

Scheint, dass da zum teil noch die Pfade zu den Logs auf zarafa stehen, jedenfalls bei fetchmail.
Habe es nun 3-4 mal installiert, nachdem ich es gelöscht habe, hat es nicht beim ersten mal geklappt.

Fetchmail geht wie gesagt immer noch nicht.