Kopano von UCS nach Docker

Da die Zeiten von Kopano ja komplett angezählt sind und es bisher keine (für den Privatmann/-frau) Alternativen gibt, stellt sich die Frage: wie kann man UCS und das derzeitige Kopano auch in Zukunft weiter nutzen.

Für mich gibt Kopano in seiner derzeitigen freien Version genau das, was ich brauche: Mails empfangen und senden. Kontakte und Termine hab ich alle in der Nextcloud.

Daher die Frage als Idee: Können wir (all diejenigen, die das aktuelle Kopano und UCS auch in Zukunft weiter nutzen wollen) unsere Kopano-Instanz aus der UCS Infrastruktur “lösen” und in einen Docker packer. Sollte dann irgendwann UCS keine Kopano-Instanz mehr im App-Store haben, könnten wir diesen Docker-Container auf eine neue (virtuelle) Maschine ziehen und dann nur noch an das neue UCS anbinden.

Gibt es da schon irgendwelche Ideen und Konzepte dazu? Denn ich denke, dass wir langsam da eine passende Lösung für uns finden sollten. Und da wir im Moment noch keinen “Stress” haben, weil UCS sagt, das die Version X die letzte mit Kopano sein wird, könnten wir da mal einen Ansatz gern erarbeiten

Wer hat Lust sich da zu beteiligen?

Habe heute gesehen, dass mittlerweile es feststeht, das in UCS 5.2 kein Kopano mehr möglich sein wird, was jetzt tatsächlich schneller kommt, als erwartet.

Dadurch wird aus der “Idee” wohl doch schneller ein “Projekt”.

Gibt es da schon entsprechende Ansätze, an die man sich einbringen kann?

Ich bin in dem Projekt schon ziemlich weit gekommen. Hab nun aber das folgende Problem:

Nach dem Import der Datenbank auf den neuen Server, habe ich zwar die deutschen Sonderzeichen und die deutschen Ordnernamen. Aber nicht alle “Smilies” die man so in der Betreffzeile einfügt, erscheinen als das passenden Icon, sondern als “Fragezeichn in einem auf der Spitze stehenden Quadrat” - ist jetzt nicht dramatisch, aber ich wüsste gern, woran das liegt.

Hab den Docker-Container mit Webapp 6.0.0, Core 11.0.2 und Ubuntu 20.04.

Hi @MyKey0815,

eins kurz vorweg die empfohlene Lösung wäre unser neues Produkt. Kopano.cloud hat eine neu entwickelte native Unterstützung für die Windows-Version von Outlook und kommt in einem einfach zu verwaltenden Container daher. Die neue Version gibt es derzeit zwar nicht im Univention Appcenter, aber einer unserer Partner stellt eine einfach zu installierende Appliance zur Verfügung, die entsprechende Vorlagen für die Anbindung an Univention beinhaltet. Und ein Migrationstool für die direkte Übernahme der alten Daten gibt es auch.

Mir ist nicht bekannt aus welcher Quelle dieser Container kommt, sofern du aber aktuell noch am alten festhalten willst, dann würde ich die Aufmerksamkeit eher Richtung GitHub - zokradonh/kopano-docker: Unofficial Kopano Docker images for all Kopano services. lenken. Wenn es zur Containerisierung des alten Stack auf Univention gekommen wäre, dann wäre das von mir verlinkte Projekte die Basis dessen geworden, auch haben wir Teile davon in unserer alten CI Pipeline verwendet.

Das ist ein Zeichen dafür dass es irgendwo in deinem Stack ein Problem mit Locales/Sonderzeichen gibt. z.B. in der PHP Konfiguration.

Hi @fbartels

Danke für deine ausführliche Email. Dazu möchte ich gern auch Stellung nehmen.

Ja, mir ist bekannt, das es das “neue” Kopano gibt - aber leider wurde ja das “Community”-Model aufgegeben. Und da ich es nur für privat einsetze (3 Benutzer) ist mir das “Mindestens 10 User”-Model sehr überdimensioniert. Außerdem hat das “alte” Kopano (so wie es grad in UCS implementiert ist) all das, was ich nutze und brauche (bin halt sehr genügsam) :wink:

Was die Docker-Version angeht, habe ich meine Source aus GitHub - mlan/docker-kopano: Docker image providing Kopano webmail, ActiveSync, ICAL, IMAP and POP3 services

