Umzug von Zarafa auf Kopano

UCS - Univention Corporate Server
,
#1

Guten Tag,

im Q1 2017 wird einer meiner Kunden den Umzug auf neue Serverhardware genehmigen. Es wird eine Ablösung von Zentyal nach UCS erfolgen (was dringend nötig ist).

Der Kunde benutzt Zarafa 7.1 (SMB) und Agorum 7.7.0.4 (Pro).

Auf der neuen Hardware wird eine UCS-Domäne mit einem Take-Over durchgeführt. Damit sind aber nur Benutzer und ein paar Einstellungen umgezogen (also das, was im AD hinterlegt ist)

Welche Option hab ich, was den Umzug des Mail und des DMS angeht? Kann ich mit einem Tool mich an den Zarafa “anbinden” und dann eine Kopie der Daten auf dem Kopano erstellen? Es handelt sich nicht um viele Benutzer (circa 10). Aber die Mails sind schon einige. Deshalb wäre ein automatischer Prozess wünschenswert.

Das gleiche bei Agorum. Das Mail Archiv hat derzeit eine Größe von 800GB. Kann man nach der Installation von Agoum auf dem UCS einfach ein DB-Dump der “alten” Instanz einspielen?

Vielen Dank für die Hinweise und Tipps
Michael

#2

Hallo Michael,

ich kann leider nur für Zarafa/Kopano sprechen, für Agorum wirst du dir noch einen anderen Experten suchen müssen (oder mal bei deren Support nachhaken).

Sofern ldap_user_unique_attribute im alten und neuen System den selben Wert referenzieren/ausgeben reicht sogar ein einfacher Import der MySQL Datenbank und die Nutzer können wieder wie gewohnt auf Ihre Daten zugreifen. Hierbei ist es sogar nebensächlich ob der Nutzerdetails oder die E-Mail-Adresse komplett identisch sind.

Solltest du nicht den Weg über Mysql und die uuid gehen wollen, dann kannst du einen Blick auf kopano-backup werfen. Diesem kannst du über die Kommandozeile einen Socket mitgeben, welche dann auch das alte System sein kann.

So oder so, ich würde empfehlen einen ausführlichen Testlauf der Migration zu machen.

#3

Hallo,

Ich habe nun alles vorbereitet um die ersten Tests zu machen. Im Serverraum ist eine Testdomäne erstellt, die den Umzug via Takeover simulieren soll. Jetzt würde ich gerne auf dem neuen System das kopano-backup ausprobieren. Wie funktioniert das mit dem Socket?

Zarafa-Server hat die IP 192.168.1.97 - Der neue Kopana-Server hat die 192.168.1.30

Der Befehl lautet ja: kopana-backup -s SOCKET

Leider konnte ich keine genaue Beschreibung für das Tool mit Beispielen finden.

Vielen Dank für weitere Hinweise zu diesem Thema

#4

Hallo mykey,

im Grunde ganz einfach. Der Socket innerhalb von Kopano//zarafa ist immer ip-des-server:237/zarafa für die verschlüsselte Variante. Innerhalb von Kopano wird statt /zarafa /kopano verwendet, es funktioniert aber auf beiden Seiten beides.

Der Aufruf wäre daher wie folgt:

kopano-backup -s ip-des-servers:237/kopano -U Nutername-eines-Admins -P Passwort-des Admins

So aufgerufen zieht er das Backup von allen, mittels -u könnte man aber auch nur einen einzelnen Nutzer angeben.

Neuer Server für Kopano
#5

Vielen Dank für die schnelle Hilfe.

Ich habe jetzt die Datensicherung mal gestartet. Bei 20 Postfächern dauert es wohl noch eine Weile. Dann werde ich die Rücksicherung in den neuen Server probieren.

LG
Michael

#6

An welche Stelle wird denn die Datensicherung abgelegt, wenn ich den zuvor angeführten Script ausführe?

Der Befehl kopano-backup --restore fragt nämlich nach einem “path to backup data”, damit ich das Restore auf dem Zielsystem (auf dem auch der Backup-Befehl ausgeführt wurde) ausgeführt werden kann.

LG
Michael

#7

Hallo Michael,

bei Ausführung des Backups wird für jeden Nutzer ein Unterordner angelegt. Wenn es also einen Nutzer “abc” gibt, dann befindet sich nach dem Backup ein Ordner “abc” in dem aktuellen Verzeichnis.

