Migration Zarafa zu Kopano

[millilenium]

ca. 40GB in Z4H und ca. 36GB in K4S
Habe die Files in der DB - also nahezu identisch

 

[Andy+]

.........Kopano4s" konnte nicht installiert werden. Legacy Zarafa4home package detected which is in conflict with Kopano4s...........

Vor Installation von K4S muss Z4H gestoppt werden. Das würde ich aber über die Konsole machen, da im Paketzentrum oft der Status nicht passt. Nimm den Befehl

/var/packages/Zarafa4home/scripts/start-stop-status stop

dann kannst Du sicher sein, dass Paket und Container off sind.

 

[peola]

Vor Installation von K4S muss Z4H gestoppt werden. Das würde ich aber über die Konsole machen, da im Paketzentrum oft der Status nicht passt. Nimm den Befehl

/var/packages/Zarafa4home/scripts/start-stop-status stop

dann kannst Du sicher sein, dass Paket und Container off sind.

Nun erhalte ich die folgende Fehlermeldung:

Legacy Zarafa4home package detecded which is conflict with Kopano4s. It must be stopped and it is reccomended to remove it. Removed z4h reverse proxy setting for webapp.

 

[Andy+]

ca. 40GB in Z4H und ca. 36GB in K4S .... also nahezu identisch

Habe die Anhänge auch in der Datenbank, das scheint mir sicherer. Nach der Migration meiner Datenbank hatte ich auch etwas weniger Belegung, ca. 11,5 zu 10,5 GB von Z4H zu K4S.

 

[Matis]

Ich habe es gewagt mein Produktiv-System umzustellen. Um er vorwegzunehmen: ich bin super begeistert!
Die Performance auf der 1515+ mit SSD und 16GB ist noch viel mehr der Knaller als auf der 719+II. Und alles lief viel runder, nichts hing, k4s startete auf Anhieb lief stabil. Das war auf der 716+II immer erst nach mehreren Anläufen der Fall.

Die Installation parallel zu z4h lief sofort einwandfrei. User angelegt, pst importiert, fetchmail konfiguriert (nur das brauchte einen Neustart von k4s um wirklich abzuholen) und es lief! Selbst der sync mit OL und IOS ging auf Anhieb.

Ich habe mir pst files für jeden User für die Migration generiert und diese gründlich aufgeräumt.
Damit konnte ich diese super gut und schnell mit der migration-pst importieren und alles war da!

Vielen Dank für k4s, an alle die daran arbeiten, das ist der Knaller!

 

[Tosoboso]

Nun erhalte ich die folgende Fehlermeldung: Legacy Zarafa4home package detecded which is conflict with Kopano4s. It must be stopped and it is reccomended to remove it. Removed z4h reverse proxy setting for webapp.

Hi, das ist eine Warnung, keine Fehlermeldung und k4s wurde installiert. Falls du nun zurück zu z4h willst, d.h. k4s stoppen, z4h starten fehlt dir der z4h /webapp reverse proxy, den. der zeigt nun auf k4s, ein Kompfort Problem
dau kannst nun mit der Migration beginnen (kopano4s-backup legacy, dann kopano4s-backup restore timestamp etc.)
-TosoBoso

 

[Tosoboso]

Ich habe es gewagt mein Produktiv-System umzustellen. Die Installation parallel zu z4h lief sofort einwandfrei. User angelegt, pst importiert, fetchmail konfiguriert (nur das brauchte einen Neustart von k4s um wirklich abzuholen) und es lief! Selbst der sync mit OL und IOS ging auf Anhieb. Ich habe mir pst files für jeden User für die Migration generiert und diese gründlich aufgeräumt. Damit konnte ich diese super gut und schnell mit der migration-pst importieren und alles war da!
Vielen Dank für k4s, an alle die daran arbeiten, das ist der Knaller!

