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 21.12.2021)- 21.12.2021:
- Virtueller Host für OnlyOffice: Hinzufügen der listen-Direktive für IPv6.
- 18.06.2021:
- Aufruf von acme.sh mit Parameter „server“, so dass Zertifikate über Let’s Encrypt bezogen werden.
- 03.02.2020:
- Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.
- 07.12.2019:
- Troubleshooting: Hinweise bzgl. X-Frame-Options hinzugefügt.
- 05.09.2019:
- Hinweise hinzugefügt, falls acme.sh statt Certbot verwendet wird.
- 23.12.2018:
- Zeilenangaben für das Übertragen der SSL-Einstellungen in die ssl.conf hinzugefügt.
- 19.12.2018:
- Die SSL-Konfiguration wird nun in das Verzeichnis /etc/nginx/snippets/ssl.conf ausgelagert, ansonsten kam es z.T. zu Problemen mit den Setzen der HTTP-Header.
- 12.11.2018:
- Die SSL-Konfiguration wird nun unter /etc/nginx/conf.d/ssl.conf gespeichert/ausgelagert.
Inhalt
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.
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).
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. Ebenfalls müssen bereits vorhandene Diffie-Hellman-Parameter (siehe Beschreibung) nicht neu erzeugt werden und können aus der bestehenden Installation übernommen werden.
Certbot
Wenn für die Generierung der Zertifikate Certbot zum Einsatz kommt, dann reicht hier folgender Befehl auf der Kommandozeile, um neue Zertifikate für beide (Sub-)Domains auszustellen:
certbot certonly --webroot -w /var/www/letsencrypt -d meinedomain.de -d onlyoffice.meinedomain.de --rsa-key-size 4096
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.
acme.sh
Falls acme.sh für die Generierung der Zertifikate verwendet wird, sollten zunächst die Grundlagen zu acme.sh aus dem Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx entnommen werden.
Der konkrete Befehl zum Erzeugen der Zertifikate sieht in diesem Fall dann so aus:
acme.sh --issue -d meinedomain.de -d onlyoffice.meinedomain.de --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/key.pem --ca-file /etc/letsencrypt/meinedomain.de/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"
Hier werden dann ebenfalls alle (Sub-)Domains mittels des Parameters -d angegeben und in einem einzigen Zertifikat „verpackt“.
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.
Dazu erstellen wir zunächst einen neuen Ordner, in dem die SSL-Einstellungen gespeichert werden sollen:
mkdir /etc/nginx/snippets
In diesem Ordner erstellen wir anschließend eine neue Datei speziell für allgemeine SSL-Einstellungen, die für alle (Sub-)Domains gelten sollen.
Hinweis: Diese ausgelagerten Einstellungen dürfen nicht im selben Ordner wie die restlichen vHosts (/etc/nginx/conf.d) gespeichert werden, da es ansonsten Probleme mit dem Setzen der HTTP-Header gibt.
In diese Datei werden nun die Anweisungen übernommen, die für die SSL- und Header-Einstellungen zuständig sind. In diesem konkreten Beispiel (siehe hier) sind die Zeilen 32-95 im Gateway-Host betroffen. Dieser Block wird nun aus dem Gateway-Host kopiert und in die ssl.conf eingefügt.
nano /etc/nginx/snippets/ssl.conf
In diesem Beispiel sind es die folgenden Inhalte.
# Certificates used ssl_certificate /etc/letsencrypt/live/meinedomain.de/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/meinedomain.de/privkey.pem; # Not using TLSv1 will break: # Android <= 4.4.40 # IE <= 10 # IE mobile <=10 # Removing TLSv1.1 breaks nothing else! # TLSv1.3 is not supported by most clients, but it should be enabled. ssl_protocols TLSv1.2 TLSv1.3; # Cipher suite from https://cipherli.st/ # Max. security, but lower compatibility ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384'; # Cipher suite from https://wiki.mozilla.org/Security/Server_Side_TLS #ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # (Modern) cipher suite from https://mozilla.github.io/server-side-tls/ssl-config-generator/ #ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits ssl_dhparam /etc/nginx/ssl/dhparams.pem; # Use multiple curves. # secp521r1: Not supported by Chrome # secp384r1: Not supported by Android (DAVdroid) ssl_ecdh_curve secp521r1:secp384r1:prime256v1; # Server should determine the ciphers, not the client ssl_prefer_server_ciphers on; # OCSP Stapling # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; # This should be chain.pem # See here: https://certbot.eff.org/docs/using.html ssl_trusted_certificate /etc/letsencrypt/live/meinedomain.de/chain.pem; resolver 192.168.178.1; # SSL session handling ssl_session_timeout 24h; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # # Add headers to serve security related headers # # HSTS (ngx_http_headers_module is required) # In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;"; add_header X-Content-Type-Options "nosniff"; add_header Referrer-Policy "no-referrer"; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; # Remove X-Powered-By, which is an information leak fastcgi_hide_header X-Powered-By;
Im nächsten Schritt werden nun diese SSL-Einstellungen aus dem Gateway-Host entfernt. Beispielweise also wieder die Zeilen 32-95. Damit die SSL-Einstellungen nun auch für den Gateway-Host gelten, wird nun statt dem entfernten Block einfach folgende Zeile mit übernommen:
include /etc/nginx/snippets/ssl.conf;
Wichtig ist hier v.a., dass die Anweisungen nicht doppelt aufgeführt sind (einmal im Gateway-Host direkt und einmal durch den Include). Daher müsen die eigentlichen SSL-Anweisungen auch aus dem Gateway-Host entfernt werden.
Anschließend starten wir den Webserver neu:
service nginx restart
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:
nano /etc/nginx/conf.d/onlyoffice.meinedomain.de.conf
Der Inhalt ist hier recht übersichtlich:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name onlyoffice.meinedomain.de;
# Include SSL configuration
include /etc/nginx/snippets/ssl.conf;
#
# Configuration for OnlyOffice
#
location / {
proxy_pass https://192.168.178.60:4433;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
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:
mkdir -p /app/onlyoffice/DocumentServer/data/certs cd /app/onlyoffice/DocumentServer/data/certs openssl genrsa -out onlyoffice.key 4096 openssl req -new -key onlyoffice.key -out onlyoffice.csr openssl x509 -req -days 3650 -in onlyoffice.csr -signkey onlyoffice.key -out onlyoffice.crt openssl dhparam -out dhparam.pem 4096 chmod 400 onlyoffice.key chmod 400 onlyoffice.crt chmod 400 onlyoffice.csr chmod 400 dhparam.pem
- 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:
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
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-secret – hier 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.
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:
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:
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).
- 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:
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:
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:
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:
docker stop ONLYOFFICEDOCKER docker rm ONLYOFFICEDOCKER
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:
docker system prune -a docker image prune -a docker container prune
Anschließend wird die neuste Version des Containers heruntergeladen und über den bekannten Befehl gestartet:
docker pull onlyoffice/documentserver 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
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
Generelle Fehlersuche
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).
nano /var/log/nginx/error.log
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:
docker logs ONLYOFFICEDOCKER
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:
sudo docker exec -it ONLYOFFICEDOCKER bash
Auf der Kommandozeile des Containers kann dann eine detaillierte Fehlersuche stattfinden. Mit folgendem Befehl kann man beispielsweise die Webserver-Logs einzusehen:
nano /var/log/nginx/error.log
Um die Kommandozeile des Containers wieder zu verlassen, reicht folgender Befehl:
exit
Spezifische Fehler
Das Öffnen eines Dokuments resultiert in einem leeren Browser-Fenster, obwohl der Document Server läuft
Dieser Fehler äußert sich meist so, dass der Document Server anscheinend ordnungsgemäß gestartet wurde und der Aufruf der OnlyOffice-Domain im Browser (https://onlyoffice.meinedomain.de) eine entsprechende Meldung anzeigt.
Allerdings können in Nextcloud keine Dokumente geöffnet werden – das Browser-Fenster bleibt einfach leer.
Hier werfen wir zunächst einen Blick in die Developer-Konsole des Browsers (F12). Hier wird vermutlich eine Fehlermeldung angezeigt, die auf ein Problem mit den „X-Frame-Options“ hinweist:
Laden verboten durch X-Frame-Options: „SAMEORIGIN“ von „https://onlyoffice.meinedomain.de/5.4.2-46//web-apps/apps/…46&lang=de-DE&customer=ONLYOFFICE&frameEditorId=iframeEditor“, Website erlaubt keine quellübergreifende (cross-origin) Frames von „https://meinedomain.de/nextcloud/apps/onlyoffice/169?filePath=test.ods“
Die Ursache ist dabei, dass der Header X-Frame-Options beim Aufruf der OnlyOffice-Domain gesetzt wurde. Dieser darf für den virtuellen Host, der für die OnlyOffice-Domain zuständig ist, nicht gesetzt werden.
Die Lösung besteht nun dain, die Stelle zu finden, an der dieser Header für die OnlyOffice-Domain gesetzt wird. Dazu durchsucht man den vHost für OnlyOffice und alle inkludierte Konfigurationen. Eine entsprechende Zeile kann dann beispielsweise folgendermaßen aussehen:
add_header X-Frame-Options "SAMEORIGIN" always;
Diese Anweisung ist dann für die OnlyOffice-Domain zu entfernen.
Nach den Änderungen und einem Neustart des Webservers kann es nun noch sein, dass der Browser-Cache einmal geleert werden muss. Anschließend sollten sich OnlyOffice-Dokumente über Nextcloud öffnen und bearbeiten lassen.
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
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
- Docker auf Ubuntu Server
- Nextcloud: Online-Office mit Collabora
Links
- Nextcloud-Homepage (englisch)
- Dynamisches DNS (Wikipedia)
- CNAME Resource-Record (Wikipedia)
- ONLYOFFICE-Homepage
- Docker-Homepage (englisch)
- Docker (Wikipedia)
- Get Docker-CE for Ubuntu (englisch)
- OpenDocument (Wikipedia)
- Office Open XML (Wikipedia)
- JSON Web Token (Wikipedia)
Hallo Jan,
wie immer TOP Anleitung.
Vielen Dank dafür.
Gruß Hans
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
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
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
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
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
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
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
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?
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
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
Hi Martin,
da scheint bei dir aber irgend etwas noch nicht zu passen:
Das „Ausknipsen“ der Zertifikats-Überprüfung mittels
'verify_peer_off' =>TRUEsollte 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
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
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
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", 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", 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", host: "onlyoffice.censored.de"
Vielen Dank schon einmal.
Grüße Stefan
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
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
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 ONLYOFFICEDOCKERdocker 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/documentserverDen Parameter
--restart=alwayshattest 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
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
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
Hallo Jan,
Wie immer ein erstklassiges Tutorial. Das System läuft auch hiermit stabil und zuverlässig.
Ich habe in meiner Einstellungen->Übersicht jetzt jedoch folgende Hinweise entdeckt:
„-Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
-Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
-Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
-Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
-Ihr Web-Server ist nicht richtig eingerichtet um .woff2-Dateien auszuliefern. Dies ist meist ein Thema der Nginx-Konfiguration. Für Nextcloud 15 wird eine Anpassung für die Auslieferung von .woff2-Dateien benötigt. Vergleichen Sie Ihre Nginx-Konfiguration mit der empfohlenen Nginx-Konfiguration in unserer Dokumentation.
-Der „Referrer-Policy“ HTTP-Header ist nicht gesetzt auf „no-referrer“, „no-referrer-when-downgrade“, „strict-origin“, „strict-origin-when-cross-origin“ oder „same-origin“. Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.“
Das Netz sagt, dass es sich um doppelt gesetzte Header handeln kann. Allerdings bringt das Auskommentieren hier keine Besserung, zumindest in einem schnellen Test.
Da die Header in diesem Tutorial in die ssl.conf ausgelagert wurden, vermute ich hier irgendwo den Bug.
Das Phänomen trat in einer NC14 Installation auf, besteht aber nach einem Update auf NC15 weiterhin.
Für deine Hilfe bin ich dir jetzt schon dankbar.
VG
Phillip
Hi Phillip,
ja, hier habe ich in der Tat ein Detail für NC 15 vergessen (woff2). Werde ich in den nächsten Tagen nochmal anpassen.
Bzgl. der Header ist es wirklich wichtig, dass diese nicht 2x gesetzt werden. Hier würde ich „von innen nach außen“ vorgehen, d.h. erst im vHost für NC die Header-Anweisungen entfernen, dann evtl. Vorkommnisse im Gateway-Host und dann nochmal testhalber in der ssl.conf.
Vorher aber bitte noch die bestehenden Config-Dateien sichern, man weiß ja nie…
Gruß,
Jan
Hallo Jan,
Der Kommentar von Jens Schuster am 15.11. hat die Lösung gebracht.
Habe ebenfalls die letzten sieben Zeilen wieder auskommentiert und im Gateway Host aktiviert.
Danach sind seltsamerweise alle Fehler, auch die woff2, aus der Übersicht verschwunden.
Gruß
Phillip
Ich nehme alles zurück.
Die woff2 Warnung kommt sporadisch wieder.
Mehrmaliges aktualisieren zeigt sie manchmal an.
Dafür sind nun ebenfalls sporadisch diese beiden Meldungen vorhanden:
„-Ihr Webserver ist nicht richtig konfiguriert um „/.well-known/caldav“ aufzulösen. Weitere Informationen hierzu finden Sie in der Dokumentation.
-Ihr Webserver ist nicht richtig konfiguriert um „/.well-known/carddav“ aufzulösen. Weitere Informationen hierzu finden Sie in der Dokumentation.“
Was mich verwundert ist, dass diese Meldungen nach Lust und Laune auftauchen. Mehrmaliges Aktualisieren der Seite ändert die Warnmeldungen.
Kennst du eine Lösung hierfür?
VG
Phillip
Hi Phillip,
wie gesagt, hier braucht es noch ein paar Anpassungen in den vHosts. Ich werde die Tage den entsprechenden Artikel (da dies nicht direkt mit OnlyOffice zu tun hat) nochmals überarbeiten. Dann sollten die Meldungen verschwunden sein.
Gruß,
Jan
Hi Phillip,
so, ich habe das Thema nun nochmal etwas näher untersucht und zwei (doch größere) Anpassungen vorgenommen.
Starte am besten mit dem Artikel zu Nextcloud. Hier waren diverse Anpassungen am Gateway-Host und am vHost für Nextcloud notwendig. Am besten wirklich mal Zeile für Zeile mit deinen vHosts vergleichen.
Im Rahmen dessen habe ich auch festgestellt, dass die Warnung bzw. /.well-known/webfinger auch erscheint, wenn dies vom Webserver her korrekt konfiguriert ist, man aber nicht die Social-App in Nextcloud installiert hat. In diesem Fall ist die Warnung also normal und kann ignoriert werden.
Das zweite Update betrifft den Artikel zu OnlyOffice. Hier müssen die Anweisungen für SSL (die ssl.conf) in einem anderen Verzeichnis gespeichert werden (ich habe hier mal das Verzeichnis /etc/nginx/snippets hergenommen). Hintergrund ist, dass ich feststellen konnte, dass es zu Problemen mit den Headern kommt (Warnungen in Nextcloud), wenn die ssl.conf im Verzeichnis der restlichen vHosts gespeichert wird (also in /etc/nginx/conf.d). Wenn die Datei woanders gespeichert wird, scheint es aber zu keinen Problemen mehr zu kommen.
Sorry, wenn ich dir da nun durch die Änderungen an beiden Artikeln etwas Arbeit gemacht habe. Jetzt ist es aber auf jeden Fall besser gelöst und optimal auf Nextcloud 15 abgestimmt.
Gruß,
Jan
Hallo Jan!
Ich hänge gerade an folgendem Punkt fest:
„Im nächsten Schritt werden nun genau diese Einstellungen aus dem Gateway-Host entfernt und durch eine einzige Zeile ersetzt“
Welche Datei genau muss hier mit neuem Inhalt gefüllt werden?
Schon jetzt herzlichen Dank!
:)
Hi,
es geht hier eigentlich nur darum, dass die Anweisungen für SSL und die Header aus dem Gateway-Host entfernt werden und in eine eigene Datei (die ssl.conf) übertragen werden. Wenn wir vom Nextcloud-Tutorial ausgehen (siehe hier), dann sind das die Zeilen 32-95. Diese Inhalte landen in der ssl.conf und werden dann über ein Include wieder in den Gateway-Host eingebunden.
Wichtig ist hier, dass keine Anweisungen doppelt auftauchen (also einmal im Hateway-Host direkt und einmal durch den Include).
Ich habe soeben diesen Artikel noch mal ein wenig angepasst, so dass es nun hoffentlich klarer sein sollte.
Gruß,
Jan
Hallo Jan,
zuerst mal: FABELHAFT, was du hier leistest. Meinen ganz grossen Respekt, vor allem, dass du deine Anleitungen immer aktualisierst und auch „rund um Nextcloud“ Anleitungen anbietest.
Aber wie könnte es auch anderst sein: ich hab dennoch eine „kleine“ Frage:
Meine OnlyOffice-Installation läuft prinzipiell, dennoch hab ich in der NC-Protokollierung immer diese PHP-Fehlermeldungen:
Undefined offset: 2 at /var/www/nextcloud/apps/onlyoffice/controller/editorcontroller.php#434
count(): Parameter must be an array or an object that implements Countable at /var/www/nextcloud/apps/onlyoffice/lib/appconfig.php#477
Sagen dir diese Meldungen etwas oder kann ich die ignorieren ?
Zusatzinfo: das ganze unter NC15.0, PHP7.2 sowie der aktualisierten Onlyoffice-Version 5.2.6
Kann das an der der noch offenen Warnung aus der NC-Systemkonfiguration liegen:
„Bei einigen Spalten in der Datenbank fehlt eine Konvertierung in big int. Aufgrund der Tatsache, dass das Ändern von Spaltentypen bei großen Tabellen einige Zeit dauern kann, wurden sie nicht automatisch geändert. Durch Ausführen von „occ db: convert-filecache-bigint“ können diese ausstehenden Änderungen manuell übernommen werden. Diese Operation muss ausgeführt werden, während die Instanz offline ist.
filecache.mtime
filecache.storage_mtime
Über einen Hinweis oder Unterstütung wäre ich dir wahnsinnig dankbar.
Schöne Grüsse Rainer
Vielen Dank für diese Anleitung! Läuft sehr gut.
:)
Mein persönlicher Hinweis bezüglich der Variante Collabora: OnlyOffice schont die Ressourcen des Servers deutlich besser, da die Darstellung und die Applikation selbst beim Client berechnet und zur Verfügung gestellt werden.
Insgesamt läuft OnlyOffice etwas geschmeidiger. Collabora bietet ausserdem weniger Funktionen für die Bearbeitung von Dokumenten.
Hi,
in der Tat ein interessanter Hinweis. Ich habe mich auch noch nicht für eine Office-Lösung entschieden. Momentan läuft bei mir beides parallel.
Gruß,
Jan
Hallo Jan!
Das ist ja interessant. Du hast beide am laufen? Ohne Probleme? Ich hab das ebenfalls versucht, aber bekomme nur das eine oder das andere Paket zum laufen.
Für beide hab ich eine eigene Subdomain angelegt. Bei Collabora muss ich aber im Adminpannel unter den Einstellungen immer die URL der Nextcloud-Installation angeben und nicht die eigens für Collabora eingerichtete, damit überhaupt etwas von Collabora sichtbar wird.
Nach dem Update auf 15.0.2 war dann Collabora nicht mehr funktionsfähig. Die Funktionen um Dateien zu erstellen und zu bearbeiten sind zwar in Nextcloud vorhanden, aber dem Aufruf der Funktion blieb der Bildschirm weiss.
Hi,
ja, beides lasse ich parallel jeweils mit Docker laufen, das stört sich gegenseitig nicht.
Jedoch braucht nur OnlyOffice eine eigene Subdomain, Collabora läuft im Kontext der Domain der Nextcloud. Das wird dann beim Starten des Collabora-Containers und in den Nextcloud-Einstellungen festgelegt.
Ob man Collabora mit einer eigenen Subdomain betreiben kann, weiß ich aktuell gar nicht. Erforderlich ist es auf jeden Fall nicht.
Auch das Update auf Nextcloud 15.0.2 hat an der Collabora-Installation nichts verändert – funktioniert bei mit nach wie vor.
Gruß,
Jan
Hallo Ja,
vielen dank für den Hinweis und toll zu sehen das bei dir beides parallel läuft. Das hat mich jetzt dazu ermuntert es nochmals mit Collabora anzugehen und siehe da, jetzt hat hat geklappt und beide Container laufen parallel. Wobei ich ehrlich nicht sagen kann warum es jetzt klappt und es vorher das nicht hat. :)
Bezüglich OnlyOffice: Hast du da in den LogFiles auch folgende Fehlermeldung:
count(): Parameter must be an array or an object that implements Countable at /var/www/nextcloud/apps/onlyoffice/lib/appconfig.php#477
?
Undefined offset: 2 at /var/www/nextcloud/apps/onlyoffice/controller/editorcontroller.php#434
oder läuft OnlyOffice bei dir komplett ohne Fehlermeldung?
Hi,
ja, manchmal hilft es, einfach nochmal von vorn zu beginnen. Super, dass es nun auch bei dir klappt.
Und ja, die Fehlermeldung kommt mir bekannt vor. Hier muss wohl etwas in der OnlyOffice-App geupdatet werden.
Gruß,
Jan
Hallo,
auch hier erstmal danke für die tolle Anleitung. Leider habe ich eine etwas andere Ausgangssituation. Meine Nextcloud läuft nicht auf dem Port 443 sondern auf 8443 (https://mydomain.de:8443/nextcloud)
Ich habe nun leider erfolglos versucht eine Verbindung mit OnlyOffice herzustellen. Kannst du mir da vielleicht bitte weiter helfen.
Vielen Dank
Gruß Andreas
Hi Andreas,
hier müsstest du vermutlich den Port ändern, auf den der vHost für OnlyOffice lauscht (also in der Datei /etc/nginx/conf.d/onlyoffice.meinedomain.de.conf).
Der Rest der Anleitung sollte eigentlich gleich bleiben.
Gruß,
Jan
Hallo Jan,
ich habe den vHost wie folgt geändert:
server {
listen 8443 ssl http2;
server_name onlyoffice.myDomain.de;
# Include SSL configuration
include /etc/nginx/snippets/ssl.conf;
#
# Configuration for OnlyOffice
#
location / {
proxy_pass https://192.168.1.8:4433;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Leider ohne Erfolg. Ich bekomme ein 403 Forbidden.
Hast du noch ein andere Idee?
Gruß Andreas
Hi Andreas,
lässt sich die Übersichtsseite aufrufen, also https://onlyoffice.meinedomain.de:8443?
Hast du das JWT-Secret bei der Einrichtung von OnlyOffice in den Nextcloud-Settings korrekt eingegeben?
Gruß,
Jan
Hallo Jan,
nein. Wenn ich die Übersichtsseite aufrufen möchte bekomme ich den 403 Forbidden.
Local über 192.168.1.8:4433 funktioniert es
Ja denke ich habe das richtig eingeben.
Gruß Andreas
Hi Andreas,
ich denke, den 403 bekommst du dadurch, dass er nicht den richtigen vHost trifft und daher den normalen Gateway-Host erwischt. Hier ist die location „/“ ja mit einem „deny all“ versehen. OnlyOffice an sich scheint ja ordnungsgemäß zu funktionieren.
Daher vermute ich, dass der Fehler „davor“ passiert. Konkret, dass hier irgendwas mit der Sub-Domain nicht stimmt. Ist hier ein CNAME-Eintrag gesetzt, der auf deine DynDNS-Domain verweist?
Gruß,
Jan
Hallo Jan,
ich bin ein Stück weiter gekommen.
Wenn ich die Übersichtsseite mit „https://mydomain.de:8443/welcome“ wird mir diese angezeigt. Versuche ich jedoch nur „https://mydomain.de:8443“ dann wird daraus https://mydomain.de/welcome (ohne :8443 was natürlich nicht funktioniert)
Versuche ich die Einstellung für den Serviceadresse der Dokumentbearbeitung in Nextcloud zu setzten erhalte ich den Fehler:
Fehler beim Anschließen (Im Dokumentenservice ist ein Fehler aufgetreten: Error while downloading the document file to be converted.)
Gibt es eine Möglichkeit den Redirect so zu machen, dass der Port in der Adresse drin bleibt? Ich denke da liegt das Problem.
Gruß Andreas
Hallo Andreas,
weil du bei der Eingabe von https://mydomain.de:8443 auf https://mydomain.de/welcome weitergeleitet wirst, sieht es für mich so aus, als ob schon der richtige vHost erwischt wird.
Ich bin da gerade etwas überfragt, ob OnlyOffice überhaupt mit einem abweichenden Port funktioniert. Auch findet man dazu nur sehr wenig im Internet. Ich habe nur hier etwas gefunden, was in etwa in die gleiche Richtung geht. Der Thread rutscht zwar später ins Russische, aber hier werden ein paar alternative URLs gelistet, die man bei der Verbindung NC->OnlyOffice ausprobieren kann.
Ansonsten wüsste ich nun auch nicht viel weiter. Hast du schon mal in die Logs von OnlyOffice gesehen wie im Artikel beschrieben?
Gruß,
Jan
Also echt geile Anleitung – die man auch mal versteht, weil wirklich alles Schritt für Schritt erklärt wird.
Die NextCloud installation habe ich bereits erfolgreich durchgeführt.
Jetzt wollte ich noch die OnlyOffice installation nachziehen – hier stoße ich nur auf 2 kleine probleme.
1. Der Container scheint nicht wohl nicht bei einem Neustart mitzstarten (villeicht bin ich auch nur einfach zu ungeduldig)
2. Die OnlyOffice Seite bekomme ich auch Angezeigt (das der Service läuft). Allerdings bekomme ich beim Verbinden von der Nextcloud zu OnlyOffice einen Timeout – Könntest du mir einen Tipp geben wo das problem liegen könnte.
Hi Bastian,
Der Container sollte eigentlich durch den Zusatz
--restart=alwaysim Start-Befehl automatisch nach einem Neustart des Rechners mit gestartet werden. Manchmal dauert das einfach ein wenig länger. Falls es mal ganz hängen sollte, hilft oft auch ein nochmaliger Neustart des kompletten Rechners. Das war bei meinen Installationen allerdings schon lange nicht mehr notwendig.Bei der Verbindung von OO zu NC wäre v.a. das Nextcloud-Log (bzw. auch das nginx error.log) interessant. Nur hier dürfte eine genauere Fehlermeldung zu finden sein. Ansonsten: Richtige Server-Adresse (mit HTTPS) und JWT-Secret eingegeben?
Gruß,
Jan
Hallo Jan,
klasse Tutorial. Ich habe leider ein Problem mit dem SSL Zertifikat für meinen Subdomain. Im Nextcloud Log ist folgender Fehler drin wenn ich die onlyoffice Instanz einbinden möchte:
HealthcheckRequest on check error: cURL error 60: SSL certificate problem: self signed certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)
Auch der Aufruf meiner Subdomain über den Webbrowser zeigt einen Zertifikatsfehler. Der Aufruf der Hauptdomain klappt ohne Probleme.
Kannst du mir einen Tipp geben warum das neue Zertifikat die Subdomain nicht beinhaltet?
Vorstufe zu der Installation war dein Tutorial für die Installation von Nextcloud unter Ubuntu:
https://decatec.de/home-server/nextcloud-auf-ubuntu-server-18-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/#Generierung_des_SSL-Zertifikats
Danke vorab.
Gruß Bernd
Hi Bernd,
wenn der Aufruf der Subdomain bereits eine Zertifikats-Warnung ergibt, dann hast du wohl das falsche Zertifikat (das selbst signierte) verwendet, um „die Verbindung nach außen“ herzustallen. Das selbst signierte Zertifikat wird ausschließlich dem OnlyOffice-Container übergeben, so dass die interne Kommunikation hier auch per HTTPS ablaufen kann.
Nach außen brauchst du eine Subdomain für OnlyOffice (hast du ja wohl bereits) und für diese Domain ein trusted Zertifikat von Let’s Encrypt. Wenn du also eine DynDNS-Domain nextcloud.meinedomain.de hat (aus dem NC-Artikel), dann brauchst du eine zweite Subdomain onlyoffice.meinedomain.de, die per CNAME auf nextcloud.meinedomain.de verweist. Bei der Zertifikats-Generierung müssen dann beide Domains (nextcloud/onlyoffice) angegeben werden, so dass das resultierende Zertifikat dann für beide Domains gültig ist. Genau dieses Zertifikat (und nur dieses) wird im vHost von nginx als zu nutzendes Zertifikat für HTTPS hinterlegt. Hier hat ein selbst signiertes Zertifikat nicht verloren.
Gruß,
Jan
Hallo Jan,
vielen Dank für die Rückmeldung. Das selbst signierte Zertifikat habe ich aktuell nicht erstellt, da die Kommunikation innerhalb der selben Maschine abläuft. Dies möchte ich ein andermal nachziehen.
Der aktuell Stand ist folgender:
Ich habe einen vServer bei einem Hostingprovider. Dort ist die Domain inkl. der Subdomain angelegt. Laut certbot certificate sind im Let’sEncrypt Zerfifikat beide Domäns vorhanden.
Gruß Bernd
Hallo Jan,
ich hab den „Fehler“ gefunden. Der saß vor dem Bildschirm. :)
Ich habe in den OnlyOffice Einstellungen in Nextcloud den Port 4433 mit eingetragen. Wenn ich den Port weglasse und nur die Subdomain eintrage funktioniert es.
Hi Bernd,
OK, dann hat sich das Problem ja erledigt.
Danke für die Rückmeldung.
Gruß,
Jan
Hallo Jan,
Nochmals vielen Dank für deine Arbeit und die Bereitstellung solcher Anleitungen.
Für mich als Neuling in diesem Bereich ist es doch eine sehr große Hilfe.
Mach weiter so. Einfach Top
Gruß Bernd
Hallo, ich hab das ganze etwas anders installiert, und zwar wie folgt:
Ich habe die Nextcloud auf einem Ubuntu Server 18.04 mittels SNAP installiert und ein Lets Encrypt Zertifikat drauf gemacht.
Dann habe ich das Docker Image von OnlyOffice installiert und ein selbstsigniertes Zertifikat installiert.
Diese Dateien hab ich ausgetauscht mit den Zertifikaten der Nextcloud und die Endungen von pem in crt geändert.
Ich starte die Docker Instanz mit den Port Parameter 4433:443 und der Dokument Server ist über die No IP Adresse gesichert erreichbar.
Will ich nun in Nextcloud den Document Server verbinden, erhalte ich folgende Meldung:
Fehler beim Anschließen (cURL error 60: SSL certificate problem: unable to get local issuer certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html))
Leider werde ich nicht schlau daraus.
Die Nextcloud ist gesichert erreichbar über https://irgendwas.sytes.net
Der Documentserver ist gesichert erreichbar über https://irgendwas.sytes.net:4433
Auch wenn ich nicht alles ganz genau nach obiger Anleitung gemacht habe, nämlich kein CNAME eingerichtet (Weil das bei No IP glaub ich mit nem Free Account gar nicht geht), hoffe ich auf ein Tip :)
Viele Grüsse
Traw
Hi Traw,
laut der Dokumentation braucht OnlyOffice genau zwei Zertifikat-Dateien: onlyoffice.key und onlyoffice.crt
Ich denke, dass die Dateien genau so heißen müssen. Auch bin ich mir nicht sicher, ob du das fullchain.pem oder das ca.pem entsprechend umbenennen musst. Einfach mal ausprobieren.
Gruß,
Jan
Hallo,
danke für die tolle Anleitung. Ich scheitere jedoch daran, dass ich bei der Konfiguration des Plugins innerhalb von nextcloud nur eine Fehlermeldung bekomme:
eingetragen bei Serviceadresse habe ich: https://onlyoffice.xxx.de/
„Fehler beim Anschließen (cURL error 7: Failed to connect to onlyoffice.xxx.de port 443: Connection refused (see http://curl.haxx.se/libcurl/c/libcurl-errors.html))“
ich kann onlyoffice.xxx.de aber aufrufen und bekomme auch die Meldung, dass der Server läuft. Ausgewiesen wird hier das letsencrypt zertifikat
über die IP kann ich das ganze auch aufrufen, mit :4433 – hier wird das selfsigned zertifikat ausgewiesen.
Hi Michael,
die Meldung könnte leider viel bedeuten. Gibt es hier Einträge im Nextcloud Log, die vielleicht etwas aufschlussreicher sind?
Das Secret, was du beim Starten des Containers angegeben hast, hast du auch in den Einstellungen zum Plugin eingefügt?
Gruß,
Jan
noch eine Ergänzung, wenn ich in /etc/hosts die adresse onlyoffice.xxx.de auf die lokale IP binde, erhalte ich anschließend eine andere fehlermeldung, die da lautet:
GetConvertedUri on check error: Im Dokumentenservice ist ein Fehler aufgetreten: Error while downloading the document file to be converted.
Hi Michael,
das Binden der Domain auf die lokale IP ist hier nicht notwendig und ich denke auch mal eher kontraproduktiv.
Was sagt das Nextcloud-Log (ohne Modifizierung der hosts)?
Gruß,
Jan
Hi,
also das hier sagt das NC-Log:
{„reqId“:“arrn2EevA15HcduhdNz2″,“level“:3,“time“:“2019-04-30T15:37:22+02:00″,“remoteAddr“:“192.168.101.13″,“user“:“user“,“app“:“onlyoffice“,“method“:“PUT“,“url“:“\/apps\/onlyoffice\/ajax\/settings“,“message“:“HealthcheckRequest on check error: cURL error 7: Failed to connect to onlyoffice.kolping.cloud port 443: Connection refused (see http:\/\/curl.haxx.se\/libcurl\/c\/libcurl-errors.html)“,“userAgent“:“Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/73.0.3683.103 Safari\/537.36″,“version“:“15.0.2.0″}
Hi Michael,
dein OnlyOffcie-Server läuft ja, wenn man die URL so aufruft. Auch der Aufruf von https://onlyoffice.kolping.cloud/healthcheck liefert „true“. Evtl. mal ohne den Slash am Ende in die OnlyOffice-Nextcloud-Konfiguration eintragen.
Wenn das auch nicht klappen sollte, dann bitte nochmals das nginx error.log checken, denn dann wird hier vermutlich eine falsche URL angefragt.
Gruß,
Jan
der „/“ am ende ändert leider nix – fehlermeldung besteht. Wo find ich das nginx log?
Danke !
Hi Michael,
findest du unter /var/log/nginx
Gruß,
Jan
https://pastebin.com/BXAg8Pbb
hier der Auszug aus dem Zeitfenster. mir hiflt das net viel. Die 13 ist das Gateway.
Hi Michael,
leider sehe ich in den Logs nur den Request, mit dem die OnlyOffice-Settings geschrieben werden sollen (PUT auf /apps/onlyoffice/ajax/settings). Kommt danach nichts mehr?
Füge doch testhalber mal folgende Zeilen in die config.php von Nextcloud ein:
'onlyoffice' =>array (
'verify_peer_off' => true,
),
OnlyOffice zickt mal gerne rum, wenn mit den Zertifikate etwas nicht passt. So tasten wir uns langsam an den Fehler ran.
Gruß,
Jan
Guten Morgen,
den Abschnitt hatte ich bereits in der config.php eingebaut.
Hi Michael,
puh, langsam bin ich da etwas ratlos.
Ich würde da mal im Nextcloud-Forum nachfragen (wenn es denn wieder funktioniert), ob da jemand noch einen heißen Tipp hat.
Kann aber auch sein, dass wir irgend etwas übersehen haben. Ist es für dich eine Option, OnlyOffice und alle Einstellungen/Apps/etc. zu entfernen und den Artikel nochmal Schritt für Schritt von vorne durchzuarbeiten? Vielleicht wurde da ein kleiner Schritt übersehen oder so.
Gruß,
Jan
Bin grad noch am testen, irgendwie scheint es evtl. was mit dem Zugriff über unser Gateway zu tun zu haben. eigentlich sollte ich ja über „wget xxx.cloud“ einen download zurück bekommen, allerdings bekomme ich hier immer connection refused. Irgendwie scheinbar weil er mit der gleichen externen ip zugreifen will von der er auch kommt. mal sehen ob und wie wir das lösen können.
Okay nun bekomme ich …
“ GetConvertedUri on check error: Im Dokumentenservice ist ein Fehler aufgetreten: Error while downloading the document file to be converted.“
Hi Michael,
die Fehlermeldung hast du mittels wget bekommen?
Sieht auf jeden Fall schon einmal so aus, als ob OnlyOffice erreichbar ist und der Fehler erst hier auftritt.
Dann solltest du nun auch im Docker-Container selbst nach Fehlern/Auffälligkeiten suchen (wie hier beschrieben).
Gruß,
Jan
Vorab wirkliche ein sehr guter Artikel. Es hat alles wunderbar geklappt nur leider bekomme ich einen CURL60 Fehler wenn ich die OnlyOffice App in Nextcloud aktivieren will. Hast du dafür vielleicht eine Lösung?
Hi Detlef,
hast du die Zertifikate mit genau den gleichen Dateinamen an den Docker-Container übergeben?
Ansonsten mal das Nextcloud-Log und auch das error.log von nginx mal ansehen, ob hier mehr Infos zu dem Fehler gefunden werden können.
Gruß,
Jan
Hallo Jan, erstmal vielen Dank, dass Du dein Wissen mit uns teilst.
Ich versuche gemäß deiner Anleitung unter Nextcloud 15.07 Onlyoffice zum rennen zu bekommen. (Alte Anleitung mit Docker ohne Subdomain)
Dies hat auch soweit geklappt, der Dokumentenserver läuft „Document Server is running“. Nun will ich die Nextcloudapp an den Server binden und bekomme folgende Meldung in den Nextcloud APP, nachdem ich alle erforderlichen Daten in die Felder eingetragen habe: „GetConvertedUri on check error: Im Dokumentenservice ist ein Fehler aufgetreten: Error while downloading the document file to be converted.“ Habe schon einiges versucht und komme nicht weiter. Hast du einen Tipp für mich?
Der Server ist nur ein interner Server welcher nicht im Internet steht, das ganze soll nur lokal im Netz laufen, daher muss ich auch nicht Domains und Subdomains arbeiten.
Die Config.php von Nextcloud habe ich bereits bearbeitet:
‚onlyoffice‘ =>
array (
‚verify_peer_off‘ => TRUE,
)
Die default.json aus dem Dockercontainer habe ich auch bearbeitet:
„rejectUnauthorized“: false
Hi,
check dazu bitte mal das Nextcloud-Log bzw. das nginx error.log. Da sollte eigentlich etwas mehr zu dem Fehler drin stehen.
Gruß,
Jan
Hallo Jan,
ich hatte nun mal wieder etwas Zeit und habe Nägel mit Köpfe gemacht und diese Anleitung durchgeackert. Vorab bin ich jedoch deinen anderen Anleitungen und gefolgt und habe den NextCoudserver inkl. OnlyOffice bis hier hin komplett neu aufgebaut. Ich hatte zwar noch einige Probleme zu meistern, aber nun läuft die Kiste. Man sollte sich exakt an dieses Setup halten, dann klappt es.
An dieser Stelle sei dir nochmal vielmals gedankt, dass Du uns hier dein Wissen zur Verfügung stelltst. Ich hoffe, dass bei den ganzen Posts hier auch Spenden dabei sind. Ich werde auf jeden Fall etwas spenden :-)
Nun aber zu meinen Fragen:
1. NextCloud: wenn ich nun „http://cloud.meinedomain.de“ eingebe, lande ich auf der nginx forbidden seite 403. Man wird dann auf „https://cloud.meinedomain.de“ umgeleitet. Es bleibt jedoch bei einer 403-Seite. (SSL Zert ist jedoch OK)
Gebe ich nun ein: „http://cloud.meinedomain.de/nextcloud“ komme ich erst dann ordentlich auf die NextCloud. Ist das so korrekt oder habe ich bei deinen Anleitungen doch noch etwas übersehen? Was muss ich tun, damit die Domain egal mit welchem Protokoll man diese anspricht „cloud.meinedomain.de“ einen redirect direkt auf „http://cloud.meinedomain.de/nextcloud“ macht?
2. Besser in meinem Fall wäre jedoch, dass der nginx-Server beim Aufruf der Domain „cloud.meinedomain.de“ direkt in „https://cloud.meinedomain.de/“ zeigen würde, statt „http://cloud.meinedomain.de/nextcloud/“
Kann ich das leicht bewerkstelligen ohne mir gleich wieder die nun funktionierende Konfig zu zerschiessen? An welchen *.confs muss ich da überall dran oder sollte man das ganze aufgrund des gesamten Gerüstes so stehen lassen?
3. Ubuntuserver18LTS, inkl. NextCloud und OnlyOffice, die Anleitungen sind ziemlich komplex. Könnte man das Ganze nicht in ein Installscript mit entsprechenen Abfragen an den Benutzer packen damit so ein Setup automatisch abläuft? Like nextCloudPi
4. Gibt es da irgendwelche Erfahrungswerte, ob man ein OnlyOffice Docker-Setup an eine vorhandene nextCloudPi-Installation andocken kann?
Fragen über Fragen, mir würde es schon sehr weiterhelfen, wenn ich Frage 1u.2 gelöst bekommen würde.
Vielen Dank vorab!
Hallo,
erst mal danke für das Lob, freut mich sehr.
Zu deinen Fragen:
1 und 2: Du möchtest Nextcloud also direkt über die Domain und nicht über ein Unterverzeichnis aufrufen. In diesem Fall kannst du dich mehr oder weniger direkt an das NC-Admin-Manual halten (siehe hier – „Nextcloud in the webroot of nginx“). Den Gateway-Host benötigtst du dann eigentlich nicht mehr, der macht die Sache eher komplizierter. Danach kannst du NC direkt über https://cloud.meinedomain.de aufrufen.
3. Man könnte sicher alles in ein Skript packen. Jedoch müsste man hier vor der Ausführung noch Hand anlegen. Teilweise auch an sehr vielen Stellen, so dass dies dann vermutlich noch mehr Fragen aufwirft. Wichtiger ist es mir, dass der Admin die einzelnen Schritte versteht, daher sind die Artikel entsprechend umfangreich mit viel Erklärungen dazwischen.
4. NextcloudPi läuft nur auf einem Raspberry, oder? In diesem Fall dürfte das zwar technisch gehen, aber die Performance dürfte dann ziemlich in den Keller gehen. Das Docker-Image verbraucht halt konstant RAM, und davon hat der Pi nun mal nicht sonderlich viel.
Gruß,
Jan
Hallo Jan,
zu NextCloudpi, so heisst das Projekt, jedoch gibt es das nicht nur für den RPI.
Das Programmiererteam stellt schon eine Weile das ganze per Installscript für Debian, Ubuntu, etc. zur Verfügung. Daher läuft läuft so eine Maschine bereits produktiv auf einem dicken Server. Nun kam ich auf die Idee, dort noch per Docker das Onlyoffice anzuklemmen. Auf internen Testsystemen klappte das immer. Sobald ich jedoch öffentliche Domains ins Spiel brachte konnte vom Nextcloud keine Verbindung zu zum intenen Onlyoffice hergestellt werden. Mit deiner Anleitung nun hatte ich beiden nun zum Laufen bekommen. Das einzige mit dem Unterordner, dies würde ich noch ändern wollen.
MfG
Hi,
OK, ich dachte, NextcloudPi wäre wirklich nur für den Raspberry. Danke für den Hinweis – wieder was gelernt.
Wenn das dann auf einem „dicken“ Server läuft, spricht natürlich nichts dagegen, daneben auch OnlyOffice aufzusetzen.
Gruß,
Jan
Hallo Jan,
erstmal vielen lieben Dank für deine prima Arbeit hier auf deinem Blog.
Und wie soll es auch anders sein, habe ich ein kleines Problem bei dem du mir evtl. weiterhelfen kannst.
Und zwar bekomme ich so eine Fehlermeldung wie mein Vorschreiber Detlef. Beim Versuch onlyoffice in der Nextcloud Weboberfäche zu aktivieren bekomme ich folgenden Errorlog:
Error onlyoffice HealthcheckRequest on check error: cURL error 60: SSL certificate problem: self signed certificate (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)
Deine Antwort auf Detlefs Frage ist bestimmt schon die Lösung, aber leider verstehe ich nicht was du damit meinst. Könntest du versuchen es noch etwas leichter zu formulieren, oder evtl. ein Bsp. zeigen?
Viele Grüße
Jörg
Hi Jörg,
das erste meint, dass die Zertifikats-Dateien genau so heißen müssen, wie in dem Code-Schnipsel angegeben (also alles ab
openssl genrsa -out onlyoffice.key 4096). Auch muss der Befehl zum Starten des OnlyOffice-Conainters genau so lauten, wie im Artikel angegeben (bis auf das Secret).Ansonsten findest du evtl. weitere Infos im Nextcloud-Log (Nextcloud-Admin-UI), oder im nginx error.log (/var/logs/nginx/error.log).
Gruß,
Jan
Moin Jan,
nach intensiven beackern deiner Anleitungen, ist mir dann doch eine Idee gekommen. Ich habe dann alle vHost’s nochmal überprüft und siehe da, bin ich fündig geworden.
Ich hatte beim Gateway-Host den proxy_pass noch auf 127.0.0.1:81 stehen. Dieser proxy_pass-Port 81 muss ja aber mit dem Port vom Nextcloud-Host übereinstimmen. Lösung -> proxy_pass 127.0.0.1:82
Nun läuft es wie es soll.
Danke
Viele Grüße
Jörg
Hi Jörg,
alles klar, dann ist das Problem ja beseitigt.
Danke für deine Rückmeldung!
Gruß,
Jan
Hallo Jan,
das Ganze müsste doch auch mit dem OnlyOffice Community Server anstatt dem Dokumenten Server funktionieren, oder?
Hi Bernd,
das kann ich dir leider nicht sagen. Ich nehme halt immer das Docker-Image, welches dafür empfohlen wird.
Gibt es für den Community-Server auch ein Docker-Image? Dann einfach mal damit ausprobieren. Ich kann mir allerdings vorstellen, dass die NC-App nur mit dem Dokumenten-Server zusammen arbeitet.
Gruß,
Jan
Moin Jan,
habe schon seit einer ganze Weile onlyoffice erfolgreich am laufen. Nun wollte ich zwecks einfacherer Updates des Containers das run-script durch ein compose-script ersetzten (habe den alten Container noch nicht gelöscht). Ich erhalte jedoch in der neuen Instanz beim Versuch ein Dokument zu öffnen folgenden Fehler:
„Sicherheitstoken des Dokuments nicht korrekt.“
Selbst mit innerhalb von NC16 neu erstellten Dokumenten funktioniert es nicht. Zum Glück kann ich noch auf den alten Container zurückwechseln…
Eine Idee wie ich diesem Fehler beikommen kann?
Mein compose-script:
version: ‚3‘
services:
documentserver:
container_name: onlyoffice
# container_name: ONLYOFFICEDOCKER #alter Containername
image: onlyoffice/documentserver:latest
environment:
– JWT_ENABLED=true
– JWT_SECRET=’geheim‘
stdin_open: true # aus docker run -i
tty: true # aus docker run -t
restart: always
volumes:
– /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data
ports:
– ‚4433:443‘
Hallo Niklas,
sorry, aber mit Docker Compose habe ich bisher noch keinerlei Erfahrungen. Daher befürchte ich, dass ich dir damit nicht wirklich weiter helfen kann.
Was ist denn beim Compose anders, bzw. was hat dies für Vorteile?
Gruß
Jan
Das hat für mich hauptsächlich Vorteile beim „updaten“ der Container, wenn ein neues Image eingespielt werden soll. Die Einstellungen, die im mit run übergeben werden, liegen dann in einer Datei „docker-compose.yml“ und es braucht nur 3 Befehle für das Update:
docker-compose down
docker image rm oder docker image prune
docker-compose up
Das ganze kann man auch noch mit Abhängigkeiten versehen, sodass andere, für den jeweiligen Dienst benötigte Container entsprechend mit gestartet/geupdated werden, z.B. redis, mariadb, php, uvm.
Grüße
Niklas
Hi Niklas,
OK, das macht Sinn, besonders wenn man viele Container am Laufen hat.
Da das bei mir nur OnlyOffice und Collabora sind, mache ich den Update-Vorgang vielleicht einmal im Monat manuell.
Gruß,
Jan
Von meiner Seite nochmal ein großes Lob an Jan für das excellent Tutorial. Wenn man die Schritte exakt befolgt läuft Onlyoffice auf Anhieb.
Mir persönlich gefällt die herausragende Funktionalität von Onlyoffice. Da kann Google Docs bei Weitem nicht mithalten. Z.B. lassen sich sogar Formeln editieren. Ebenfalls herausragend ist die Kompatibilität mit MS-Office Dokumenten. Hier stimmt einfach alles.
Einziger Haken: Es gibt noch keine Android-App, die man mit Nextcloud verbinden kann.
Vielen Dan Jan, auch für deine unermüdliche Unterstützung!!
Hi Jürgen,
ja, mobil kann man die Dokumente noch nicht richtig bearbeiten. Das geht momentan leider nur mit Collabora mit der Nextcloud App.
Gruß,
Jan
Hallo Jan,
danke für die Anleitung.
Möchte sie gerne umsetzen aber ich verwende acme.sh statt den certbot. wie müsste die Zeile dann lauten?
In deinen anderen Anleitungen benutzt du ja auch acme.sh, daher.
Schönen Pfingstmontag
Hi Marvin,
der acme.sh Befehl ist etwas anders, da du hier ja auch angeben kannst, wo die Zertifikate „installiert“ werden sollen. Am besten gehst du nach dieser Anleitung vor, ersetzt jedoch die Domains mit deinen eigenen.
Gruß,
Jan