Wie geht's mit dem Zarafa Package weiter?

[Jack_77]

Ich hab mich getraut und 0.5.4 runter geschmissen und 0.6.9 installiert. Ging einfacher als gedacht.
SMTP gabs mal wieder probleme>auskommentieren von smtpd_recipient_restrictions und smtpd_sender_restrictions = reject_unknown_address brachte Abhilfe (Debian CHroot). reject_unknown_sender_domain war schon auskommentiert.
Fetchmail ging auch nicht auf Anhieb>Unter /var/packages/Zarafa4home/etc/zarafa stand in der Datei default-fetchmail:

-e # Declare demon mode here
START_DAEMON=yes

Habe meine default-fetchmail Datei mit folgendem Inhalt raufkopiert:

# This file will be used to declare some vars for fetchmail
#
# Uncomment the following if you don't want localized log messages
# export LC_ALL=C

# If you want to specify any additional OPTION to the start
# scripts specify them here
# OPTIONS=...

# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=yes

Damit lief auch Fetchmail wieder

Die neue Webapp ist schon cool.

Danke Euch

 

[Andy+]

Genauso ist das ..... ..... viel Spass damit.

 

[FricklerAtHome]

Absturz nach dem heutigen Update: Habe heute auf DSM 6.1.4 upgedatet und dann das Dockerpacket auch aktualisiert.

Danach ist der DockerContainer alle paar Minuten abgeschmiert. Zum Glück nur auf meiner Testkiste.

Lösung: Zarafa incl. Docker-Container deinstalliert ---- Wichtig Datenbank behalten!! . Im neuen Docker den Container als Abbild neu vorgeladen und dann Zarafa neu installiert.

Läuft wieder.

Der Frickler

 

[Andy+]

Das war bei mir auch so, gleiche Vorgehensweise.

 

[FricklerAtHome]

Mal was Anderes: Zertifikate

Viele von euch haben beschrieben wie ihr mit "Let'sEncryt" Zertifikaten umgeht.

Meine Zarafa-Installation hat nur einen Kontaktpunkt ins Internet über die ActiveSync Schnittstelle, ansonsten bin ich per VPN erreichbar. Dementsprechend gehe ich mit den Zertifikaten etwas anders um. Auf einem Raspi mit Debian habe ich mittels openCA eine "private ROOT-CA" aufgesetzt. Mit dieser habe ich für alle Synos jeweils ein Zertifikat, vor allem auch für deren IP Adresse als Common Name. Diese Zertifikate habe ich dann in den Synos als Default-Zertifikat eingerichtet. Das Zertifikat für den ActiveDirectory-Dienst der Syno ist weiter dafür verfügbar. Das IP-Zertifikat ist aber der Standart. Dieses Zertifikat wurde bei der ZARAFA-Installation für die SSL Kommunikation genutzt. --- Gefühlt hat sich die Geschwindigkeit der ActiveSync Geschichten hierdurch deutlich erhöht.
Diese Zertifikate habe ich bei meinen WIN Kisten sowohl über den Outlook-Dialog als auch noch einmal in den Einstellungen des Internet-Explorers / Edge eingestellt. Ich nutze das ähnlich auch für ssh-Zugriffe ohne Passwort. Damit laufen dann Scripte auf irgendwelchen Kisten aus einer zentralen Instanz. --- Warum nutzt ihr extern zertifizierte Stamm- bzw. Domänenzertifikate. Ich habe mich wegen der kurzen Laufzeiten, den fehlende Wildcards in meinem privaten Netz dagegen entschieden. Exposed Host, DMZ oder gar einen direkt errechbaren SMTP Port 25 gibt es bei mir nicht. Das wird schön bei meinem Provider gehostet.

Grüsse der Frickler

 

[Andy+]

Ich für meinen Teil bin da zum einen nicht so der Experte.

Zudem habe ich hauptsächlich nur meinen Produktivserver am Laufen, die anderen und der Backupserver läuft in der Regel nur zeitweise. Insofern würde ich alles auf dem Produktivsystem lösen wollen. Bei mir ist das Hauptproblem die Erreichbarkeit des Servers aus anderen Netzwerken, z.B. aus Firmennetzwerken, die ja in aller Regel sehr ristriktiv sind. Beim Versuch, aus solchen Netzwerken einen VPN-Tunnel aufzubauen, bin ich bis heute gescheitert, insofern stellte sich diese Variante bis heute nicht. Daher gehe ich bis heute den Weg über DynDNS und http/https-Protokolle, da eher selten auch Ports zugelassen sind. Und wenn Ports gehen, gehen wieder nicht alle Protokolle, wie zB. SCP, FTP usw. Das ist auch der Hauptgrund, weshalb ich ownCloud einsetzte, da ich bislang noch kein Netzwerk erlebt habe, was mir das blockt, auch wenn ich schon mal einen Proxy überlisten musste.

