DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Nextcloud: Online-Office mit Collabora

Nextcloud Logo

Nextcloud bietet schon seit einiger Zeit ein Feature namens Collabora: Durch die gleichnamige Nextcloud-App ist es möglich, Office-Dokumente live in der Cloud über einen Browser zu bearbeiten – auch durch mehrere Nutzer der Cloud gleichzeitig.

Da es nicht einfach mit der Aktivierung der Collabora-App getan ist, zeigt der folgende Artikel, welche Voraussetzungen für Collabora erfüllt sein müssen und wie das Online-Office für Nextcloud installiert und konfiguriert wird.

Als Basis dient wie immer der Artikel Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.

Update-Historie ((letztes Update 20.01.2019)
  • 20.01.2019:
    • Hinwies hinzugefügt, wie die Verfügbarkeit eines Updates für Collabora erkannt werden kann.
  • 15.01.2019:
    • Hinweis hinzugefügt, dass das mobile Bearbeiten von Dokumenten mit aktiver Server-seitigen Verschlüsselung nicht möglich ist.
  • 13.01.2019:
    • Fehler beim Kommando zum Starten des Docker-Containers bereinigt.
  • 07.01.2019:
    • Anweisungen im Gateway-Host überarbeitet.
    • Nun ist auch die Bearbeitung von Dokumenten mit der Nextcloud App möglich.
    • Start-Anweisungen für den Docker-Container angepasst, so dass auch die Admin-Oberfläche von Collabora verfügbar ist.
  • 17.12.2018:
    • Der Docker-Container für Collabora wird nun mit einem Namen gestartet, damit dieser später nicht über die ID angesprochen werden muss.
    • Vorgehen zum Update des Docker-Containers aktualisiert.
    • Neuer Absatz Troubleshooting, falls Collabora nicht wie erwartet funktioniert.
  • 09.03.2018:
    • Hinweis auf Reboot nach Collabora-installation hinzugefügt.
  • 16.06.2018:
    • Hinweis auf den Parameter overwriteprotocol in der config.php von Nextcloud hinzugefügt.

Online-Office in Nextcloud integriert: Collabora

Mit Collabora Online bietet Nextcloud Online-Office-Funktionalitäten, die mancher vermutlich schon von Google Docs kennt: Office-Dateien wie doc, docx, ppt, pptx, xls, xlsx und Open Document Formate können so direkt über einen beliebigen Browser live in der Cloud bearbeitet werden.

Neben der gleichnamigen Nextcloud-App sind hier noch einige weitere Voraussetzungen zu erfüllen. Die eigentliche Arbeit übernimmt hierbei ein Docker-Container. Wer mit den Grundlagen zu Docker noch nicht vertraut ist, sollte sich dazu erst einmal den Artikel Docker auf Ubuntu Server durchlesen. Hier wird neben den Docker-Grundlagen auch die Installation auf einem Ubuntu Server erklärt.

Durch den Einsatz eines Docker-Containers muss für den Einsatz von Collabora recht wenig installiert und konfiguriert werden: Das Docker-Image bringt alle Voraussetzungen und Abhängigkeiten mit, so dass der Administrator sich hier nicht mit dem wie und warum beschäftigen muss. Der Container ist hier eine Art Blackbox, die dafür sorgt, dass das Feature Online-Office in Nextcloud ganz einfach funktioniert.

Collabora installieren und konfigurieren

Genug der Theorie, nun installieren und konfigurieren wir Collabora, so dass Nextcloud um Online-Office-Funktionalitäten erweitert werden kann.

Voraussetzungen

Um Collabora einsetzen zu können, sind einige Voraussetzungen zu erfüllen:

  • Ein System, welches Docker ausführen kann. Wie man Docker auf Ubuntu Server installiert, habe ich bereits im Artikel Docker auf Ubuntu Server erklärt.
  • Eine Subdomain, auf der Collabora später erreichbar ist. Hier reicht es aus, wenn Nextcloud über eine Subdomain (z.B. nextcloudtutorial.goip.de) erreichbar ist.
  • Nextcloud muss über eine gesicherte SSL-Verbindung (HTTPS) angesprochen werden können. Da wir für die Subdomain nextcloudtutorial.goip.de ein gültiges SSL-Zertifikat über Let’s Encrpyt erzeugt haben, ist diese Voraussetzungen in unserem Fall erfüllt.

Im Zusammenhang mit dem letzten Punkt ist noch zu beachten, dass der Parameter overwriteprotocol in der Konfiguration von Nextcloud gesetzt ist:

nano /var/www/nextcloud/config/config.php

Hier muss folgender Eintrag zu finden sein:

'overwriteprotocol' => 'https',

Falls diese Einstellung nicht zu finden ist, dann sollte diese vor der Installation von Collabora noch vorgenommen werden.

Collabora installieren

Wenn Docker bereits auf dem System eingerichtet ist und alle Voraussetzungen für Collabora erfüllt sind, dann kann das Docker-Image heruntergeladen werden:

docker pull collabora/code

Der Download dauert eine Weile, da knapp 1 GB an Daten heruntergeladen werden müssen.

Anschließend wird der Collabora-Container gestartet:

docker run --name=COLLABORADOCKER -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloudtutorial\\.goip\\.de' -e "username=Admin" -e "password=gEheImesPaSsw0rt" --restart always --cap-add MKNOD collabora/code

Diese Anweisung sorgt dafür, dass der Collabora-Container beim Systemstart immer automatisch geladen wird. Alle Anweisungen an Port 9980 werden an den Container weitergeleitet. Wichtig ist hier auch die Subdomain, unter der Collabora später erreichbar sein soll. Wichtig: Alle Punkte müssen in der Domain mit einem doppelten Backslash escaped werden (also nextcloudtutorial.goip.de wird zu nextcloudtutorial\\.goip\\.de).

Mit username bzw. password werden die Anmeldedaten für die Admin-Konsole von Collabora vergeben (dazu später mehr). Wenn die Admin-Konsole nicht benötigt wird, kann man diese Parameter auch einfach weglassen.

Damit der Webserver nginx Anweisungen an den Collabora-Container weiterleiten kann, müssen folgende Anweisungen in den Gateway-Host von nginx hinzugefügt werden (im server-Block für HTTPS). Hier helfen uns die Reverse-Proxy-Fähigkeiten von nginx:

#
# Collabora
#
# static files
location ^~ /loleaflet {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

# WOPI discovery URL
location ^~ /hosting/discovery {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

# main websocket
location ~ ^/lool {
    proxy_pass https://localhost:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $http_host;
    proxy_read_timeout 36000s;
}

# for mobile editing
location ^~ /hosting/capabilities {
    proxy_pass https://localhost:9980;
    proxy_set_header Host $http_host;
}

Nach der Installation von Collabora sollte man das System nochmals komplett neu starten. Wenn dieser Punkt ausgelassen wird (oder nur der Webserver neu gestartet wird), dann führt dies in einigen Fällen danach zu Problemen.

reboot now

Danach ist die Installation von Collabora abgeschlossen.

Collabora in Nextcloud einrichten

Weiter geht es in Nextcloud. Einloggen als Admin und anschließend kann unter Apps Collabora Online aktiviert werden:

Collabora Online App im Nextcloud App Store

Collabora Online App im Nextcloud App Store

Bevor Collabora nun verwendet werden kann, muss die App noch konfiguriert werden. Dazu wechseln wir in den Admin-Bereich von Nextcloud. Unter Collabora Online muss hier noch die URL eingetragen werden, unter der Collabora läuft. Dies ist die gleiche URL, wie wir beim Starten des Docker-Containers angegeben haben (inklusive Protokoll, also https://nextcloudtotorial.goip.de):

Collabora Konfiguration in Nextcloud

Collabora Konfiguration in Nextcloud

Nun können Office-Dateien (z.B. docx oder xlsx) in der Dateien-App von Nextcloud geöffnet und bearbeitet werden:

Online-Office mit Collabora unter Nextcloud

Online-Office mit Collabora unter Nextcloud

Hier ist auch die gleichzeitige Bearbeitung durch mehrere Nutzer der Cloud möglich.

Collabora Admin-Konsole

Wenn der Collbora-Container mit den Parametern username/password gestartet wurde, ist nun unter der URL https://nextcloudtutorial.goip.de/loleaflet/dist/admin/admin.html die Admin-Console von Collabora zu erreichen. Zur Anmeldung wird einfach der Benutzername und das Passwort verwendet, welche beim Starten des Containers angegeben wurden. Auf der Admin-Konsole erhält man einige Infos über das Collabora-System (angemeldete Benutzer, Ressourcenverbrauch, etc.).

Die Admin-Konsole von Collabora

Die Admin-Konsole von Collabora

Bearbeitung von Dokumenten mit mobilen Endgeräten

Dokumente können nun nicht nur in der Weboberfläche von Nextcloud bearbeitet werden, es ist zudem möglich, die Bearbeitung direkt in der Nextcloud-App (Android/iOS) vorzunehmen.

Um ein Dokument direkt in der App mit Collabora zu bearbeiten, wählt man dazu im erweiterten Menü der Datei (drei Punkte) die Option „Mit Collabora bearbeiten“. Schon kann das Dokument editiert und auch direkt wieder gespeichert werden, ohne dass man eine weitere App auf dem Smartphone benötigen würde.

Hinweis: Momentan ist die Bearbeitung von Dokumenten mit Mobilgeräten nur möglich, wenn die Server-seitige Verschlüsselung nicht aktiv ist.

Collabora updaten

Von Zeit zu Zeit werden Updates für das Collabora-Image veröffentlicht (dies sollte im Nextcloud-Blog angekündigt werden). Man kann allerdings auch manuell überprüfen, welche Version aktuell installiert ist. Dazu öffnet man einfach ein Dokument mit Collabora und ruft das Menü Hilfe > Über auf. Hier wir dann die installierte Version angezeigt:

Hilfe > Über zeigt die aktuell installierte Version an

Hilfe > Über zeigt die aktuell installierte Version an

Die Version des aktuellsten Images kann nun über Docker Hub (eine Art Suche für Docker-Images) ermittelt werden. Dazu sucht man einfach nach collabora/code und lässt sich dann die Tags anzeigen. Schneller geht es über diesen Direktlink. Hier werden dann alle Versionen des Images angezeigt:

Die aktuelle Version im Docker Hub

Die aktuelle Version im Docker Hub

Zwar werden im Menü Über nur drei Versionsnummern angezeigt, allerdings sollte man auch anhand des Datums sehen können, wenn eine neue Version des Containers bereitsteht.

Das Update selbst erfolgt dann in wenigen Schritten. Zunächst wird der aktuelle Container gestoppt und entfernt:

docker stop COLLABORADOCKER 
docker rm COLLABORADOCKER

COLLABORADOCKER ist dabei der Name des Containers, der beim ersten Start angegeben wurde. Alternativ kann hier auch die ID des Containers verwendet werden (zu ermitteln mit docker ps).

Optional: Bei der Arbeit mit Docker bleiben oft Reste auf dem System zurück (z.B. alte, ungenutzte Container). Gerade wenn auf dem System ausschließlich Collabora per Docker betrieben wird, empfiehlt es sich, das komplette Docker-System zu bereinigen. Dazu werden einfach folgende Befehle ausgeführt:

docker system prune -a 
docker image prune -a 
docker container prune

Anschließend wird die neuste Version des Containers herunter geladen und gestartet:

docker pull collabora/code 
docker run --name=COLLABORADOCKER -t -d -p 127.0.0.1:9980:9980 -e 'domain=nextcloudtutorial\\.goip\\.de' -e "username=Admin" -e "password=gEheImesPaSsw0rt" --restart always --cap-add MKNOD collabora/code

Anschließend sollte Collabora in der neuesten Version laufen.

Troubleshooting

Manchmal kann es vorkommen, dass Collabora nicht wie erwartet funktioniert. Da einige Komponenten beteiligt sind (Webserver, Nextcloud, Docker-Container), sollte man das Problem erst einmal eingrenzen.

Zunächst sollte überprüft werden, ob in den Admin-Einstellungen die URL für Collbora übernommen werden konnte. Falls dies schon nicht funktioniert, sollten zunächst einmal die Logs des Webservers kontrolliert werden (auf der Maschine, wo der Gateway-Host zu finden ist und auch Nextcloud installiert ist):

nano /var/log/nginx/error.log

Hier sollten dann Fehlermeldungen zu finden sein, mit den man das Problem weiter eingrenzen kann.

Falls Collabora sich in Nextcloud korrekt einrichten ließ, aber trotzdem nicht funktioniert (z.B. wenn sich keine Dokumente öffnen lassen), dann sollten in diesem Fall zunächst einmal das Nextcloud-Log überprüft werden (in der Admin-Oberfläche von Nextcloud unter Protokollierung).

Falls hier auch nichts auffälliges zu sehen ist, sollten die Logs des Docker-Containers überprüft werden:

docker logs COLLABORADOCKER

Hier sind dann u.U. Hinweise zu finden, dass z.B. ein benötigter Dienst nicht gestartet werden konnte. In diesem Fall hilft es meistens, den Rechner, auf dem Collabora läuft, einfach mal neu zu starten.

Erst wenn dies auch keine Besserung bringt, kann man sich auch auf die Kommandozeile des Containers selbst einloggen. Dazu einfach auf der Docker-Maschine folgenden Befehl ausführen:

sudo docker exec -it COLLABORADOCKER bash

Auf der Kommandozeile des Containers kann dann eine detaillierte Fehlersuche stattfinden, da man hier direkten Zugriff auf die Logs des Docker-Systems hat.

Um die Kommandozeile des Containers wieder zu verlassen, reicht folgender Befehl:

exit

Fazit

Mit Collabora kann Nextcloud in wenigen Schritten um Online-Office-Funktionalitäten erweitert werden. Dadurch können Office-Dateien direkt und „live“ in der Cloud bearbeitet werden, ohne dass diese zuvor heruntergeladen werden müssen. Durch den Einsatz eines Docker-Images für Collabora geht die installation des Features schnell und einfach von der Hand.

Weiterführende Artikel

Links

, , , , , ,

Kommentare: 149

  • Jürgen Roth sagt:

    Hallo Jan,

    ich erhalte zwar eine Anmeldemaske, kann mich aber nicht anmelden.
    Binn mir sehr sicher den richtigen Anmeldenamen (admin) und das korrekte Passwort zu benutzen.
    Lässt sich das ggfs. zurücksetzen?
    Sorry für die Umstände
    Gruß
    Jürgen

    • Jan sagt:

      Hallo Jürgen,

      das Passwort für die Collabora-Übersichtsseite wird über den Docker-Befehl zum Starten des Containers mitgegeben.
      Also einfach Container herunterfahren und mit (korrigiertem) Befehl nochmal starten.

      Gruß,
      Jan

      • Jürgen Roth sagt:

        Hallo Jan,

        da ich nur eine Teilzeitstelle habe komme ich hier nicht richtig weiter.
        Ich habe alles noch mal komplett deinstalliert. Hatte aus versehen Docker aus Ubuntu-Quellen installiert. Da ich jede Fehlermöglichkeit ausschliessen will, habe ich nach einer Anleitung von Docker neu installiert. Danach nach deiner Anleitung Collabora neu installiert.
        Hello Test am Schluss ist erfolgreich.
        Will ich die Admin-Seite aufrufen erscheint nun jedoch Fehler 502 (Bad Gateway)
        Wo kann ich diesen Fehler eliminieren? Weisst du wer mir hierbei, auch gegen Entgelt, helfen kann die Installation ans Laufen zu bekommen?
        Über Remote-Sitzung müsste das ja hinzubekommen sein.

        Grüße
        Jürgen

        • Jan sagt:

          Hallo Jürgen,

          „Bad Gateway“ bedeutet im Allgemeinen, dass der Upstream (in diesem Fall der Docker-Container) nicht erreicht werden kann, oder einen Fehler geworfen hat. Hier einfach mal die Schritte unter Troubleshooting durcharbeiten. Irgendwo hier sollte ein Hinweis zu finden sein, was da schief läuft.

          Nutzt du evtl. einen neuen Raspberry Pi 4? Habe gehört, dass es hier beim „Containern“ Probleme geben soll…

          Wenn es bei dir gar nicht nicht klappen will: Für das, was ich hier im Blog Hobby-mäßig mache, gibt es noch den professionellen Ableger (siehe hier). Vielleicht auch eine Lösung.

          Gruß,
          Jan

  • Leo W sagt:

    Hi Jan,

    Wie immer eine super Anleitung, allerdings schaffe ich es nicht NC mit CODE zu verbinden. Wenn ich die Docker Logs auslese bekomme ich folgenen error:

    standard_init_linux.go:211: exec user process caused „exec format error“

    Hat das was damit zu tun das ich Debian 10 nutze? Mein System ist ein RockPro64 mit Debian 10 welches ich über ein Update von Debian 9 von ayufan erhalten habe. Wenn ich uname -a eingebe zeigt er mit an aarch64, also 64 Bit ist vorhanden.

    Könnte es sein, dass Debian 10 noch zu frisch ist für den Docker Container? wenn ja, wie ließe sich das beheben?

    Gruß

    Leo W.

    • Jan sagt:

      Hallo Leo,

      ich weiß nur, dass es mit Collbora/Docker auf einem Raspi mal Probleme gab (lag glaube ich an der Inkompatibilität von ARM).
      Habe leider kein Debian 10 im Einsatz, kann es also nicht testen. Würde mich aber sehr wundern, wenn es unter Debian 10 nicht gehen sollte.
      Hat es denn funktioniert, als du noch auf Debian 9 unterwegs warst?

      Gruß,
      Jan

  • Florian sagt:

    Hallo Jan,

    nach etlichen Stunden Recherche hoffe ich auf einen Profi-Tipp.

    Nextcloud und Collabora sind nach deinen Anleitungen eingerichtet (VM in Hyper-V). Ein IIS läuft auf meinem WinServer 2019 und ein URL Rewrite/Reverse Proxy schickt die Anfragen von cloud.domain.de an die IP der Nextcloud VM 192.168.0.0 das klappt alles.
    Collabora funktioniert auch ABER nur lokal, weil die websocket url wss://192.168.0.0/lool/https://cloud.domain.de/nextcloud/… ist.

    Irgendwie logisch weil nginx die Anfragen über den IIS auf 192.168.0.0 erhält und der IIS die Antworten wieder umschreibt.

    Ich habe jetzt in nginx einen weiteren virtuellen host für office.domain.de angelegt, der auf Port 111 reagiert und die Anweisungen für den Collabora Container dort eingetragen. In Nextcloud ist die Collabora URL dann https://office.domain.de:111 und das funktioniert.

    Dafür ist natürlich ein zusätzlicher Port in meiner Firewall offen und der Gateway-Host wird auch umgangen, irgendwie nicht zufriedenstellend.
    Mir fällt aber auch kein anderer Weg ein bzw. reicht mein Wissenstand noch nicht aus. Gibt es da vielleicht eine elegantere Lösung ein?

    Gruß
    Florian

    • Jan sagt:

      Hallo Florian,

      ich muss gestehen, dass ich mit dem IIS nicht besonders gut auskenne, daher klammere ich das erst einmal aus (und gebe eher eine allgemeine Beschreibung ab).

      Eine Lösung könnte sein, dass du die Office-Subdomain auf die gleiche IP deines Internet-Anschlusses weiter leitest. Bei DynDNS brauchst du hier wohl einen CNAME-Eintrag auf der Domain.
      Entscheidend ist nun der erste Webserver, der den Request entgegen nimmt. Dieser muss auf Grund der Domain, über die der Request gestellt wurde, entscheiden, an welchen Endpunkt im LAN der Request weiter geleitet werden muss.
      Bei nginx wird die Unterscheidung nach Domain durch den server_name bestimmt. Ich weiß leider nicht, wie sich so etwas per IIS realisieren lässt. Vielleicht könnte die Lösung daher auch sein, vor den IIS noch einen nginx Reverse Proxy zu stellen. Das sollte die Konfiguration dann im einiges einfacher machen (wenn du mich fragst – ist natürlich Geschmackssache).

      Gruß,
      Jan

      • Florian sagt:

        Hallo Jan,

        danke für die Tipps! Momentan lasse ich es über meinen Umweg laufen, das funktioniert ja recht gut. Noch eine nginx davor ist mir momentan zu kompliziert weil einige andere Dienste über den IIS laufen.

        Ich glaube fast dass Collabora in dieser Konfiguration über den IIS einfach nicht funktioniert. In einem Onlyoffice Forum gab es ein ähnliches Problem und da klappte es auch nicht.
        Bei Gelegenheit baue ich mir eine Testumgebung, vielleicht finde ich ja noch einen Weg.

        Gruß
        Florian

  • p0ddie sagt:

    Hi,

    ich habe einen Nextcloud auf Ubuntu Server ganz gemäß deiner Anleitung gebaut, also läuft nextcloud jetzt unter nextcloud.meinedomain.de/nextcloud mit einem let’s encrypt Zertifikat. Ich habe ein wenig Schwierigkeiten zu verstehen, in welche Datei die „Anweisungen in den Gateway-Host von nginx hinzugefügt werden (im server-Block für HTTPS)“ sollen. Hättest du einen Tipp für mich?

    Ich habe sie mal testweise in die /etc/nginx/conf.d/nextcloud.meinedomain.de.conf eingetragen, bekomme aber nach Neustart in der Protokollierung in Nextcloud nur:

    GuzzleHttp\Exception\ConnectException: cURL error 7: Failed to connect to nextcloud.meinedomain.de port 9980: Connection refused (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

    inb4 Port 9980 ist per NAT offen und per ufw erlaubt.

    Irgendwo muss ich also noch etwas zulassen (oder einen zus. reverse proxy erstellen? – habe zu wenig Erfahrung mit diesen Sachen) aber ich komme nicht drauf. Ich wäre für eine Idee total dankbar! :)

    • Jan sagt:

      Hi,

      der Gateway-Host ist im Rahmen des Tutorials /etc/nginx/conf.d/meinedomain.de.conf, d.h. der Host, der für die Domain an sich zuständig ist und als einziger „von außen“, also Port 443 erreichbar ist.
      Die anderen vHosts sind alle nur lokal und laufen über HTTP.

      Gruß,
      Jan

  • gregor sagt:

    Hallo Jan

    Danke für die Anleitung.

    Ich habe Nextcloud und Collabora auf einem Uraid System als Docker laufen.

    Der Reverse Proxy (NginxProxyManager) ist auch in eine Docker und läuft auch auf diesem Server welcher eine öffentliche IP hat. Alle Let’sEncrypt Zertifikate wurden von NginxProxyManager erstellt.

    Die Installation von Collabora hat problemlos funktioniert. Der Server ist auch über die FQDN von aussen erreichbar. Sowie natürlich Nextcloud auch.

    In Nextcloud habe ich die SubDomain von Collabora unter dem Menupunkt Collabora im Admin eingegeben. Das funktioniert alles und wird als OK bestätigt.

    Nun, ich kann leider keine Dateien öffnen in NC. Jedoch kann ich eine erstellen. Öffnen leider nicht. Es kommt die Meldung „Collabora Online konnte nicht geladen werden – Bitte versuche es später noch einmal“

    Im Backadmin sehe ich dann in den Logs folgende Fehler:

    [richdocuments] Error: GuzzleHttp\Exception\ConnectException: cURL error 28: Connection timed out after 5001 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) at <>

    0. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php line 149
    GuzzleHttp\Handler\CurlFactory::createRejection(GuzzleHttp\Handl … l}, {errno: 28,error … 9})
    1. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php line 102
    GuzzleHttp\Handler\CurlFactory::finishError(GuzzleHttp\Handler\CurlHandler {}, GuzzleHttp\Handl … l}, GuzzleHttp\Handler\CurlFactory {})
    2. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlHandler.php line 43
    GuzzleHttp\Handler\CurlFactory::finish(GuzzleHttp\Handler\CurlHandler {}, GuzzleHttp\Handl … l}, GuzzleHttp\Handler\CurlFactory {})
    3. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/Proxy.php line 28
    GuzzleHttp\Handler\CurlHandler->__invoke(„*** sensitive parameter replaced ***“, „*** sensitive parameter replaced ***“)
    4. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/Proxy.php line 51
    GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(„*** sensitive parameters replaced ***“)
    5. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php line 37
    GuzzleHttp\Handler\Proxy::GuzzleHttp\Handler\{closure}(„*** sensitive parameters replaced ***“)
    6. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Middleware.php line 30
    GuzzleHttp\PrepareBodyMiddleware->__invoke(„*** sensitive parameter replaced ***“, „*** sensitive parameter replaced ***“)
    7. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/RedirectMiddleware.php line 70
    GuzzleHttp\Middleware::GuzzleHttp\{closure}(„*** sensitive parameters replaced ***“)
    8. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Middleware.php line 60
    GuzzleHttp\RedirectMiddleware->__invoke(„*** sensitive parameter replaced ***“, „*** sensitive parameter replaced ***“)
    9. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/HandlerStack.php line 67
    GuzzleHttp\Middleware::GuzzleHttp\{closure}(„*** sensitive parameters replaced ***“)
    10. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php line 277
    GuzzleHttp\HandlerStack->__invoke(„*** sensitive parameter replaced ***“, „*** sensitive parameter replaced ***“)
    11. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php line 125
    GuzzleHttp\Client->transfer(„*** sensitive parameter replaced ***“, „*** sensitive parameter replaced ***“)
    12. /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php line 131
    GuzzleHttp\Client->requestAsync(„get“, GuzzleHttp\Psr7\Uri {}, {verify: „/data/ … }})
    13. /config/www/nextcloud/lib/private/Http/Client/Client.php line 149
    GuzzleHttp\Client->request(„get“, „https://collabo … y“, {proxy: null,ver … e})
    14. /config/www/nextcloud/apps/richdocuments/lib/WOPI/DiscoveryManager.php line 106
    OC\Http\Client\Client->get(„https://collabo … y“, {timeout: 5})
    15. /config/www/nextcloud/apps/richdocuments/lib/WOPI/DiscoveryManager.php line 78
    OCA\Richdocuments\WOPI\DiscoveryManager->fetchFromRemote()
    16. /config/www/nextcloud/apps/richdocuments/lib/WOPI/Parser.php line 41
    OCA\Richdocuments\WOPI\DiscoveryManager->get()
    17. /config/www/nextcloud/apps/richdocuments/lib/TokenManager.php line 196
    OCA\Richdocuments\WOPI\Parser->getUrlSrc(„application/vnd.oasis.opendocument.text“)
    18. /config/www/nextcloud/apps/richdocuments/lib/Controller/DocumentController.php line 236
    OCA\Richdocuments\TokenManager->getToken(„*** sensitive parameters replaced ***“)
    19. /config/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php line 170
    OCA\Richdocuments\Controller\DocumentController->index(„*** sensitive parameter replaced ***“)
    20. /config/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php line 99
    OC\AppFramework\Http\Dispatcher->executeController(OCA\Richdocument … {}, „index“)
    21. /config/www/nextcloud/lib/private/AppFramework/App.php line 125
    OC\AppFramework\Http\Dispatcher->dispatch(OCA\Richdocument … {}, „index“)
    22. /config/www/nextcloud/lib/private/AppFramework/Routing/RouteActionHandler.php line 47
    OC\AppFramework\App::main(„OCA\\Richdocume … r“, „index“, OC\AppFramework\ … {}, {_route: „richdocuments.document.index“})
    23. <>
    OC\AppFramework\Routing\RouteActionHandler->__invoke({_route: „richdocuments.document.index“})
    24. /config/www/nextcloud/lib/private/Route/Router.php line 299
    call_user_func(OC\AppFramework\ … {}, {_route: „richdocuments.document.index“})
    25. /config/www/nextcloud/lib/base.php line 1008
    OC\Route\Router->match(„/apps/richdocuments/index“)
    26. /config/www/nextcloud/index.php line 38
    OC::handleRequest()

    GET /apps/richdocuments/index?fileId=1213625&requesttoken=smboU8587SwSDymGcy0sJZHiipBlj9DODtotnrdNNUc%3D%3Axx6MKboUvx13ZkuxAlt%2BF9%2B3vcYRurm6Ta5f349idAQ%3D

    Desweiteren habe ich in den Logs von Collabora folgende Einträge:
    wsd-00027-00035 2020-03-27 21:01:08.819163 [ websrv_poll ] ERR Socket #24 SSL BIO error: closed unexpectedly (-1). (0: Success)| ./net/SslSocket.hpp:278
    wsd-00027-00035 2020-03-27 21:01:08.819282 [ websrv_poll ] ERR Error while handling poll for socket #24 in websrv_poll: SSL Socket closed unexpectedly.| ./net/Socket.hpp:594
    wsd-00027-00035 2020-03-27 21:01:08.828610 [ websrv_poll ] WRN client – server version mismatch, disabling browser cache. Expected: 48938d4| wsd/FileServer.cpp:279

    Hat das etwas zu tun mit den Anweisungen die in den Serverblock von Nginx kopiert werden sollen? Wo muss diese nun genau hin, im Docker von Collabora oder in den Docker von NC?

    Wäre toll wenn Du mir helfen könntest.

    Grüsse Gregor

    • Jan sagt:

      Hallo Gregor,

      hast du zufällig in der SSL-Konfiguration von nginx irgendwas wie die folgende Zeile drin stehen:
      ssl_ecdh_curve secp521r1:secp384r1;

      Hier gibt es aktuell Probleme mit neueren Versionen des Collabora-Containers. Daher muss die Ziele etwas abgeändert werden:
      ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

      Da ist nur so eine Vermutung, aber vielleicht trifft das genau auf dein Problem zu.

      Gruß,
      Jan

  • Amelia sagt:

    Hallo Jan,

    vielen, vielen Dank für die vielen tollen Anleitungen. Ich habe NC als nextcloudpi auf einem Raspberry Pi laufen. Um auch die Funktionen von Collabora nutzen zu können habe ich bei Hetzner einen CloudServer gemietet, um dort einen Collabora Server aufzusetzen. Ich habe versucht die Anleitung umzumünzen und der Docker Continer läuft soweit, auch die Admin Konsole ist erreichbar. In der NC kommt allerdings eine Fehlermeldung „Unaitorisierter WOPI Host…“. Hast du eine Idde?

    Mfg
    Amelia

    • Jan sagt:

      Hi,

      welche Domain hast du beim Starten des Docker-Containers angegeben? Hier müsste die Domain deiner Cloud (also auf dem Raspi) angegeben werden, wenn mich nicht alles täuscht.

      Gruß,
      Jan

      • Amelia sagt:

        Hallo Jan,

        nochmals vielen Dank für Deine Anleitung und deine Hilfe!
        Das habe ich auch nach einiger Recherche heruasgefunden und hatte ich anfangs wohl falsch gemacht. Ich hatte aber außerdem einen Fehler in der nginx Konfiguration.
        Jetzt habe ich den Container mit der Cloud-URL neugestartet und den Fehler in der nginx.conf augenscheinlich behoben. Mit nginx Reverse Proxy und Collabora im Docker funktioniert jetzt nach einigen Tagen und vielen Versuchen tatsächlich alles!
        Danke.

        Mfg
        Amelia

        • Jan sagt:

          Hallo Amelia,

          OK, dann hat sich das Problem ja erledigt.
          Danke für deine Rückmeldung.

          Gruß,
          Jan

          • Amelia sagt:

            Hi,

            noch eine Frage. In einem Artikel Schreibstil Du, dass die Office Lösungen auch parallel laufen können. Heißt das ich kann einfach OnlyOffice daneben per Dicker starten und dann beides benutzen?

            Mfg
            Amelia

          • Jan sagt:

            Hi Amelia,

            genau, beide Lösungen kannst du parallel betreiben. Hat v.a. den Vorteil, dass man beides installieren und ausprobieren kann, wenn man sich zwischen den Lösungen entscheiden muss/will.

            Gruß,
            Jan

  • Amelia sagt:

    Hi nochmal Jan,

    ich habe jetzt auf dem externen Server auf dem schon Collabora für meine NC läuft noch OnlyOffice installiert. Im Browser ist die OnlyOffice Seite mit Aufruf über die Domain und auch über IP Adresse, jeweils mit Port Angabe erreichbar und bis dahin alles in Ordnung.
    Bei der Einbindung in den NC Einstellungen wird ein Zertifikatsfehler angezeigt wenn ich die OnlyOffice-Server-Domain mit Port angebe:
    Fehler beim Anschließen (cURL error 60: SSL certificate problem: self signed certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)).
    Also irgendetwas stimmt mit den Zertifikaten nicht. Akzeptiert NC keine selbst signierten Zertifikate? Für die Domain habe ich aber eigentlich auch schon Let’s Encrypt Zertifikate erzeugt, da es bei Collabora ja nur so funktioniert. Werden die dann nicht automatisch für OnlyOffice auch benutzt?
    Ich hoffe du kannst mir hier nochmal auf die Sprünge helfen.

    Liebe Grüße!

    • Jan sagt:

      Hi,

      ja, für OnlyOffice brauchst du eine extra Domain mit eigenen Let’s Encrypt Zertifikaten. Das ganze habe ich schon einmal hier beschrieben.
      Es gibt auch die Option, die Zertifikats-Prüfung seitens Nextcloud zu deaktivieren, aber davon rate ich dringend ab.

      Gruß,
      Jan

1 2

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.