MODULARE INSTALLATION // Feature Request K4S

[FricklerAtHome]

@Tosoboso

Glück Auf liebe Kopanois

ich habe wieder rumgespielt und experimentiert. Bekanntlich setzt sich Kopano (in groben Oberbegriffen) aus mehreren Komponenten zusammen.
MTA = Mail Transfer Agent (mit regelhaft Postfix und den Antispam / Antivirus Komponenten), regelt zumindest den Mail-Versand nach drausen und übergibt Mails von draussen an Kopano
Kopano = Der eigentliche Core des Systems, der immer zwingend mit einer Datenbank (MARIADB) verbunden ist, die eigentliche Colab-Software
WEB-Konnekt = der Zugriff für Clients mittels Z-Push, Web-Server und Kopano-WebApp, die Clientzugriffsebene auf den Core

Der MTA und die Datenbank sind Linux-Standard Komponenten. D.h. man kann sie auch ohne Kopano für jegliche Zwecke nutzen.
Nachdem Tosoboso in einem anderen Threat mal darauf hinwies das man "POSTFIX" auch auf einer anderen Hardware als Kopano laufen und ansprechen kann und dies auch mit dem MariaDB Datenbankserver funktioniert, sieht meine aktuelle "Kopano-Gesamt-Konzeption" nun so aus:
Ich habe den MTA (Postfix mit nun RSPAMD anstatt AmavisNew) und die MariaDB auf eine externe Hardware ausgelagert ( passive gekühlter MINI-Intel Barebone mit 7 W Verbrauch, 16 GB RAM und 250 GB SSD ). KOPANO läuft auf dem Syno-NAS lediglich mit seinen Basis-Komponenten ( Core, Spooler, Web- und Z-Push Integration etc. ).
Ich habe also den MTA Ausfall- und Fehlkonfigurationssicher. Gleiches gilt für die Datenbank. K4S. ---- Das hier zu beschreiben geht zu weit, wer aber Performance braucht dem sei der Schritt dringend empfohlen.

Nun zum Feature-Request: lieber Tosobos du hattest selbst erwähnt mit dem Gedanken zu spielen für das K4S in der Primär-Installation einen anderen MTA als "localhost" einbinden zu wollen bzw. zuzulassen, ich kann diesen Gedanken nun auch für die Komponente Datenbank (als Wunsch-Feature) erweitern.
Seitdem ich den MTA für meine Bedürfnisse einmal eingerichtet hatte bedarf er langfristig keiner Änderungen. Die Datenbank wird mittels CRON mehrfach täglich aus der externen Hardware auf das NAS gedumpt, und ist selbst für meine Ansprüche damit Safe. Was will man mehr.
Für die Anwender die weiter alles auf einem NAS brauchen und wollen, hast du ja schon den Weg super fertig vorbereitet. Für die User mit den EXTRA-Würsten wäre meine Anfrage aber eventuell eine echte Option. Ich kann mir aus verschiedenen Gründen sogar weitere Misch-Optionen vorstellen.

Schön wenn es eine Antwort gäbe, auch von den weiteren K4S Usern.

Immer ein Licht bei der Nacht!

F@H

 

[Tosoboso]

Hi F@H,
dein Feature Request bedeutet, die Kopano Komponenten in einzelne container also Microservices zu zerlegen und dies via Docker compose zu steuern. Dann könnte man auch Container wie den Postfix MTA auslassen.. Die Verwendung von Docker-Compose ist auch schon von Felix / fbartels angepreisen worden und der richtige Weg. Nur bedeutet das aber ein komplettes Refactoring von Kopano4s incl. Steuerung Installation, GUI.
Das habe ich auch vor, ist aber ein dickes Brett für eine Person.
Ich habe bereits mit den Containern etwas Prototyping betrieben und es soll ein k4s-core (server, dagent, fetchmail), k4s-addon (gateway, ical, spamd, search), k4s-web (webapp, z-push), k4s-postfix, k4s-rspand geben. Alles konfiguriert via compose und .env Datei. Mit dem Editor kann man dann Docker Services in der Compose Datei raus nehmen.

Was die Synology Orchestrierung angeht: auf dem Community Package Hub findest du Jitsi-Meet, das exakt nach dem Schema Docker compose, Microservices und einer Synology Installationsroutine plus Admin-GUI mit Ajax funktioniert. Das ist mein Prototyp Projekt für den Umbau von Kopano. Glück auf.
-TosoBoso

 

[FricklerAtHome]

Hi Tosoboso

das hört sich gut an und geht genau in die Richtung in die ich dachte. Leider ist Docker und erst recht Docker-Compose für mich nur ein Rand-Thema ( ich kenn nur die Prinzipien und Grundlagen ). Jitsi-Meet kenne ich (Frickelei nach einem Heise-Artikel --- auch als Docker-Ansatz), mangels Nachfrage in meiner Betreuten Umgebung hab ich mich damit aber nicht weiter beschäftigt. Das es für dich ein dickes Brett ist in diese Richtung weiter zu entwickeln brauchst du nicht zu erwähnen. Das kann ich vollständig nachvollziehen. Leider kann ich dir da mangels Grundlagen auch nicht helfen. --- Ich bin aber auch der Meinung das es der richtige Weg ist!

