Kopano4S (Zarafa 2.0)

[speedyhome]

@Andy

Ich habe 2 Datenbanken 1 mit attachments in der DB und eine aktuellere DB wo File-System sind
Desweiteren hab ich ein Kopano auf CentOS 7 laufen in einer Virtual Machine au einer DS was mir von
der Leistung her nicht so gefällt diese DB habe ich mal kopiert und als kopano4s DB genommen
mit dieser DB ist in der webapp auch alles in Deutsch

neue User sind dennoch Englisch !

die DB mit den Files included, da gibts ja ein script das dir die DB säubert und als files ablegt

db-convert-attachments-to-files


bei der installation um auf file attachment zu kommen darf das packet nach dem installieren
nicht gestartet werden und per ssh die server.config umgestellt werden, erst dann den
Docker Container starten.

 

[Tosoboso]

ich bin von Zarafa4h auf Kopano4s umgestiegen, indem ich die bestehende Zarafa-Datenbank, die in MariaDB 5 lief, unverändert in MariaDB 10 dupliziert habe und dann die Migrationsvariante von Kopano4s installiert habe, die auf diese Datenbank zugreift. Das läuft in dieser Version bisher absolut problemlos, allerdings frage ich mich nun, ob ich das Update für Kopano4s sorglos installieren kann und mein Kopano danach noch läuft - oder ob da noch vorbereitende Schritte nötig sind?

