Kopano4S (Zarafa 2.0)

[Tosoboso]

Anpassung LogRotate - High Load

Ich habe ein Problem mit logrotate gefunden, in /etc/logrotade.d steht die Datei mail. Hier sind die Logs mit "mail.*" angegeben. Dies ermöglicht logrotate eine rekursive Schleife im die Unendlichkeit und er packt und packt.
Ändern von mail.* nach mail.log und ergänzen für mail.err , mail.info.
Danach entweder das ..\log komplett removen oder Stück für Stück die 1000ende Dateien löschen. Probleme mit Hoher Last durch Logrotate:
Auf der Syn:
/var/log/kopano:
for i in *.gz ; do rm $i ; done
In der Docker Console:
cd /etc/logrotade.d
Datei mail
Hier ist ein * drin, der verursacht recursive rotates …..
Ersetzen mit mail.log, warn, info und err
Vi mail.warn

Super Recherche und danke für den Hinweis. Das Problem werde ich mim nächsten Release k4s v. 0.8.0 fixen, bzw. bereits im Container vorab fixen, damit nach einem Image Reload der Spkut vorbei ist (> kopano4s-init refresh).
Für die gz Logs werde ich auch ein Removal vorsehen (> kopano4s-init gzlogs)
-TosoBoso

 

[Tosoboso]

Hallo zusammen,
die Container sind Altualisiert bzgl. dem Bug-Fix mit logrotate loop.
Ausführen von > kopano4s-init refresh löst das Problem.
-TosoBoso

 

[Andy+]

Es gibt wieder ein neues Image D-Core-8.7.1.0_Webapp-3.5.6_Z-Push-2.5.1_WMeet-0.29.5 und jedesmal, wenn ein solches Update (kopano4s-init refresh) ansteht, geht der Mailversand nicht. Ein Restart von Postfix oder des Kopanoservers hilft nicht und ein Restart des gesamten Paketes auch nicht. Zuletzt bleibt nur ein Reboot des ganzen Servers.

Kann das umgangen werden?

Update

Nach einer gewissen Zeit geht es dann => etwas Geduld, wenn man es weiss....

 

[Andy+]

Danke, jetzt ist gut ....

 

[FricklerAtHome]

Das nach einem Release-Update einige Zeit bis zur Funktionalität verstreicht ist und wird FAKT bleiben.
Gebt dem aktualisierten System 15 Minuten bis zu 2 Stunden Zeit um "aktuell" funktionsfähig zu werden. Das liegt an den SOCK's und weiteren Abhängigkeiten. Also nach jedem Update etwas Geduld.
@ Tososboso: das aktuelle Community Build 9.0.1.5 rennt

Glück Auf und immer ein Licht bei der Nacht
Frickler@Home

 

[FricklerAtHome]

Hinweis für MAC Catalina und DESKAPP Aktualisierung

Glück Auf Kopano'ies

wer von euch die aktuelle DeskApp 2.5.4 unter MacOS Catalina einsetzen möchte erhält eine Fehlermeldung das Apple in der Anwendung nicht nach Viren suchen kann.
Damit es läuft müßt ihr die Systemsteuerung => Sicherheit öffnen. Da findet ihr unten den Hinweis:" DeskApp wurde ... Wollen Sie es trotzdem öffnen?" Ja! und dann geht es.
Eventuell muss noch ein Admin bestätigen.

Glück Auf und immer ein Licht bei der Nacht
F@H

Der aktuelle Nightly-Build rennt bei uns!

 

[Andy+]

.........aktuelle Community Build 9.0.1.5 ..........

Ich bin mir fast sicher, dass er die bereits am Wickel hat und testet ... ... wie heisst es so schön, gut Ding braucht Weile, bis dahin werden die Emails noch Geduld haben müssen .... . Für mich spielt das eh keine Rolle, da Default.

 

[FricklerAtHome]

Performance

Glück Auf Kopano'ies