Insofern habe ich für Zarafa4h explizit ein Let'sEncryt-Zertifikat angelegt und diesem eine eigens eingerichtete DynDNS angelegt und als "Dienst" zugeordnet. Wenn ich nun auch intern die IP´s über Zertifikate abdecken wollte, müsste ich im Reverse-Proxy diese anlegen für die Umleitung und diesem "Dienst" wieder eine neues Zertifikat zuordnen oder so ähnlich. dann hätte ich wohl einen ähnlichen Effekt. Bislang habe ich das für Interzwecke unterlassen und spreche Zarafa4h mit http und Port 9080 oder 236 an. Mails nach extern gehen dann wieder über ein Relay und Port 587.

 

[Jack_77]

Gibt es eigentlich eine zarafa-admin weboberfläche mittlerweile. Nicht, dass es viel Arbeit wäre die Einrichtung über cmd auszuführen, interessiert mich nur.

 

[Andy+]

Ja, gibt es. In der v6.9.0 in der weitesten Ausbaustufe, aber noch nicht vollständig.

 

[Jack_77]

Gibt ja keine blöden Fragen, aber wie komme ich da drauf?

 

[Andy+]

Startmenü (oben links), dann sollte da ein Icon mit "Zarafa-Webapp" sein. Wenn nicht, dann steht das Paket im Paketzentrum vlt. auf "angehalten".

 

[Jack_77]

Startmenü (oben links), dann sollte da ein Icon mit "Zarafa-Webapp" sein. Wenn nicht, dann steht das Paket im Paketzentrum vlt. auf "angehalten".

Manchmal sieht man den Wald vor lauter Bäumen nicht. Habe auch mittlerweile Deinen Post mit der URL gefunden http://IP:Port/webman/3rdparty/Zarafa4home/index.cgi

 

[pcmartino59]

Hallo Zarafa Kollegen,
hat jemand von euch eine Ahnung was ich machen muss um meine Testumgebung , die ich jetzt auf VirtualDSM gezogen habe auch das Z4h Installieren kann? Der sagt mir die Platform wird nicht unterstütz. Was kann ich ändern damit es klappt.... so könnte ich auch öffters Testen wenn ein neues Package raus kommt ohne mir jedenmal die Live umgebung in gefahr zu bringen.
Danke euch schon mal im vorraus Gruß Pac

P.S updates von der Syno ( Docker und Systeme ) haben das erst mal stress gemacht.
Bei der 2 Syno die ich habe habe ich das Z4h im Packgecenter gestopt und dann erst die updates gemacht. System und Docker wurden Aktualisiert ohne Probleme. Habe dann das Z4h noch gestartet und es lief ohne probleme. Super durch

 

[FricklerAtHome]

Zarafa4H geht nicht in einem virtuellen DSM. Zumindest nicht bei mir. Docker geht noch. Aber eine manuelle Installation von Zarafa4H klappt nicht da es noch nicht für alle erdenklichen Synos die entsprechenden "Kernel / CPU" Anpassungen im SPK gibt. Zum Beispiel DS 3615sx geht DS 3617sx nicht. VirtualDSM wird von Tosoboso wahrscheinlich gar nicht bedacht werden können. Es gab mal für Benutzer mit inkompatiblen Kisten zu SPK den Hinweis, dies dierekt und händisch im SPK zu ändern. (irgendwie hier auf den fast 180 Seiten) Ich wage aber zu bezweifeln das dies funktioniert.
Du könntest als Alternative eine virtuelle DSM per VMware Esxi erstellen. Darin funktioniert es. Ich glaube auch in einer realen VMware Player VM mit einem alternativen Bootloader. Das Ding liefe dann quasi nur bei Bedarf auf deinem PC.

Gruss der Frickler

 

[pcmartino59]

danke für die schnelle antwort.... Mal schauen vielleicht hat ja noch jemand eine Idee... Schlecht wäre dies ja nicht zum Testen.
Grüße Pac Dein Tip ist nicht schlecht versuche es mal

 

[Andy+]

Die verwendbaren Platformen sind