Die Migrationen laufen nun rund, weil mehrere Optionen bestehen und k4s automatisch den Bug erkennt von z4h und kopano-dbadm k12-16 zur Reparaturaufruft (=> https://kb.kopano.io/display/WIKI/kopano-server+no+longer+starts+after+upgrading+-+K-1216) Das habe ich die letzten Wochen eingebaut und getestet.. Übrigens zum Thema Dank an alle, das Coding des Pakets ist nach wie vor eine 1-Man Show mit Test (=> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=7GBYGXMV8UHYJ), Rat und Tat der Community und nicht zu Vergessen fachliche Tips von Felix / fbartels.
-TosoBoso

 

[peola]

Hi, das ist eine Warnung, keine Fehlermeldung und k4s wurde installiert. Falls du nun zurück zu z4h willst, d.h. k4s stoppen, z4h starten fehlt dir der z4h /webapp reverse proxy, den. der zeigt nun auf k4s, ein Kompfort Problem
dau kannst nun mit der Migration beginnen (kopano4s-backup legacy, dann kopano4s-backup restore timestamp etc.)
-TosoBoso

Danke tosoboso

für den Hinweis.

Ich hatte es auch gemerkt, dass kopano4s Version 0.8.8 läuft. Backup legacy hat funktioniert genauso wie backup restore.
In der MariaDB 10 wurde die Datenbank "kopano" mit 25 Tabellen und entsprechender grösse eingerichtet.
Nach dem Start von k4s auf meiner Synology DS1517+ waren erstaunlicherweise schon alle Benutzer eingerichtet. Die übernommenen Benutzer können sich über webapp anmelden und der Inhalt schein komplett vorhanden zu sein.

Voller Euphorie habe ich Zarafa4h komplett (alle Aufbewahrungen deaktiviert) deinstalliert und damit beginnt nun mein richtig ernstes Problem.

Die Weboberfläche von kopano4s lässt sich nicht mehr starten (wird nicht gefunden), das Admin-Tool zeigt keine Benutzer mehr an. Es lassen sich auch keine neuen Benutzer mehr anlegen. Die Datenbank "kopano" ist in seiner vollen Grösse noch in der MariaDB 10 vorhanden.

Also habe ich nun in mehreren unterschiedlichen Versuchen (Datenbank / Benutzer / Konfigurationseinstellungen behalten, mit webapp reverse Proxy, ohne webapp reverse proxy, bis einschliesslich alles deinstallieren) deinstalliert und wieder neu installiert. Kopano4S kann nicht mehr auf die Weboberfläche zugreifen und neu angelegte Benutzer werden nicht übernommen oder angezeigt.

Zarafa4H konnte ich dagegen installieren und eine gesicherte Datenbank in MariaDB 5 zurückspielen. Hier funktioniert alles wie gewohnt. Auch bei der Parallelinstallation Kopano4S/Zarafa4H kann Kopano nicht auf die Weboberfläche zugreifen und es können keine Benutzer anleget werden.

Was muss ich ändern um Kopano wieder in den originalen Zustand zu versetzen, ohne den kompletten Server neu aufzusetzen?

Danke für die weitere Hilfe!

Grüessli
peola

 

[Matis]

Das hört sich nicht gut an. Ich hoffe es ist zu klären. Ich kann Dir leider keinen Tipp geben.
Aber danke für den Hinweis!!
Ich wollte heute z4h löschen. Das lasse ich nun tunlichst bleiben.

 

[Matis]

... noch eine Frage an die, die schon erfolgreich Ihre großen db umgezogen haben.
Wie hat das dann anschließend mit dem sync der Clients geklappt?
IOS geht er wenn man in den folger geht,
OL geht bei mir gar nicht, die Ordner werden nicht synchronisiert. ActiveSync streicht die Segel. Habt Ihr alle noch den OL-Client laufen?
Danke.

 

[Tosoboso]

Voller Euphorie habe ich Zarafa4h komplett (alle Aufbewahrungen deaktiviert) deinstalliert und damit beginnt nun mein richtig ernstes Problem. Die Weboberfläche von kopano4s lässt sich nicht mehr starten (wird nicht gefunden), das Admin-Tool zeigt keine Benutzer mehr an. Es lassen sich auch keine neuen Benutzer mehr anlegen... deinstalliert und wieder neu installiert. Kopano4S kann nicht mehr auf die Weboberfläche zugreifen und neu angelegte Benutzer werden nicht übernommen oder angezeigt.
Was muss ich ändern um Kopano wieder in den originalen Zustand zu versetzen, ohne den kompletten Server neu aufzusetzen?
peola

Hi hier sind mehrre Punkte genannt, die wir differenzieren müssen:
1) Die Beobachtung / Vermutung nach Migration mit Parallel Installation z4h / k4s, dass durch z4h Deinstallation k4s gerendert wurde
Das ist konzeptionell schwer vorstellbar, ich werde es aber Testen. z4h ist auf MariaDB5, k4s auf MariaDB10, z4h hat Docker Debian Container basis Debian 8, k4s 9, z4h hat etc und mounted Shares anders als k4s. Die einzige Überschneidung ist der Reverse Proxy auf /webapp, den k4s ja entfernt.
2) Anlegen von neuen Benutzern, kein login via Webapp möglich
In der neusten Kopano Community wird bei Verwendung von kopano-admin kein Store mehr angelegt. Das führt dazu, dass man neue Nutzer nicht einloggen kann. Dies ist im Forum beschrieben bzgl. store anlegen und auch im neusten k4s GUI behoben (call zu Store Anlegen beigefügt)
3) Neuaufsetzen auf Basis der Datenbank geht bei z4h, aber nicht k4s
Auch das ist eine Beobachtung / Annahme, die ich konzeptionell nicht folgen kann, denn z4h und k4s sind hier identisch: alles was es braucht ist die Datenbank, sofern man die Anhänge nicht auslagert, und dann kann man Installieren. Es ist jedoch angeraten nach Deinstall einen Reboot zu machen und dann neu zu installieren mit Verwendung der alten Datenbank. Andy+ macht das routinemässig mit positivem Feedback.
4) Docker Container bricht ab und dann funktionieren admin-GUI, webapp nicht.
Hier liegt höchstwahrscheinlich das Problem und es gilt rauszufinden, warum Docker abbricht.
Es kann z.B. sein, dass noch Ports belegt sind, durch z4h Zombie, oder einfach Synology Mail-Server.
Es kann auch sein, dass du beim Re-Install k4s Attachments on FS nicht Deaktiviert hast. Dann stoppt k4s.
Also im Docker GUI dem k4s Container Sektion Protokoll nach Output und Fehlern Suchen, Im k4s server.log nach Fehlern suchen (Docker Protokoll zeigt auch die letzten server.logs bei Abbruch) Dienste stoppen, die Ports blockieren, in Docker GUI Checken, ob alle Monuts da sind. Da ist das Troubleshooting was ansteht.
TosoBoso

 