Gordon in einem anderen Threat und wir haben uns mit der Trennung von MySql / MariaDB vom Kopano-Kern beschäftigt.
Wir sind nach etlichen Versuchen wieder bei der alten JD Technologie gelandet. Entweder läuft MariaDB wieder nativ auf der Syno, oder wie bei mir auf einer weiteren Syno. Das ist trotz potenziellen Geschwindigkeitsverlust bei uns super stabil. Es hält auch die Systemlast aller Systeme niedrig und hat nicht die alten Effekte das sich MariaDB unter BRTFS unperformant anfühlt. Man muss lediglich entsprechend der Kopano-Server Log-Hinweise die --- max-allowed-packet in mariaDB auf 16 MB setzen (mittels my.cfg). Der Standartwert von Synology ist hier mit 10 MB zu klein.
Damit wächst unsere VM nicht in Bezug auf die Zunahme der Datenbank-Größe und wir können einen SQL-DUMP zur Sicherung gezielt und trivial nutzen.
Ein einziges aber nur sporadisch auftretendes Problem: Wenn in der externen Maria der Dump läuft (Dauer bei uns ca. 7-12 Minuten) ist kein Kontakt von Clients möglich. Das hat bei unserer Installation dazu geführt das, dass das Handy meiner Frau über Z-PUSH eine Aktualisierung angefragt hat. MariaDB war aber zu diesem Zeitpunktt mit dem Dump beschäftigt und hat Kopano-Anfragen nicht bedient. Folglich versuchte es das Handy 5 Mal in 3 Minuten und wurde prompt von Fail2Ban ausgesperrt. -- Falsch, nicht das Handy sondern die IP Adresse des reverse-proxy wurde gebannt. Und damit alle Zugriffe per Z-PUSH, aller Handy oder Z-PuSH Clients!
Wer also einen reverse-proxy (wegen lets-encrypt) einsetzt, erhält mit fail2ban ein zweischneidiges Schwert. Das gilt auch für postgrey über zusätzliche Viren / SPAM Proxys. Wir sperren nur für drei Stunden und Dumpen tief in der Nacht. Das löst in der Regel dieses Problem. Sie sind aber vorgekommen.
Als Erfahrungswert spendieren wir Kopano 2 Kerne und 2,56 MB RAM (dann wir bei uns defacto nicht geswapt) und MariaDB 1 Kern und ebenfalls 2 GB RAM. Mit dieser Einstellung sind wie gefühlt schneller als alles was wir zuvor einstellen konnten. Ja das sind jetzt auch in Summe fast 5 GB für das Kopano System. Aber ohne 8 GB RAM in der Syno hat man mit Docker-Einsatz etc. eh ein Problem. Unser Fazit RAM hilft, wie und wo eingesetzt muss jeder für sich probieren.

Glück Auf und immer ein Licht bei der Nacht
Frickler@Home

 

[FricklerAtHome]

@ Andy+
ich habe Tosoboso versprochen "funktionierende" nightly_Builds rückzumelden. Das tue ich.
Das hilft Tosoboso.

 

[dafri]

Jetzt darf ich, die dunkleste Kerze auf dem Kuchen, fragen: Das heißt vereinfacht: Ich gehe in die Kopano GUI, dort K-cmds, wähle kopano4s-init im dropdown und ins feld kommt refresh, danach "run" klicken und der Horror ist vorbei? Kopano zieht sich selbständig den neuesten container? Das wäre ja cool!
Oder muß ich manuell etwas über docker machen?

 

[Andy+]

Genauso ist es ... nichts ist manuell zu machen.

 

[Andy+]

Gibt es eigentlich ein Changelog zu den einzelnen Modulen:

core-9.0.1.5
files-3.0.0.5+104
webapp-3.5.14.2550+1484
webmeetings-0.29.5_1
kopano-deskapp-2.5.4

 

[FricklerAtHome]

üblicherweise unter zB.:

https://documentation.kopano.io/kopano_changelog/deskapp.html#kopano-deskapp-2-5-4

für die DeskApp

Aber nicht vollständig gepflegt. CORE 9 noch ohne Changelog

Glück Auf und immer ein Licht bei der Nacht
F@H

 

[Tosoboso]