cedarview
avoton
evansport
alpine
alpine4k
x86
bromolow
braswell
apollolake

und kann hier nachgesehen werden. Die Plattformen, die nicht geführt werden, können ggf. trotzdem zum Laufen kommen, indem mit 7-zip o.d. die INFO aus der SPK geöffnet und durch entsprechende Eintragungen angepasst wird. Wenn das zum Laufen kommt, was nicht garantiert ist, sind selbstverständlich ausführliche Tests erforderlich, da ansonsten keine Funktionssicherheit besteht, da offiziell andere, als die genannten Plattformen, eigentlich nicht unterstützt werden.

 

[pcmartino59]

Spitze danke euch.... habe es auf Hyper-V am laufen jetzt. Top damit kann man arbeiten und testen.

 

[Tosoboso]

Absturz nach dem heutigen Update: Habe heute auf DSM 6.1.4 upgedatet und dann das Dockerpacket auch aktualisiert. Danach ist der DockerContainer alle paar Minuten abgeschmiert. Zum Glück nur auf meiner Testkiste.Lösung: Zarafa incl. Docker-Container deinstalliert ---- Wichtig Datenbank behalten!! . Im neuen Docker den Container als Abbild neu vorgeladen und dann Zarafa neu installiert. Läuft wieder.

Ich habe keine Ahnung was Synology bei den major Docker Updates macht, aber die Docker Architektur würde es erlauben, sogar bei laufendem Container Updates zu machen.
Erfahrungswert ist jedoch: vor Docker Update z4h zu stoppen und danach zu starten. Wenn das nicht hilft, dann zarafa-reset container; das ist eigentlich auch nix Anderes, als Neu-Install.
Man kann eine Paketabhängigkeit setzten, sodass bei jedem Docker Update zuerst z4h gestoppt wird, das kann ich aber nicht machen, sonst ist z4h Debian Chroot futsch; ich werde es aber beim geplanten k4s machen; Docker only.
.TosoBoso

 

[Tosoboso]

Mal was Anderes: Zertifikate Viele von euch haben beschrieben wie ihr mit "Let'sEncryt" Zertifikaten umgeht.

..Und viele wissen nicht u, die nesuten Features unter der Haube.. Man kann mit zarafa-reset ssl die Synology Zertifikate erneuern. Man kann auch z4h bei jedem Start Prüfen lassen, ob das Synology Default Zertifikat noch dem Zarafa Zertifikat entspricht, und es Updaten lassen. Aktuell ist das noch nicht in der GUI; Anpassen der /var/packages/Zarafa4home/etc/package.cfg Parameter Z_SYNC_SYNOCERT="OFF" =>"ON" Aktivert das. Dann wird der LetsEncrypt Update auf der Synology zu z4h durchgereicht.
Übrigens werden nun auch die Zertifiaket für IMAP, ICAL gesetzt, aber nicht Aktiviert; da muss man noch selbst Hand anlegen in /etc/zarafa4h/gateway.cfg bzw. ical.cfg
-TosoBoso

 

[Tosoboso]

Zarafa4H geht nicht in einem virtuellen DSM. Zumindest nicht bei mir. VirtualDSM wird von Tosoboso wahrscheinlich gar nicht bedacht werden können.

VirtualDSM wurde von mitr schon bedacht, ich habe nur nicht genug Zeit und limitierte Anzahl an Synos das zu Testen. Ich hatte glaub ich mal z4h in Docker VDSM auf einer DS716+II ab Laufen, muss das noch mal verifizieren.
Grundsätzlich spricht nichts gegen z4h Docker in DockerDSM, es muss nur passen mit der Angabe des Prozessors in der SPK INFO; mit VirtualDSM auf Xen und z4h habe ich noch keine Erfahrungen und mein Syno-Fuhrpark gibt das aktuell nicht her.
-TosoBoso

 

[pcmartino59]

@TOSOBOSO
hatte nur gedacht es vereinfacht wahrscheinlich bei vielen z4h Testen. Somit wäre die live und Testumgebung schneller zu trennen und man würde risikoreicher zum testen kommen. Ich muss immer auf der liveumgebung testen da Z4h bei meinen alten synos nicht mehr läuft.... Deswegen hatte ich diese Idee.
Bin dabei z4h mal auf meiner neuen VM unter WIN10 und hyper-v zu Testen. Installieren konnte ich die VM schon. Jetzt fehlt nur noch z4h. So kann ich mehr probieren und auch mehr feedback geben.
Gruß Pac super JOB Tosoboso danke