Umzug von Zarafa auf Kopano

UCS - Univention Corporate Server
,
#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

#21

Mensch - Ihr seid aber auf Draht! Vielen Dank.

Die Installation ist schon etwas älter. Die DBs habe ich auch schon mehrfach umgezogen. Da ist wohl ein bisschen Sand ins Getriebe gekommen.

Mit https: habe ich einen Zertifikatsfehler bekommen, da das Zertifikat auf den öffentlichen FQDN zeigt. Dort ist Mapi aber nicht freigeschaltet.

Mit http und Port 236 hats erst auch nicht funktioniert. Jetzt habe ich mal einzellne Mailboxen angesprochen.
So gehts scheinbar. Er zieht die Daten runter. Wenn ich die Sicherungen nun auf den Kopano zurückgeschrieben bekommen - perfekt.

Vielen Dank.
VG - Fossi

#22

Vielen Dank.

Das hat tatsächlich funktioniert. Beim ersten Anlauf gab es leider Probleme. Ich habe die locales auf de_DE.UTF-8 gesetzt. Auch das System habe ich so aufgesetzt und Anpassungen im Apache unter /envars vorgenommen. Beim Erzeugen eines Users sind die Ordner in Kopano jedoch ohne Sonderzeichen angelegt worden. Erst ein Installieren der en_GB.UTF-8 und ein umbenennen in Englisch und Retour auf Deutsch hat die Verzeichnisse korrekt angelegt. Ein zuvor durchgeführter restore hat zusätzliche unterordner angelegt. Das war nicht optimal.

Jetzt lehnt der neue leider noch die Mails von aussen ab. da muss ich noch dran arbeiten. Wenn jemand eine Idee hat: Letzter Fehler: 451 4.4.1 - Connection Time out.

Da ich einen weiteren Server in der Form aufgesetzt habe, habe ich da noch keine Idee dazu. Klingt nach Firewall, 25, 443, 465, 587 sind aber offen. Für das Thema mache ich aber dann ggf. einen neuen Thread auf.

VG - Fossi

Vielen Dank.

#23

All das sollte auf einen Univention System eigentlich nicht notwendig sein. Ist die letzte App Version installiert?

#24

Ich habs soeben nochmal frisch installiert und habe den Fehler an gleicher Stelle gefunden.

Die App Kopano läuft als 8.6.2. Mit wohl 8.6.8 werden die defeaults nicht mehr unter /etc/default/kopano, sondern in /etc/kopano/admin.cfg gesetzt. Die Datei unter /etc/kopano wird angelegt, jedoch kann der core damit “noch” nichts anfangen und es wird gar kein Userstore angelegt und es erscheint ein Fehler auf den falschen Parameter, wenn auf der Cli kopano-admin angesprochen wird. Nach Auskommentieren werden die Stores erstellt, jedoch ohne Sonderzeichen in den Ordnernamen. Für den zuerst angelegten User habe ich dann den Store manuell erzeugt, der dann auch die Sonderzeichen enthielt. Ein testweise danach über die Managementconsole erstellter Benutzer wird ohne Sonderzeichen in kopano erstellt.

Meinen Fehler habe ich übrigens wohl auch gefunden: EWE sperrt wohl per default in ihren Netzen den Port 25. Dann weiß ich nun, warum ich mit meinem Server seit dem Umzug Probleme habe. Bin heute schier verzweifelt. Irgendwann hatte ich dann raus, das tatsächlich der Port 25 bei mir von außen nicht erreichbar ist - natürlich erst nach etlichen Versuchen an anderer Stelle.

Ich richte jetzt erstmal wieder fetchmail ein - auf der neuen Maschine. Am Dienstag soll ich einen Anruf bekommen.

VG - Fossi

#25

Maschine läuft. Gibts eine Möglichkeit, einzelne Standardordner zu löschen, die sich über die Oberfläche nicht löschen lassen?

RSS Feeds
RSS-Feeds

wäre da so ein Beispiel. Danke übrigens für den hervorragenden Support hier.

VG - Fossi

#26

Merkwürdig. Ich habe mal https://jira.z-hub.io/browse/KUCS-38 erstellt um bei Zeit das mal nachzustellen.

Nein, das ist nicht vorgesehen.

#27

Meine Zarafa/Yaffas machen mich fertig. Ich kann machen was ich will. Ich versuche die Mailboxen zu extrahieren und bekomme die Verbindung nicht auf die Reihe:

kopano-backup -s http://x.x.x.x:236/zarafa -U markus -P xxx -u user1

Führt immer wieder zu folgender Meldung:

HrLogon server “http://x.x.x.x:236/zarafa” user “markus”: network error
backup - WARNING - could not connect to server at ‘http://x.x.x.x:236/zarafa’, retrying in 5 sec