HI, es gibt einen Thread dazu: https://www.synology-forum.de/showthread.html?93474-Migration-Zarafa-zu-Kopano mit Hinweisen etc., aber es ist aktuell nicht so einfach...
Zuerst ist die Migrations-Version wie der Name schon sagt zum Migriren da und nicht für den Betrieb mit Updates etc.Man muss sie Deinstallieren und dann eine Community oder Supported Version installieren, aber Vorsicht:
Während der Import der Zarafa Datenbank tadellos funktioniert kommt das Problem: der direkte Upgrade von der Kopano 8,4,4 auf 8.5.x bzw. 8.6.x funktioniert nicht, das ist ein zu grosser Sprung; -Kopano "Feature": Kopano.Service stopp und die Fehlermeldung ist im server.log zu finden und auch im Docker Log.
Was man machen kann, ist statt per Datenbank Transfer kopano-backup nutzen (http://manpages.ubuntu.com/manpages/artful/man8/kopano-backup.8.html), alle User exportieren, dann neu installieren, und per restore wieder einspeilen, das geht..
-TosoBoso

 

[Tosoboso]

nur bekomm ich es nicht hin das kopano4s auf deutsch umzustellen weder über console noch über sql , alle how-to's durchgeführt steht überall de_DE.UTF-8 drin vllt könnt ihr mir einen Tip geben wie es doch funktioniert. Achso Umaulte im Namen also Angezeigter Namen geht auch nicht

Hi, erstmal zur Bestätigung: in der /etc/kopano/default sind gesetzt <KOPANO_LOCALE="de_DE.UTF-8"> und <KOPANO_USERSCRIPT_LOCALE="de_DE.UTF-8"> ? Wenn ja (bei Neuistallation k4s 0.8.4 so ) dann sollten die neuen Postfächer in Detusch angelegt werden. Es kann aber sein, das noch im Container / Nginx Webserver die CodePage eingestellt werden muss und deswegen Umlaute in WebApp falsch angezeigt werden. Ich werde mal Nachforschen und Testen
-TosoBoso

 

[speedyhome]

@Tosoboso

Sprache Deutsch geht jetzt ! *Kopf-Schüttel* wenn man nicht genau hinkuckt ! einfach im Docker Container die ENV LANG=de_DE.UTF-8 mitgeben dann wird der User auch richtig
im docker mit umlauten übergeben ! im Nginx wirds richtig angezeigt ! War ein Übergabe-Problem beim User anlegen wegen der Spracheinstellung LANG=POSIX im Container.
Folder werden immer noch Englisch angelegt *grummel*.

Mit dem script kopano-localize-folders -u test --lang de_DE.UTF-8 kommt eine Fehlermeldung Error: kopano is not translated in de_DE.UTF-8

Irgendwas stimmt nicht mit Phyton und gettext ^^

Edit:

Hab mal in meinem CentOS 7 Kopano Installation nachgeschaut

Im Docker fehlt /usr/share/locale/de habe mal von meiner CentOS kopiert und siehe da

test
test: Changing localized folder names to "de_DE.UTF-8"

Edit 2:

kopano legt jetzt die Ordner in Deutsch an wenn man einen User anlegt
Es hat die Übersetzungs-Datei gefehlt im /usr/share/locale/de/LC_MESSAGES/kopano.mo

Machst du das mal ins Docker Image ?

 

[Tosoboso]

Hi, danke für die Hinweise zu locales Settings und ja ich werde es in den Container einbauen im nächsten Release.
Deine Angaben bzgl. LANG Environment decken sich mit meinen Recherchen. Hast du das in der /etc/profiles gelöst.
-TosoBoso

 

[speedyhome]

Hi, nein braucht man nicht im container machen, hab jetzt mal das Container - File gelöscht und neu installiert, um die Schritte nach zu volziehen ohne
den unnötigen Müll den ich im Container angestellt hab zu entschlacken.

@tosoboso ich schreib mal ausführlich für die anderen User du weisst ja was ich meine

Also für die Übergabe von Usernamen mit Umlauten ("angezeigter Name") und File-Attrachments

- Neuinstall -> Paket nicht ausführen lassen ! Da mit dem ersten Start die DB angelegt wird !
(gilt für Language und Attachments ist nur eine Vorsichtsmassnahme weil ich nicht weiss was kopano-server da schon reintackert )

- in der DSM-Oberfläche in dem Container die Umgebungs - Variablen LANG und LANGUAGE anlegen mit dem Wert "de_DE.UTF-8"
- in der server.cfg im Pfad /var/packages/Kopano4s/etc/kopano die Parameter attachment_storage = files setzen "#" nicht vergessen zu löschen vor dem Wert
attachment_path = /var/lib/kopano/attachments Pfad so lassen nur "#" weg und Speichern.
- Docker-Container starten

- Jetzt habt ihr schon mal ein laufendes Kopano mit leerer DB auf Files-Attachment und der erste Schritt zu Deutsch - Einstellung

Es gibt jetzt 2 wege die Locales in das Docker - Image zu bekommen ( entweder ihr mountet im Docker ein Verzeichnis auf der NAS
oder ihr nehmt die schon vorhandene freigabe attachments im /volume1/kopano/attachments die ist ja identisch mit dem Pfad im Container
der in der server.cfg steht

- in den Container per ssh gehen ob ihr das über die DSM Oberfläche macht oder per Putty mit "docker exec -it kopano4s bash ist Wurscht
die locales "de" in /usr/share/locale kopieren (kann ich euch zu verfügung stellen wenn gewünscht

Fertig !

Für die die eine DB mit attachments haben die müssten mit dem kopano-script die DB umwandeln
Anleitungen gibt es wie Sand am Meer Zarafa-Anleitung geht auch hat sich nur der Name geändert

@tosoboso das script hab ich im container auch nicht gefunden


@tosoboso
Würdest du noch für das WebApp - Plugin gmaps im Installer ein Feld einfügen für den Google-API-Key
dann muss man das nicht in der config tun, bzw. das config / die config's im Admin aufnehmen zum ändern ?

 

[Tosoboso]

Hi, LANG im Image bzw. Container zu setzen ist bereits in Planung. Die restliche Funktionalität war bereits implementiert, Stichwort dbk-reconfigure locales. Ich kann aber nur dringend abraten, die Loacales aus Synology in Docker Debian zu Kopieren oder zu mounten, die sind alle bereits da. Das ist gefährlich und nicht nötig. Das macht man unter Debian nativ. Die restlichen Ausführungen sind alle ok.
-TosoBoso

 

[speedyhome]

nein ich habe nicht die locales aus syno genommen ^^ sondern von meiner VM wo kopano drauf läuft
das mounten galt auch nicht für die syno locales, das galt nur für die kopano.mo im locales/de/ zum rein kopieren

hab ja dazu geschrieben das man die über den mount attachments holen kann oder man mountet ein verzeichnis auf der syno direkt
ich glaub da hast du was falsches raus gelesen

mmmh dpkg-reconfigure locales hatte ich im container versucht bzw. gemacht hilft nur nicht weil im verzeichnis /usr/share/locales nix drin ist wo kopano seine
übersetzung sucht

 

[Tosoboso]

Danke speedyhome für die Hinweise, jetzt hab ich es verstanden .
Also ich habe nun die LANG und LANGUAGE Variablen im Image bzw. Container gesetzt, aber Kppano legt ums verrecken nicht die /usr/share/locale/de/LC_MESSAGES/kopano.mo an.. Ich baue auch parallel in Debian-Strech Kopano, was einfacher zu Debuggen ist, als im Dockerfile, aber auch da geht es nicht. Man muss dazu sagen, dass ich mit Debian arbeite (also nicht apt-get install language-pack-nl wie bei Ubuntu, sondern Anpassen /etc/locale.gen, dann ln -s /etc/locale.alias /usr/share/locale/locale.alias dann dpkg-reconfigure locales). Ich hätte auch kein Problem die Übersetzungsdateien in das Docker Image zu kopieren, denn es ist ja nur ein generisches Build und nicht ür jede Sprache, aber wie gesagt ich kann dme Installer das kopano.mo nicht entlocken und bin offen für Ideen.
EDIT: Ich glaube es gefunden zu haben: Debian9-Slim, das ich verwende blendet als Slim alle locales LC_MESSAGES aus.. Ich habe jetzt einen normalen Debian Container gebaut, kein --no-install-recommends bei apt-get install und schon tut sich was, die kopano.mo ist da....Andererseits möchste ich den Debian-Slim Container beibehalten, weil das extrem an Platz spart. Da gibt es nur eins: Ein temporärer Container als Debian alles bauen und die *.mos gezip in den näcshten Container kopieren.. Den Docker Hack wende ich bereits an und werde diesen erweitern..
-TosBoso

 

[speedyhome]

mmmh in der core der comunity version ist doch diese pack drin

kopano-lang_8.6.80.1169-0+164.1_all.deb

kann man die nicht verwenden ??

dpkg -X kopano-lang_8.6.80.1169-0+164.1_all.deb /

sollte gehen

 

[Tosoboso]

Mit dem script kopano-localize-folders -u test --lang de_DE.UTF-8 kommt eine Fehlermeldung Error: kopano is not translated in de_DE.UTF-8. Hab mal in meinem CentOS 7 Kopano Installation nachgeschaut Im Docker fehlt /usr/share/locale/de habe mal von meiner CentOS kopiert und siehe da: test test: Changing localized folder names to "de_DE.UTF-8"
kopano legt jetzt die Ordner in Deutsch an wenn man einen User anlegt Es hat die Übersetzungs-Datei gefehlt im /usr/share/locale/de/LC_MESSAGES/kopano.mo Machst du das mal ins Docker Image ?

Hi, ich habe das Docker Image angepasst (noch nicht released) und die kopano.mo sind im Container vorhanden. Nun bekomme ich diesen Fehler, zumidestens bei Supported KP 8.6.2 https://forum.kopano.io/topic/777/kopano-localize-folders/2
Der Bug Report Eintrag ist ~2m alt, gut möglich, dass es in den nighliy build gelöst ist und noch nicht in der Supported Version, aber auch gut möglich dass noch etwas fehlt.
Daher: mit welcher Kopano Version hast du getestet (8.6.80.x?) und von welcher Version hast du die Übersetzugsdateien kopano.mo und ggf. Andere rüber kopiert?
HIntergrund warum die Übersetzungsdateien (kopano.mo) nicht im Docker Build waren: Die Dateien sind in kopano-lang-* und das ist Teil der Installation, aber aus Docker Tuning Gründen habe ich auf Debian-Slim aufgesetzt und mit apt-get install --no-install-recommend gearbeitet. Das führt dazu, dass Kopano die Übersetzungsdateien nicht anlegt. Lösung: Install in Iterim Container mit Debian-full und ohne no-recommends und dann Rüberkopieren der Übersetzungdateien (kopano.mo) in den finalen Container (klingt etwas kompiziert ist einfach Tuning und spart mit anderen Anhängigkeit ~50% Image Size).
Ich werde nun Testen, ob das Übersetzen in andere Sprachen funktioniert und ob mit de die neuste Community funktioniert. -Stay tuned..
Edit: nl_NL.UTF-8 funktioniert, also ist es ein de lokales Problem und der o.g. Bug schlägt zu, zumindest bei der Supported Version KP 8.6.2
.TosoBoso

 

[speedyhome]

Hi,
ich hatte es mit der Version 8.4.90.313 probiert mit den locales wo zwar funktioniert haben,
danach mit der aktuellen, bei beiden läuft das script ohne fehler durch, aber bei der neuen Version
ist auch der öffenliche ordner übersetzt aktuell wo es funktioniert ist die Version von meinem
letzten Post.

kopano-lang_8.6.80.1169-0+164.1_all.deb

 

[Andy+]

Ist das nur für Versuche, oder wie müssen wir das interpretieren

 

[Andy+]

Geil, scheint da kommt endlich Files .....

 

[lea1999]

Ich verwende seit einiger Zeit Z4h und will nun angesichts des EOL auf K4s wechseln. Dazu habe ich auf einem zweiten NAS aus dem Paketzentrum die aktuelle Beta 0.8.4 heruntergeladen und installiert (nicht die Migrations-Version), inkl MariaDB10 (10.0.34) und Docker (17.05.0).
Ich schaffe es nicht, K4s zum Laufen zu bekommen. Nach der Installation und Ausführung von K4s erhalte ich:
sudo kopano-status
Core: Kopano Server Not Running, Dagent Not Running, Spooler Not Running, Search Not Running, Monitor Disabled, Gateway Not Running, ICAL Not Running, Syslog Not Running
Mail: Postfix Not Running, Postgrey Not Running, Amavis Not Running, Clamav Not Running, Fetchmail Disabled, Courier-Imap Disabled
Web: NGINX Not Running, PHP5-FPM Not Running, Presence Disabled, Webmeetings Disabled, CoTurn Disabled
Ein kopano-restart liefert:
Stopping Kopano core...
kopano-server: unrecognized service
kopano-spooler: unrecognized service
kopano-dagent: unrecognized service
kopano-search: unrecognized service
kopano-gateway: unrecognized service
kopano-ical: unrecognized service
Stopping Kopano mail...
Stopping Kopano web...
Starting Kopano core ...
kopano-server: unrecognized service
kopano-spooler: unrecognized service
kopano-dagent: unrecognized service
kopano-search: unrecognized service
Starting enhanced syslogd: rsyslogd.
kopano-gateway: unrecognized service
kopano-ical: unrecognized service
Starting Kopano mail ...
Starting Postfix Mail Transport Agent: postfix.
Starting postfix greylisting daemon: postgrey.
Starting ClamAV daemon: clamd .
Starting amavisd: amavisd-new.
Starting Kopano web ...
Starting nginx: nginx.
Core: Kopano Server Not Running, Dagent Not Running, Spooler Not Running, Search Not Running, Monitor Disabled, Gateway Not Running, ICAL Not Running, Syslog Running
Mail: Postfix Running, Postgrey Not Running, Amavis Running, Clamav Running, Fetchmail Disabled, Courier-Imap Disabled
Web: NGINX Running, PHP5-FPM Running, Presence Disabled, Webmeetings Disabled, CoTurn Disabled
und anschliessend hält der Docker-Container an.
Das Protokoll von Docker enthält folgende Ausgaben:
date stream content
2018-07-08 07:18:23 stdout exiting as server stopped; if non-grace shutdown see last entry from /var/log/kopano4h/server.log and consider kopano-init container or re-install
2018-07-08 07:18:23 stdout staying alive while kopano service is running..
2018-07-08 07:18:23 stdout giving up; restart package or run kopano-init container to address mount issues
2018-07-08 07:16:43 stdout Active services: kopano-server kopano-spooler kopano-dagent kopano-search rsyslog kopano-gateway kopano-ical postfix postgrey clamav-daemon amavis nginx php7.0-fpm
2018-07-08 07:16:43 stdout health check error: no msql socket via mount point; mariadb not yet running?
2018-07-08 07:15:59 stdout initializing av database..
2018-07-08 07:15:35 stdout setting acl, ssl, encryption shared secrets
2018-07-08 07:15:34 stderr Generation complete.
2018-07-08 07:15:34 stderr en_US.UTF-8... done
2018-07-08 07:15:31 stderr de_DE.UTF-8... done
2018-07-08 07:15:29 stderr Generating locales (this might take a while)...
2018-07-08 07:15:21 stdout increasing php upload_max_filesize to 15M..
2018-07-08 07:15:21 stdout increasing file-limits for user kopano running sockets..
2018-07-08 07:15:20 stderr usermod: no changes
2018-07-08 07:15:20 stdout modifying kopano user and group ids (1038 / 65540) plus file limits ..
2018-07-08 07:15:19 stdout initializing virtual aliases and pwd e.g. for proxy..
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/search.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/search.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/monitor.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/monitor.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/ical.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/ical.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/gateway.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/gateway.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/backup.cfg: No such file or directory
2018-07-08 07:15:19 stderr sed: can't read /etc/kopano/backup.cfg: No such file or directory
2018-07-08 07:15:19 stderr cp: cannot stat '/etc/kopano/dagent.cfg': No such file or directory
2018-07-08 07:15:19 stderr cp: cannot stat '/etc/kopano/server.cfg': No such file or directory
2018-07-08 07:15:19 stderr kopano-ical: unrecognized service
2018-07-08 07:15:19 stderr kopano-gateway: unrecognized service
2018-07-08 07:15:19 stderr kopano-monitor: unrecognized service
2018-07-08 07:15:19 stdout image intializing UID, GID, etc-cfg, log, ssl, post-build

Es reklamiert offenbar fehlenden sql socket, doch die MariaDB läuft.

Hat jemand eine Idee, woran das liegen könnte?

 

[Andy+]

Hast Du in MariaDB ein Root-Passwort hinterlegt? Denn danach wird zu Beginn der Installation von K4s gefragt. Du kannst das auch prüfen, indem Du mit phpMyAdmin prüfst, ob die Datenbank und der Benutzer kopano angelegt ist und die Datenbank ihre 25 Tabellen hat.

 

[lea1999]

Ja, ich habe das MariaDB Root-Passwort gesetzt und bei der Installation angegeben. Die Datenbank kopano ist erstellt, aber enthält keine Tabellen. Der User kopano ist angelegt und hat alle Rechte. Ich habe MariaDB auch entfernt und neu installiert ebenso K4s. Der Fehler bleibt.

 

[Andy+]

Ich denke, dann passt irgendwas mit den Rechten nicht.

 

[Tosoboso]

Probleme mit Community Build k4s 0.8.4 / 0.8.5

Hi, es gibt aktuell Probleme mit dem Community Build, wenn man selbst baut. Dies gilt für die k4s 0.8.4 und auch für die 0.8.5, die ich am Fr. 6. hochgeladen habe und bald verfügbar sein wird. Deswegen habe ich auch im Docker Hub die Community base und full (inkl. files) wieder entfernt; diese waren noch online als Andy am Fr. den Screenshot oben gemacht hat.
Was funktioniert, ist die Supported in base und full, sowohl per download vom Docker Hub, als auch beim Paket selbst-bauen. Aber für die Supported braucht men eben die Subscription bei Kopano (1 Jahr, 5 User base: ~80€). Die Migration v. 8.4.5 funktioniert auch, aber Diese hat einen Zeitschalter: nach 3 Stunden stoppt der Container, da Migrieren nicht Dauerbetrieb ist.
Ebenfalls funktionieren sollte die k4s 0.8.4, solange man den 'build package instead of loading from tosoboso docker hub' deaktiviert lässt, dann wird das Image von vor ca. 2 Monaten geladen, was ja funktioniert hatte; konkret: Community-8.6.80_Web-3.4.14_Push-2.4.1.
Nochmal es handelt sich bei dem Fehler höchst warscheinlich um Probleme in den Kopano Nightly Build Debian Images, denn die k4s Docker Build Skripte sind identisch und funktionieren tadellos bei Supported Debian Images. Im Detail zum Fehler: bei den Nightly Builds werden die Pakete gefunden, aber es weder weder die Konfigdateien geschrieben, noch der Linux Service registriert, daher auch die Fehler Meldungen bei sed cannot find und unknown Service bei Starten im Init Skript.
Ich gehe davon aus, dass die Probleme in den Kopano Community nightly builds sehr bald (1-2) Tage behoben sind. Dann kann man wieder das neuste Community Image bauen und auch die k4s 0.8.5 verwenden (Community-8.6.80_Web-3.4.17+_Push-2.4.3+). Bis dahin: k4s 0.8.4 und kein 'build own image'
EDIT Ich vermute die 2 Monate alte k4s Community Version auf dem Docker Hub Tosoboso passt nur zur k4s 0.8.3. Die k4s 0.8.4 und 0.8.5 finden kein passendes Image auf dem Docker Hub und machen dann ein Own Build als Fallback, selbst wenn der Haken build own beim Installieren nicht gesetzt ist; gleiches gilt bei Upgrade. Das kann ich aktuell nicht Ändern und damit müsst ihr warten, bis die Probleme der nightly builds behoben sind, oder bis ich ein neues Release mit pre-packaged Images online stelle. Letzteres dauert ein paar Wochen, denn es ist Ferienzeit..
-TosoBoso

 

[Tosoboso]

Hi zusammen, k4s v.0.8.5 ist nun verfügbar auf dem Community Package Hub (https://www.cphub.net/?id=40&pid=743)
Ich weiss jedoch nicht, ob das Problem beim Bauen des Image von den Kopano Community DPKG Images noch besteht (siehe Oben) und kann es auch gerade nicht Testen.
Also Vorsicht beim Laden der k4s 0.8.5 Community; wer eine 2. Syno zum Testen hat (Andy?) sollte es dort erstmal versuchen. Ob es geht, oder nicht merkt man schnell: wenn noch nicht, dann stoppt das k4s Paket und man hat im Docker Protokoll die Fehlermeldungen no such files und no such service.. Bitte um Rückmeldung der Mutigen, ob es geht.
Am Paket kann und werde ich nichts ändern. Das Problem ist auch neu, hatte ich so noch nie, dass die Kopano Beta aus den Nightly Build Images gar nicht geht. Das nächste k4s Paket in Planung (dauert noch ein paar Wochen) wird den neusten gebauten k4s Container (Community bzw. Supported) Laden, so dass ich 'antizyklisch' arbeiten kann, wenn das k4s SPK bereits auf dem Community Hub ist, kann ich dann weitere neue Docker Images nach schieben. Aktuell ist im k4s SPK noch das Docker Image Release per Konfig verdrahtet und wenn das nicht gefunden wird, dann wird das Paket lokal gebaut, was im Syno-Info Center so angezeigt wird und ca 12m dauert. In Zukunft statt dessen wie gesagt: das neuste Image im Docker Hub als Fallback. Ebenso wird man dann von der k4s GUI aus ein Update / Refresh machen können. Damit muss ich nicht jedesmal für einen Kopano Image Refresh ein neues SPK Paket hochladen, sondern kann einfach alle 2 Wochen die Docker Images erneuern und kurz Prüfen, ob das Nightly Build dieses Tages funktioniert. So weit die Planung. Stay tuned.
-TosoBoso