Nextcloud mit Collabora

[maalik]

@Martinus1977: Wenn ich im RP localhost mit http anspreche, dann habe ich mein altes Problem, dass nichtmal der Ladebalken auftaucht. Der Fehler im Log erscheint dennoch!
Off-Topic: Gibt es eine Anleitung zum Wildcard-Zertifikat erstellen und dann importieren? Mich nervt es langsam, für jede Subdomain ein eigenes Zertifikat zu erstellen. Leider bietet Synology noch nicht die Option ein Let's Encrypt Wildcard-Zertifikat zu erstellen

@blinddark: Scroll mal so auf Seite 1-3 rum. Der offizielle Container startet aber stürzt nach ein paar Sekunden ab. Bisher hat es noch niemand geschafft diesen zum laufen zu kriegen.

 

[Martinus1977]

Ich meint auch nicht, dass http der richtige weg für den localhost ist, das muss schon https sein! Ich bekomme nur deinen Fehler in meinem log, wenn ich das per http mache (den Reverse)

OffTopic: Zur Wildcard: das nervt total. Zuerst musst du auf deinem externen vhost das aktuelle letsencrypt installieren, dann noch einen DNS eintrag ändern, dann das Zertifikat exportieren, in die einzelnen bestandteile zerlegen (also in privat.key, zert-ca.cert und zert.cert) und die dann in der Synology importieren.
Das ist so nervig, dass ich da lieber mit der Synology einzelne Zertifikate erstelle. War bei mir ein Test, ob es überhaupt funktioniert. Jetzt sieht es aber fast so aus, als könnte das noch zumindest für collabora den Unterschied machen.

 

[maalik]

Ich meint auch nicht, dass http der richtige weg für den localhost ist, das muss schon https sein!

Das hatte ich schon verstanden. Ich habe es nur mal als Test ausprobiert. Ich denke aber nicht, dass das Zertifikat die Rolle spielt.

Mein Problem tritt vor der loolwsd.xml auf: Wenn ich meine Domain als Host komplett rausschmeiße, dann bekomme ich die gleiche Fehlermeldung. Entweder harmoniert also etwas an meinem System nicht mit Collabora, oder es liegt doch an Zertifikat und/oder Reverse Proxy.
Hat sich denn jemand von Euch mal mit dem eigenen Zertifikat von Collabora beschäftigt? Also ob das irgendeine Rolle spielt? Habt ihr da Eure eigenen Pfade eingetragen?


Hier mal mein Log nach dem Start. Irgendetwas auffällig?

2018-11-21 10:30:50	stdout	office version details: { "ProductName": "Collabora Office", "ProductVersion": "5.1", "ProductExtension": ".10.21", "BuildId": "e91d2c2d59b035e40bdefac5fe06fb210180ed86" }
2018-11-21 10:30:48	stdout	loolforkit version details: 2.0.4 - 2.0.4
2018-11-21 10:30:48	stdout	Getting CA Private Key
2018-11-21 10:30:48	stdout	subject=/C=CA/ST=BCN/L=Barcelona/O=Dummy Authority/CN=collabora
2018-11-21 10:30:48	stdout	Signature ok
2018-11-21 10:30:48	stdout	e is 65537 (0x10001)
2018-11-21 10:30:48	stdout	.....+++
2018-11-21 10:30:48	stdout	......+++
2018-11-21 10:30:48	stdout	Generating RSA private key, 2048 bit long modulus
2018-11-21 10:30:48	stdout	e is 65537 (0x10001)
2018-11-21 10:30:48	stdout	........................................................+++
2018-11-21 10:30:48	stdout	...............................+++
2018-11-21 10:30:48	stdout	Generating RSA private key, 2048 bit long modulus
2018-11-21 10:30:48	stdout	Running init scripts...

Bei einem Neustart des Containers (nicht Start/Stop) bekomme ich zudem am Ende noch das hier:

2018-11-21 10:34:27	stdout	kit-00041-0041 10:34:27.388325 [ loolkit ] ERR  Poco Exception: Exception: symlink() failed| kit/Kit.cpp:1738
2018-11-21 10:34:27	stdout	kit-00041-0041 10:34:27.388121 [ loolkit ] ERR  symlink("../lo","/opt/lool/child-roots/41/opt/collaboraoffice5.1") failed (errno: File exists)| kit/Kit.cpp:268

 

