DecaTec

Programmieren, Fotografie, Home-Server und einiges mehr

Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain)

Nextcloud OnlyOffice Logo

Nextcloud bietet neben dem Speichern von Dateien auch noch erweiterte Funktionen wie z.B. die Verwaltung von Kontakten und Kalendern. Ebenso sind Online-Office-Funktionalitäten mit der eigenen Cloud-Lösung möglich: Hier gibt es die Alternativen ONLYOFFICE und Collabora. Für welche Lösung man sich hier entscheidet, ist zunächst einmal Geschmackssache.

Zum Thema ONLYOFFICE gab es bereits einen Artikel in diesem Blog. Die hier gezeigte Lösung hatte allerdings einen entscheidenden Nachteil: Die Office-Funktionalitäten waren nur verfügbar, wenn man über das lokale Netzwerk (LAN) auf die eigene Cloud zugegriffen hat. Das Bearbeiten von Dokumenten über das Internet war auf diese Art und Weise nicht möglich, da beim Bearbeiten von Dokumenten immer direkt auf die IP zugegriffen wurde, auf der ONLYOFFICE installiert wurde. Diese LAN-IP war über das Internet natürlich nicht erreichbar.

In diesem Artikel soll es daher wieder mal um die Einrichtung von ONLYOFFICE mittels Docker unter Nextcloud gehen. Dieses Mal sollen jedoch keine Einschränkungen für die Benutzung des Online-Office gelten: Somit ist dann der Zugriff sowohl über das lokale Netzwerk, also auch über das Internet möglich.

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

Update-Historie (letztes Update 12.11.2018)
  • 12.11.2018:
    • Die SSL-Konfiguration wird nun unter /etc/nginx/conf.d/ssl.conf gespeichert/ausgelagert.

 

Zweite (Sub-)Domain für ONLYOFFICE

Ich gehe in diesem Artikel davon aus, dass der eigene Server, auf dem Nextcloud bereits läuft, über die DynDNS-Domain meindomain.de erreichbar ist. DynDNS sorgt hier dafür, dass die öffentliche IP-Adresse des Routers auf eine Domain gemappt wird. Im Router wird die Domain dazu in den DynDNS-Einstellungen hinterlegt. Leider unterscheidet sich das Vorgehen von Router zu Router, daher würde eine detaillierte Anleitung für verschiedene Router-Modelle dem Umfang des Artikels sprengen.

Voraussetzung für ONLYOFFICE ist nun eine zweite (Sub-)Domain, über die der Dokumenten-Server später erreichbar sein wird. Als Beispiel nehme ich hier einfach die Domain onlyoffice.meinedomain.de. Diese zweite Domain muss dabei ebenfalls auf die öffentliche IP-Adresse des Routers „zeigen“, ist sozusagen auch eine zweite (oder besser gesagt alternative) DynDNS-Domain.

Mehrere DynDNS-Domains mittels CNAME

Und genau das ist hier das Problem. In fast allen Router-Modellen kann nur ein DynDNS-Anschluss mit nur einer Domain festgelegt werden. Die Lösung für dieses Problem stellt ein sog. CNAME-Eintrag für eine zweite (Sub-)Domain dar. Mittels CNAME wird einfach ausgedrückt ein alternativer Name für eine Domain hinterlegt: Der CNAME-Eintrag der Office-Domain muss daher die bereits vorhandene DynDNS-Domain sein.

Wo kann man diesen CNAME-Eintrag nun hinterlegen? Dies passiert normalerweise in der Domain-Verwaltung des Webspace-Providers. Auch hier unterscheidet sich das Vorgehen von Anbieter zu Anbieter, gute Erfahrungen konnte ich hier allerdings mit All-Inkl.com (Affiliate-Link) machen.

Hier loggt man sich zunächst im Kundenportal (KAS) ein und legt eine neue Subdomain an. Dazu findet man im Menü den Eintrag Subdomain. Über den Punkt Neue Subdomain anlegen kann hier eine neue Subdomain beantragt werden. Hier kann man alle Einstellungen einfach übernehmen, da diese Domain später nicht auf den Webspace, sondern die öffentliche IP-Adresse des eigenen Routers zeigen wird.

All-Inkl.com: Neue Subdomain anlegen

All-Inkl.com: Neue Subdomain anlegen

Um nun noch den CNAME-Eintrag für die neue Subdomain hinzuzufügen, muss man die Domain-Einstellungen unter Tools > DNS-Einstellungen bearbeiten. Hier sieht man dann die eigene Domain, über die auch der DynDNS-Anschluss läuft (meinedomain.de). Mit einem Klick auf Bearbeiten kann diese Domain modifiziert werden. Hier klickt man dann auf den Punkt neuen DNS Eintrag erstellen. Folgende Einstellungen sind hier vorzunehmen:

  • Name: Der Name der Subdomain (hier also onlyoffice.meinedomain.de).
  • Typ/Prio.: CNAME
  • Data: Hier wird die eigentliche DynDNS-Domain eingetragen (also meinedomain.de).
All-Inkl.com: CNAME-Eintrag für Subdomain erstellen

All-Inkl.com: CNAME-Eintrag für Subdomain erstellen

Nach einem Klick auf Speichern werden die Änderungen übernommen.

SSL-Zertifikat für die neue Domain hinzufügen