..wir haben uns mit der Trennung von MySql / MariaDB vom Kopano-Kern beschäftigt. Wir sind nach etlichen Versuchen wieder bei der alten JD Technologie gelandet. Entweder läuft MariaDB wieder nativ auf der Syno, oder wie bei mir auf einer weiteren Syno. Das ist trotz potenziellen Geschwindigkeitsverlust bei uns super stabil. Es hält auch die Systemlast aller Systeme niedrig und hat nicht die alten Effekte das sich MariaDB unter BRTFS unperformant anfühlt. Man muss lediglich entsprechend der Kopano-Server Log-Hinweise die --- max-allowed-packet in mariaDB auf 16 MB setzen (mittels my.cfg). Damit wächst unsere VM nicht in Bezug auf die Zunahme der Datenbank-Größe und wir können einen SQL-DUMP zur Sicherung gezielt und trivial nutzen.
Ein einziges aber nur sporadisch auftretendes Problem: Wenn in der externen Maria der Dump läuft (Dauer bei uns ca. 7-12 Minuten) ist kein Kontakt von Clients möglich. Folglich versuchte es das Handy 5 Mal in 3 Minuten und wurde prompt von Fail2Ban ausgesperrt. -- Falsch, nicht das Handy sondern die IP Adresse des reverse-proxy wurde gebannt. Und damit alle Zugriffe per Z-PUSH, aller Handy oder Z-PuSH Clients!

Hi F@H,
Kopano4S läuft seit eh und jeh mit MariaDB nativ auf der Synology und die Empfehlung ist MariaDB auf einem ext4 Volume und am besten mit SSD zu verwenden.
MariaDB wird von k4s Paket übrigens automatisch getuned, was max-allowed-packet und inodb_buffer angeht..
K4S hat mitlerweile übrigens auch Fail2Ban, auch nativ mit einem extra Paket auf der Synology (siehe CPHub nach Fail2Ban4S).
Aber die Zugriffe auch k4s während einem Datenbank Dump brechen nicht ab und damit gibts auch keinen F2B Fehlalarm.
Zusammengefasst verstehe ich, dass du mit Alternativen in VMWare Testest und gerne vorweg gehst, ebenso gibst du Tips an die Gemeinde bei Technischen Dingen.
Aber das VMWare Konstrukt nähert sich immer mehr an K4S an und Docker ist da einfach(er) und "leichter" meiner Meinung nach.
Kannst ja überlegen, ab wann es sich lohnt vom Fork zurück auf k4s zu kommen (Vorraussetzung: F2B, Spamassassin etc., gibt es ja nun in k4s, nur die SPAM GUI steht noch aus)...
Und ja ich arbeite an den Docker Images Community 9.0.1, Debian 10..
-TosoBoso

 

[FricklerAtHome]

Glück Auf @ Tosoboso

ich bin hier weiter im Forum für Zarafa unterwegs weil es die für mich die aktivste Community in Deutsch zum Thema Kopano ist. Ich bin auch im KOPANO.IO Forum aktiv, aber da geht es nur um Kopano und die Rahmenprogramme ( Postfix / MariaDB etc), die den gesamten Betrieb ausmachen sind aussen vor. Ich lese und versuche hier weiter zu helfen, da ich mittlerweile eine lange Fan-Historie zu Zarafa und jetzt Kopano habe.
Schön das du meinen Ansatz KOPANO in einer VM zu nutzen für einen FORK erklärst. Und wir brauchen hier auch nicht den Evangelisten-Krieg Virtuelle Maschine vs. Docker führen. Da muss jeder wissen mit welchen Mitteln, wer sein Ziel erreicht. Wir / Ich haben da, auch aus der Erfahrung deutlich andere Erwartungen und Anforderungen, als die Nutzer von K4S. --- Ich habe gerade noch mal ein paar Seiten aus dem Thread "Wie geht es weiter mit Zarafa" gelesen. So etwas über Seite 200 um den 13.02.2018. --- Nach Julians Abkündigung hatten wir Ängste zu einer zweiten "Kopflosigkeit".