[maalik]

Es tut sich was! Oh man, wie doof.
Ich hatte heute mal die Idee, nicht über meine Cloud auf ein Dokument zuzugreifen, sondern über einen freigegebenen Link. Da kam dann glücklicherweise die Fehlermeldung, dass die Antwort von office.domain.de zu lange gedauert hat. Also dachte ich mir, da muss doch was am Reverse Proxy nicht stimmen.
Ich habe dann im Reverse Proxy als Ziel nicht localhost, sondern die IP, also 192.168.1.11 eingetragen. Seitdem funktioniert es, dass zumindest mal Collabora lädt. Ich bekomme nun eine "Es konnte keine Verbindung zum Dokument aufgebaut werden"-Fehlermeldung.
Naja, immerhin.

Im Log steht folgendes:

2018-11-22 20:43:11	stdout	wsd-00029-0031 20:43:11.817555 [ client_req_hdl ] WRN  WOPI host did not pass optional access_token_ttl| wsd/FileServer.cpp:255
2018-11-22 20:43:11	stdout	wsd-00029-0032 20:43:11.115774 [ client_ws_0003 ] ERR  ClientRequestHandler::handleClientRequest: BadRequestException: Failed to convert and send file.| wsd/LOOLWSD.cpp:1240

 

[abrocksi]

Und wenn man soweit gekommen ist wie maalik, dann verzweifelt man an der Fehlermeldung. Ich glaube, das hat mit dem Storage driver (= Device mapper) unter Docker zu tun. Siehe Post #74 in diesem Threat.

cheers,
abrocksi

 

[maalik]

Aber warum geht es dann bei manchen und bei manchen nicht?

 

[maalik]

Gibt's was neues an der Collabora-Front? Leider bin ich bis dato nicht weitergekommen

 

[Martinus1977]

Nichts wirklich neues. Bei mir ist weiterhin der Stand, dass ich Dokumente (zu 99% sind das .odt) öffnen kann. Die Performance ist hier aber eher unterirdisch. Bishweilen kommt es vor, dass ich hier scheinbar in ein timeout renne beim ersten öffnen. Gehe ich zurück und öffne es erneut, ist alles schick und zügig lesbar.
Die Thematik speichern eines Dokuments habe ich nach wie vor nicht gelöst.
In der Zwischenzeit hatte ich auch mal versucht, mir einen virtuellen Ubuntuserver zu installieren und dort collabora via Docker zu installieren - ich bin kläglich gescheitert. So wie ich das sehe, dürfte dieses jedoch die beste Option sein, nur fehlt mir hier zu Zeit mich dort hineinzudenken. Ich hab in Erinnerung, dass das hier einer schon gemacht hat. Vielleicht kann das ja jemand aus dem Ärmel schütteln und hier dokumentieren.
Bzgl device-mapper: ja, irgendwas stimmt da glaube ich wirklich nicht, allerdings kann der (die/das???) Synology Docker eigentlich das Format AUFS (habe aber hier schon wieder zu wenig Plan...)
Somit: Stagnation

 

[maalik]

Ich bin inzwischen auch auf OnlyOffice umgestiegen. Vor allem, da ich eh kaum mit OpenDocument-Dateiformaten arbeite und OnlyOffice dort den Fokus gelegt hat.
Installation war kinderleicht und ohne Probleme.

 

[Martinus1977]

OnlyOffice ist nett, zerhackt mir aber meine .odt Dateien, in denen Logo mit Kopf- und Fußzeile sind.
Einzige Lösung die für mich funktioniert, ist die Installation einer VM (Ubuntu 18.04 LTE), innerhalb derer ich dann wiederum Docker installiert habe und in diesem Dockercontainer läuf dann Collabora. Wie bescheuert das ist, kann ich kaum in Worte fassen, aber es funktioniert.
Performance geht anders, aber es erfüllt seinen Zweck. Ich kann jegliche Office Dokumente öffnen, selbst aus der Nextcloud App (Android & iOS) funktioniert das reibungslos. Jeden Tag will man damit nicht arbeiten müssen, aber um "mal eben gerade" was anzupassen, ist das nutzbar.
Die 918+ macht das recht klaglos mit, Prozessor ist hier nicht wirklich die Limitierung, eher der Ram, der so zu 90% voll ist. Beizeiten steht da RAM-Ausbau an, mal sehen ob das dann einen Schub bringt. (Beizeiten ist zum Glück ein dehnbarer Begriff, kann Monate dauern bis ich dafür Zeit finde).

 