Ein Restore ist dann ein “kopano-backup --restore -u abc abc/” (wieder aus dem selben Verzeichnis). Sollte abc auf dem neuen System anders heißen, muss “-u abc” entsprechend angepasst werden.

#8

OK. Hab die Daten gefunden. Aber das man alle Benutzer wieder zurückliest, dafür gibt es keinen Befehl. Ich muss also für jeden einzelnen Benutzer das Restore aufrufen.

Bei 20 Benutzern kein riesen Thema. Aber ich will lieber vorher nochmal nachfragen

LG
Michael

#9

Hallo Michael,

das ist korrekt einen “restore all” Befehl gibt es nicht. Sofern aber der alte Nutzername dem neuen entspricht ist dies ja mit einem einfachen Bash Skript erledigt.

#10

[quote=“fbartels”]Hallo Michael,

das ist korrekt einen “restore all” Befehl gibt es nicht. Sofern aber der alte Nutzername dem neuen entspricht ist dies ja mit einem einfachen Bash Skript erledigt.[/quote]

Hier der passende Script, für alle die das selbe Problem haben :wink:

[code]#!/bin/bash

for i in $(ls /root/); do
echo $i
kopano-backup --restore -u $i /root/$i/
done[/code]

Kopano inline.txt
#11

Hallo,

ich habe massive Probleme mit meinem Zarafa-Server. Ein normales Update unter Univention ist nicht möglich.
Außer, dass ich vor ein paar Jahren Z-Push von Hand installiert habe, habe ich keine weiteren Änderungen auf dem Server seit der Installation vorgenommen. Ausgenommen die Updates welche ich über die WebConsole eingespielt habe.
Nun würde ich gerne den Server komplet neu aufsetzen und entweder in diesem Rahmen das Update auf Kopano ausführen oder die alte Zarafa-Version wieder installieren und danach den Updatepfad wie hier beschrieben durchführen:
https://wiki.z-hub.io/display/K4U/Migrating+from+the+old+Zarafa+Univention+Apps+to+Kopano4UCS

Um die Datenbank zu sichern möchte ich einen SQL-dump ausführen. Dieses Kommando habe ich dazu verwendet:

mysqldump --single-transaction -u <user> -p <password> zarafa

Leider passen die übergebenen Usercredentials nicht. Weder der Administrator noch irgendein anderer Zarafa-Admin kann die Datenbank dumpen.
Gibt es einen speziellen User der dazu genutzt werden muss? Muss ich einen speziellen Benutzer irgendwo anlegen?
Leider komme ich da derzeit nicht weiter da alle anderen Verfahren eines Backups entweder nicht kompatibel sind oder nicht funktionieren.

Da ich aufgrund jüngster Erfahrungen den Server komplett neu aufsetzen möchte, würde ich mir das Backup einzelner User-Accounts gerne ersparen um diese dann Zeitaufwändig wieder herzustellen.
Am schönsten wäre es für mich den Server einfach neu zu installieren und die Datenbank aus einem Backup wieder herzustellen.

Vielen Dank im Voraus.

Mit freundlichen Grüßen
Hendrik Dreyer

#12

Hallo,

eine Antwort habe ich bereits gefunden:
[url]Kopano SQL dump Password]

Dies werde ich zeitnah testen und schauen ob ich dies genauso auf Zarafa anwenden kann.

Mit freundlichen Grüßen
Hendrik Dreyer

#13

Hallo,

den Dump habe ich nun wie folgt durchgeführt:

mysqldump --single-transaction -u root -p zarafa > zarafa.dump Enter password:

Das Kennwort ist unter /etc/mysql.secret gespeichert.
Ich werde als nächstes ein vollständigens Backup durchführen und den Zarafa Server dann neu installieren.

Mit freundlichen Grüßen
Hendrik Dreyer

#14

Gibt es irgendwo eine Anleitung, wie man einen solchen dump ab besten in Kopano zurückspielt ?
Ich würde das gerne mit einem dump aus einem Zentyal (Zarafa 7.1) ausprobieren.
Danke.
Rainer Berns

#15