Damit die Verbindung zu ONLYOFFICE stets verschlüsselt, also über HTTPS abläuft, muss für die neue Subdomain noch ein SSL-Zertifikat über Let’s Encrypt erzeugt werden. Dazu wird das bereits für Nextcloud verwendete Zertifikat modifiziert, indem wir dieses Zertifikat um eine weitere (Sub-)Domain erweitern. Hierfür sind keine Änderungen an den virtuellen Hosts von nginx erforderlich, es reicht einfach folgender Befehl auf der Kommandozeile:

Wichtig ist hier die Angabe aller (Sub-)Domains mit dem Parameter -d. Nach diesem Befehl werden die Zertifikats-Dateien unter /etc/letsencrypt/live/meinedaomin.de erneuert. Nicht wundern, hier wird nicht für jede (Sub-)Domain ein Zertifikat erzeugt, sondern nur ein Zertifikat, welches für mehrere Domains ausgestellt ist.

Die Diffie-Hellman-Parameter (siehe Beschreibung) müssen nicht neu erzeugt werden können aus der bestehenden Installation übernommen werden.

Auslagern der SSL-Einstellungen aus dem virtuellen Host für Nextcloud

Für die neue Domain muss nun natürlich ein neuer virtueller Host angelegt werden. Dieser zielt wieder auf SSL ab, daher sind hier auch sämtliche SSL-Einstellungen wie ssl_certificate, ssl_protocols, ssl_ciphers, etc. notwendig. Damit wir diese nicht doppelt pflegen müssen (im Gateway-Host und im virtuellen Host für ONLYOFFICE), lagern wir diese Anweisungen für SSL einfach aus.

Vorher sollten alle virtuellen Hosts gesichert werden, falls beim Umzug etwas schief gehen sollte.

Wir erstellen dazu eine neue Datei speziell für allgemeine SSL-Einstellungen, die für alle (Sub-)Domains gelten sollen:

Folgender Inhalt wird dazu aus dem Gateway-Host übernommen:

Im nächsten Schritt werden nun genau diese Einstellungen aus dem Gateway-Host entfernt und durch eine einzige Zeile ersetzt:

Anschließend starten wir den Webserver neu:

Nun sollte man zunächst einmal testen, ob alle vorhandenen Web-Anwendungen (wie z.B. Nextcloud) noch wie erwartet funktionieren. Erst wenn diese Überprüfung erfolgreich war, sollte man hier weitermachen.

Virtuellen Host für ONLYOFFICE hinzufügen

Alles funktioniert noch? Gut! Dann weiter…

Im nächsten Schritt wird für die neue Subdomain ein eigener vHost hinzugefügt:

Der Inhalt ist hier recht übersichtlich:

Die SSL-Einstellungen haben wird ja zuvor ausgelagert, so dass diese nun in diesem zweiten vHost einfach wiederverwendet werden können.

Wichtig bei der Angabe des proxy_pass:

  • Für die Verbindung zur Maschine, auf der später ONLYOFFICE laufen wird, nutzen wir ebenfalls HTTPS. Wenn dies der gleiche Rechner ist, auf dem auch Nextcloud schon läuft, könnte man hier auch einfach auf HTTP setzen, da die Kommunikation dann nur Rechner-intern abläuft (dazu später mehr).
  • Die IP ist hier die lokale IP-Adresse des Rechners, auf dem ONLYOFFICE später laufen wird. Dies kann also die IP der Maschine sein, auf der auch der Webserver (und z.B. Nextcloud) läuft, oder auch eine andere Maschine im LAN.
  • Als Port habe ich hier 4433 angegeben. Dies ist besonders wichtig, wenn ONLYOFFICE auf dem gleichen Rechner installiert wird, auf dem auch der Webserver/Nextcloud läuft. Der Standard-Port für HTTPS 443 wäre hier schon (durch den Gateway-Host) belegt, also muss man auf einen anderen Port ausweichen.

Installation und Einrichtung ONLYOFFICE

Nachdem nun sämtliche Voraussetzungen erfüllt sind, kann es an die Installation von ONLYOFFICE gehen. Ich bevorzuge hier den Weg über Docker, da eine komplett manuelle Installation sehr aufwendig ist. Hier ist es auch egal, auf welcher Maschine ONLYOFFICE installiert wird. Entweder man installiert das Online-Office direkt auf dem Rechner, auf dem auch Nextcloud bereits läuft, oder man nimmt eine zweite Maschine (oder VM), auf der dann nur ONLYOFFICE betrieben wird.

Docker sollte auf jeden Fall bereits installiert sein. Fall nicht, sollte dieser Schritt wie im Artikel Docker auf Ubuntu Server nun nachgeholt werden.

Alle folgenden Schritte müssen auf der Maschine ausgeführt werden, auf der ONLYOFFICE installiert werden soll.

Vorbereitungen für die Installation

Die Verbindung zu ONLYOFFICE sollte aus Sicherheitsgründen immer verschlüsselt, also über HTTPS ablaufen. Durch den vHost für ONLYOFFICE ist die Verbindung über das Internet auch bereits verschlüsselt. Bleibt nur der Verbindungsweg vom Webserver auf die Maschine, auf der das Online-Office später laufen wird (also die Verbindung im lokalen Netzwerk). Diese Verbindung sollte ebenfalls verschlüsselt werden, damit auch LAN-intern stets sichere Verbindungen aufgebaut wird.