[peola]

Danke Tosoboso

für deine weiteren Hinweise. Aus diesem Anlass habe ich noch einmal alles neu abgearbeitet und es hat mit mehreren kleinen Stolpersteinen geklappt.

Meine Vorgehensweise und die damit verbundenen kleinen Problemen sahen wie folgt aus:

Ich habe die migrierte kopano-Datenbank aus der MariaDB 10 von Hand gelöscht.
Von Zarafa habe ich über Outlook von jedem Benutzer Backup.pst exportiert (Achtung: Notizen und Dateien müssen zuvor in Outlook neu angelegt werden durch z.B. Inhalte kopieren und einfügen).

Zarafa4H (Version 0.7.5) habe ich inkl. Datenbank und Backup komplett deinstalliert und den Server neu gestartet.

Darauf habe ich Kopano4S (Version 0.8.9) nach Anleitung Wikipedia Schritt für Schritt eingerichtet.
Nach der Installation habe ich den Server (Synology DS 1517+) neu gestartet und den Internetbrowser-Cache gelöscht.

Nach dem erfolgten Neustart konnte ich tatsächlich wieder Kopano-WebApp starten.
Meine Benutzer (wie in Zarafa angelegt) konnte nun ich wieder mit Kopano4S-Admin anlegen (inkl. mindestens einem Admin-Benutzer).
Somit hatte ich vermutlich zuvor Cache-Probleme, einen fehlerhafte Datenbank oder es macht tatsächlich der Neustart des Servers etwas aus.