[maalik]

Ich denke für .odt- Dateien ist Collabora besser, das stimmt. Ansonsten war es mir aber auch zu kompliziert, das hinzubekommen...

 

[Jofe]

Hallo,

ich möchte diesen Beitrag noch einmal aktivieren. Seit Tagen versuche ich Collabora Online lauffähig zu machen. Ohne Erfolg. Doch der Reihe nach:

Meine Konfiguration:
Auf meiner DS-718+ läuft Docker.
Darin habe ich den MariaDB und nextcloud-Container installiert.
Auf dem NAS habe ich den Reverse Proxy aktiviert und die Port 80 und 443 werden an den nextcloud container weitergeleitet.
Meine Domain, ich nenne sie hier next.meinedomain.de, zeigt auf mein NAS.
--> Im Prinzip habe ich alles nach dieser Anleitung von inidiBit (besten Dank!) eingerichtet: https://indibit.de/synology-docker-nextcloud-installieren/
--> nextcloud funktioniert top und ist über next.meinedomain.de errreichbar.
--> So weit so gut.

Nun kommt der knifflige Part – collabora online:
- Hier lade ich mir das Image collabora/code in Docker und aktiviere den Container.
- Dabei verwende ich folgende Parameter:
Netzwerk: bridge
Port: 9980/9980
Umgebungsvariable: domain = next.meinedomain.de
- Unter nextcloud:
- hier installiere ich die App collabora online
- unter Einstellungen/collabora online trage ich im Feld URL next.meinedomain.de:9980 ein.

Das Ergebnis:
- Ich kann in nextcloud Office-Dokumente anlegen, diese aber nicht bearbeiten.
- Klicke ich ein Office-Dokument an so kommt die Fehlermeldung "Collabora Online konnte nicht geladen werden - Bitte versuche es später noch einmal".

Kann mir jemand weiterhelfen?


Gruß
Joe

 

[Jofe]

Ergänzung:

in der Zwischenzeit habe ich selbst weiterexpirmentiert:

Ich habe das Dockerimage von orboan/collabora installiert.Und dadurch hat sich grundlegendes geändert.

Mit https://office.meinedomain.de erhalte ich ein "ok" des Collabora-Online-Servers.
Im ReverseProxy von Synology leite ich entsprechend die Ports 443 und 9980 der office.domain.de auf den Container von Collabora um.

Wenn ich jetzt auf ein Office-Dokument in der nextcloud klicke öffnet sich Collabora. Das Menü von Collabora ist sichtbar.
Allerdings erhalte ich die Meldung:



--> Fehlermeldung: "Es konnte kein Verbindung zu Ihrem Dokument hergestellt werden. Bitte versuchen Sie es erneut."

Hat mir jemand einen Tipp, an was das liegen könnte?

Gruß
Joe

 

[Martinus1977]

Ich habe das über Docker der Synology komplett in den Sack gehauen. Irgendwas fehlte immer, irgendwas lief instabil,...

Einzige Lösung die ich für mich jetzt funktional umgesetzt habe:

Man installiere eine VM (in meinem Fall Ubuntu Server), innerhalb dieser VM habe ich dann Docker installiert und in diesem Docker habe ich dann Collabora laufen.

Meiner Meinung nach hat Synology bei Ihrer Docker-Implementation irgendeinen Schrott verzapft, den man auf normalem Wege nicht lösen kann. Deshalb dieser - durchaus bescheuerte und Ressourcen-Intensive Weg - oder wie mein Mathelehrer immer zu sagen pflegte: mit dem Nagel vom Knie ins Auge - but: it works

 

[Artur190]

Ergänzung:

in der Zwischenzeit habe ich selbst weiterexpirmentiert:

Ich habe das Dockerimage von orboan/collabora installiert.Und dadurch hat sich grundlegendes geändert.

Mit https://office.meinedomain.de erhalte ich ein "ok" des Collabora-Online-Servers.
Im ReverseProxy von Synology leite ich entsprechend die Ports 443 und 9980 der office.domain.de auf den Container von Collabora um.

Wenn ich jetzt auf ein Office-Dokument in der nextcloud klicke öffnet sich Collabora. Das Menü von Collabora ist sichtbar.
Allerdings erhalte ich die Meldung:

Anhang anzeigen 49354

--> Fehlermeldung: "Es konnte kein Verbindung zu Ihrem Dokument hergestellt werden. Bitte versuchen Sie es erneut."

Hat mir jemand einen Tipp, an was das liegen könnte?

Gruß
Joe

Hast du es ans laufen gebracht?

 

[Penthys]

Bei mir läuft es jetzt mit NextCloud und LibreOffice im Synology Docker. Die Lösung ist für diejenigen, bei denen das Office/Collabora im Docker wegen seccomp nicht läuft. Da seccomp im Kernel present sein muss, kann nur Synology das aktivieren. In der Datei /etc/loolwsd/loolwsd.xml lässt sich seccomp aber deaktivieren. Dazu den Abschnitt:

<security desc="Altering these defaults potentially opens you to significant risk">
<!-- 23-07-2018 -->
<!-- Deactivating seccomp because the VM which runs on top of virtuozzo doesn't supports the sec kernel module. -->
<seccomp desc="Should we use the seccomp system call filtering." type="bool" default="true">false</seccomp>
<capabilities desc="Should we require capabilities to isolate processes into chroot jails" type="bool" default="true">true</capabilities>
</security>

suchen und in der seccomp Zeile das true in false ändern, so wie im obigen Beispiel ausgeführt.

Danach den Container neu starten. Es meckert zwar immer noch das fehlende seccomp an, aber sieht auch, dass es das eh nicht verwenden soll und macht weiter.

Mit originalen aktuellen LibreOffice Image läuft jetzt alles wunderbar aber sollte für das Collabora Image auch so funktionieren.

 

[3247]

Ich habe das ganze mit dem offiziellen Docker-Image und nur mit Konfigurationsoptionen bei mir zum Laufen bekommen (zuerst auf einer verstorbenen DS1515+, dann nach der Migration auf einer DS1621+).

Die notwendigen Änderungen an der /etc/loolwsd/loolwsd.xml lassen sich auch über Umgebungsvariablen setzen. Neben Seccomp schalte ich auch die Capabilities aus, damit das Log nicht mit Fehlermeldungen zugemüllt wird.

Weil das ganze ohnehin hinter dem Reverse Proxy läuft, benötigt es im Container auch kein SSL/TLS. Wenn jemand die Daten innerhalb der DS abgreifen kann, habt ihr ganz andere Problem und TLS hilft auch nicht mehr. Also schalte ich das auch ab. Nach extern wird natürlich TLS mit einem von der DS erzeugten Let'sencrypt-Zertifikat verwendet.

Ich starte den Container allerdings nicht über DSM, sondern (zusammen mit Nextcloud, der Datenbank und einem Webcron) über docker-compose über die Kommandozeile, über das DSM müssten sich die Umgebungsvariablen aber genau so setzen lassen. Auszug aus meiner docker-compose.xml - entscheidend ist die Umgebungsvariable "extra_params":

   office:
        image: libreoffice/online
        restart: always
        tty: true
        ports:
            - 9980:9980
        environment:
            - "domain=cloud\\.example\\.org"
            - "server_name=office\\.example\\.org"
            - "DONT_GEN_SSL_CERT=1"
            - "extra_params=--o:security.seccomp=false --o:security.capabilities=false --o:ssl.enable=false --o:ssl.termination=true"

DONT_GEN_SSL_CERT=1 verhindert, dass der Container ein unnötiges SSL-Zertifikat generiert. Sollte keinen Unterschied machen – abgesehen davon, dass der Container dadurch etwas schneller startet.

Die Parameter in extra_params haben folgende Bedeutung:
--o:security.seccomp=false schaltet die Verwendung von Seccomp ab.
--o:security.capabilities=false schaltet die Verwendung von Capabilities ab. Es braucht dann auch kein CAP_ADD mehr.
--o:ssl.enable=false schaltet SSL/TLS im Container ab.
--o:ssl.termination=true sagt dem Container, dass er hinter einem Proxy sitzt, der SSL/TLS macht.

