CollaboraOnline Docker an Nextcloud anbinden

Hallo zusammen,

bei meinem Versuch, CollaboraOnline als Docker-Container (CODE 3.2) an die Nextcloud (bei mir auch Docker-Host) anzubinden, hängt Code beim Aufrufen eines Dokuments mit dem Hinweis “Initialisierung” und anschließendem grauem Blatt und ausgegrauten Menüpunkten (des CollaboraOnlineOffice) und dann “Es konnte keine Verbindung mit dem Dokument hergestellt werden …”, wenn ich die Nextcloud (in orange) aus dem WLAN (blau) oder von zu Hause (rot) aufrufe. Aus dem grünen Netz dagegen kann ich das Dokument bearbeiten.
Installiert habe ich das Ganze nach dieser Anleitung: https://www.collaboraoffice.com/code/
Die Nextcloud in orange ist unter nextcloud.schuldomain.de erreichbar und Collabora unter office.schuldomain.de. Das Letsencrypt-Zertifikat gilt für beide und wurde auch in den Einstellungen des Apache so eingetragen.
Abgesehen davon, dass ich das mit dem Docker nicht ganz durchschaue, verstehe ich nicht, warum es aus dem grünen Netz funktioniert und aus blau oder rot nicht.

Was macht hier den Unterschied des Zugangs aus?

Schöne Grüße

Christian

Hi.
Ich hatte eine ähnliche Meldung neulich auch mal, als ich versucht, die domain unter einem Namen zu erreichen, der nicht bei dem docker-Befehl eingetragen war, für den das Zertifikat aber dennoch gültig war. Dann kommt hier die Meldung:

Unautorisierter WOPI-Host. Bitte versuchen Sie es später noch einmal und melden Sie sich bei Ihrem Administrator, falls das Problem weiterhin besteht.

Man muss die NextCloud also jetzt immer mit dem richtigen Namen ansprechen – und zwar genau der, mit dem du den docker-container gestartet hatttest. Ich bin übrigens nach dieser Anleitung vorgegangen:

Schönen Gruß,
Michael

Hallo Michael,

diese Anleitung bin ich nochmal Schritt für Schritt durchgegangen. Das Ergebnis sieht immer noch so aus, dass ich von zu Hause aus - also über “rot” vom IPFire - nicht zum Editieren der Dokumente komme.
Die Logs vom docker des Collabora sehen so aus:

wsd-00025-00026 07:00:27.956822 [ prisoner_poll ] WRN ForKit not responsive for 7996 ms forking 1 children. Resetting.| wsd/LOOLWSD.cpp:371
wsd-00025-00034 07:00:33.484804 [ websrv_poll ] WRN WOPI host did not pass optional access_token_ttl| wsd/FileServer.cpp:540
wsd-00025-00039 07:00:34.505416 [ docbroker_001 ] WRN Missing JSON property [WatermarkText]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.505614 [ docbroker_001 ] WRN Missing JSON property [HidePrintOption]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.505721 [ docbroker_001 ] WRN Missing JSON property [HideSaveOption]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.505827 [ docbroker_001 ] WRN Missing JSON property [HideExportOption]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.505941 [ docbroker_001 ] WRN Missing JSON property [EnableOwnerTermination]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.506041 [ docbroker_001 ] WRN Missing JSON property [DisablePrint]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.506140 [ docbroker_001 ] WRN Missing JSON property [DisableExport]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.506237 [ docbroker_001 ] WRN Missing JSON property [DisableCopy]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:34.506351 [ docbroker_001 ] WRN Missing JSON property [DisableInactiveMessages]| wsd/Storage.cpp:421
wsd-00025-00039 07:00:47.535778 [ docbroker_001 ] WRN Attempted ping on non-upgraded websocket!| ./net/WebSocketHandler.hpp:280
kit-00036-00040 07:00:47.536180 [ lokit_001 ] WRN Skipping unload on incomplete view.| kit/ChildSession.cpp:72
kit-00036-00040 07:00:47.536344 [ lokit_001 ] ERR No socket associated with WebSocketHandler 0x0xe3a6150| ./net/WebSocketHandler.hpp:100
wsd-00025-00026 07:00:48.044848 [ prisoner_poll ] WRN Waking up dead poll thread [docbroker_001], started: true, finished: true| ./net/Socket.hpp:512
wsd-00025-00026 07:00:48.045645 [ prisoner_poll ] WRN Waking up dead poll thread [docbroker_001], started: true, finished: true| ./net/Socket.hpp:512
wsd-00025-00026 07:00:48.046519 [ prisoner_poll ] WRN Waking up dead poll thread [docbroker_001], started: false, finished: true| ./net/Socket.hpp:512

Zur Sicherheit habe ich vom virtuellen Client im grünen Netz die Nextcloud aufgerufen, von dort funktioniert das Editieren.

Jetzt erscheinen folgende Fehlermeldungen nicht mehr:

WRN Skipping unload on incomplete view.| kit/ChildSession.cpp:72
kit-00036-00040 07:00:47.536344 [ lokit_001 ] ERR No socket associated with WebSocketHandler 0x0xe3a6150| ./net/WebSocketHandler.hpp:100
wsd-00025-00026 07:00:48.044848 [ prisoner_poll ] WRN Waking up dead poll thread [docbroker_001], started: true, finished: true| ./net/Socket.hpp:512

In welchen Logs könnte ich denn weiter nach der Ursache suchen?

Edit: Auf dem IPFire nutze ich pound, um die Anfragen an nextcloud.-.-, office.-.- und server.-.- richtig weiterzuleiten.
Edit: Braucht es eine Firewallregel auf dem IPFire, damit es läuft? Nach meinem Verständnis ruft die Nextcloud-Instanz das Collabora aber auf demselben Rechner (im Docker-Container) auf, hier geht doch gar nichts über das Netz.

VG Christian

Hi Christian.
Hmmm … da kann ich leider nicht viel zu sagen. Hast du’s schon in der Collabora-Community versucht?
Ich sehe das so wie du: Der docker-Container läuft auf dem gleichen Host wie die Nextcloud und wird lokal über Port 9980 aufgerufen.
Dennoch: Ich habe hier eine Firewall-Regel im IPFire auf Port 9980 –> NextCloud (DMZ, 172.16.17.2) gesetzt. Du kannst es ja mal damit versuchen. Wenn es von GRÜN aus bereits funktioniert …

Schönen Gruß,
MIchael

Hallo Michael,

die Firewall-Regel hat leider nichts verändert.
Ich werde mal die Collabora-Community fragen.
Vielen Dank

Schöne Grüße

Christian

Wieder einen Schritt weiter:

Es liegt an der Konfiguration von pound auf dem IPFire. Nachdem ich die pound-Konfiguration für https://office.-.- gelöscht habe und auf dem Coova die IP-Adresse für office.-.- in /etc/hosts eingetragen habe, kann mein virtueller Client aus dem “WLAN”-Netz auch Dokumente öffnen.
Jetzt muss nur noch der restliche Verkehr aus rot ungestört an pound vorbei kommen.

Geschafft. Nach Hinweisen in einem Forum (leider den Link nicht mehr gefunden) kann pound als reverse proxy nicht mit Websockets umgehen. Was Websockets sind weiß ich auch nicht recht.
Jedenfalls habe ich pound durch HAproxy ersetzt. Der kann die https-Anfragen ohne das Zertifikat dafür bereit zu halten an den richtigen Server weiterleiten (Stichwort: SNI).
Falls jemand an der Konfiguration interessiert sein sollte, kann ich sie hier reinstellen.

1 Like

Hi.
Oh, das ist eine wichtige Information, würde ich sagen!!
Ich habe im Moment POUND noch nicht im produktiven Einsatz, aber wenn es mit HAProxy besser läuft, werde ich Pound erst gar nicht nutzen. (Zudem wird ja die kommende OPNSense-FW ebenfalls mit HAProxy und nicht mit POUND kommen, nehme ich an.)
Michael

Hi Christian,

ich häng mich mal hier dran:
bei mir sieht es genauso aus: ein host cloud.schule.de, ein host api.schule.de und nach der anleitung https://nextcloud.com/collaboraonline/ vorgegangen.
Ebenso letsencrypt-zerfitikat für beide.
Beide stehen in Orange.
Es gibt ne Firewallregel für je einen, von der Firewall(Orange) zur IP in Orange.

Problem:
Ich komme weder von außen noch von innen an die dokumente, es kommt kurz “Lade Dokumente”, dann dreht sich ein weißer kreis in der Mitte. Irgendwann kommt “ZEitüberschreitung”

Was funktioniert ist:

Ich habe auch noch pound am laufen, weil ich die entsprechende HAProxy-config nicht habe: kannst du mir die zuschicken?

Ich hab vllt. noch was anders als du: die DNS-Auflösung, evtl die Firewall, ich habe auch einen Fehler im apache2-log gefunden, wenn ich /lool/adminws aufgerufen habe… funktioniert das bei euch, bei denen collabora läuft?

VG, Tobias

Hallo Tobias,

  1. zum Fehler beim Aufruf von /lool/adminws: da steht bei mir in den logs: AH01144: No protocol handler was valid for the URL /lool/adminws. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
  2. Meine HAProxy config (/etc/haproxy/haproxy.cfg) hänge ich an (Schuldomain umbenannt haproxy.zip (1,6 KB))
  3. Bei mir läuft die Nextcloud in orange auf einem Ubuntu 16.04 mit Apache-Server und Collabora als Docker-Image auf demselben Host. Der Start des Docker-Images braucht etwas Zeit, nach 1 Minute läuft es aber auf jeden Fall, wie gewünscht. Das Docker-Image wird wie in der Anleitung zu CODE 3.4 gestartet. Die Subdomain office.meineschule.de ist evtl. gar nicht mehr notwendig. Es läuft meines Wissens alles unter demselben Namen nextcloud.meineschule.de

Wahrscheinlich tauchen noch mehr Fragen auf, die ich gerne beantworte.

VG Christian

Hi Christian,

danke für die Tipps. HAProxy hab ich noch nicht umgesetzt

Stimmt. Ich habe einen anderen Server, der eine weltweite IP hat. Dort hat nach längerem hin- und her genau das funktioniert: Ich verwende meineschule.de als Apache Servername und erreiche dort meine cloud, schreibe dort auch den Proxy rein.
Die nextcloud wird unter einem unterverzeichnis erreicht: meineschule.de/cloud.

Dann funktioniert es, aber seltsamerweise nur, wenn ich den interaktiven dockercontainer stop und wieder starte. Beim ersten Start kommen folgende Fehlermeldungen:

...
WRN  Linking/copying files from /opt/collaboraoffice5.3 to /opt/lool/child-roots/bNpQ8SdB6wpRoRXu/lo/ is taking too much time. Enabling verbose link/copy logging at information level.| kit/Kit.cpp:169
...
WRN  ForKit not responsive for 117453 ms forking 1 children. Resetting.| wsd/LOOLWSD.cpp:390
...
[ lokit_001 ] ERR  Failed to load: file:///user/docs/UadyA1LmkfrgqIs9/Daten%20und%20Speicher.ods, error: loadComponentFromURL returned an empty reference| kit/Kit.cpp:1554
[ lokit_001 ] ERR  Failed to get LoKitDocument instance for [file:///user/docs/UadyA1LmkfrgqIs9/Daten%20und%20Speicher.ods].| kit/ChildSession.cpp:370
...
mehr Fehler

Im Frontend kommt dann
grafik

Beim zweiten Starten desselben Containers (STRG+C + docker start -ai container_name) kommt dann

...
WRN  ForKit not responsive for 7800 ms forking 1 children. Resetting.| wsd/LOOLWSD.cpp:390
...
sonst keine Fehler mehr...

und im Client (nextcloud) wird das Dokument ordentlich gezeigt.

Das war jetzt alles noch nicht mal in der linuxmuster.net hinter dem IPFire/pound.

VG, Tobias

So, auch mit HAProxy funktioniert es nun bei mir.

Allerdings hab ich auch Probleme/Dinge festgestellt:

  • hier funktioniert es ohne Neustart des Containers, vermutlich ist mein anderer Server einfach zu langsam beim ersten Start.
  • Alle meine Probleme sind irgendwie gelöst, außer, dass es in den Logs des collabora-Servers noch Fehlermeldungen zur DNS-Auflösung gibt. Auswirkungen sind wohl nur, dass es keine Vorschaubildchen gibt. Das Anzeigen der Dokumente funktioniert.

Juhu!

Vielen Dank, Christian!
Tobias

Hallo.
Als Update & Info … ich habe vorhin ein Update des collabora-docker-Containers eingespielt. Das funktioniert tadellos. Anleitung hier:
https://www.bitblokes.de/collabora-online-libreoffice-nextcloud-docker-code/
(unter " Docker-Version von Collabora Online aktualisieren"). Die Option -e habe ich weggelassen.

Was mir aber auffiel: Collabora öffnet zwar meine eigenen Dokumente problemlos – seit dem Update übrigens auch .docx Dateien ohne Probleme. Aber wenn ich auf geteilte Ordner gehe, weigert sich das Programm zu starten. Das gleiche Verhalten zeigt sich, wenn ich eine Datei unter “Home_auf_Server” anklicke. Offenbar kommt Collabora nicht mit verlinkten Dateien klar!? Ist das bei euch auch so??

Schönen Gruß,
Michael

Nein und ja. In Geteilten Ordnern kann man Dateien mit collabora öffnen. Wenn das nicht ginge wäre ja überhaupt keine Kollaboration möglich!
Und ja: Home_auf_Server eingebundene Daten kann ich tatsächlich auch nicht öffnen.
Wer hat denn onlyoffice am Laufen und kann berichten, ob ein per smb-share eingebundenes LAufwerk wir Home_auf_Server in der Cloud mit onlyoffice funktioniert?
VG, Tobias

Vielleicht liegt’s dran, wie die Dateien geteilt wurden? Stichwort “kann bearbeiten”? :thinking:

Nein, stimmt nicht.
Wenn ich eine DAtei mit “nicht bearbeiten” teile, kann derjenige die DAtei in Collabora öffnen, sieht aber nur noch:
grafik

Ich hijacke den Thread mit folgender Observation: Wenn ich DAteien neu teile, kann ich die fein graunlaren Einstellungen nicht mehr finden, es sieht so aus:
grafik

ist das bei euch auch so?
VG Tobias

Hallo Tobias,
ich habe (auf einem Non-Linuxmuster.net-System) eine SMB-Share eingebunden (eigenes Home-Share) und war in der Lage mit Onlyoffice Dateien anzulegen, zu editieren, …
Viele Grüße, Andreas

Hallo Andreas,
danke für die Rückmeldung. Dann werde ich auch demnächst mal auf onlyoffice umstellen.
VG, Tobias

Hallo zusammen,

nur der Hinweis: seit Version 6 scheint es einen Bug zu geben, wenn man versucht, Dateien auf SMB-Shares zu bearbeiten, wenn man die Shares nicht selbst einbindet, sondernüber die Variable $user.

Bis Version 5.x hat das Bearbeiten auf dem Userhome bei uns wunderbar funktioniert - seit 6.x geht es nicht mehr.

Siehe: https://github.com/nextcloud/server/issues/15934#issuecomment-506853476

Gibt es denn Erfahrungen bzgl der Unterschiede von OnlyOffice und Collabora? Letzteres kam bei uns recht gut an, als es noch lief :slight_smile: Andererseits gab es dieses < 20-Einschreänkung, über der dann eine Warnung erschien…

Viele Grüße,
Thomas