Hallo,
ich bin gerade bei der Migration eines 7.2.2-Zarafa-Systems => UCS/Kompano. Die Attachements habe ich per rsync kopiert, nun bleibt noch die mysql, von der ich einen Dump erzeugt habe. Kann ich diesen Dump einfach in UCS in die mariadb restoren bzw. was hat es mit dieser uuid zu tun? Wird da die Zuordunung der Benutzer zu den Postfächern abgebildet und wo finde ich die?

#16

Ja, einem Import des Dumps sollte nichts im Wege stehen. Eine noch ältere Zarafa Version sollte problematisch sein aber 7.2.2 sollte noch gehen. Siehe dazu auch https://kb.kopano.io/display/WIKI/Migrating+from+ZCP+7.1+or+earlier+to+Kopano+Core+8.5+or+later

Ja, korrekt. Über die die Unique ID des Users erkennt Kopano (bei Zarafa war das identisch) welche Benutzer es in der LDAP Quelle gibt (und dementsprechend Stores erzeugen oder löschen muss). Welches Attribut hierfür genutzt wird ist in der ldap.cfg definiert. Wenn sich dieses Attribut ändert, dann gehen Postfachzuweisungen und u.a. auch ACLs verloren.

Grundsätzlich lässt sich diese Zuordnung aber wiederherstellen. Die Schritte in http://wiki.zarafa.com/index.php/Zarafa_DB_to_LDAP_user_plugin_conversion sind grundsätzlich identisch egal ob das Ursprungssystem das DB Backend oder einfach nur eine andere unique ID verwendet hat. Eine leicht aktualisierte Version des db-upgrade-… Skripts gibt es unter https://stash.z-hub.io/projects/Z4U/repos/zarafa4ucs/browse/scripts/db-upgrade-addressbook-entryids-delegate.pl.

Sollte es hierzu noch Fragen geben empfehle ich ein Ticket bei unserem Support aufzumachen.

#17

Ich stehe vor dem gleichen Problem, habe drei Yaffas Installationen, die nun so langsam zu alt werden. Ich kann also nicht die mysql eines 7.1 nehmen und in die kopano eines aktuellen 8.6 zurückspielen, da sich Änderungen an der Struktur ergeben haben. Ist das richtig?

Jetzt habe ich in diesem Thread die Lösung über kopano-backup gefunden. Ist das in den kostenlosen Varianten verfügbar? Das wäre die perfekte Lösung, da es sich um recht kleine Installationen mit je nur bis zu 5 Nutzern handelt.

Ist kopano-backup bei der UCS sowieso verfügbar? dann könnte ich mein Backup-Scenario überdenken. Bislang habe ich Nachts ein dump und per rsync das /data - Verzeichnis auf einen NFS mount vom Nas geschoben. Läuft seit Jahren einwandfrei und auch die Postfächer waren nach einem zurückspielen immer verfügbar, sofern im Vorfeld die Benutzer identisch angelegt wurden. Auf die LDAP-Einträge habe ich da nicht geachtet. War Yaffas da anders aufgestellt, als UCS?

Danke für die Unterstützung.

VG - Fossi

#18

Fast. Damit die datenbankinterne Struktur aktualisiert werden kann, müsste die Datenbank halt einmalig mit einem 7.2er Server gestartet werden. Neuere Kopano Versionen bringen diese Konvertierung nicht mehr mit.

Kopano ist 100% OSS, die kostenpflichtigen Versionen enthalten keine zusätzlichen Komponenten. Diese erhalten “lediglich” mehr Aufmerksamkeit in Bezug auf Testing und für diese gibt es offiziellen Support durch Kopano.

Ja, siehe oben.

Nein, wie oben schon einmal geantwortet nutzt Yaffas/Zarafa da die selben mechanismen, wie auch Univention/Kopano.

#19

Ich kann da eingeben, was ich will. Ich bekomme einen Haufen Netzwerkfehler. Kann es sein, das die Firewall vom UCS alles blockiert?

Croot@MAR-UCS1:~# kopano-backup -s x.x.x.x:237/zarafa -U Markus -P xxxx
[error ] gsoap connect: ()
[error ] HrLogon server “x.x.x.x:237/zarafa” user “Markus”: network error
2018-11-05 23:19:34,804 - backup - WARNING - could not connect to server at ‘x.x.x.x:237/zarafa’, retrying in 5 sec

#20

Es muss entweder ein http:// oder ein https:// davor

Mastodon