Wenn ONLYOFFICE auf dem gleichen Rechner gehostet wird, auf dem schon Nextcloud und der Webserver laufen, ist dieser Schritt eigentlich optional, da hier nur eine Rechner-interne Verbindung zustande kommt. Trotzdem empfehle ich diese Schritte auszuführen, besonders wenn die Office-Lösung und der Webserver/Nextcloud auf unterschiedlichen Maschinen installiert werden.

Da wir hier ja nur mit einer IP-Adresse arbeiten (die beim proxy_pass angegeben wird), können wir hierfür kein Let’s Encrypt Zertifikat erstellen, da diese Zertifikate nicht auf IP-Adressen, sondern nur auf Domains ausgestellt werden können. Daher greifen wir hier auf ein selbst signiertes Zertifikat zurück.

Dieses wird mit folgenden Befehlen erzeugt:

  • Beim Befehl openssl req -new -key onlyoffice.key -out onlyoffice.csr wird man nach dem „Common Name“ gefragt (Common Name (e.g. server FQDN or YOUR name)). Hier ist einfach die IP des lokalen Systems anzugeben (in diesem Fall 192.168.178.60). Ebenso kann man ein „challenge password“ angeben. Dieses kann man einfach leer lassen (einfach mit Enter bestätigen).
  • Achtung: Die Erzeugung der sog. Diffie-Hellmann-Parameter mit einer Länge von 4096 Bit (openssl dhparam -out dhparam.pem 4096) kann u.U. sehr lange dauern. Auf schwacher Hardware kann das schon einmal mehrere Stunden in Anspruch nehmen. Wer nicht so lange warten möchte, kann die Schlüssel-Länge auf 2048 Bit reduzieren (openssl dhparam -out dhparam.pem 2048).
  • Das Zertifikat hat eine Gültigkeit von 3650 Tagen (10 Jahre). Hier kann bei Bedarf auch eine andere Gültigkeitsdauer angegeben werden.

Installation ONLYOFFICE

Die Installation beschränkt sich dann dank Docker auf einen einzigen Befehl:

Hier gilt es folgende Punkte zu beachten:

  • Den Container nennen wir hier ONLYOFFICEDOCKER, damit dieser später über diesen Namen und nicht über eine kryptische ID angesprochen werden kann.
  • Da bereits der Webserver auf Port 443 lauscht (wenn ONLYOFFICE auf dem gleichen Rechner gestartet wird), müssen wird hier auf einen alternativen Port ausweichen. Der Parameter -p 4433:443 sorgt hier dafür, dass der Port 4433 des Docker-Hosts auf den Port 443 innerhalb des Docker-Containers gemappt wird. Wichtig ist hier, dass dieser Port (4433) mit demjenigen übereinstimmt, der beim proxy_pass im vHost für ONLYOFFICE angegeben wurde.
  • Die nächsten zwei Parameter (-e JWT_ENABLED=’true‘ -e JWT_SECRET=’geheimes-secret‘) erhöhen die Sicherheit, da zur Kommunikation mit dem Container ein sog. JSON Web Token benötigt wird. Im Grunde genommen handelt es sich dabei um ein Passwort (geheimes-secrethier sollte man natürlich ein eigenes Passwort wählen), welches später in Nextcloud hinterlegt werden muss, damit die Verbindung zu ONLYOFFICE aufgebaut werden kann. Dies verhindert, dass der ONLYOFFICE-Container „unbemerkt“ von anderen Verbindungen genutzt werden kann.
  • Mit —restart=always wird der Container bei jedem Systemstart automatisch gestartet.
  • Mit dem letzten Parameter (-v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data onlyoffice/documentserver) wird ein sog. Volume definiert: Alle Dateien, die im Verzeichnis /app/onlyoffice/DocumentServer/data des Hosts liegen, werden innerhalb des Containers im Verzeichnis /var/www/onlyoffice/Data onlyoffice/documentserver bereitgestellt. Diese Funktion wird benötigt, damit der Container das zuvor erzeugte Zertifikat finden und nutzen kann.

Nun wird das entsprechende Docker-Image heruntergeladen und auch gleich gestartet.

Installation von ONLYOFFICE mittels Docker

Installation von ONLYOFFICE mittels Docker

Nach dem Starten des Containers läuft ONLYOFFICE bereits. Wenn man nun im Browser die Domain onlyoffice.meinedomain.de oder die IP-Adresse der jeweiligen Maschine (dann aber mit dem alternativen Port 4433) aufruft, sollte folgende Seite erscheinen:

ONLYOFFICE läuft

ONLYOFFICE läuft

Einbinden von ONLYOFFICE in Nextcloud

Nachdem ONLYOFFICE läuft, geht es nun mit der eigenen Nextcloud weiter, damit hier Online-Office-Funktionalitäten hinzugefügt werden können.

Die passende App findet man dabei im Nextcloud App Store in der Kategorie Büro & Text:

ONLYOFFICE im Nextcloud App-Store

ONLYOFFICE im Nextcloud App-Store

