Kopano4S (Zarafa 2.0)

[Andy+]

Sehr gut.... ... So in dieser Weise habe ich das auch gemacht.

 

[Matis]

Diese Fehler-Email bekomme ich nach wie vor seit dem Update:

/etc/cron.daily/logrotate:
invoke-rc.d: WARNING: No init system and policy-rc.d missing! Defaulting to block.
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

Damit kann ich gar nichts anfangen!

 

[Andy+]

Wenn K4S ansonsten läuft, kannst Du das erst mal ignorieren. Zum Thema logrotate finden sich jedoch einige Beiträge hier.

 

[Matis]

Mach ich, hatte ich nur vor dem Update nicht, also muß da was passiert sein.
Ich mach bei Gelegenheit mal ne Neuinstallation, um zu sehen, ob es damit weggeht.

 

[honk013]

Diese Fehler-Email bekomme ich nach wie vor seit dem Update:

/etc/cron.daily/logrotate:
invoke-rc.d: WARNING: No init system and policy-rc.d missing! Defaulting to block.
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

Damit kann ich gar nichts anfangen!

Hallo Matis,

ich habe schon seit langem auch genau diese Fehlermeldung. Definitv schon mit Version 1.10, aber ich glaube schon vorher.

Meistens sieht sie so aus:

/etc/cron.daily/logrotate:
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

Mal so:

/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

Und manchmal so:

/etc/cron.daily/logrotate:
invoke-rc.d: WARNING: No init system and policy-rc.d missing! Defaulting to block.
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

Ich habe keine Ahnung warum. Ändern tue ich nichts.
Ich habe mich mittlerweile daran gewöhnt diese Mail jeden Morgen um ca. 06:30 Uhr von "root" zu bekommen und verschiebe sie gleich in einen anderen Ordner.

VG

 

[dougi]

Hallo Zusammen, hallo Tosoboso,

habe nach dem Update auf 1.11 beim Start über das Paketzentrum folgende Felhermeldungen

error kopano share still empty post mount timeout 2 sec

Docker-Container wurde unerwartet beendet

Der Container lässt sich jedoch aus Docker heraus aufrufen und läuft dann auch. Versuche ich nun über das Paketzentrum zu starten, dann wird auch der laufende Container beendet.

Wo muss ich evtl eine Berechtigung nachziehen bzw einen Share anlegen/umbenennen?

Danke und Gruß
Dougi

 

[Tosoboso]

Wie wird eigentlich die Herausgabe einer Default festgelegt? Derzeit ist die Kopano Groupware Core meines Wissens die v8.7.9, orientiert sich das zB. daran? Wird ggf. die v9.x.x übersprungen, da es diese ohnehin nicht lange gegeben hat?

Hi, die Regel geplant für die Default ist ein Zeitversatz von 3-9 Monaten zur aktuellen Core und 1-2 Versionen älter.
Da sind wir aus dem Plan und ich bereite ein Update der Default auf 8.7.7 vom 6.12'19 vor. Die Logrotate Warnungen versuche ich mit zu beheben.
-TosoBoso

 

[Tosoboso]

Hallo Zusammen, hallo Tosoboso, habe nach dem Update auf 1.11 beim Start über das Paketzentrum folgende Felhermeldungen error kopano share still empty post mount timeout 2 sec
Der Container lässt sich jedoch aus Docker heraus aufrufen und läuft dann auch. Versuche ich nun über das Paketzentrum zu starten, dann wird auch der laufende Container beendet. Wo muss ich evtl eine Berechtigung nachziehen bzw einen Share anlegen/umbenennen?

Hi, Abhilfe durch Anpassung mit vi von MOUNT_TIMEOUT=30 in der package.cfg.
Die Konfig findest du in /var/packages/Kopano4s/etc/package.cfg. -Hintergrund:
Ich habe den Mount-Timeout eingeführt, für Fälle, wie bei mir, wenn man mit Verschlüsselten Shares Arbeitet, das Packet nach Reboot zu schnell startet und fehlschlägt. Der Timeout sollte aber im Default 20 und nicht 2s betragen, ich Prüfe, was beim Update gesetzt wird (die Konfig-Variable gabs ja vorher nicht).
-TosoBoso

 

[dougi]

Das war es leider nicht. Jetzt kommt der gleiche Fehler mit timeout 20. In Docker ist zumindest zu sehen, dass der Container nicht startet.

Weiterhin habe ich festgestellt, dass kopano-presence nicht startet. Folgende Ausgabe dazu auf der Console:

Traceback (most recent call last):
File "/usr/sbin/kopano-presence", line 4, in <module>
import kopano_presence
File "/usr/lib/python3/dist-packages/kopano_presence/__init__.py", line 20, in <module>
from flask import Flask, request, abort
ImportError: No module named 'flask'

Soll ich mal den Container neu bauen? Wenn ja mit welchem Befehl ohne Daten zu verlieren?

Viele Grüße
Dougi

 

[honk013]

Wenn bei mir nach einem Update Fehler auftreten, lasse ich den Container nochmal bauen. Geht ohne Datenverlust mit den "K-Cmds -> kopano4s-init -> refresh".
Hat bei mir schon ein paar Male geholfen.

 

[Andy+]

Wie man es bei K4S auch macht, nach Update oder Neuinstallation stets einen Reboot der DS durchführen. Erst dann auftretende Fehler sind erst mal die bleibenden.

 

[dougi]

Reboot und Container refresh haben leider beide nicht geholfen. Timeoutfehler bleibt bestehen

 

[Tosoboso]

Hi Dougi, mit welcher Edition arbeitest du? Default oder Community?
Welche Fehlermeldung steht im Docker-Container Log (via Docker Gui, Container Kopajo4s, Details, Protokoll) und was steht im server.log unter /var/log/kopano?
-TosoBoso

 

[dougi]

Default

Nahc dem Refresh startet der Container auch nicht mehr mit folgender Meldung:

Start container kopano4s failed: {"message":"OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused "rootfs_linux.go:59: mounting \\"/volume1/docker/kopano4s/localtime\\" to rootfs \\"/volume1/@docker/aufs/mnt/ae4595a654bf77213bf44b8d2be725f2ded2b1444e6c1f62e3c312fbddcea886\\" at \\"/volume1/@docker/aufs/mnt/ae4595a654bf77213bf44b8d2be725f2ded2b1444e6c1f62e3c312fbddcea886/usr/share/zoneinfo/Europe\\" caused \\"not a directory\\""": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type"}

So sehen die Mountpoints aus:


Dieser Eintrag ist unter /volume1/docker/kopano4s dazugekommen.:

 

[Tosoboso]

Hi, das Mounten von timezone wurde in k4s 1.0.9 abgeschafft und gegen die Menuaswahl per Zeitzone ersetzt, weil es sporatisch zu Problemen führt.
Das Mounten braucht man damit nicht mehr und ich werde es rausnehmen.. Bei mir und Anderen gibt es das Problem mit dem Mohunten gerade nicht, ich kann es also nicht nachstellen, nur abstellen..Nächstes Release k4s 1.12 kommt bald (eingecheckt)..
-TosoBoso

 

[honk013]

Habe gerade einen "refresh" gemacht und das kam dabei raus:



Respekt!!!

Mal schauen, wie die Version läuft.

 

[Tosoboso]

Hi zusammen,
wie von honk013 bereits gespoilert ist die neue k4s Version 1.12 auf dem Weg und man kann das aktualisierte Default Image Laden (Sprung von Core 8.7.1 auf 8.77 und Webapp 3.5.6 auf 3.5.12 aus der Kopano Libary).
In dem Image ist eine weiterere Logrotate Warnung ausgemerzt für z-push. Ich hoffe das war es jetzt mit Anpassungen Logrotate.
-TosoBoso

 

[dougi]

Habe den localtime mount raus genommen. Damit startet der Container wieder - aber starten aus dem Paketzentrum nach wie vor mit der Fehlermeldung empty share timeout

Scheinbar habe ich ein altes Dockerbuild-File? Habe noch mal ein refresh gemacht und dannach war der timezone-bind wieder im Container. Wie bekomme ich den nun das aktuellste Build-File in mein Setup?

 

[honk013]

Hi zusammen,
.......... In dem Image ist eine weiterere Logrotate Warnung ausgemerzt für z-push. Ich hoffe das war es jetzt mit Anpassungen Logrotate.
-TosoBoso

Hallo Tosoboso,

ich hoffe, dass Du mir das "Spoilern" nicht übel nimmst. Wollte meine Freude nur an die Community weitergeben.

Habe übrigens heute Morgen, seit vielen Wochen, keine Logrotate-Mail mehr von "root" bekommen. Das Problem scheint gefixed zu sein. SUPER ARBEIT. VIELEN DANK!!!!!!!!!!!!!!!

 

[Matis]

... update lief super. leider heute morgen wieder ein error-mail:

/etc/cron.daily/logrotate:
invoke-rc.d: WARNING: No init system and policy-rc.d missing! Defaulting to block.