Die exportierten backup.pst-Dateien habe ich in den Ordner ../kopano/backup kopiert. Hierzu habe ich unter DSM 6.2 in der "Systemsteuerung" unter "Gemeinsamer Ordner" -> "Bearbeiten" des Ordners "kopano" aufgerufen. Unter "Allgemein" habe ich "Verbergen sie diesen gemeinsamen Ordner unter "Netzwerkumgebung"" deaktiviert und unter "Berechtigungen" den entsprechenden Administrator Lesen/Schreiben-Berechtigung vergeben.

Nun habe ich mit Putty-SSH als root-Benutzer (Telnet auch möglich) mit dem Befehl "kopano-migration-pst backup.pst -u Mail-Benutzername" alle Benutzerkonten einzeln migriert. Den Server habe ich darauf wieder neu gestartet.

Die Internetbrowser-WebApp starte ich unter "https://mail.domain.com", kann mich problemlos anmelden und der Inhalt scheint komplett zu sein. Im Kalender musste ich jedoch Fehler feststellen. Sich wiederholende Einträge wurden alle übernommen, jedoch keine Einzel angelegten Termine. Die einzelnen Termine habe ich dann aus der exportierten backup.pst in Outlook als Ordern eingebunden und die fehlenden Einträge entsprechend kopiert. Des weiteren wurden durch die Migration ein paar Ordner doppelt angelegt, welche ich dann wieder gelöscht habe.

Bis hierher läuft nun die WebApp und Outlook 2016.

Unter Windows 10 benutze ich "Kopano DeskApp Version 1.0.40" wegen der Funktionalität als Outlook-Ersatz. Diese lässt sich jedoch nicht starten (Fehler: auf dem Server wird WebApp nicht gefunden).
Ich war erst der Meinung, dass die Kopano DeskApp zu veraltet ist und habe mir eine neuere Version (1.9.7) besorgt. Jedoch kam es auch hier zum gleichen Fehler. Der Fehler lag an der Anmeldeadresse des Servers. Bei Zarafa brauchte ich für die DeskApp lediglich "mail.domain.com", Kopano jedoch "mail.domain.com/webapp".
Somit läuft also auch Kopano DeskApp ohne Probleme.

Kommen wir nun zu mobile Geräte!
Hier benutzen wir in erster Linie Android-Geräte mit Android 8 und darauf die App "nine" installiert habe. Diese scheinen auf dem ersten Blick zu funktionieren. Bei genauerer Betrachtung musste ich feststellen, dass viele Mails nicht mehr in HTML sondern in ASCII angezeigt wurden. Darauf habe ich eine komplette Neusynchronistation durchgeführt, jedoch ohne eine Verbesserung.
Hier hat es nur geholfen, das Benutzerkonto in "nine" zu löschen und neu anzulegen.

Somit laufen Android Geräte mit der App "nine" bei mir auch problemlos.

Unter DSM 6.2 - Systemsteuerung - Aufgabenplaner - Erstellen - geplante Aufgabe das benutzerdefinierte Script "kopano-backup" eintragen und als Administrator ausführe funktioniert ebenfalls ohne Probleme für die regelmässige Sicherung.

Die Zugriffszeiten sind nun spürbar schneller und ich bin auch fast zufrieden.

Fast? Ich habe es bisher noch nicht hinbekommen, mit Kopano4S-Admin "Gruppen", "Benutzer einer Gruppe zuweisen" und "senden als" anzulegen. Hier scheint jeder Eintrag ins Leere zu laufen.