Mit der von dir erwähnten Version hab ich auch schon “experimentiert”, aber da hab ich es leider nicht auf Anhieb hinbekommen, dass ich es über einen anderen als dem angeführten http://kopano.demo/ aufrufen konnte. Bei der Version von mlan konnte ich es über die IP aufrufen

Meine Idee ist nämlich, dass ich Kopano als eigenen Stack laufen habe und es eine Anbindung an das bestehende UCS per LDAP gibt. Mittlerweile sehe ich, dass vieles in UCS sehr granular einstellbar ist - und das hat Auswirkungen auf die Anpassungen der “Standard-Settings” eines alleinstehenden Kopano-Stack

Anscheinend bin ich wohl der Einzige, der den Weg gehen will, da es kaum noch eine aktive Kopano-Community in dieser Hinsicht gibt bzw. Personen die sich die Mühe machen wollen dafür eine Lösung zu finden.

Wie gesagt: ich bin eigentlich schon recht “weit” im Projekt - hab einiges an Zusammenhängen herausgefunden - und würde das gern dann am Ende auch “veröffentlichen”. Vielleicht findet sich ja noch der eine oder andere und hat ein paar Ideen dazu

@fbartels Ich werde mir das mit deinem Link nochmal anschauen, wenn du sagst, das dies das von dir/euch/Kopano “ernste Alternative” Projekt gewesen ist. Denke dass da dann auch die entsprechenden Punkte in Bezug auf “Deutsches Umfeld” etwas mehr beachtet waren

Moin
kannst du die von dir eingesetzte Version nicht in einer VM mit debian installieren und dann per ldap an den UCS anbinden oder gibt es diese freie Version nicht als download?

Gruß Ben

Ja, das ist einie Eigenheit von Caddy. Die Requests werden auf ihren Hostnamen geprüft und daher ist es nicht möglich eine andere Adresse/IP als die konfigurierte zu verwenden. Generell würde ich empfehlen (auch für kleine Netzwerke) statt der IP einen DNS Namen zu verwenden. Das ist auch zuhause mit einfachen mitteln möglich (eventuell unterstützt es der Router auch schon von Haus aus). Auch für den per Default konfigurierten OIDC Login ist dies notwendig.

Ja, ich hatte schon zu Anfang von Corona nach jemandem gesucht der die Maintenance übernehmen will, aber trotz beteuerungen ist leider nie etwas daraus geworden.

Hi @BenSommer

ich denke schon, dass dies noch möglich ist. Meine Vermutung war, dass ein Docker-Stack da etwas “anwenderfreundlicher” ist, weil die Konfigurationen per Parameter übergeben werden können und (besonders jetzt, wo es noch vieles zu testen gibt) die Installationszeit verkürzt

Außerdem müssen die Anpassungen an das UCS-LDAP so oder so gemacht werden, da durch die Struktur von UCS vieles über Einstellungen und Paramter in UCS geht.

Hi @fbartels

mittlerweile hab ich das hinbekommen mit dem “FQDN” - der Name würde jetzt auch passen für mein Netzwerk. Ich denke dass es dann echt besser ist, das ich mit dem Projekt weiter mache und schau, wie weit ich komme.

Echt schade das keiner die Maintenance von dem Projekt übernommen hat. Leider fehlt mir da das Wissen zu Docker und Kopano um dort als “Fachmann” auszuhelfen. (Alleine der Hinweis, dass man “eigene Container erstellen kann, die man dann auch hochladen könnte”, hab ich noch nie gemacht und bisher noch nicht gebraucht) Ich bastel darum jetzt eher rum um das bestehende nach und nach umzusetzen und dann evt. bei Interesse auch zu dokumentieren.

