Migration Zarafa zu Kopano

[sky63]

Hallo zusammen,

kann mir mal jemand der kopano mit attachments im Filesystem laufen hat die UID und GID des Verzeichnisses /volume1/kopano/attachments nennen?

danke und gruss,
sky

 

[sky63]

kopano4s-backup, Zeile 246

Original

$SUDO chown -R root.kopano attachments

Neu

$SUDO chown -R kopano.kopano attachments

Dann startet das ganze zumindest

danke und gruss,
sky

 

[webcook]

Hallo zusammen,

ich habe meinen K4S nun soweit laufen und wollte mich an die Migration der Daten von meiner alten Zarafa-Installation (v0.6.0 / Zarafa 7.1.10) (auf einer alten DS114 mit ARM-Prozessor) zu meiner Kopano4S-Installation (v1.0.9 / Kopano C-Core 9.0.2) auf meiner DS218+ machen. Bei dieser Gelegenheit möchte ich auch Dateianhänge von der DB ins Dateisystem auslagern.
Ich bin dabei der Anleitung (https://wiki.z-hub.io/display/K4S/Migration+from+Zarafa) gemäß Option 2 gefolgt, zumal ich ja eine laufende Zarafa-Instanz parallel zu meiner Kopano-Instanz auf verschiedenen Maschinen habe - mutmaßlich sollte es viel einfacher nicht gehen.

Zunächst habe ich auf der DS114 einen Zarafa-User mittels

zarafa-admin -u xxxxx -a yes

in die Administratoren-Rolle gehoben.

Dann habe ich auf der Kopano-Seite einen User mit demselben Namen xxxxx und angelegt und der Administratorrolle hinzugefügt.

Anschließend wollte ich von der ds218+ aus die Daten von User xxxxx mit

kopano-backup -s http://ZARAFA_IP:236/zarafa -U xxxxx -P "yyyyy" -u xxxxx -l INFO --skip-junk --skip-deleted

ins Dateisystem der DS218+ exportieren.


Dabei tritt folgender Fehler auf:

2019-12-28 00:19:07,741 - backup - INFO - starting backup
2019-12-28 00:19:07,786 - backup - INFO - stopping backup
no store with entryid 'http://192.168.0.114:236/zarafa'
Kopano brick level backup completed in 0 : 1 min:sec...
Per user kopano created in backup share (container: /var/lib/kopano/backup):

Welcher Store ist hier gemeint, wo liegt hier mein Fehler?
Ist der unter Option 2 beschriebene Weg für den zu überwindenden Versionsprung (Z 7.1.10 => K 9.0.2) überhaupt gangbar?
Welche Alternativen auf DB-Ebene habe ich, bevor ich die Daten über einen Client (Outlook/IMAP) von Zarafa nach Kopano schiebe?
Letzteres würde ich gerne vermeiden.

Wie immer schon mal großen Dank vorab für die prima Unterstützung hier!

Viele Grüße
webcook

 

[Andy+]

Du kannst nur die Migration durchführen und die Daten auf Plausibilität prüfen. Sofern Du nur Dich als User hättest, wäre noch der weg über Outlook. Bedeuted, Offline alle Daten exportieren und für die neue Installation importieren. Das wäre quasi das sicherste.

 

[webcook]

Hallo Andy+,

ich hatte zuvor auf der K4S Seite den User xxxxx noch nicht angelegt. Nachdem ich das erledigt hatte, sieht die Fehlermeldung "schlichter" aus, habe meinen Post #83 entsprechend editiert. Weiter bin ich aber dennoch nicht...

Außer mir gibt es noch 2 weitere User im Familienkreis, also überschaubar. Daher werde ich mir wohl mal den Weg über Outlook/IMAP ansehen.

Danke und Grüße
webcook

 

[Tosoboso]

..die Migration der Daten von meiner alten Zarafa-Installation (v0.6.0 / Zarafa 7.1.10) ..zu meiner Kopano4S-Installation (v1.0.9 / Kopano C-Core 9.0.2) auf meiner DS218+ machen. Bei dieser Gelegenheit möchte ich auch Dateianhänge von der DB ins Dateisystem auslagern. Ich bin dabei der Anleitung (https://wiki.z-hub.io/display/K4S/Migration+from+Zarafa) gemäß Option 2 gefolgt, zumal ich ja eine laufende Zarafa-Instanz parallel zu meiner Kopano-Instanz auf verschiedenen Maschinen habe - mutmaßlich sollte es viel einfacher nicht gehen..

Hi, die Migration mit Prallel Betrieb wie oben beschrieben geht Nur mit Zrafa4h, Zarafa 7.1.18, vorher wird das mit dem Zarafa-backup-plus bzw kopano-backup nicht unterstützt und ja es geht viel einfacher:
1) Ein Backup der Zarafa Datenbank ziehen mittels dem Skript zarafa-backup.sh und Rüberspielen von /volume1/zarafa/backup auf /volume1/kopano-backup (siehe hier: https://www.synology-forum.de/showt...no-oder-Zarafa&p=836051&viewfull=1#post836051)
2) Migration auf der Ziel-Synology starten mit: >kopano4s-migration-zarafa start und den Fortschritt per >tail -f /volume1/kopano/backup/migrate-steps.log Monitoren.
Das wars.. Wenn die Installation auf der Ziel-Synology mit Attachments On FS durchgeführt wurde, dann ist das schon berücksichtigt beim Import
-TosoBoso

 

[webcook]

Danke, Tosoboso!

Ich nehme an, dass ich alle User der alten Zarafa-DB (MariaDB5, Attatchments in DB) zunächst in der Kopano-DB (MariaDB10, Attachments on FS) händisch anlegen muss oder werden diese automatisch erzeugt?

Wie verhält es sich mit Einträgen in öffentlichen Kalendern, kommen die mit? Wem "gehören" die?

Grüße
webcook

 

[Tosoboso]

. Ich nehme an, dass ich alle User der alten Zarafa-DB (MariaDB5, Attatchments in DB) zunächst in der Kopano-DB (MariaDB10, Attachments on FS) händisch anlegen muss oder werden diese automatisch erzeugt? Wie verhält es sich mit Einträgen in öffentlichen Kalendern, kommen die mit? Wem "gehören" die?

Moin, es müssen keine User in der Ziel-Datenbank (mehr) angelegt werden, das machen die Skripte von selbst incl. hashed Passwort, Rechte Freigaben SekretärIn, Send As etc. Grundsätzlich kommt alles mit, was einem User zugeordnet wird auch dem Public User und dessen Freigaben. Sollte also passen. Lass mich vom Ergebnis wissen, denn die Skripte Migration, Upgrade, Downgrade waren kein triviales 5m Ding bzgl User Import..
-TosoBoso

 

[webcook]

Das mache ich gerne.

Ich habe also gerade die (jungfräulichen) User in der GUI wieder gelöscht. Um die obsoleten Stores aus der DB zu löschen wollte ich mit

kopano-admin --list-orphans

die entsprechenden Store-IDs herausfinden. Aber der Schalter --list-orphans geht nicht mehr ("The selected option is deprecated in this utility.") und das neue Tool kopano-storeadm beschwert sich über eine fehlende UTF-8 locale und bricht mit Fehler ("Your system does not appear have the ""de_DE.UTF-8"" or ""de_DE.UTF-8".UTF-8" locale available") ab. Tatsächlich kann ich aber keine falschen Interpretationen von Zeichen ausmachen, alles schein i.O. zu sein.

Was ist da los? Wie bekomme ich die Store-IDs heraus, um die Stores zu löschen?

-webcook

 

[webcook]

Lass mich vom Ergebnis wissen, denn die Skripte Migration, Upgrade, Downgrade waren kein triviales 5m Ding bzgl User Import..

Hallo Tosoboso,

den vorangegegangenen Ungereimtheiten zum trotz habe ich mittels zarafa-backup.sh auf der DS114 die Zarafa-DB abgezogen und auf die DS218+ kopiert und dort mit kopano4s-migrate-zarafa start in die Kopano-DB einzuspielen versucht - das Ergebnis ist allerdings nicht wie gewünscht:

1. Es wurden keine User in Kopano angelegt
2. Es wurden keine User-Stores in der Kopano-DB angelegt
3. Es wurden keine Attachments ins FS (/volume1/kopano/attachments) ausgelagert

Somit kann ich nicht nachvollziehen, ob überhaupt User-Daten übertragen wurden. Die Logdatei migrate-server.log ist bis auf

2019.12.29-16.27.51 Truncated log b4 starting migration version..

leer.
Die Logdatei migrate-steps.log zeigt zumindest den Anschein eines Fehlers:

Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) restore to kopano-db. 4) user export from kopano migration version 5) restore users to kopano baseline
2019.12.29-16.06.32 step 1: create baseline dump from kopano...
2019.12.29-16.06.33 step 2: skipped as zarafa dump exists for today...
2019.12.29-16.07.00 step 3: restore zarafa dump of 201912291510 into kopano...
2019.12.29-16.27.51 step 4: starting kopano migration (8.4.5) to run user export...
2019.12.29-16.32.02 ERROR running imported data (see migrate-server.log); rolling back..
2019.12.29-16.32.02 rollback restore kopano baseline dump of 201912291606 ...

Aufschlussreicher ist da vielleicht die Ausgabe von kopano4s-migration-zarafa start:

Starting migration steps: 1) kopano baseline backup 2) zarafa db-backup. 3) restore to kopano-db. 4) user export from kopano migration version 5) restore users to kopano baseline
2019.12.29-16.06.32 step 1: create baseline dump from kopano...
starting mysql-dump of kopano to /volume1/kopano/backup... use help for details e.g. on restore
dump done, saving attachments linked to kopano...
dump for kopano completed in 0 : 0 min:sec.
2019.12.29-16.06.33 step 2: skipped as zarafa dump exists for today...
Stopping Kopano core...
stopping kopano-server..
stopping kopano-spooler..
stopping kopano-dagent..
stopping kopano-gateway..
Stopping Kopano web...
stopping nginx..
stopping php7.3-fpm..
Stopping Kopano mail...
stopping postfix..
Stopping Kopano sys...
stopping rsyslog..
stopping cron..
kopano4s
Kopano services stopped
2019.12.29-16.07.00 step 3: restore zarafa dump of 201912291510 into kopano...
stoping kopano for restore of kopano from dump of 201912291510...
Kopano services not running exit false
2019.12.29-16:0700 un-zipping dump sql file dump-zarafa-201912291510.sql.gz..
2019.12.29-16:0723 starting sql import..
restore for kopano completed in 17 : 6 min:sec.
2019.12.29-16:2408 doing cleanup zipping back imported dump.sql file..
2019.12.29-16:2751 done..
2019.12.29-16.27.51 step 4: starting kopano migration (8.4.5) to run user export...
refresh: initializing container from fresh image loaded at docker hub..
init: remove and build kopano4s docker container from refreshed image.. stop:
remove container:
kopano4s
remove image:
Untagged: tosoboso/kopano4s:C-Core-9.0.2_Webapp-4.0.2566_Z-Push-2.5.1
Untagged: tosoboso/kopano4s@sha256:973e6edcb5a5eea61b29e42441d293cfd4375976cdcb96e2f931ed37b18dfbf7
Deleted: sha256:91c8ffdbd832972ce719ac6cd551511f9ebef54b1dab40f7b38d0a3e8398632d
Deleted: sha256:01a9451f2dbd3ecc4136091c1411ee6ca3b0242400d7b9211d8f05b954d7f79c
Deleted: sha256:3cea7c6fbecc84ab7b533be5f0f79d6ebe284badefc38c4a0849f1caac3b8195
Deleted: sha256:7c86a7177e99c017bc92d188b01289f7640f98dabdcb89fac0235bed31d645c3
Deleted: sha256:0add300666510d2b7646c0ac26ed7526b36f14822fbf5b1d5ae8b471295b1915
Deleted: sha256:30d84c3b34ba8658514ef5cd8b8bc1f87823939590f1a0da92e41808e3c00d33
Deleted: sha256:831c5620387fb9efec59fc82a42b948546c6be601e3ab34a87108ecf852aa15f
build M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5:
k4s container run failed: Unable to find image 'tosoboso/kopano4s:M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5' locally.docker: Error response from daemon: manifest for tosoboso/kopano4s:M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5 not found..See 'docker run --help'..
2019.12.29-16.28.02 sleep 4 min to have migration version running smoothly with zarafa database import..
2019.12.29-16.32.02 ERROR running imported data (see migrate-server.log); rolling back..
2019.12.29-16.32.02 rollback restore kopano baseline dump of 201912291606 ...
stoping kopano for restore of kopano from dump of 201912291606...
Kopano services not running exit false
2019.12.29-16:3203 un-zipping dump sql file dump-kopano-201912291606.sql.gz..
2019.12.29-16:3203 starting sql import..
restoring attachments linked to kopano...
attachments/
attachments/0/
[...]
attachments/1/
attachments/1/0/
attachments/1/0/1.gz
[...]
attachments/2/
attachments/2/0/
attachments/2/0/2.gz
[...]
restore for kopano completed in 0 : 37 min:sec.
2019.12.29-16:3240 doing cleanup zipping back imported dump.sql file..
2019.12.29-16:3240 done..
refresh: initializing container from fresh image loaded at docker hub..
init: remove and build kopano4s docker container from refreshed image.. stop:
build C-Core-9.0.2_Webapp-4.0.2574_Z-Push-2.5.1:
postmap on '/etc/kopano/postfix/valiases'..
postmap on '/etc/kopano/postfix/recipient_bcc'..
postmap on '/etc/kopano/postfix/sender_bcc'..
postmap on '/etc/kopano/postfix/recipient_access'..
postmap on '/etc/kopano/postfix/sender_access'..
waiting for services to restart: 60s..
Core: Kopano Server Running, Spooler Running, Dagent Running, Search Disabled, Monitor Disabled, Gateway Running, ICAL Disabled
Web: NGINX Running, PHP7.3-FPM Running, Presence Disabled
Mail: Postfix Running, Postgrey Disabled, Clamav Disabled, Amavis Disabled, Spamd Disabled, Fetchmail Not Running, Courier-Imap Disabled
Sys: Syslog Running, Cron Running
Kopano4s already running
Kopano services started

Sieht so aus, als wäre beim Versuch, den Container mit dem Migrations-Kopano zu ziehen, etwas schief gelaufen.

Es wurden allerdings in /etc/kopano/postfix/ die Dateien recipient_access, recipient_bcc, sasl_passwd, sender_access, sender_bcc, sender_relay und valiases bzw. deren hashes modifiziert.

Kannst Du anhand dieser Angaben erkennen, was das Problem ist? Welche weitere Informationen benötigst Du?

Danke und Grüße
webcook

 

[Tosoboso]

Hi webcook,
danke für die Logs und 'sorry for inconveniance': kannst du die Migration bitte nochmals starten, denn du bist in einen blöden Ausnahmefehler gerannt:
Dei Migration wurde zurückgerollt, weil der k4s Container nicht starten konnte, denn es war gerade kein Migration Image verfügbar, da ich just am 29.12. einen Docker Image Update gamacht hatte und das Image derweil 10-15m nicht exisitert....

 build M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5:
k4s container run failed: Unable to find image 'tosoboso/kopano4s:M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5' locally.docker: 
Error response from daemon: manifest for tosoboso/kopano4s:M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5 not found..See 'docker run --help'..
2019.12.29-16.28.02 sleep 4 min to have migration version running smoothly with zarafa database import..
2019.12.29-16.32.02 ERROR running imported data (see migrate-server.log); rolling back..