Ansonsten hoffe ich, dass ich dem einen oder anderen auch ein wenig helfen konnte.

Dank an allen aktiven Entwicklern!

Freundlichs Grüessli

peola

 

[Dani Düsentrieb]

Hallo Zusammen,

@Tosoboso zu deinem ersten Punkt hab ich bei mir folgende Erfahrungen gemacht. Ich hatte auch zarafa4h installiert und habe zusätzlich kopano4s installiert und danach die Datenbank migriert. Da ich nicht sofort zarafa4h deinstalliert habe wurde beim nächsten Neustart natürlich zarafa4h neben kopano4s wieder mit gestartet und hat auch wieder fleißig E-Mails abgerufen da es kopano4s überlagert hat. Ich habe dann gleich zarafa4h deinstalliert und das lief ohne Probleme durch und hat meine parallele kopano4s Installation nicht beeinträchtigt.

Das auf den Mobilen Gräten die HTML-Mails im ASCII angezeigt wurden, war bei mir auch so. Allerdings hatte ich das Problem nur in einem Postfach aber dort auf dem Mobil Gerät als auch in der WebApp. Nach einem Neustart der Server war das Problem auch verschwunden und ich die Clients nicht neu syncen.

Gruß Daniel

 

[sky63]

Hallo zusammen,

wahrscheinlich hab ich es irgendwo überlesen, aber bei allen die bisher migriert haben scheint die Ausgangsversion ein laufendes z4h mit Attachments in der DB zu sein. Wie läuft den das wenn ich die Attachments schon unter zarafa im FS habe? Werden die Anhänge durch das migrationsscript an die richtige Stelle kopier/verschoben? Oder muss ich das manuell machen?

gruss,
sky

 

[Huhie]

Guten Morgen Zusammen,

ich lasse einmal wöchentlich ein Backup (HyperBackup) auf meine zweite Syno durchlaufen. Danach muss ich k4s fetchmail
immer mit dem Befehl "kopano-fetchmail init" neu starten. Kann mir jemand sagen, warum das so ist und ob ich das evtl.
per Aufgabenplaner anstossen kann?

Werden Notizen vom Kopano Server nicht in Richtung iOS synchronisiert?

vg und einen schönen Start in die Woche!

Huhie

 

[sky63]

Hallo zusammen,

• über Putty

  kopano4s-backup legacy

  laufen lassen (Dauer ca. 2 1/2 Stunden)
• über Putty

  kopano4s-backup restore timestamp

  des Dumps ausgeführt

K4S ist klasse, läuft stabil und schnell!
Hoffe ich konnte hier weiterhelfen.

Wenn ich das so durchführe ist das Verzeichnis /volume1/kopano/attachments leer obwohl mir kopano4s-backup

saving attachments linked to zarafa...

bzw.

restoring attachments linked to kopano...

ausgibt.

Muss ich die jetzt von Hand kopieren?

gruss,
sky

 

[Tosoboso]

Wenn ich das so durchführe ist das Verzeichnis /volume1/kopano/attachments leer obwohl mir kopano4s-backup

saving attachments linked to zarafa...

bzw.

restoring attachments linked to kopano...

ausgibt. Muss ich die jetzt von Hand kopieren?
gruss, sky

Hi zu kopano4s-backup attachments: das Verzeichnis wird standardmässig mitgesichert.
Im Normalfall ist legacy Zarafa / Zarafa4h mit Attachments in der Datenbank aufgesetzt, die Konvertierung auf Attachments im Filesystem erfolgt dann im 2. Schritt via bordeigenem kopano-backup.
Für den Fall Zarafa4h mit Attachments Sichert k4sbackup im legacy Mode von /volume1/zarafa/attachments und Schreibt in den KopanonShare Backup eine Datei kopano-attachments-timestamp.tgz zusammen mit der Database Dump Datei.
Bitte Prüfen, ob das der Fall ist, ich schau parallel in dem Skript nach und Teste diesen Sonderfall. Hoffe das hilft.
-TosoBoso

 