Ich hab alles durch: Gross- und Kleinschreibung, neuen Admin-User angelegt, laut netstat -tulpen wird an 0.0.0.0:236 gelauscht.

Dann habe ich versucht, das ganze bei mir zu Hause nachzuvollziehen, hab den alten Server raufgefahren und auch da gleicher Fehler. Ich komme einfach nicht mehr an die Postfächer.

Wie kann ich denn dem ganzen auf den Grund gehen? Warum siehts so aus, als wenn der Server gar nicht da wäre? Auch ein Ping geht ohne Probleme. Die Rechner hängen im selben VLan in der DMZ. Es fühlt sich so an, als wenn MAPI sich taub stellt, als wenn da was in irgendeiner .conf steht. Ich habe aber nichts dergleichen finden können.

Schon jetzt Danke für die Unterstützung.

VG - Fossi

#28

Hallo @Fossi,

ich würde empfehlen hierzu einmal mit den vorhandenen Informationen (welche Zarafa Version, welche Kopano Version, etc) einmal an unserem Support zu wenden. Hier kann dann unter umständen jemand auch mal direkt auf die Maschine schauen.

#29

Moin Herr Bartels.

Auf den Support habe ich leider keinen Zugriff. Ich habe aber heute bei zwei Kunden einen funktionierenden Test durchgeführt. Eine aktuelle Installation des UCS 4.2 hat die Daten ohne murren extrahiert. Der UCS 4.3 bringt - meine ich - Kopano 8.6.8 auf die Platte. Der 4.2 Kopano 8.4 irgendwas.

Die Maschinen wurden in der vergangenen und dieser Woche neu installiert. Zum extrahieren habe ich nur den Core aufgespielt und beim 4.2 keine Aktualisierungen durchgeführt. Die Zarafa-Installation ist auf dem letzten Stand der Bitbone-Repositories (Yaffas) das müsste 7.1.14 gewesen sein. An den Firewalls etc. habe ich im lokalen Netz der DMZ keine weiteren Änderungen vorgenommen.

Schade, das die Migration mit den aktuellen Paketen so nicht mehr möglich ist. Ich bin mir nicht sicher, ob das so gewünscht ist. Dies nur für den Support und die Community runtergeschrieben. Ich stelle bei Bedarf gern Zugang zu den Maschinen her.

VG - Fossi

#30

Einer der Vorteile einer gültigen Subskription: damit wäre all die Arbeit oben (und die Zeit die investiert wurde um zu der zugrundelegenden Erkenntnis zu kommen) erspart geblieben.

Wie dem auch sei mit einer aktuellen Kopano Version klappt auch die Verbindung zu einem 7.1er Zarafa wieder.

#31

Hallo,
ich habe hier auch noch einen “alten” Zarafa 7.1 Server gefunden. Er soll komplett migriert werden. Update auf eine höhere Version klappt nicht mehr.
Leider kann auch das Kopano Backup vom neu installierten UCS Server nicht auf den alten 7.1 Server zugreifen.
Du schreibst das es mit einer aktuellen Kopano Version wieder funktionieren soll, ich habe hier einen ZCP 7.1.14-51822 und einen Kopano 8.6.8.2

Ich bekomme auch immer nur die gleichen Meldungen wie oben schon bemerkt:

Kann ich irgendein Paket manuell updaten oder wie bekomme ich ein Backup/Restore zwischen diesen Systemen hin??

Vielen Dank,
Gerd

#32

Kunden mit einer gültigen Subskription könnten auf die Version 8.7.0.110-0+61.1 aktualisieren, dort müsste es wieder funktionieren.

Alternativ könnte kopano-backup per Docker ausgeführt werden. Dies geht z.B. so docker run --rm -it -v /var/run/kopano/:/var/run/kopano -v $(pwd):/kopano/path zokradonh/kopano_utils kopano-backup -h

Mehr zu diesen Docker Images gibt es unter https://github.com/zokradonh/kopano-docker

#33

Danke für den Hinweis, ist schon bekannt wann es dieses 8.7 Update auch für User ohne Subskription geben wird? Das ist hier ein privater Server mit 4 Anwendern…

#34

Das habe ich zuletzt in Mails in Outlook 2016 no longer consistent after upgrade to Kopano Core 8.6.8.2 beantwortet.

Eine Subskription für bis zu 5 Benutzer kostet 75€ pro Jahr (zzgl. MwSt). Vermutlich hat dein Server höhere Stromkosten als das was Kopano pro Jahr kostet.

#35

2 posts were split to a new topic: Fehlermeldung bei Durchführung von kopano-backup

#37

@gulden kannst du die letzten beiden Posts in ein eigenes Topic verschieben? Danke

Mastodon