-TosoBoso

 

[Tosoboso]

Um die obsoleten Stores aus der DB zu löschen wollte ich mit >kopano-admin --list-orphans die entsprechenden Store-IDs herausfinden. Aber der Schalter --list-orphans geht nicht mehr ("The selected option is deprecated in this utility.") und das neue Tool kopano-storeadm beschwert sich über eine fehlende UTF-8 locale und bricht mit Fehler ("Your system does not appear have the ""de_DE.UTF-8"" or ""de_DE.UTF-8".UTF-8" locale available") ab. Tatsächlich kann ich aber keine falschen Interpretationen von Zeichen ausmachen, alles schein i.O. zu sein.
Was ist da los? Wie bekomme ich die Store-IDs heraus, um die Stores zu löschen?

Hi, da klappt irgendetwas nicht mit der Auflösung von locale durch kopano-storeadm; kopano-admin leitet die Befehle auf die neue Utility um.
Dieser Check scheint neu zu sein und im Container gibt es bei:

 locale -a  :C  C.UTF-8  de_DE.utf8  en_GB.utf8  en_US.utf8  POSIX

man beachte utf8 im Listing bzw. UTF-8 erwartet von kopano-storeadm und in /etc/locale.gen ist wiederum UTF-8 drin..
Abhilfe, taktisch bis ich eine Lösung habe ist Auskommentieren: sed -i -e 's~^default_store_locale~#default_store_locale~g' /etc/kopano/admin.cfg
EDIT ich habe den Fehler gefunden: die Config darf keine Anführungszeichen haben; Abhilfe: > sed -i -e 's~"de_DE"~de_DE~g' /etc/kopano/admin.cfg und das werde ich im nächste Release per Update-Fix berücksichtigen..
-TosoBoso

 

[webcook]

Hallo Tosoboso,

ich habe die Migration nach Rezept nochmals angestoßen, aber irgendwas stimmt immer noch nicht mit dem Container des Migrations-Kopano:

2019.12.31-15.48.03 step 4: starting kopano migration (8.4.5) to run user export...
refresh: initializing container from fresh image loaded at docker hub..
init: remove and build kopano4s docker container from refreshed image.. stop:
remove container:
kopano4s
remove image:
Untagged: tosoboso/kopano4s:C-Core-9.0.2_Webapp-4.0.2574_Z-Push-2.5.1
Untagged: tosoboso/kopano4s@sha256:50a4a9451828850ecd8d34e56ee7d546cf5901c2bfff6e237eac1c2605e83e42
Deleted: sha256:38e144b5870f5110996fc64eee8e8be2d76681dc58a684ad5ddedb6c508f5df3
Deleted: sha256:2945d543fe3cad2844f4c5ba0608bdaf0939bec19ffb2dc528a97bacd4c6e102
Deleted: sha256:a2e1a9611fdda6126a28fb7159dcf1e8cc52dada66b586da06800f9d91c7ad92
Deleted: sha256:2d9eb75ee81d217985fbaee82886d65e1f5e3bc91dbcb624809d16a2b243842e
Deleted: sha256:93424484d9ce7dcba75504f92a4a90ebf12e984a6bf05a35adacf9931cce400b
Deleted: sha256:767b6923ffee0e45b1e6a7cf4252bcfbd338ef54d35e26785b66427bdc6db25a
Deleted: sha256:831c5620387fb9efec59fc82a42b948546c6be601e3ab34a87108ecf852aa15f
build M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5:
k4s container run failed: Unable to find image 'tosoboso/kopano4s:M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5' locally.docker: Error response from daemon: manifest for tosoboso/kopano4s:M-M-Core-8.4.5.0_Webapp-3.4.2_Z-Push-2.4.5 not found..See 'docker run --help'..
2019.12.31-15.48.15 sleep 4 min to have migration version running smoothly with zarafa database import..
2019.12.31-15.52.15 ERROR running imported data (see migrate-server.log); rolling back..
2019.12.31-15.52.15 rollback restore kopano baseline dump of 201912311525 ...

Oder liegt es irgendwelchen Cache, die ich nicht geleert habe?

Danke schon mal und guten Rutsch nachher!
Grüße
webcook

 

[Tosoboso]

HI, da hat sich ein Doppeltes M- eingeschlichen und das.kommt vermutlich aus der library Datei, so dass das Image nicht gefunden wird.
Mach mal folgendes: > sudo sed -i -e "s~M-Core~Core~" /var/packages/Kopano4s/scripts/library. Und versuche es danach nochmals (den Fehler behebe ich im nächsten build)..
-TosoBoso

 

[webcook]

Öffentliche Kalender

Frohes neues Jahr Euch allen,
Hallo Tosoboso,

diesmal lief die Migration glatt durch; lediglich das Logfile "migrate-server.log" enthält eine Warnung:

2020.01.02-10.49.38 Truncated log b4 starting migration version..
Thu Jan  2 10:51:20 2020: [ notice] Starting kopano-server version 8.4.5.0 (pid 4977)
Thu Jan  2 10:55:57 2020: [warning] K-1540: Unable to get server list: server list

Ich finde aber dennoch alles wieder in meinem User (soweit ich vorher alle Mails auswendig gelernt habe).

Allerdings kann ich die öffentlichen Kalender nicht finden - weder im Baum der Objekte im Webapp, noch in der Kalenderansicht. Übersehe ich da was oder werden die bei der Migration nicht berücksichtigt?

Grüße
webcook

 

[webcook]

Hallo Tosoboso,

tatsächlich wurde kein Public-Store angelegt, so konnten meine öffentlichen Kalender nicht emigriert werden. Nachdem ich die /etc/kopano/admin.cfg nach deinem Hinweis aus Post #92 (Achtung: Dein Regex korrigiert die "" in der Kommentarzeile, nicht im relevanten Konfigurationseintrag) angepasst habe, konnte ich den Public-Store mit

kopano-storeadm -P

von Hand erzeugen und meine öffentlichen Kalender neu anlegen und befüllen.

Anschließend noch die /etc/z-push/z-push.conf.php anpassen damit die öffentlichen Kalender auch über Active Sync / Z-Push auf die Mobilgeräte kommen. Allerdings war

/usr/share/z-push/backend/kopano/listfolders.php

im Kopano4S-Container zum Auslesen der Folder-ID etwas kniffelig zu finden - vielleicht verlinkst Du es auch nach außen ins FS der Synology, z.B. nach /etc/z-push?

Nach deinen geringfügigen Korrekturen läuft die Migration von Zarafa nach Kopano auf DB-Ebene (bis auf die öffentlichen Ordner) nahezu reibungslos ab - wirklich tolle Arbeit hast Du da geleistet!

Nochmals vielen Dank und beste Grüße
webcook