Der laufende Container:


Der Reverse Proxy muss dann entsprechend mit HTTPS extern und HTTP intern konfiguriert werden, außerdem müssen zwei Header gesetzt werden:

 

[Flooney09]

Hallo zusammen,

ich hoffe hier kann mir jemand weiterhelfen.
Ich habe nun Nextcloud und Collabora jeweils als Docker laufen und kann auch den Collabora Server verbinden.
Will ich nun jedoch ein Dokument bearbeiten, bleibt es weiß und im Log taucht folgende Meldung auf:
wsd-00006-00029 2021-05-19 16:26:37.185465 [ websrv_poll ] WRN convert-to: Requesting address is denied: 79.XXX.XXX.XXX| wsd/LOOLWSD.cpp:2391
Habe mich bereits in sämtlichen Foren umgeschaut, finde aber keine richtige Lösung dazu.
Die Umsetzung habe ich befolgt wie von 3247 beschrieben.

 

[Messiah]

Ich habe das ganze mit dem offiziellen Docker-Image und nur mit Konfigurationsoptionen bei mir zum Laufen bekommen (zuerst auf einer verstorbenen DS1515+, dann nach der Migration auf einer DS1621+).

Die notwendigen Änderungen an der /etc/loolwsd/loolwsd.xml lassen sich auch über Umgebungsvariablen setzen. Neben Seccomp schalte ich auch die Capabilities aus, damit das Log nicht mit Fehlermeldungen zugemüllt wird.

Weil das ganze ohnehin hinter dem Reverse Proxy läuft, benötigt es im Container auch kein SSL/TLS. Wenn jemand die Daten innerhalb der DS abgreifen kann, habt ihr ganz andere Problem und TLS hilft auch nicht mehr. Also schalte ich das auch ab. Nach extern wird natürlich TLS mit einem von der DS erzeugten Let'sencrypt-Zertifikat verwendet.

Ich starte den Container allerdings nicht über DSM, sondern (zusammen mit Nextcloud, der Datenbank und einem Webcron) über docker-compose über die Kommandozeile, über das DSM müssten sich die Umgebungsvariablen aber genau so setzen lassen. Auszug aus meiner docker-compose.xml - entscheidend ist die Umgebungsvariable "extra_params":

   office:
        image: libreoffice/online
        restart: always
        tty: true
        ports:
            - 9980:9980
        environment:
            - "domain=cloud\\.example\\.org"
            - "server_name=office\\.example\\.org"
            - "DONT_GEN_SSL_CERT=1"
            - "extra_params=--o:security.seccomp=false --o:security.capabilities=false --o:ssl.enable=false --o:ssl.termination=true"

DONT_GEN_SSL_CERT=1 verhindert, dass der Container ein unnötiges SSL-Zertifikat generiert. Sollte keinen Unterschied machen – abgesehen davon, dass der Container dadurch etwas schneller startet.

Die Parameter in extra_params haben folgende Bedeutung:
--o:security.seccomp=false schaltet die Verwendung von Seccomp ab.
--o:security.capabilities=false schaltet die Verwendung von Capabilities ab. Es braucht dann auch kein CAP_ADD mehr.
--o:ssl.enable=false schaltet SSL/TLS im Container ab.
--o:ssl.termination=true sagt dem Container, dass er hinter einem Proxy sitzt, der SSL/TLS macht.

Der laufende Container:


Der Reverse Proxy muss dann entsprechend mit HTTPS extern und HTTP intern konfiguriert werden, außerdem müssen zwei Header gesetzt werden:

@3247 Danke für die Anleitung, hat auf Anhieb funktioniert.
Ich habe noch Verständnisfragen. Warum muss ich LibreOffice eine Domain geben? Nextcloud muss doch nicht über extern auf den Office Server zugreifen. Bei der Verbindung von NC zu MariaDB, benutze ich doch auch die lokale Adresse.

Gruß Messiah

 

[abrocksi]

Hi Messiah,

warum das so sein muss, kann ich Dir nicht beantworten. Ich kann aber berichten, dass es bei der Alternative zu Collabora, Onlyoffice, ebenfalls nur mit einer Subdomain klappt. Vermutlich von den Entwicklern so gewünscht und gecoded.

cheers,
abrocksi