Ich werde beginnen meine “Fehler”/“Probleme” im entsprechenden Forum bei GitHub posten ( Own LDAP-Server: how configure docker-compose.yml · Issue #499 · zokradonh/kopano-docker · GitHub ) , da ich denke, dass sie da besser aufgehoben sind, als hier im UCS-Forum. Oder was würdest du vorschlagen @fbartels ?

1 Like

Hallo zusammen,

auch ich hatte vor ca. 2 Jahren nach längerer Suche mit UCS und Kopano endlich die (fast) perfekte Lösung für unser kleines Büro gefunden, insbesondere für die 3 Mitarbeiterinnen, die nicht von Outlook weg wollen/können.

Testphase verlief eigentlich ganz gut, bis auf Performanceprobleme mit Activesync und großen Postfächern bei uns mit > 50 GB.

In der Feintuningsphase und Suche nach Lösungen, unsere Postfächer zu entschlanken, kamen dann schon die ersten Gerüchte auf, dass Kopano Community nicht weiter entwickelt wird, was dann letzen Endes auch bestätigt wurde.

Bin dann vorsichtig geworden, ob wir überhaupt noch auf ein totes Pferd setzen sollten, aber mangels Alternativen (außer richtiges MS Exchange) kam die Idee, die bisherige UCS-Kopano Version weiter zu nutzen, aber als abgeschottetes System nur im LAN ohne Internetanbindung und von außen nur über VPN.

Nachdem jetzt aber auch Univention angekündigt hat, dass Kopano überhaupt nicht mehr mit UCS 5.2 laufen wird, was ich technisch nachvollziehen kann, würde ich das aus heutiger Sicht nicht mehr machen wollen.
Deshalb hatte mir Deinen @MyKey0815 Beitrag von vor 4 Monaten wieder etwas Hoffnung gegeben, doch noch eine halbwegs vernünftige Lösung zu finden.

Halbwegs deshalb, weil die Performanceprobleme mit unseren großen Postfächern und Anbindung von Outlook nur über Activesync (Z-Push) ja trotzdem ungelöst bleiben würden.

Die von Dir @MyKey0815 angestrebte Dockerlösung auf Grundlage von @fbartels verlinkten GitHub-zokradon/kopano-docker wäre ja weiterhin nur mit Z-Push ?

Oder gibt es da mittlerweile doch noch Fortschritte gegenüber der alten UCS-Version (Frage an @fbartels) ?

Falls ja, dann wäre ich natürlich auch sehr an einer (funktionierenden) Dockerlösung interessiert, könnte für euch auch gerne alles mögliche Testen, aber leider fehlen mir die entsprechenden Programmierkentnisse um tatkräftig mitzuhelfen, und in Docker muss ich mich sowieso erst grundsätzlich einarbeiten.

Falls @fbartels mir signalisieren sollte, dass die alte Z-Push Technologie für den heutigen produktiven Einsatz sowieso eine Sackgasse ist, dann wäre tatsächlich das neue Kopano-Cloud bzw. in unserem Fall on Premise Kopanion eine Überlegung wert, aber nur weil wir als kleines Büro perfekt in das Beuteschema von ca. 10 Mitarbeitern passen und die Kosten überschaubar sind, privat wäre ich weiterhin für eine freie Lösung.

Also wollte nur mein Interesse bekunden, und euch sagen, dass ihr nicht allein mit euren Wünschen seid, und auch gerne helfen würde, aber leider nur beschränkte Möglichkeiten habe.

Viele Grüße, Mario

Der alte Stack und auch das von mir verlinkte Docker Projekt sind definitiv obsolet (bzw. werden es ab dem Erreichen des EOL Datums sein). Das neue Kopano.cloud hat eine komplett überarbeitete Architektur und native Unterstützung für Outlook (Online Mode und Cached Mode) grosse Postfächer sind damit kein Problem mehr.

Danke für deine Rückmeldung und dein Interesse @trentatre

Ich sehe das wie du: Kopano.cloud in einem Unternehmen einzusetzen wäre mit den Kosten auch legitim und für mich die bevorzugte Lösung. So hatte ich als Berater einer Firma sogar Kopano mit Lizenzen empfohlen und installiert. Aber mir geht´s eher um das “private Nutzen”.

Ich selbst setzte nur die Weboberfläche ein. Meine Frau benutzt Outlook 2016 mit dem Kopano-Konnector. Und mein Handy ist per Z-Push angebunden, damit ich im Urlaub oder wenn es mal nötig ist, auf das Postfach zuzugreifen kann.

Also der Stand meiner “Nachforschungen” ist: ich habe 2 “Demo”-Stacks für Kopano die ich “out of the box” mit den Demodaten auch zum Laufen bekomme. D.h. das “System” als solches steht und wäre machbar. Das von @fbartels scheint etwas “älter” zu sein als das von “mlan” (Link siehe oben). Welcher der beiden Stacks jetzt “das Rennen macht”, weiß ich noch nicht.

Bei dem “mlan”-Stack war ich schon sehr “weit” (Anbindung an UCS, Datenimport ohne Attachments). Was noch fehlte ist das alles korrekt angezeigt wird (da war der Tipp ja mit PHP) und das der Mailversand/Empfang funktioniert.

Besondere Herausforderung ist halt das Thema “UCS Anbindung”. Weil hier statt einer Datei mit Einstellungen, sehr viele Dateien mit Aufgabenspezifischen Einstellungen berücksichtig werden müssen. Deshalb ist es eigentlich egal, ob ich Kopano Standalone installiere oder per Docker: die Anbindung an UCS bleibt.

Natürlich ist mir klar, dass ich hier auf ein “totes Pferd” setze - keine Updates - keine neuen Features uä. Aber ich nutze es in dieser Konstellation schon 10+ Jahre und bin 100% mit allem zufrieden. Und ich möchte meine Daten hier lokal im Netz behalten/lagern.

Fazit: ich werde weiter mir beiden Stacks versuchen eine passende Lösung für mich zu finden - hoffentlich bevor UCS 5.2 rauskommt

Danke euch beiden für euer schnelles Feedback.

Für unser Büro werde ich mich dann lieber in Richtung Kopano Cloud umsehen, falls ich keine andere Alternative finden sollte.

Privat werde ich deine Docker-Lösung gerne weiter verfolgen.

Das ist ein Zeichen dafür dass es irgendwo in deinem Stack ein Problem mit Locales/Sonderzeichen gibt. z.B. in der PHP Konfiguration.

@fbartels Ich denke es könnte auch dran liegen, dass der Export und der Import in die neue DB nicht sauber/korrekt ist.

Export auf der UCS-Seite:

mysql --version
mysql  Ver 15.1 Distrib 10.3.39-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
mysql -u root -p

USE kopano; SELECT @@character_set_database, @@collation_database;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
+--------------------------+----------------------+
| @@character_set_database | @@collation_database |
+--------------------------+----------------------+
| latin1                   | latin1_swedish_ci    |
+--------------------------+----------------------+

mysqldump -p --single-transaction  --skip-set-charset --default-character-set=latin1 --routines kopano -r kopano.sql

Import für die neue Instanz:

mariadb --version
mariadb from 11.5.2-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using  EditLine wrapper

mariadb -u root -p
drop database kopano;
CREATE DATABASE kopano;
GRANT LOCK TABLES on *.* TO 'kopano'@'%';
ALTER DATABASE kopano CHARACTER SET latin1 COLLATE latin1_swedish_ci;

mariadb -u root -p kopano < /var/lib/mysql/kopano.sql

Könnte es damit zusammenhängen? Wie würde man den Export/Import jetzt korrekter Weise ausführen?

warum die ganzen manuellen Schritte zum charset? Es sollte ein einfaches mysqldump -p --single-transaction --routines kopano -r kopano.sql reichen. Auch muss vor dem Import die Datenbank nicht angelegt werden, das kommt automatisch aus der sql Datei.

https://documentation.kopano.io/kopanocore_administrator_manual/backup_restore.html#sql-dump-through-mysqldump

Ich hab das heute nochmal mit dem Export probiert. Leider ist das ohne neuanlegen der DB anscheinend doch nicht möglich

root@fb6a62dd78b3:/# mariadb -u root -p  < /var/lib/mysql/kopano.sql
Enter password:
--------------
DROP TABLE IF EXISTS `abchanges`
--------------

ERROR 1046 (3D000) at line 22: No database selected

Den Export auf dem UCS hab ich wie folgt gemacht:

mysqldump -p --single-transaction --routines kopano -r kopano.sql

Das ist weil der Name der Datenbank in dem restore Kommando fehlt.

mariadb -u root -p kopano < /var/lib/mysql/kopano.sql vs mariadb -u root -p < /var/lib/mysql/kopano.sql

Das war auch mein erster Verdacht. Darum hatte ich es dann per

root@fb6a62dd78b3:/# mariadb -u root -p kopano < /var/lib/mysql/kopano.sql
Enter password:
ERROR 1049 (42000): Unknown database 'kopano'

probiert. Was aber dann auch nicht klappte. Darum hatte ich die Idee mit dem “zuvor anlegen” der DB - was aber alles wohl etwas kompliziert macht

Ok, sie wie es aussieht hatte ich das falsch in Erinnerung. Die Datenbank (CREATE DATABASE kopano;) muss in der Tat vorher manuell angelegt werden.

Ich habe hier kein UCS Kopano System mehr im direkten Zugriff aber wenn ich mir deine anderen Antworten ansehe, dann wundere ich mich über latin1 als char set. Aber auf einem nicht UCS System ist das scheinbar auch so.

Mastodon