Kopano4S (Zarafa 2.0)

[Tosoboso]

Das mit der Fehlermail von Logrotate ist mit dem neuen Image leider nicht besser geworden (just for Info).

/etc/cron.daily/logrotate:
error: rsyslog:14 duplicate log entry for /var/log/kopano/fetchmail.log
error: skipping "/var/log/kopano/nginx-access.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/kopano/nginx-error.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/kopano/nginx.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/kopano/z-push/z-push-error.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/kopano/z-push/z-push.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
run-parts: /etc/cron.daily/logrotate exited with return code

Danke für den Hinweis, habe ich behoben und ich Lade die Images neu hoch. =>kopano4s-init refresh sollte dieses Mal Abhilfe schaffen..
-TosoBoso

 

[Tosoboso]

ich habe eine Neuinstallation der V1.09b durchgeführt und dabei nur die Datenbank behalten. Fetchmail wird weiterhin als "not running" angegeben, läuft aber. Da ich das sowieso schon länger vorhatte, habe ich daraufhin ein Downgrade auf die V1.09 Stable durchgeführt und siehe da: der Fetchmail Status wird hier korrekt angegeben. Offensichtlich ist hier ein kleiner Bug bzw, Schönheitsfehler in der Community Version vorhanden. Also nach einem Update nicht wundern! Fetchmail läuft, auch wenn der Status etwas anderes ausgibt.

Hi, das Prblem mit der Abfrage von fetchmail status gibt es nur uner Debian 10 Buster.
Keine Ahnung warum, aber service fetchmail status etc. funktioniert nicht ggf mit Problemen in der Datei /etc/init.d/fetchmail. Eigentlich ein Problem / Bug mit Fetchmail, aber ich habe einen Workaround erstellt und Frage den fetchmail running status anders ab..
Damit wird nun auch fetchmail nicht mehr mehrfach nachgestartet. Das Image wurde gerade haochgeladen =>kopano4s-init refresh....
-TosoBoso

 

[Tosoboso]

