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.
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:
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:
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.
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 …
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.
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
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”
in den logs des apache gibt es keine Fehler, sondern 200 OK für dokumente, die ich in nextcloud anklicke
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?
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.
Meine HAProxy config (/etc/haproxy/haproxy.cfg) hänge ich an (Schuldomain umbenannt haproxy.zip (1,6 KB))
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.
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
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.
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.
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??
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
Nein, stimmt nicht.
Wenn ich eine DAtei mit “nicht bearbeiten” teile, kann derjenige die DAtei in Collabora öffnen, sieht aber nur noch:
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:
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
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.
Gibt es denn Erfahrungen bzgl der Unterschiede von OnlyOffice und Collabora? Letzteres kam bei uns recht gut an, als es noch lief Andererseits gab es dieses < 20-Einschreänkung, über der dann eine Warnung erschien…
Hi @thoschi,
weil ich deinen kommentar im anderen Thread nicht hier finden kann, nochmal die Frage: Läuft collabora außerhalb eines docker-containers schneller als innerhalb?
Und wenn ja - nach welcher Anleitung hast du collabora separat aufgesetzt?
Für die <20-Einschränkung gibt es ja workarounds, anderer Thread wiederum.
Andererseits gab es dieses < 20-Einschreänkung, über der dann eine Warnung erschien…