Aber eine kurze Frage: Bei dir wären es 5 orchestrisierte Container. Wo landet die Datenbank? Im Container R-spamd? Dein geplantes k4s-addon würde ich im k4s-core lassen. Die restliche Aufteilung macht auch in meinen Augen Sinn.

Danke für die Antwort!
Glück Auf F@H

 

[Andy+]

Ich finde einen modularen Aufbau auch charmant, zumal bei Updates auch nicht immer alle Komponenten betroffen sind. Wichtig fände ich ein userfreundliches Management des Ganzen, sonst käme hier ein hoher Prozentsatz nicht klar damit. Sicher, Docker-Compose ist auf jeden Fall schon mal der richtige Ansatz, es käme aber schlussendlich auf die GUI an, dass die Bedienung intuitiv ist und vielleicht grobe Fehler unterbindet.

Bei Komponenten, wie der Datenbank, welche man sich ja oft zudem mit anderen Applikationen teilen muss, in meinem Falle der MariaDB10 habe ich gleich 6 davon, liegt es eher am User, diese zu verwalten, ich würde da keine Änderung sehen. Wer Performance braucht und die Datenbank besser auf einer SSD laufen lässt, der sollte das fertigbringen.

Ich bringe da nochmal einen Oldie ins Spiel, den Mailserver von Synology. Die jetzige Installationsroutine ist wirklich sehr gut aufgebaut usw. Dennoch habe ich immer wieder gelesen, dass User ein Problem haben bei den Einträgen und es an Vorstellung fehlt, oder vielleicht nur KnowHow. Was spricht dagegen, das zu gestalten, wie bei Z4H, dass der Mailserver die Schnittstelle nach draussen ist? Was war der Hauptgrund, davon wegzugehen?

 

[Tosoboso]

Hi zusammen, zu den Punkten:
#1 Datenbank: MariaDB soll ausserhalb nativ bestehen bleiben und per Socket gemountet werden. Redis für rsampd als Container mit Socket mount.
Ratio: MySql ist eine Shared Komponente und bei Backup plus DR Replikation ist das nativ einfacher als mit Docker Containern

#2 Core plus add-on: es sollten möglichst wenig Prozesse in einen Container sein, daher die Idee optionales auszulagern und nur server, spooler, dagent in einen Container, der genaue Scnitt ist noch nicht entschieden:
Ratio: Steuerung und Orchestrierung im Container mit Child Prozessen ist sehr aufwending vorallem wenn ein Delay nötig ist, bis Kopano-Server läuft

#3 Mailserver von Synology unterstützt kein LMTP via virtual domain oder virtual mailbox: ohne Docker konnte man Dagent als Prozess aus Postfix Mail-Server aufrufen mit Docker geht das nicht da man Root sein muss. Die andere Variante: LMTP als virtual Mailbox wird von Synology Mailserver nicht unterstützt. Von Postfix sehr wohl. Es gibt ggf. noch die Möglichkeit Synology Mailserver per mail relay und transport-maps zu konfigurieren, aber ich bin es ehrlich gesagt leid, da Reverse Engineering zu betreiben, wenn Synology die Postfix Funktionen verbiegt.

#4 Die GUI wird auch modular überarbeite, funktioniert dann mit Perl-Webservices und AJAX JS und nicht mehr ein monolitisches Perl Skript. Das ist im Ansatz in jitsi-meet aufgesetzt.
#5 jitsi: @F@H: der Jitsi-Meet Synology von Heise ist per Kubernetes und Helm aufgesetzt, das ist auch sehr komplex, da ist das Docker Package der Jitsi Gemeinde mit meiner GUI als Wrapper 'handlicher'; schau es dir einfach mal an
-TosoBoso

 

[Andy+]

Das klingt alles gut und nach, sagen wir mal K4S v2.0 (......). Wie sieht das aus mit Jitsi-Meet

https://www.synology-forum.de/threads/jitsimeet-fuer-synology.108287/

https://www.cphub.net/?id=40&pid=916

wäre das wohl unabhängig von Webmeeting in Kopano und besteht da vielleicht eine gewisse Kompatibilität über zB. Plugins zu Zoom, Teams und weitere?

 

[Tosoboso]

Hi, Jitsi-Meet ist komplett unabhängig von Kopano Webmeetings und dem neuen Kopano-Meet und ist frei verfügbar.
Für Kopano Meet muss man die Lizenz aufstocken. Beides läuft mit WebRTC; Raum und User Konzepte sind etwas Anders.
Die einfachste Art, Jitsi-Meet in DeskaApp einzubinden wäre via Intranet Plugin.
-TosoBoso