Grommunio for Synology (G4S)

[Caramlo]

Jep , so sieht es bei mir auch aus!

 

[FricklerAtHome]

Frohes Neues aus dem Ruhrpott

Rund um das Thema Sicherheit und Zertifikate noch ein Hinweis:
Ich schalte meiner GROM Kiste einen Reverse Proxy (vom NAS) mit echten Let's Encrypt Zertifikaten vor. Der GROM bekommt nur ein selbstsigniertes Zertifikat aus dem Setup Prozess. Es ist dann für zB.: gromo.example.com als FDQN ausgestellt.
Das Setup erstellt aber nur ein Zertifikat mit einer 30 tägigen Gültigkeit. Denkt daran wenn ihr in den Produktivbetrieb mit selbstsignierten Zertifikaten geht! Für den Autodiscover-Prozess aus Outlook ist ein Zertifikat (egal ob selbstsigniert oder ein in GROM importiertes "amtliches Zertifikat" zwingend erforderlich.
Meine aktuelle Test-VM aus dem latest-ISO läuft ohne Files, Chat, Meet aber mit dem Piler-Archiver. Ich nutze strikt den Setup-Mechanismus. Der merkt eine php7 Abhängigkeit des Files-Repo an und beantwortet dies automatisch mit "(a)" wie Abbruch. Es sei auch kein php8-smb installiert. Ich nutze Files nicht mit einem MIX aus php7 und php8, das kann später Probleme machen und php7 ist seit gestern abgekündigt.
Aus dem Setup kann wie oben bereits angemerkt, ohne Tricks keine lauffähige "GROM-OWNCLOUD" abgebildet werden. -- Das ist zumindest meine heutige Erfahrung.
Das Setup generiert für "Archive" keine passende php8 Config im Ordner "/etc/php8/fpm/php-fpm.d". Die wird aber für einen sicheren Start von NGNIX und der Datenbank benötigt. Aber in Ordner "/etc/php7/fpm/php-fpm.d" liegen entsprechende Dateien mit "pool-grommunio*". Die habe ich in den php8 Pfad kopiert. Nach einem "reboot" ging dann Archive mit Web-Interface. --- Das hinter Archive stehende PILER / MAILPILER ist etwas "strange". Da probiere ich noch rum. Das braucht eigentlich nur jemand der eine Rechtsfähige Mailarchivierung haben muss. Ich mache das aktuell mit einem kommerziellen Produkt.
Chat und Meet setzen wir mangels Nachfrage nie ein und statt Files in GROM haben wir eine superstabile eigenständige Nextcloud VM.

F@H

 

[Andy+]

So ist das auch bei mir. Ich hatte die

/etc/postfix/sasl_passwd
[smtp.yoursmt.server]:587 'user':'password'

entsprechend angelegt. Bei mir ist dort der gleiche Eintrag, wie bei K4S. Dann noch Port 587 in der main.cf (relayhost = smtp.strato.de:587) ergänzt, dann ging das alles.

 

[Vogi]

Hi Andy+

zu Deinem anderen Thema:

Ich denke, ich kann mit meinem Konto bzw. Tarif bei Strato nicht alle Anforderungen darstellen, u.a. kann ich auch keine feste IP einrichten

Ich habs bei mir über einen DynDNS Anbieter (z.B. no-ip.com) gelöst. Die daraus resultierende "unschöne" DynDns Adresse habe ich dann als CNAME Eintrag für mail.meine-domain.de eingetragen. Damit ist dann mein Server auch ohne weitere Kosten unter der gefälligen Adresse erreichbar. Selbiges habe och auch für weitere Subdomains (autodiscover usw.) am Laufen

Darf ich nochmal nachfragen, wie Du das gemacht hast:

Mit der ISO nun habe ich die v2022.12.1 vom 29.12.2022 einwandfrei installieren können. Auch Files über WebDAV funktioniert.

Ich hab aufeghört, wo der php Konflikt aufgetaucht ist... und F@H scheint die gleiche Erfahrung zu haben. Vielleicht hast Du ja nen cleveren Weg gefunden... ansonsten würde ich das Thema auch erstmal nach hinten schieben.

Danke Vogi

 

[Caramlo]

@F@H:
Meine Installation deckt sich da ziemlich genau mit Deiner. Nur Basis-Grommunio mit E-Mail ohne den weiteren Schnickschnack. Das Archiv habe ich noch nicht zum Laufen bekommen. Ich habe das selbstsignierte Zertifkat neu erstellt mit einer Gültigkeit von 10 Jahren und dieses auf meinem PC installiert, damit Outlook nicht mehr meckert. Die mobilen Clients und der Webzugriff erfolgen über den Reverse Proxy auf der Syno mit gültigem Let's Encrypt Zertifikat.
Aktuell kämpfe ich gerade mit dem Upgrade meiner 2022.05.2 Version (Basis Leap 15.3 mit allen Updates) auf die 2022.12.1 (Basis Leap 15.4) Auch bei mir das größte Problem ist die Umstellung auf PHP 8. Da habe ich noch keinen erfolgreichen Weg gefunden. Ich vermute, in der Community Version ist das Upgrade noch nicht richtig umgesetzt. Habe mir schon dreimal meine laufende VM geklont und erfolglos verschiedene Upgradeversuche gestartet, bislang ohne Erfolg.
Falls da einer einen Tipp hat, wäre ich dankbar. Ansonsten halt abwarten, bis sich da in der Grommunio Community was tut.

 

[FricklerAtHome]

Noch eine Anmerkung zum Thema "Autodiscovery":

Es sind zwei Einsatzscenarien zu beachten

Ihr möchtet Outlook für Windows auch aus dem Internet benutzen, oder Outlook für Windows läuft nur in eurem Heimnetzwerk.
Wir haben uns strikt gegen die Nutzung von Outlook fW direkt aus dem Internet entschieden. Entweder nutzen unsere User die im Internet stehen eine VPN Verbindung ins Heimnetz und darüber dann Outlook fW, oder sie sind strikt mittels ActiveSync auf ihrem aktuellen Mail-Stand (also Handys, Tabletts etc.). Alles Andere ist uns zu unsicher. Wir geben auch den SMTP-Port von Kopano oder GROM nicht zum Internet frei. Ein aus dem Internet erreichbarer PORT 25 zieht innerhalb von Sekunden viele nicht gewünschte Gäste an. Unser Kopano / GROM ist direkt nur im Heimnetz erreichbar. Alles was reinkommen soll läuft über FETCHMAIL und alles was raus soll über smtp_auth. Lediglich OfW benutzt diesen Autodiscovery Mechanismus. Der EWS Konnekt ist aktuell weder in Kopano noch GROM vollqualifiziert vorhanden.
Zuletzt wird auch der Autodiscover allein nicht reichen. Für die Public-Folders muss bzw. sollte auch noch ein public.folder.root Eintrag existieren und wer mehr als eine Mail-Domäne auf GROM betreibt braucht diese Einträge für jede M-Domäne.

Bei uns hinterlegen wir das im Heimnetzinternen DNS Server der Synologie.
Für jede M-Domäne gibt es folgende Forward-Lookup Zonen: autodiscovery.m-domäne1.tld, public.folder.root@m-domäne1.tld und hostname.m-domäne1.tld. In jeder dieser Zonen gibt es einen Host-A Eintrag der auf die IP Adresse des GROM-Servers verweist. Für jede weitere M-Domäne ergeben sich dann entsprechende weitere Zonen. Also autodiscover.m-domäne2.tld mit wieder einem Host-A Eintrag für die IP des GROM-Servers.
Wir machen das auf dem internen DNS Server damit wir nicht auf jedem Host die Host-Datei editieren müssen wie Caramlo das beschrieben hat. Funktionieren sollte aber auch dieser Weg.

Ja unser Heimnetz ist aus dem Internet erreichbar, aber nur über einen einzigen PORT und die dazugehörige DynDNS Adresse hat rein gar nichts mit den Adressen unserer M-Domänen zu tun. Das entsprechende Mapping erfolgt im Reverse-Proxy und ist für Aussenstehende intransparent.
intern treiben wir dies noch ein ganzes Stück weiter. Das ist aber nicht RFT konform.

F@H

 

[FricklerAtHome]

@Caramlo

Ich lasse aktuell in meiner GROM-Produktiv-Kiste noch alles beim Alten! Keine Versuche mittels "zypper ref && zypper up && zypper dup" um auf GROM unter opensuse15.4 mit php8 zu kommen. Erst wenn im GROM Forum das Realese 2022-12-01 offiziell angekündigt ist werde ich da etwas versuchen. Bis dahin baue ich an der Test-VM mit der Latest-APP-VM ISO. Die habe ich funktionsgleich zur 2022-05-02 laufend.
Wenn das mit zypper-dup nicht klappen sollte, kann ich dann ganz entspannt lediglich die Benutzer aus dem dann alten Produktiv migrieren. Das sind ja wegen der 5 User Community Begrenzung nicht viele.
Wie du schon richtig bemerkt hast nutze ich in Kopano und GROM nur die Basics. Keine Files, Chat, Meet und bisher auch kein Archive. Alles andere ergibt in meinem privaten Umfeld und auch bei den betreuten Nachbarn keinen vertretbaren Sinn. ich werde mich deshalb hier zu keinem der optionalen Add-On äußern.

Gutes Neues
F@H

 

[Andy+]

Dafür muss der WebDAV-Server installiert sein. Intern von Server zur VM verwende ich kein SSL:



Genauso habe ich das in K4S auch.

 

[FricklerAtHome]

Da haben wir ja schön aneinander vorbei geredet. Files ist bei GROM eine eigene Owncloud-Instanz auf dem GROM Server.
Du nutzt nur das Datei-Plugin im User-Web-Interface um auf die Cloud-Station deiner Syno zuzugreifen. Zwei ganz verschiedene Schuhe.

F@H

 

[Andy+]

mit Outlook über ActiveSync den falschen Ansatz. Grommunio bietet die native Outlookanbindung über Mapi

Ist auch für MAPI die unterste Vorauswahl die passende?

 

[FricklerAtHome]

Nein!

Du must den Standart Weg gehen über das Interface:



Keine manuelle Konfiguration. Also hier Name, E-Mail-Adresse und zwei mal das Kennwort. Dann "Weiter" und über ein funktionierendes Autodiscover sollte dann alles laufen. Es wird ein Zertifikat-Fehler angezeigt mit einem roten X an erster Stelle und drei grünen Haken darunter. Das Zertifikat öffnen und dann lokal installieren. Anschließend sollte der Mapi Konnekt gehen. Am besten nutzt du hierzu ein eigenständiges Profil (Erstellbar in der Systemsteuerung)

F@H

 

[Andy+]

Danke!

Zusammen mit dem Eintrag in der "C:\Windows\System32\drivers\etc\hosts"

192.168.168.114 autodiscover.xxxxxxx.de

hat das geklappt.

 

[FricklerAtHome]

Dafür muss der WebDAV-Server installiert sein. Intern von Server zur VM verwende ich kein SSL:

Ich gehe mal davon aus du den WebDav Server auf der Synology meinst. Mit dem Files Plugin im WebIF hast du bei der Cloudstation eventuell Glück. Auf meine nextcloud komme ich so nicht aus GROM. Im Kopano Files plugin kann ich das sog. Backend einstellen. Bei mir owncloud und es rennt in Kopano. Bei GROM bleibt es in der Ansicht beim BACKEND Profil lediglich grommunio.
Deine Lösung funktioniert zu mindest bei mir nicht.

F@H

 

[Andy+]

WebDav Server auf der Synology

Genau.

Du kannst darüber auf jeden beliebigen, in der Synology-Systemsteuerung hinterlegten, freigegebenen Ordner anzeigen, für welchen Du Zugriffsrechte hast. Hinterlegst Du für den Webdav base path nur "/" werden alle Ordner mit Zugriffsrechten angezeigt. Bei mir heisst das aus der Historie heraus nur zufällig CloudStation. Ich habe aber tatsächlich mehrere Accounts bzw. Unterverzeichnisse hinterlegt, mit welchen ich laufend arbeite.

Lösung funktioniert zu mindest bei mir nicht

Wenn Du in irgendeiner Form eine WebDAV-Verbindung zu Deinen Datenbeständen aufbauen kannst, sollte es darüber gehen. In K4S hatte ich bislang auch WebDAV, weil es bei mir am schnellsten war. Mit Owncloud, SMB usw. ging das zwar auch, war aber zu träge, fand ich.

 

[FricklerAtHome]

@Andy+

Ja, das kann man so machen wie du es beschriebst. Sicherheitstechnisch habe ich dabei jedoch krause Nackenhaare. Aus dem WebDav ist dein NAS angreifbar. Ich nutze da lieber eine dezidierte NextCloud VM. Besonders weil wir hier den drop-box Ersatz für den Sportverein meiner Tochter (also viele "Unbekannte Benutzer") ziemlich sicher gestallten können. Im Heimnetz brauchen wir kein WebDav da alle internen Clients und User gegen "Synology Directory" gemappt sind (faktisch LDAP für Windows, Linux und MacOS). Dieses LDAP können wir in Kopano / GROM jedoch nicht als LOGIN Basis für alle User nutzen. Die ersten Kinder sind ausgezogen und greifen nur noch per Zugriff von aussen auf die Resourcen drinnen zu. Deshalb verwalten wir unsere user in GROM / Kopano weiter in der lokalen Datenbank. Hier können sie ihr Password eigenverantwortlich über das Password-Plugin des WebIF verwalten.
Also deutlich andere Ansprüche als bei dir.
Umso wichtiger sind die Angaben wie, in welcher Version auf welcher Umgebung wir hier agieren.

F@H

 

[Andy+]

Ich habe heute das System geupdated:

 

[FricklerAtHome]

sieht gleichwertig zu meiner ausgabe aus

 

[Andy+]

Immer wieder habe ich ein Thema mit nginx



Auch über das Terminal mit



nicht behebbar, Neustarts helfen auch nicht. Zuvor konnte ich das mit einem Systemupdate beheben. Das Ganze ist entstanden, weil ich über IMAP angefangen habe, meine Emails zu importieren, was zu 30-40% auch erfolgt ist.

Könnten da Timeouts im Spiel sein?

Nach einem Neustart des Hostservers gings dann wieder. Habt ihr sowas auch?

 

[FricklerAtHome]

was sagt den "systemctl status nginx" aus einer reinen ssh verbindung und nicht über die CUI?

 

[Andy+]

Die CUI sieht erst mal wieder normal aus nach dem Hostneustart und dann Start der VM. Im Moment sieht der Status so aus:

/$ systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2023-01-02 13:14:40 CET; 6min ago
Process: 1441 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Main PID: 1442 (nginx)
Tasks: 2 (limit: 4664)
CGroup: /system.slice/nginx.service
├─ 1442 "nginx: master process /usr/sbin/nginx -g daemon off;"
└─ 1443 "nginx: worker process" "" "" "" "" "" "" "" "" ""

Wie es aber momentan aussieht, habe ich mir durch den Import wieder die Datenbank zerschossen, wie beim letzten Import schonmal. Da hatte ich alles gelöscht und von vorne angefangen. Das steht wohl einmal mehr an, wenn sich die Datenbank nicht reparien lässt.

Admin-Loginseite:



Web-Loginseite: