Grommunio for Synology (G4S)

[Andy+]

Da hänge ich derzeit fest

Willst Du Nextcloud/Owncloud im Files-Plugin einen Account anlegen, geht das nur über eine DNS im Stil

https://serveradresse/nextcloud/remote.php/webdav/

Dann sollte das laufen.

 

[Andy+]

entsprechenden Web-Dav Pfad (siehe unter Dateien, Dateien-Einstellungen)

Ist leider falsch. Das gilt auch für die Grommunio Installation.

 

[FricklerAtHome]

meine aktuellen Erkenntnisse:

In einer neuen TEST VM habe ich GRO mit dem ISO vom 23.03.2023 komplett neu eingerichtet. Nachdem ich dann diese sauber auch in mein DNS integriert habe, funktionierte die Einbindung der GRO-NC-Instanz auch im GRO-WEB Interface. Ohne die direkte DNS Auflösung funktionierte vieles nur teilweise. Die GRO VM Instanz ist nun bei mir flächendeckend im internen Netz unter der FQDN der VM direkt erreichbar.
Nach diesem Eingriff gelang auch sofort der Zugriff auf "GRO-FILES" mit den als Standart vorgegebenen Einstellungen. Ich habe lediglich den FQDN der GRO-Instanz auf meinen Host VM Namen angepasst. Die GRO-NextCloud ist also auch aus der GRO-WEB-APP und nativ über "https://fqdn/files/" erreichbar.
In meiner produktiven Maschine ist lediglich über das FILES-Plugin der GRO-WEB-APP meine exteren NC Kiste eingebunden.

UND NUN:

ich nenne mal beide Szenarien verständlich:

TYPE A: meine produktive Nutzung mit GRO-CORE und NC als externe Instanz
TYPE B: GRO mit GRO Files in der aktuellen DEMO-GRO VM

Beides geht. Aber in beiden funktioniert kein "Hochladen in die NC" aus der GRO-WEB-APP.
Ist man auf dem direkten WEB-Interface der jeweiligen NC geht alles (hochladen, löschen etc.)

 

[491810]

Entsprechend in der config in der VM die Domains und IPs hinterlegen, mit welchen die VM Instanz angesprochen wird.

Habe mal eben in beide Files geschaut. Steht in beiden das gleiche - quasi nichts. Hast Du mal ein Beispiel vom Aufbau (Deiner)?

 

[Andy+]

diesem Eingriff

Ich habe das hinterher auch vermutet, dass das wohl absolut durchgängig sein muss, wie bei einer Produktivinstallation.

 

[Andy+]

Beispiel vom Aufbau

Die config in Grommunio4S ist sofort erkennbar als NC config, wenn man NC oder auch OC kennt. Also typischer Aufbau.

 

[Andy+]

kein "Hochladen in die NC" aus der GRO-WEB-APP.

Damit ist es unbrauchbar. Da gibt es noch einiges zu optimieren, jedenfalls hat das in K4S funktioniert.

In der Gro WebAPP geht die WebDAV Anbindung direkt auf die Sources jedenfalls astrein in beide Richtungen ohne NC oder OC.

 

[491810]

Die config in Grommunio4S ist sofort erkennbar als NC config, wenn man NC oder auch OC kennt. Also typischer Aufbau.

Was ist denn soooo schwierig, mir Deine config - die persönlichen Daten eben neutralisiert - kurz zu posten?

 

[Andy+]

Ich habe ja nicht gesagt, das wäre ein Problem

/var/lib/grommunio-files/config/config.php

<?php
$CONFIG = array (
  'overwritewebroot' => '/files',
  'datadirectory' => '/var/lib/grommunio-files/data',
  'logfile' => '/var/log/grommunio-files/files.log',
  'theme' => 'theme-grommunio',
  'logtimezone' => 'UTC',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/share/grommunio-files/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/lib/grommunio-files/apps-external',
      'url' => '/apps-external',
      'writable' => true,
    ),
  ),
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => true,
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'upgrade.disable-web' => true,
  'upgrade.automatic-app-update' => true,
  'updater.server.url' => '127.0.0.1',
  'integrity.check.disabled' => true,
  'updatechecker' => false,
  'has_internet_connection' => false,
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'secret' => 'yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => 'subdomian.domain.dl',
    2 => 'domain.dl',
    3 => 'mail.domain.dl',
    4 => 'VM-IP',
    5 => 'subdomian.domain.de', (eine weitere für die Testinstallation)
  ),
  'dbtype' => 'mysql',
  'version' => '25.0.4.1',
  'overwrite.cli.url' => 'http://localhost/files',
  'dbname' => 'grofiles',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'grofiles',
  'dbpassword' => 'grofiles',
  'installed' => true,
  'instanceid' => 'zzzzzzzzzzzzzzzzzzzz',
  'user_backends' =>
  array (
    0 =>
    array (
      'arguments' =>
      array (
        0 => 'https://subdomian.domain.dl/dav',
      ),
      'class' => '\\OCA\\UserExternal\\BasicAuth',
    ),
  ),
  'mail_from_address' => 'admin',
  'mail_smtpmode' => 'sendmail',
  'mail_sendmailmode' => 'smtp',
  'mail_domain' => 'domain.dl',
  'mail_smtphost' => 'localhost',
  'mail_smtpport' => '25',
  'csrf.disabled' => true,
);

 

[Andy+]

Ich habe wohl einen für mich einfachen Weg gefunden, den gesamten Inhalt eines Postfaches in eine neue Installation zu transferieren, welche fertig eingerichtet sein sollte, einschliesslich der User. Jedes Postfach allerdings getrennt:

1. Export mit Outlook, oberste Ebene, in eine Name.pst
2. Hochladen der PST in die neue Installation in zB. /usr/local/share/Name.pst
3. über Konsole in das Verzeichnis springen /usr/local/share/
4. gromox-pff2mt Name.pst | gromox-mt2exm -u target@mailbox.de

Dann finden sich alle Inhalte in der WebAPP in einem Unterordner, dann müssen nur noch die Inhalte verteilt werden, das wars.

 

[491810]

Geil-o-mat. Das spart ja sowas von Arbeit und vor allem Zeit wenn man die Gro nochmal neu aufsetzen darf/muss/will. Danke.

 

[Andy+]

Ich habe das heute morgen getestet, das dauert auch nicht lange, Dank SSD´s. Ich hatte das schon mal getestet, als der Umstieg bevorstand, da gings nicht, weshalb auch immer, daher damals Import auch über Outlook. Jedenfalls ob so oder so, ist das deutlich einfacher gegenüber dem, was da im Gro-Forum so kursiert.

 

[Caramlo]

Ist leider falsch. Das gilt auch für die Grommunio Installation.

Deine Aussage ist ebenso falsch wie wenig informativ.
Mit eben diesen Einstellungen, allerdings ohne "https://meine.maildomain.tld/ vorweg sondern nur den Pfad ohne Domäne klappt der Zugang zumindest bei meiner Installation der Nextcloud auf meiner Synology. Mein Problem basiert auf einem PHP-Problem und nicht am Zugang.

Deine Aussage ist vermutlich nur richtig hinsichtlich einer Nextcloud Installation direkt auf der GRO-VM mittels grommunio-files.
Vielleicht aber auch da nicht, da müsste man sich den Web-Dav Pfad anschauen, der in der VM-internen Nextcloud angegeben ist. Da ich diesen Ansatz nicht verfolge, da ich ja eine funktionierende Nextcloud habe, kann ich dazu nichts beitragen.

Ich halte nichts von pauschalisierten Aussagen, die ohne Wissen der Installationen anderer User getätigt werden. Da sollte man auf pauschale Beiträge, die auf Halbwissen basieren, verzichten.
So halte ich das zumindest.

 

[Andy+]

Du musst die Beiträge in der Abfolge sehen, der Post allein bringt das auch nicht.

Ich hatte bis gestern gedacht, dass man für die WebDAV-Adresse, egal, ob nun Nextcloud, Owncloud, Gro-NC aus der jeweiligen Instanz und im Dateimodus unten links die Einstellungen übernehmen kann, damit die jeweilige Anbindung im Files-Plugin funktioniert. Dem ist nicht so, @FricklerAtHome hat den Hinweis gegeben und bei mir funktioniert es wie folgt

Mit nativem Nextcloud, mit https://DNS-zur-Nextcloudinstanz und path
/nextcloud/remote.php/webdav/

Mit nativem Owncloud, mit https://DNS-zur-Owncloudinstanz und path
/owncloud/remote.php/webdav/

Mit Grommunio, mit https://DNS-zur-Grommunio-NC-Instanz und path
/files/remote.php/webdav/

Mit einem sehr wichtigen Unterschied, den ich nun auch gelernt habe. Während es für die Einbindung einer nativen Nextcloud oder Owncloud Instanz egal ist, mit welcher Adresse die WebAPP geöffnet wurde, also mit IP oder irgendeine DNS, Ist es bei der Einbindung der Grommunio-NC Instanz in das Plugin zwingend, dass die WebAPP mit der in der Grommunio-Installation hinterlegten subdomain.domain.dl geöffnet wird. Nur dann und nur mit dieser Einstellung läuft das.

Das ist nicht unbedingt schön, dafür selten. Dafür sind das oben nun Fakten, es kann jeder für seine Umgebung interpretieren, was er will.

 

[FricklerAtHome]

HINWEIS:

Unterschiede zwischen GRO und KOPA:

GRO ist deutlich für einen größeren und verteilten Einsatz konzipiert. So kann eine nach außen als Einheit gesehene Instanz physikalisch auch aus mehreren Servern in unterschiedlichen Netzwerken (und damit auch IP4 Adressbereichen) bestehen. IP6 muss deshalb intern eingeschaltet bleiben. Damit dies funktioniert brauchen alle Unterinstanzen auch einen FullQualifiedDomainName (FQDN) der zumindest in einem für alle erreichbaren DNS Verzeichnis erreichbar ist. --- Auf die Funktionalität von Einträgen in Host-Dateien ist deshalb kein Verlass! Das kann fuktionieren, muss es aber nicht.
Ich betreibe in meinem Heimnetz eine DNS Kaskade. Alle Clients nutzen primär den Synology DNS Server der zusammen mit dem Synology Directory quasi ein ActiveDirectory abbildet. Das stellt auch die Nutzerrechte auf die Synology-Ordnerfreigaben etc. sicher. Alle DNS Anfragen die vom Syno-DNS nicht beantwortet werden können landen bei einer ADGuard Instanz. Das dient als Sicherheits-Modul für den Zugriff in die weite Welt.
In der weiten Welt besitze ich eine Domäne (nennen wir sie "meine-welt.de") mit aktuell 5 Subdomänen. Per dynDNS sind diese FQDN Adressen weltweit zu meiner extern sichtbaren IP Adresse auflösend. Ruft also jemand im Internet z.B. "daten.meine-welt.de" per DNS auf, bekommt er meine aktuelle externe IP im Internet angeboten. Das nutzt aber noch nichts, da bei mir auf keiner der Adressen ein Standartport (zb.: 443 oder 80) geöffnet ist. Kennt der Client den richtigen Port wird er mittels Syno-Reverse-Proxy und abgesichert durch let's encrypt an den entsprechenden internen Serverdienst weitergeleitet. Damit für interne Clients die ganze Kaskade zur Namensauflösung nicht notwendig ist, gibt es im Syno-DNS-Server für jeden der Serverdienste entsprechende Zoneneinträge. Damit kann bereits intern ein FQDN für jede Maschine / Server bereitgestellt werden. Auf diesen ist in der Regel auch ein eigen erstelltes Zertifikat mit CA eingerichtet.
Unter GRO ist diese interne DNS Auflösung wichtig da ansonsten MAPI für die Win-Outlook-Clients nicht zuverlässig funktioniert (nicht nur das Autodiscover für die Anmeldung).
Bei Tests und Rumprobieren sollten also immer FQDN genutzt werden und nicht die Direktansprache mittels IP-Adresse. das ist auch für die Funktionalität der weiteren Dienste wie CHAT, MEET, OPENOFFICE und ARCHIVE wichtig! Für Testsysteme stelle ich lediglich entsprechende Einträge im Syno-DNS bereit.

Näheres auch in WalterH's Empfehlungen

 

[FricklerAtHome]

@Andy+

es ist sogar noch etwas komplexer. So wie du deine Einstellungen darstellst

Mit nativem Nextcloud, mit https://DNS-zur-Nextcloudinstanz und path
/nextcloud/remote.php/webdav/

Mit nativem Owncloud, mit https://DNS-zur-Owncloudinstanz und path
/owncloud/remote.php/webdav/

liegen deine nextcloud und owncloud theoretisch oder auch real in einer einzigen realen Adresse Https://DNS zu DIR/ als Unterverweis. Deshalb musst du /nextcloud.... bzw. /owncloud.... vor /remote.php/webdav nutzen (selber Basis-Server mit entsprechenden instanzen?). Bei mir laufen alle Serverdienste solitär als VM mit eigener internen und externen FQDN. Hier reicht dann lediglich ein /remote.php/webdav.
In der GRO Instanz läuft die GRO-Nextcloud aber wie bei deinen NC / OC Instanzen als Unterdienst mit der Kennung "files". Deshalb ist dort die Kennung /files/remote.php/webdav notwendig.
So wie ich deinen Zugriff aus dem Internet glaube verstanden zu haben rufst du immer die gleich https://ADRESSE auf ergänzt du diese nur mit entsprechenden /SERVERDIENST/ Ergänzungen, also zum Beispiel https://ADRESSE.dl/nextcloud/remote.php/webdav. Ich halte das für extrem unsicher!
Mein Zugriff aus dem Internet folgt immer den Schema https://subdomain.meine-adresse.dl:mein-dezidierter-Port/! Anschließend sortiert mir der Reverse-Proxy alles in die richtige Auflösung und sichert das mit Lets Encrypt ab. Da brauche ich dann halt für NC oder OC nur noch /remote.php/webdav und den richtigen PORT! ---- Bei der GRO-NC kommt jetzt eine Besonderheit hinzu. Sie läuft tatsächlich als Unterdienst des FQDN der GRO. Und deshalb muss dann der /Serverdienst/ also /files/ ergänzt werden. ---- Ich hoffe das ist nun verständlich!

 

[Andy+]

Was Du beschreibst, stimmt alles. Die Frage ist nur, wie das dann passend abgebildet werden soll, ggf. über zusätzliche Hardware? Offen gesagt, bin ich da etwas zu wenig der Experte.

 

[Vogi]

Hi zusammen,

ich habe bisher nur das Files Plugin von "grommunio web" ohne Nextcloud/Files Installation genutzt und mich damit mit dem WebDAV Server der Synology verbunden. Das klappt bei mir leider nicht mehr.

Unter /var/log/phpo-fpm.log finde ich folgenden Eintrag:

[10-Apr-2023 11:43:57] WARNING: [pool grommunio-web-pool] child 14604 said into stderr: "NOTICE: PHP message: [ERROR][AccountStore] Unable to update the account to as FILES_PASSWORD_IV/FILES_PASSWORD_KEY is not set"
[10-Apr-2023 11:45:00] WARNING: [pool grommunio-web-pool] child 15464 said into stderr: "NOTICE: PHP message: [ERROR][AccountStore] Account check failed: Unknown error"

Funktioniert das bei Euch noch?
Ich hatte auch kurz bevor mir das aufegafllen ist nen Stromausfall bei dem die Synology mit weg war... bevor ich mich da jetzt auf die Suche mache, würde es mit viel Arbeit sparen, wenn es mit dem Synology WebDAV Server gar nix zu tun hat.

Danke Euch!

 

[Andy+]

Das ist freilich Mist. Wenn Du in der WebAPP "Dateien" und nicht "Files" meinst, dann läuft das noch.



Ich habe darüber auch eine WebDAV Verbindung mit dem Host/DS und das läuft wie gewohnt.

Hast Du vlt. aktuelle Updates eingespielt? Ist da auch nichts blockiert von der Sicherheit? Neuanlegen bringt nichts?

 

[FricklerAtHome]

Versuch es mal mit dem Zurücksetzen auf Werkseinstellungen unter Einstellungen "Dateien".
Danach ggf. den Client beenden und auch die GRO neu starten.