Wenn die App aktiviert wurde, können die Einstellungen nun in der Admin-Oberfläche von Nextcloud unter dem Punkt ONLYOFFICE angepasst werden (damit alle Einstellungen angezeigt werden, muss man auf den Punkt Erweiterte Servereinstellungen klicken).

Nextcloud: ONLYOFFICE-Einstellungen in der Admin-Oberfläche

Nextcloud: ONLYOFFICE-Einstellungen in der Admin-Oberfläche

  • Serviceadresse der Dokumentbearbeitung: Hier wird die Subdomain angegeben, die wir extra für ONLYOFFICE angelegt habe, in diesem Beispiel also https://onlyoffice.meinedomain.de.
  • Geheimer Schlüssel (freilassen, um zu deaktivieren): Hier ist das JWT-Token anzugeben, welches beim Starten des Docker-Containers angegeben wurde (geheimes-secret).
  • Alle anderen Felder kann man leer lassen.

Nach einem Klick auf Speichern sollte eine Meldung erscheinen, dass die Einstellungen erfolgreich übernommen wurden.

Anschließend können Office-Dokumente ganz einfach direkt in der Cloud bearbeitet werden:

Online-Office mit Nextcloud und ONLYOFFICE

Online-Office mit Nextcloud und ONLYOFFICE

Update von ONLYOFFICE

Von Zeit zu Zeit erscheint ein neues Docker-Image für ONLYOFFICE. Leider ist es etwas umständlich herauszufinden, welche Version gerade installiert ist und ob es eine neue Container-Version gibt.

Um zu ermitteln, welche Version aktuell installiert ist, öffnet man am besten ein beliebiges Office-Dokument. Mit der Info-Schaltfläche wird die installierte Version von ONLYOFFICE angezeigt:

Über die Info-Schaltfläche kann die installierte Version ermittelt werden

Über die Info-Schaltfläche kann die installierte Version ermittelt werden

Die Version des aktuellsten Images kann nun über Docker Hub (eine Art Suche für Docker-Images) ermittelt werden. Dazu sucht man einfach nach onlyoffice 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 in der ONLYOFFICE-Hilfe nur drei Versionsnummern angezeigt, allerdings sollte man auch anhand des Datums sehen können, wenn eine neue Version des Containers bereitsteht.

Das Update selbst kann man dann in wenigen Schritten durchführen:

Zunächst wird der aktuelle Container gestoppt und entfernt:

ONLYOFFICEDOCKER ist hier der Name des Containers, den wir beim ersten Start angegeben haben. Hier könnte man auch die ID des Containers angeben (kann man mit docker ps ermitteln).

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 ONLYOFFICE per Docker betrieben wird, empfiehlt es sich, das komplette Docker-System zu bereinigen. Dazu werden einfach folgende Befehle ausgeführt:

Anschließend wird die neuste Version des Containers heruntergeladen und über den bekannten Befehl gestartet:

Beim zweiten Befehl ist hier nur wichtig, dass genau das gleiche JWT_SECRET wie schon beim Start des Containers angegeben wird, ansonsten kann nach dem Update keine Verbindung mehr von Nextcloud hergestellt werden.

Troubleshooting

Manchmal kann es vorkommen, dass ONLYOFFICE nicht wie erwartet funktioniert. Bei dem System sind ziemlich viele Komponenten beteiligt (Webserver, Nextcloud, Docker-Container), so dass man zunächst einmal das Problem eingrenzen sollte.

Zunächst sollte immer erst die Subdomain für ONLYOFFICE aufgerufen werden: onlyoffice.meinedomain.de

Erscheint hier nicht die Übersichtsseite von ONLYOFFICE, dann tritt das Problem wohl auf dem Verbindungsweg vom Internet zum Webserver auf. Dann 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).

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

Wenn die Seite erreichbar ist, aber ONLYOFFICE trotzdem nicht funktioniert, sollte 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:

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

Erst wenn dies auch zu keinen neuen Erkenntnissen führt, kann man sich auch auf die Kommandozeile des Containers selbst einloggen. Dazu einfach auf der Docker-Maschine folgenden Befehl ausführen:

Auf der Kommandozeile des Containers kann dann eine detaillierte Fehlersuche stattfinden. Mit folgendem Befehl kann man beispielsweise die Webserver-Logs einzusehen:

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

Fazit

Es sind schon einige Schritte notwendig, um ONLYOFFICE in Verbindung mit Nextcloud zum Laufen zu kriegen. Dennoch lohnt es sich, da man nun direkt in der eigenen Cloud ein Online-Office nutzen kann. Wer vorher beispielsweise Google Docs verwendet hat, wird sich auch bei ONLYOFFICE sehr schnell zurechtfinden – und das ohne die neugierigen Blicke von Google & Co, da alle Daten sicher in der eigenen Nextcloud gespeichert sind.

Weiterführende Artikel

Links

 

, , , , , , , , , , , , , , ,