So wie damals gilt auch heute, ich bin hier nicht als Troll oder Besserwisser unterwegs. Ich sage dir ernsthaft und mit größtem Respekt Danke für deine Arbeit an einem nativen Synology-SPK. Genauso gerne gebe ich Hilfen, wenn jemand hier Fragen stellt und diese nicht SPK-spezifisch sind. Ebenso kann ich mit meinen Mittel evtuell Dir bei der Containerentwicklung helfen. Deshalb benenne ich "Nightly-Community-Stable-Build's" die ich erfolgreich im Einsatz habe und noch nicht in K4S Containern auftauchen. Damit will ich dir beim Testen helfen. -- Wenn nicht gewünscht, lassen wir das.
Ich möchte sicher nicht kontraproduktiv zur Intention von "Zarafa als Syno-App" auftreten. --- Ich vertrete weiter den Hogwards-Ansatz: "Wer nach Hilfe fragt, dem soll Hilfe zuteil werden". Wer fragt muss aber auch bereit sein sich ernsthaft und mit eigener Wissengenerierung für eine Lösung qualifizieren. Das Prinzip: "Ich kann alles, weil bei einem Problem kenn ich ein Forum, das das Problem für mich ohne Erkenntnisgewinn löst", nicht mein Ansatz zur Wissensweitergabe ist.

Herzlichen Dank für die Ausladung von Andy+ und von dir in diesem Thread weiter aktiv teilzunehmen.

Glück Auf und immer ein Licht bei der Nacht
der Frickler@Home

 

[Tosoboso]

Herzlichen Dank für die Ausladung von Andy+ und von dir in diesem Thread weiter aktiv teilzunehmen.

Meine Einladung war aktiv(er) an Kopano4S in Docker teilzunehmen und das war keine Ausladung an dich bgl. Teilnahme an dem Forum. Bitte vermische nicht Statements in anderen Threads, die nicht von mir sind mit meinen.
Ich sehe deine Beiträge nicht als kontraproduktiv (s.o). und will auch keinen religösen Streit über Docker vs. VM Ware austragen. Es war ein wenig "teasen" was die Lösungsansätze angeht, das ist alles.
Wissensweitergabe ist eben auch mein Ansatz (z.B. signierte Pakete werden in beiden Ansätzen verwendet und ich teile gerne solche Recherchecn, die übrigens sehr zeitaufwendig war).
Also bitte nicht falsch verstehen und falsch abbiegen. Das mit der Angst bzgl. Kopflosigkeit verstehe ich. Genau deswegen sollten wir uns nicht vor den Selben stossen und ich hatte das auch nicht vor. Alles Weitere gerne per PM..
-TosoBoso

 

[Andy+]

...... die Ausladung von Andy+ .......

Da hast Du wohl was falsch verstanden.

Es ging lediglich darum, dass Du verständlicherweise mit Stolz kundgibst, was Du alles experimentierst und wie gut das alles läuft. Das will Dir auch keiner nehmen und ich finde das toll, dass Du anderen hilfst und betreust, wie Du so schön sagst. Jedoch haben wir dann nichts davon, wenn Du mit uns nicht Dein gefragtes Wissen teilst und nicht nur das, was Du gerad bereit bist, zu geben. Gerade im Falle der VMM Installation mit Kopano ist mir das aufgefallen. Gehe ich von mir aus, dann sieht jeder im Forum im Prinzip meinen Wissenstand und das ist der Unterschied. So wie Du auch, habe ich keine Lehrgänge oder sowas gehabt und habe alles erarbeitet, ergoogelt usw. und das teile ich vollumfänglich, den Eindruck hatte ich bei Dir nicht. Vielleicht ist das ein etwas überzogenes Bild, aber um das geht es im Grunde.

Mehr ist das nicht, niemand lädt Dich aus, Du bist selbstverständlich herzlich willkommen, Dein "Glück Auf ...." würde wirklich fehlen, von daher, bleib uns weiterhin aktiv erhalten ....

 

[honk013]

Moin allerseits,
habe gerade auf die Stable 1.0.7 upgedatet und danach folgendes festgestellt.

In der ersten Zeile von "Kopano4s-Admin -> Fetchmail" steht auf einmal das drin:



Das war davor nicht! Muss das so sein, wo kommt das auf einmal her und wie bekomme ich das wieder weg?
Danke für Eure Hilfe.

 

[Andy+]

Das ist bei mir auch, war aber vorher schon.

 

[honk013]

Moin Andy,

nö, bei mir war das nicht so; deswegen frage ich.

Bei mir standen immer nur die drei Zeilen mit den jeweiligen Informationen zu den einzelnen E-Mailkonten in der Tabelle. Die erste Zeile ist ja auch - für mich - sinnbefreit.
Habe mir die "fetchmailrc" mal angeschaut. Da steht diese erste Zeile auch nicht drin.