[sky63]

.....
Für den Fall Zarafa4h mit Attachments Sichert k4sbackup im legacy Mode von /volume1/zarafa/attachments und Schreibt in den KopanonShare Backup eine Datei kopano-attachments-timestamp.tgz zusammen mit der Database Dump Datei.
Bitte Prüfen, ob das der Fall ist, ich schau parallel in dem Skript nach und Teste diesen Sonderfall. Hoffe das hilft.
-TosoBoso

Die Datei im KopanoShare ist vorhanden aber quasi leer

ash-4.3# tar -tf /volume1/kopano/backup/attachments-201810022154.tgz
attachments/

Offensichtlich wird der Pfad falsch gesetzt und nicht /volume1/zarafa/attachments sondern /volume1/kopano/attachments getart. Wenn ich in das Verzeichnis
/volume1/kopano/attachments eine Testdatei anlege und dann nochmal ein kopano4s-backup legacy durchführe ergibt das

ash-4.3# tar -tf /volume1/kopano/backup/attachments-201810022203.tgz
attachments/
attachments/testdatei

Ich habe aber die Stelle (noch) nicht gefunden wo dieser Pfad gesetzt wird.

gruss,
sky


Wenn ich richtig sehe ist dieser Abschnitt für das Backup zuständig

351 # backup attachements if they exist
352 if [ "$ATTACHMENT_ON_FS" == "ON" ] && [ ! -d "ls -A $ATTM_PATH" ]
353 then
354     MSG="saving attachments linked to $DB_NAME..."
355     TS=$(date "+%Y.%m.%d-%H.%M.%S")
356     echo -e "$TS $MSG" >> $DUMP_LOG
357     echo -e "$MSG"
358     CUR_PATH=`pwd`
359     cd $K_SHARE
360     $SUDO tar cfz $DUMP_PATH/attachments-${TSTAMP}.tgz attachments/
361     cd $CUR_PATH
362 fi

K_SHARE wird nur einmal und zwar in Zeile 48 gesetzt

48             K_SHARE="/volume1/kopano"

Z_SHARE ist nirgendwo definiert.

Frage dazu: WIRD K_SHARE während der Installation gesetzt und in das Script gebaut oder ist das hart verdrahtet?

 

[sky63]

Hallo,

habe im Script den Pfad zu meinem attachments-Verzeichnis hart verdrahtet der Variable Z_SHARE zugewiesen und in Zeile 359 aus K_SHARE Z_SHARE gemacht. Dann läuft es sauber durch. Danach läuft dann auch ein kopano4s-backup restore ohne Fehlermeldung durch. Allerdings hat die Datenbank dann 26 tables. Sollten das nicht nur 25 sein?

Wie gesagt, ist jetzt hart verdrahtet, müsste man um es sauber zu machen aus der server.cfg des zarafa auslesen.

gruss,
sky

 

[sky63]

Hallo zusammen,

erster Start

 Wed Oct  3 18:19:35 2018: [=======] Starting kopano-server version 8.6.81 (pid 10322 uid 0)
 Wed Oct  3 18:20:03 2018: [error  ] Attachments are stored with option 'files', but 'database' is selected.
 Wed Oct  3 18:20:03 2018: [=======] Server shutdown complete.

Frag ich mich wieso, wenn ich bei der Installation Filesystem angegeben habe. Egal. Alle Einstellungen in /etc/kopano/server.cfg bezüglich der attachments angepasst.

Zweiter Start

  Wed Oct  3 18:27:03 2018: [=======] Starting kopano-server version 8.6.81 (pid 35 uid 0)
 Wed Oct  3 18:27:03 2018: [error  ] Unable to change ownership for attachment directory '/var/lib/kopano/attachments'
 Wed Oct  3 18:27:03 2018: [=======] Server shutdown complete.

Frag ich mich auch wieso. Die Berechtigungen wurden durch das

kopano-backup restore <ts>

gesetzt.

gruss,
sky