UPDATE: ical läuft jetzt. Hatte in meiner Verzweiflung versucht die ical.cfg direkt zu bearbeiten. Wenn ich jetzt im Container "kopano-ical" gestartet habe, hat er diese Zeilen angemeckert. Also wieder den Kommentar rein gemacht, nochmal und und nun zeigt der Status und die Log das ical läuft. Aber ich kann immer noch keine ical abrufen. Der Browser meldet immer "Verbindung zurückgesetzt". Der Port 8080 ist aber offen.
Menne :-(Jemand eine Idee?
Neuer Versuch: Im Container in kann ich einen wget auf localhost machen. Scheint also so, als ob der caldav Server nur auf localhost lauscht.... wie kann ich das ändern?

Hi, versuch mal auf Port 8443 also mit SSL. Wenn Kopano im Modus Force-SSL läuft, werden die http ports 80 für,Web, 8080 für ICAL etc. nicht freigegeben...

 

[webcook]

Hallo Matis,
Hallo Andy+

@webcook:
* das ist nur ein button, mußt du anklicken um das andere Bild zu sehen.
* revers proxy mache ich manuell in der Systemsteuerung und klick das bei der Installation nie an, dann hab ich das besser unter Kontrolle, den Überblick und kann selbst entscheiden.

Ich möchte aber intern das Webapp unter https://KOPANO_IP/webapp erreichen, nicht über https://SUBDOMAIN.KOPANO_IP erreichen. => Neuinstallation?

Danke und Grüße
webcook

 

[Andy+]

Dafür ist keine Neuinstallation von K4S erforderlich und geht nur über die Systemsteuerung im DSM.

 

[Andy+]

Heute wäre sowas wie ein "auto kopano4s-init refresh" gut gewesen, mindestens 3 neue Sets mit Images waren online, das nenne ich mal eine flotte Leistung ....

 

[Andy+]

Auch das nun wenige Minuten alte Default Image wurde mit "kopano4s-init refresh" sauber geladen und läuft bei mir auf Anhieb nach Abschluss des Refreshs. Kein Neustart der DS oder andere Restarts sind erforderlich. Mailversand und -empfang geht einwandfrei.

 

[InTheCloud]

Auch bei mir läuft das Update jetzt ohne Probleme durch und Kopano läuft danach auch normal.
Großes Kompliment an Tosoboso und alle anderen die hier mitwirken.

Bei mir verbleiben folgende Probleme:
1. Auch nach dem letzten Update (gestern Abend) gibt es einen Fehler bei logrotate:

/etc/cron.daily/logrotate:
error: error setting owner of /var/log/kopano/z-push/z-push-error.log to uid 1023 and gid 1023: Operation not permitted
error: error setting owner of /var/log/kopano/z-push/z-push.log to uid 1023 and gid 1023: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

2. Nach jedem Update aber auch nach jedem Neustart der Diskstation werden keine neuen Emails mehr an meine Apple Geräte gepusht.
Die Datei "z-push-error.log" zeigt dann folgenden Eintrag:

03/01/2020 15:40:25 [11824] [WARN] [meinbenutzername] StatusException: ExportChangesICS->InitializeExporter(): Error, mapi_exportchanges_config() failed: 0xFFFFFFFF8004010F - code: 12 - file: /usr/share/z-push/backend/kopano/exporter.php:230

Ich muss dann folgendes machen um das Problem zu fixen:

k4s
kopano-search stop
rm -r /var/lib/kopano/search
kopano-search start

Hinweis: Ich habe ca. 19.000 Emails in meiner Inbox...
Hat vermutlich nichts mit der Paketierung für die Synology zu tun, oder? Soll ich das im z-push Forum melden?

Welcher Editor ist eigentlich im Paket mit dabei? Habe bei mir jedes Mal VIM nachinstalliert. Vielleicht könnte man den auch dauerhaft mit aufnehmen...

 

[InTheCloud]

2. Nach jedem Update aber auch nach jedem Neustart der Diskstation werden keine neuen Emails mehr an meine Apple Geräte gepusht.

Habe mal wieder nach dem Problem gesucht. Es wird hier intensiv diskutiert:

https://forum.kopano.io/topic/2269/z-push-2-4-5-sync-issue-0xffffffff8004010f/73

Bei einigen hilft die Erhöhung des Parameters "max_allowed_packet" in der Datei "/var/packages/MariaDB/etc/my.cnf" von 16MB auf 64MB.
Bei anderen hat dieser Fix geholfen: https://bugs.debian.org/cgi-bin/bug...51;filename=fix-zpush-sync-error.patch;msg=15
Der wurde aber leider noch nicht in die offiziellen Builds übernommen...

Werde jetzt mal max_allowed_packet=64M versuchen und mich dann wieder melden.

 

[honk013]

Moin,

habe gestern Abend das letzte Image der Stable 1.0.9 "refreshed" und das läuft auch bei mir ohne Probleme. Vielen Dank an Tosoboso!!!!!!!!!!!!!!!

Wieder nur als kleine Rückmeldung: Die Logrotate Fehlermail ist kleiner geworden. Sie besagt nur noch:

/etc/cron.daily/logrotate:
error: error setting owner of /var/log/kopano/z-push/z-push-error.log to uid 1023 and gid 1023: Operation not permitted
error: error setting owner of /var/log/kopano/z-push/z-push.log to uid 1023 and gid 1023: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

Sonst alles SUPER!!!

VG

 

[Tosoboso]

Z-Push Probleme mit Apple und grossen Mail-Boxen: MySQl Tuning

..Nach jedem Update aber auch nach jedem Neustart der Diskstation werden keine neuen Emails mehr an meine Apple Geräte gepusht... Habe mal wieder nach dem Problem gesucht.
Es wird hier intensiv diskutiert: https://forum.kopano.io/topic/2269/z-push-2-4-5-sync-issue-0xffffffff8004010f/73
Bei einigen hilft die Erhöhung des Parameters "max_allowed_packet" in der Datei "/var/packages/MariaDB/etc/my.cnf" von 16MB auf 64MB.
Bei anderen hat dieser Fix geholfen: https://bugs.debian.org/cgi-bin/bug...51;filename=fix-zpush-sync-error.patch;msg=15 - Der wurde aber leider noch nicht in die offiziellen Builds übernommen...
Werde jetzt mal max_allowed_packet=64M versuchen und mich dann wieder melden.

Moin, bitte die MySql Tuning Einstellungen über die GUI, oder das Tool machen, dann landet man auch nicht irrtümlich bei der falschen MariaDB Config (K4S nutzt MariaDB10 =>/var/packages/MariaDB10/etc/my.cnf). Siehe scrrenshot:

Bei der Gelegenheit möchte ich auf die neuen Möglichkeiten beim Tuning hinweisen (incl. InnoDB-Log-File) z.B. kann man mit kopano4s-tuning info die Details ausgeben (2GB Bsp.) und mit kopano4s-tuning 40 Dies setzen, was auch per GUI geht.

admin@Diskstation:~$ sudo kopano4s-tuning info
Mem Total:2045004KB/2GB Cached Buffers:294880KB Free:901616KB Usable:1196496KB
Max Tunig:40% MySQl InnoDB-Buffer-Pool:352MB InnoDB-Log-File:88MB aka 21%
Kopano Cache-Cell-Size:384MB C-Object-Size:4MB CIndexObjSize:8MB aka 19%

-TosoBoso

 

[honk013]

Moin,

was wären denn geeignete Werte für "MyMaxPacket", "DbBuffer" und "Tuning" und woran liegen die (Arbeitsspeicher, Prozessor, Taktrate)?

 

[Tosoboso]

Genau das schlägt ja das Tool mit Parameter info vor (siehe Oben am Besispiel einer Syno mit 2GB Speicher, Ich empfehle 40% Buffer Tuning, sobald man 2BG, oder mehr aht; also kopano4s-tuning 40 und dann MyMaxPacket auf 64M, wie oben im Screenshot.
Übrigens sollte man Kopano gestoppt haben und dann >kopano4s-tuning info von der Cmd-Line ausführen, sonst verfälscht das laufende Kopano die Auswertung.. PS: Prozessor & Taktrate sind nicht wichtig, nur Hubraum = Ram zählt; gut sind 6-10GB..
-TosoBoso

 

[honk013]

Okay, danke. Habe ich gerade ausgeführt und folgende Werte erhalten:

Mem Total:10042004KB/10GB Cached Buffers:8057940KB Free:1043080KB Usable:9101020KB
Max Tunig:60% MySQl InnoDB-Buffer-Pool:1024MB InnoDB-Log-File:256MB aka 12%
Kopano Cache-Cell-Size:2304MB C-Object-Size:8MB CIndexObjSize:16MB aka 23%

Die Werte Max. Tuning und DB-Buffer kann ich auslesen, aber was ist mit dem MyMaxPacket Wert? Ist 64M der max.Wert?

 

[InTheCloud]

@Tosoboso: Vielen Dank für den Tip mit den Parametern in der GUI. War mir gar nicht aufgefallen, dass es da "My Max Paket" gibt...

Ich hatte das Tuning bereits auf 40%. Könnte man damit nicht auch gleich den "My Max Paket" auf 64M setzen?

Auf der Console bekomme ich folgende Werte (Kopano Paket angehalten):

ash-4.3# kopano4s-tuning info
Mem Total:8164620KB/8GB Cached Buffers:4055692KB Free:676572KB Usable:4732264KB
Max Tunig:40% MySQl InnoDB-Buffer-Pool:1024MB InnoDB-Log-File:256MB aka 15%
Kopano Cache-Cell-Size:1536MB C-Object-Size:4MB CIndexObjSize:8MB aka 18%

Interessant ist, dass der "InnoDB-Buffer-Pool" mit 1024MB angegeben wird, der Parameter "DbBuffer" in der Kopano GUI steht aber auf 1536M...

 

[Andy+]

Die v1.1.0 ist online. Um diese installieren zu können, zumindest ist das auf dem manuellen Weg so, muss ein Eingriff erfolgen. In der Datei

/var/packages/Kopano4s/INFO

muss die Version von 1.09 in 1.0.9 geändert werden, sonst geht die Installation nicht.

 

[honk013]

Danke Andy für die Info.
Jetzt wird das Update auch in dem Paketzentrum angezeigt!

 

[Matis]

Super, läuft einwandfrei. Danke für die Info, Andy.
1.09 > 1.1.0 deshalb geht es ohne Änderung nicht.
Super Job Tosoboso, das wird immer perfekter!

Ich hab mal ne andere Frage:
Ich habe nun 1.1.0 D-core 8.7.1.0 und seither die Anhänge in der db.
Was muß ich denn tun, wenn ich umstellen will auf speichern im Verzeichnis?
Und wie sieht das dann aus mich backup und restore? Wie ist die Verknüpfung zu den Anhängen und werden die mitgesichert und wieder hergestellt?
Danke.

 

[Andy+]

Wenn die Anhänge in der DB sind, hat das den Vorteil, dass alles im DB-Package ist. Das ist mit ein Grund, weshalb ich nicht umgestellt habe, zudem das Übertragen auf eine andere DS einfacher ist. Glücklicherweise hat Tosoboso mit dem kopano4s-backup ein Tool geschaffen, dass im Falle der Anhangablage im Filesystem es genau zwei Backupdateien gibt, für die DB und zum Package gehörend die Anhänge. Dieses Double ist immer zueinander gehörend, von Sicherung zu Sicherung. Das macht auch ein Übertragen auf eine andere DS relativ einfach.

Daher besser nicht das kopano-backup (ohne ....4s) verwenden, da dann im Backupverzeichnis jede einzelne Email abgelegt wird und sich entsprechend Einträge vorfinden. Die Anhänge sind extra zu sichern. Das wirkt irgendwie unsicher und hat mich immer davon abhalten, die Anhänge in das Filesystem zu speichern, sondern in der Datenbank zu belassen mit eindeutiger Zuordnung zum Email.

Um den Wechsel durchzuführen, ist es unumgänglich, alles zu exportieren, dann für die Anhänge von Datenbank auf Filesystem umzustellen und alles wieder zu importieren. Nur den Parameter ändern in der server.cfg bewirkt keine Umstellung "von alleine".

 

[Caramlo]

Zum Umstellen der Anhänge ins Filesystem gibt es auch ein Script! => Danke, Tosoboso!!

Usage: kopano4s-attachment-tofs plus start | help.
Migrating Kopano off attahment(s) from database to file system by in 4 steps
Step 1: database backup as a fallback. Use kopano4a-backup restore timestamp to recover if this job fails.
Step 2: mapi brick-level method kopano-backup for importing users into new structure later.
Step 3: truncate kopano database, restart with attachment(s) on fs which will recreate database ready for import
Step 4: import of users via kopnao4s-restore-user all setting old password.
This is an all-in one scripted solution taking away the pain of using the attachment migration script adn procedures.
It reccomended to run this sript via Synology task scheduler to avoid time-out before completion when running via terminal
It is required to have an initial brick level kopano-backup run to allow shorter total runtime of this script.
Command requests completed in 0 seconds.

Ich selbst habe das noch nicht ausprobiert, würde aber auf jeden Fall vorher noch ein Backup der Datenbank machen und an einem neutralen Ort speichern.