Kommentare: 21

  • Hans sagt:

    Hallo Jan,

    wie immer TOP Anleitung.

    Vielen Dank dafür.

    Gruß Hans

  • Hans sagt:

    Hallo Jan,

    du hast einen kleinen Fehler in deinem Skript.

    anstatt include/etc/nginx/conf.d/ssl.conf; hast du include /etc/nginx/ssl.conf;
    geschrieben.
    Hier fehlt conf.d

    Gruß Hans

    • Jan sagt:

      Hi Hans,

      nein, das ist an dieser Stelle schon korrekt so, da die Datei im Tutorial tatsächlich unter /etc/nginx/ssl.conf (ohne conf.d) angelegt wurde.
      Du könntest diese Datei allerdings auch unter /etc/nginx/conf.d/ssl.conf anlegen, dann muss der include natürlich anders lauten.

      Edit: Habe nun doch die Pfade angepasst, da die ssl.conf unter conf.d doch besser aufgehoben ist. Danke für den Hinweis!

      Gruß,
      Jan

  • Hallo Jan,

    danke für deine Anleitung. Nachdem Onlyoffice jetzt auch außerhalb des Netzwerks funktioniert habe ich auch darauf umgestellt. Es funktioniert soweit auch alles.

    Allerdings habe ich jetzt im Übersichts-Menü der Admin Einstellungen wieder die Sicherheitswarnungen, die sich auf die http-header beziehen. Den entsprechenden add_header-Befehl habe ich auch in die ssl.conf ausgelagert, aber irgendetwas klappt da nicht. Sonst funktionieren alle Zugriffe.

    Leider habe ich mit der Integration von Onlyoffice auch auf Nextcloud 14.0.3 upgedated. Es könnte also auch daran liegen.

    Hast du vielleicht eine Idee?

    Grüße Jens

    • Jan sagt:

      Hi Jens,

      das bezieht sich auch die Referrer-Policy, oder? Hier gibt es meines Wissens nach Probleme, wenn der Header mehrfach gesetzt wird. Daher kontrollier doch bitte mal „von innen nach außen“ (d.h. erst im vHost für Nextcloud, dann im Gateway-Host und anschließend in der ssl.conf) ob der Header hier gesetzt wird und entferne ihn. Danach Webserver neu starten.
      Nextcloud setzt diesen Header wohl automatisch, so dass eine Anweisung über den Webserver dann den header verdoppelt. Dies führt wiederum dazu, dass dieser Header einfach ignoriert wird.

      Gruß,
      Jan

      • Jens Schuster sagt:

        Hallo Jan,

        doppelter Eintrag war der richtige Ansatz.

        Vielleicht solltest du deine Anleitung an der einen Stelle anpassen. Ich habe den letzten Block der ssl.conf mit den add_header Befehlen zurück in den Gateway-Host geschoben und jetzt sind alle Sicherheitswarnungen wieder weg.

        Danke für deine Hilfe.

        Grüße Jens

        • Jan sagt:

          Hi Jens,

          wenn du die Anweisungen in der ssl.conf wieder in den Gateway-Host verschoben hast, wo sind dann die SSL-Anweisungen für die OnlyOffice-Subdomain definiert? Denn diese werden für den Zugriff über HTTPS benötigt, aber der Gateway-Host ist ja beim Zugriff auf die OnlyOffice-Subdomain gar nicht im Spiel.

          Gruß,
          Jan

          • Jens Schuster sagt:

            Hallo Jan,

            ich habe nur die letzten 7 Befehle (add_header…) in den Gateway-Host verschoben und den Rest in der ssl.conf gelassen. Die „Rest-“ ssl.conf habe ich dann mit dem include-Befehl in den vHost eingebunden. Damit stehen die ssl Anweisungen zur Verfügung, oder?

            Grüße Jens

          • Jan sagt:

            Hi Jens,

            ok, so macht das mehr Sinn. ich dachte schon, du hättest die SSL-Anweisungen ganz rausgenommen, dann hätte ich erwartet, dass OnlyOffice gar nicht mehr funktioniert.

            Gruß,
            Jan

  • Hans sagt:

    Warum benötige ich eine zweite Subdomain. Könnte ich es nicht über die Domain machen wie bei der nextclout und den nginx Server auf z.b. meinedomain.de/Office verweisen?

    • Jan sagt:

      Hi Hans,

      also über ein Unterverzeichnis (wie schon bei Nextcloud) habe ich OnlyOffice nicht zufrieden stellend zum Laufen gebracht. Hängt denke ich mit internen Redirects zusammen (also innerhalb des OnlyOffice-Containers) und hier ist dieses Unterverzeichnis nicht bekannt.
      Wenn du keine zweite Subdomain haben willst, ist denke ich die einzige Alternative, dass du die gleiche Domain wie Nextcloud verwendest, aber auf einem anderen Port (z.B. 4433). Dazu brauchst du dann aber ebenfalls einen zweiten nginx vHost für OnlyOffice (der dann eben nur auf einen anderen Port lauscht). Zudem brauchst du in diesem Fall eine weitere Portfreigabe.
      Um hier die „Angriffsfläche“ möglichst gering zu halten, habe ich mich für die Lösung mit der zweiten Subdomain entschieden.

      Gruß,
      Jan

  • Martin sagt:

    Hallo Jan,
    danke für die tolle Anleitung – ich hatte mich früher schon mal mit einer OO-Installation (2 Server, ohne Docker)
    ‚rumgeschlagen und war nach einer Woche noch nicht fertig. So wars ein Tag …

    2 Anmerkungen noch:

    a) die Überprüfung des self-signed certs schlägt fehl (natürlich). Nach setzen von
    ‚onlyoffice‘ =>
    array (
    ‚verify_peer_off‘ =>TRUE,
    ),
    in der /var/www/nextcloud/config/config.php ging es …

    b) ferner war es notwendig, in der docker-Instanz im File
    /etc/onlyoffice/documentserver/default.json den Wert
    „services“: {
    „CoAuthoring“: {
    „requestDefaults“: {
    „rejectUnauthorized“: true

    auf false zu setzen.

    Ich hoffe, daß sich die Implikationen für die Sicherheit der Installation
    dabei in Grenzen halten …

    Nochmals vielen Dank,
    Martin

    • Jan sagt:

      Hi Martin,

      da scheint bei dir aber irgend etwas noch nicht zu passen:
      Das „Ausknipsen“ der Zertifikats-Überprüfung mittels 'verify_peer_off' =>TRUE sollte nicht notwendig sein, da das selbst signierte Zertifikat nur für die interne Kommunikation (proxy_pass vom OO vHost an den Docker-Container) genutzt wird. Die Kommunikation zwischen Nextcloud und OO findet ausschließlich über die OO-Subdomain statt, wo ja ein valides Zertifikat eingebunden ist (Let’s Encrypt).

      Dein zweiter Punkt könnte ein Sicherheitsproblem darstellen, da du hiermit anscheinend die Überprüfung des JWT-Tokens ausschaltest. Wenn du nun in den Einstellungen zu OO (in der Nextcloud Admin-UI) ein falsches JWT-Token eingibst, könnte OO trotzdem erreichbar sein – was so natürlich nicht gewünscht ist.

      Gruß,
      Jan

      • Martin sagt:

        Jan,
        Danke ! Ich habe mir die Kiste nochmal vorgeknöpft, und jetzt läuft alles wie nach Deiner Anleitung !

        Des Rätsels Lösung:
        Ich habe statt der Letsencrypt-Lösung ein ‚richtiges‘ Zertifikat verwendet und bin dahingehend von der Beschreibung abgewichen. Da ich eigentlich ein Apache-Mensch bin und die Zertifikatskette dort immer separat vom Zertifikat ausliefere habe ich auch hier in nginx nur das eigentliche Server-Cert verwendet; nginx braucht aber (wie Du ja auch geschrieben hast !) die volle Kette plus Serverzertifikat in einer Datei.

        Das hat dann letztendlich jede Menge Folgefehler produziert, u.A. auch solche ‚Bad gateway‘ -Sachen wie in Stefans Post unten ….

        BTW: Mein ‚zweiter Punkt‘ war auch so eine Folge – hat mit dem JWT-Token nichts zu tun; ich hatte nach obigen Workarounds mal bewußt ein falsches Token angegeben, und da kam dann eine andere, eindeutige Meldung, daß das Token falsch ist.

        Nochmals vielen Dank !
        Martin

        • Jan sagt:

          Hi Martin,

          ja, manchmal steckt der Teufel im Detail. ;-)
          Auf jeden Fall danke für deine Rückmeldung. Ist vielleicht auch für andere hilfreich, die mit ähnlichen Problemen konfrontiert werden.

          Gruß,
          Jan

  • Stefan sagt:

    Hallo Jan,

    erst einmal, wieder eine super Anleitung.
    Vielen Dank dafür.

    Man merkt dir an, dass das Thema dir echt liegt und dein Blog dir Spaß macht.
    Gibt es in diesem Umfang leider nicht so oft.

    Habe mit deiner Anleitung das Ganze auch wieder super zum laufen bekommen.
    Leider lädt nach einem Neustart des Servers OnlyOffice auf der Subdomain nicht.

    Ich bekomme die Fehlermeldung:

    502 Bad Gateway
    nginx

    In der Error-Log von Nginx finde ich folgende Einträge:

    2018/11/21 08:41:07 [crit] 1242#1242: *3682 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: IP.Cen.sor.ed, server: 0.0.0.0:443
    2018/11/21 08:41:07 [crit] 1242#1242: *3683 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: IP.Cen.sor.ed, server: 0.0.0.0:443
    2018/11/21 08:41:08 [crit] 1242#1242: *3684 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: IP.Cen.sor.ed, server: 0.0.0.0:443
    2018/11/21 09:45:33 [error] 1242#1242: *4243 open() „/usr/share/nginx/html/robots.txt“ failed (2: No such file or directory), client: IP.Cen.sor.ed, server: censord.de, request: „GET /robots.txt HTTP/1.1“, host: „-censored-“
    2018/11/21 10:07:35 [error] 1242#1242: *4392 access forbidden by rule, client: IP.Cen.sor.ed, server: censored.de, request: „GET / HTTP/1.1“, host: „censored.de“
    2018/11/21 10:07:35 [error] 1242#1242: *4392 open() „/usr/share/nginx/html/favicon.ico“ failed (2: No such file or directory), client: IP.Cen.sor.ed, server: censored.de, request: „GET /favicon.ico HTTP/1.1“, host: „censored.de“
    2018/11/21 11:08:42 [error] 1242#1242: *4812 access forbidden by rule, client: IP.Cen.sor.ed, server: censored.de, request: „GET / HTTP/1.1“, host: „censored.de“
    2018/11/21 11:08:43 [error] 1242#1242: *4813 access forbidden by rule, client: IP.Cen.sor.ed, server: censored.de, request: „GET / HTTP/1.1“, host: „censored.de“
    2018/11/21 14:16:38 [error] 1242#1242: *6302 access forbidden by rule, client: IP.Cen.sor.ed, server: censored.de, request: „GET / HTTP/1.0“
    2018/11/21 16:05:12 [error] 1238#1238: *7084 access forbidden by rule, client: IP.Cen.sor.ed, server: censored.de, request: „GET / HTTP/2.0“, host: „censored.de“
    2018/11/21 16:05:12 [error] 1238#1238: *7084 open() „/usr/share/nginx/html/favicon.ico“ failed (2: No such file or directory), client: 84.135.87.30, server: censored.de, request: „GET /favicon.ico HTTP/2.0“, host: „censored.de“
    2018/11/21 17:09:00 [crit] 1242#1242: *9344 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: IP.Cen.sor.ed, server: 0.0.0.0:443
    2018/11/21 18:28:37 [error] 1242#1242: *11112 access forbidden by rule, client: IP.Cen.sor.ed, server: censored.de, request: „GET / HTTP/2.0“, host: „censored.de“
    2018/11/21 18:28:37 [error] 1242#1242: *11112 open() „/usr/share/nginx/html/favicon.ico“ failed (2: No such file or directory), client: IP.Cen.sor.ed, server: censored.de, request: „GET /favicon.ico HTTP/2.0“, host: „censored.de“
    2018/11/21 18:28:51 [error] 1242#1242: *11123 open() „/usr/share/nginx/html/favicon.ico“ failed (2: No such file or directory), client: IP.Cen.sor.ed, server: censored.de, request: „GET /favicon.ico HTTP/2.0“, host: „censored.de“

    IP-Adressen, etc. habe ich mal zensiert.

    Können diese Log-Einträge etwas mit OnlyOffice zu tun haben?
    Wenn ja, kannst du mir hier helfen?

    Der ONLYOFFICEDOCKER-LOG spuckt mir folgendes aus:
    (Hier liegt glaube ich eher der Fehler)

    ==> /var/log/onlyoffice/documentserver/nginx.error.log <==
    2018/11/14 22:43:25 [error] 729#729: *2 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.178.60, server: , request: "GET /healthcheck HTTP/1.0", upstream: "http://127.0.0.1:8000/healthcheck&quot;, host: "onlyoffice.censored.de"
    2018/11/14 22:43:25 [error] 729#729: *2 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.178.60, server: , request: "GET /healthcheck HTTP/1.0", upstream: "http://127.0.0.1:8000/healthcheck&quot;, host: "onlyoffice.censored.de"
    2018/11/14 22:43:25 [error] 729#729: *5 no live upstreams while connecting to upstream, client: 192.168.178.60, server: , request: "GET /welcome/img/icon-cross.png HTTP/1.0", upstream: "http://docservice/welcome/img/icon-cross.png&quot;, host: "onlyoffice.censored.de"

    Vielen Dank schon einmal.

    Grüße Stefan

    • Jan sagt:

      Hi Stefan,

      kommst du nach einem Neustart der Kiste auf die Übersichtsseite, wenn du im Browser einfach onlyoffice.meinedomain.de eingibst? Es kann wohl keine gesicherte Verbindung aufgebaut werden („unsupported protocol“). Hast du hier evtl. TLSv1.3 im Einsatz? In ser ssl.conf sollte auf jeden Fall dies hier zu finden sein: ssl_protocols TLSv1.2 TLSv1.3;

      Auf jeden Fall ist dies denke ich der auslösende Fehler. Das nginx Log aus dem OnlyOffice-Container gefällt mir auch nicht, aber darum sollten wir uns erst kümmern, wenn der Rest funktioniert. Das ist vielleicht auch nur ein Folgefehler.

      Gruß,
      Jan

      • Stefan sagt:

        Hallo Jan,

        nein beim Neustart steht auf der Subdomain ‚onlyoffice.meinedomain.de‘ die Fehlermeldung:

        502 Bad Gateway
        nginx

        In der ssl.conf sind die TLSv1.2 TLSv1.3 Einträge vorhanden. Habe gerade die .conf Dateien alle überprüft. Wenn mir nichts entgangen ist, dann sind hier keine Fehler drin.

        Kann es mit meiner abweichenden Ordnerstruktur von nginx zusammenhängen? Bei mir befinden sich die virtuellen Hosts im ’sites-available‘ Ordner mit Verknüpfung (ls -s) auf den ’sites-enabled‘ Ordner. Die ssl.conf liegt im ’sites-available‘ Ordner. Der Include ist natürlich angepasst.

        Ich habe gerade einen interessanten Zusammenhang festgestellt, den ich auch reproduzieren kann:

        Bei einem Neustart läuft der Dokumentserver, bzw. OnlyOffice nicht. Aufruf der Subdomain spukt ‚502 Bad Gateway‘ aus.
        Rufe ich aber den Docker Log auf (docker logs ONLYOFFICEDOCKER) läuft danach der Dokumentserver einwandfrei und ich kann OnlyOffice normal nutzen…

        In der Error-Log von Nginx finde ich dann folgende Einträge:

        2018/11/22 13:06:08 [warn] 930#930: „ssl_stapling“ ignored, host not found in OCSP responder „ocsp.int-x3.letsencrypt.org“ in the certificate „/etc/letsencrypt/live/censored.de/fullchain.pem“
        2018/11/22 13:06:08 [warn] 930#930: „ssl_stapling“ ignored, host not found in OCSP responder „ocsp.int-x3.letsencrypt.org“ in the certificate „/etc/letsencrypt/live/censored.de/fullchain.pem“
        2018/11/22 13:06:08 [warn] 1041#1041: „ssl_stapling“ ignored, host not found in OCSP responder „ocsp.int-x3.letsencrypt.org“ in the certificate „/etc/letsencrypt/live/censored.de/fullchain.pem“
        2018/11/22 13:06:08 [warn] 1041#1041: „ssl_stapling“ ignored, host not found in OCSP responder „ocsp.int-x3.letsencrypt.org“ in the certificate „/etc/letsencrypt/live/censored.de/fullchain.pem“
        2018/11/22 13:08:41 [error] 1052#1052: *34 connect() failed (111: Connection refused) while connecting to upstream, client: IP.cen.sor.ed, server: onlyoffice.censored.de, request: „GET /welcome/ HTTP/2.0“, upstream: „https://192.168.178$
        2018/11/22 13:08:41 [error] 1052#1052: *34 connect() failed (111: Connection refused) while connecting to upstream, client: IP.cen.sor.ed, server: onlyoffice.censored.de, request: „GET /favicon.ico HTTP/2.0“, upstream: „https://192.168.$
        2018/11/22 13:09:20 [error] 1052#1052: *34 connect() failed (111: Connection refused) while connecting to upstream, client: IP.cen.sor.ed, server: onlyoffice.censored.de, request: „GET /welcome/ HTTP/2.0“, upstream: „https://192.168.178$
        2018/11/22 13:09:20 [error] 1052#1052: *34 connect() failed (111: Connection refused) while connecting to upstream, client: IP.cen.sor.ed, server: onlyoffice.censored.de, request: „GET /favicon.ico HTTP/2.0“, upstream: „https://192.168.$

        Läuft bei mir etwas mit den letsencrypt Zertifikat falsch?

        Hast du eine Idee?

        Danke nochmal.

        Viele Grüße

        Stefan

        • Jan sagt:

          Hi Stefan,

          OK, das bedeutet, dass nach einem Neustart der Kiste der OnlyOffice-Container nicht richtig läuft. Ein Fehler „Bad Gateway“ sagt hier aus, dass er das „Backend“, also den Webserver im OnlyOffice-Container, nicht erreichen kann.

          Ich würde andeiner Stelle das ganze Docker-System nochmal bereinigen:
          docker stop ONLYOFFICEDOCKER
          docker rm ONLYOFFICEDOCKER
          docker system prune -a
          docker image prune -a
          docker container prune

          Anschließend nochmal alles von vorn:
          docker run --name=ONLYOFFICEDOCKER -i -t -d -p 4433:443 -e JWT_ENABLED='true' -e JWT_SECRET='geheimes-secret' --restart=always -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data onlyoffice/documentserver

          Den Parameter --restart=always hattest du ja sicher auch mit angegeben, oder?
          Falls du den Befehl per Copy&Paste übernommen haben solltest, dann versuch dieses mal die komplett manuelle Eingabe in die Kommandozeile.

          Die Fehler wegen ssl_staping sind nur Warnungen und können irgnoriert werden.

          Gruß,
          Jan

          • Stefan sagt:

            Hi Jan,

            danke für die schnellen Antworten.

            Leider habe ich immer noch keinen Erfolg…
            Heißt: Neustart + DokumentServer unter Subdomain aufrufen = Bad Gateway.

            Habe das System gerade auch mal auf den neusten Stand gebracht und alle Host-Dateien überprüft. Docker komplett aufgeräumt und OnlyOffice neu installiert (den Befehl manuell eingegeben und –restart=always ist drin). Passt eigentlich alles. Läuft danach auch alles super. Bis halt zum Neustart.

            Ich habe den Fehler jetzt soweit eingrenzen können, dass der ONLYOFFICEDOCKER nicht automatisch startet. Starte ich den Container nach dem Neustart manuell mit: ‚docker start ONLYOFFICEDOCKER‘,
            rennt das System wie ne eins.

            Provisorisch konnte ich mir jetzt helfen, indem ich via Crontab mit @reboot den Befehl bei jedem Neustart ausführen lasse.

            Warum OnlyOffice nicht automatisch startet verstehe ich aber nicht.
            Hast du eine Idee, woran das noch liegen könnte?

            Ich schau jetzt mal, ob die Einträge in der nginx/error.log weiterhin auftreten.

            Ich kann mich gar nicht genug bedanken ;)

            Viele Grüße & schönen Abend.

            Stefan

          • Jan sagt:

            Hi Stefan,

            gut, zumindest haben wir das Problem schonmal eingrenzen können. Leider kann ich dir da jetzt nicht mehr wirklich weiter helfen.
            Aber die Idee mit dem Cronjob @reboot könnte hier tatsächlich helfen.
            Ansonsten würde ich mal nach einem Reboot der Maschine ins syslog des OO-Containers schauen. Aber das hat dann glaube ich wieder zur Folge, dass der Container normal ansprechbar sein wird…

            Gruß,
            Jan

Schreibe einen Kommentar

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