Troubleshooting Nextcloud in Plesk mit Docker und OnlyOffice- oder Collabora-Image

By Markus WeingärtnerDocker, Fehlerbehebung, Plesk

Wenn Ihr Probleme bei der Konfiguration eines Docker-Images auf einem Plesk-Host habt, z.B. nach den beiden Tutorials hier:

OnlyOffice mit Docker in Plesk
Collabora Online Office mit Docker in Plesk

Dann solltet Ihr die folgenden Hinweise durchgehen und prüfen:

Hinweis 1: DNS-Resolver

Plesk Onyx ist ein Administrations-Panel für Webhosting, aber es stellt auch grundlegende Funktionen als DNS-Server zur Verfügung. Erstelle ich eine Subdomain, ist es natürlich wichtig, dass diese auch vernünftig aufgelöst wird. Deshalb sollten wir sicherstellen, dass der Plesk-Host sich auch selbst als DNS-Resolver nutzt und nicht irgendwelche Nameserver, die in der Grundkonfiguration von unserem VPS-Hoster eingetragen wurden.

Da ich nicht davon ausgehe, dass jeder seine eigenen Nameserver betreibt, sollte es in der Domain-Verwaltung beim Provider zumindest zwei A-Records geben, die auf die externe IP-Adresse Eures Plesk-Hosts zeigen:

domain.tld
*.domain.tld

zusätzlich kann und sollte es für die beiden Hostnamen auch noch AAAA-Records (IPv6) geben, wenn IPv6 auf Eurem Plesk-Host aktiv ist.

Überprüfen wir zuerst, ob die Einträge in der /etc/hosts auf unserem Server richtig sind:

cat /etc/hosts

Hier sollten auf jeden Fall diese beiden Einträge für localhost existieren:

127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost ip6-localhost ip6-loopback

zusätzlich existiert noch ein Eintrag für die externe bzw. interne IP-Adresse, wenn beim Provider NAT eingesetzt wird:

IP-Adresse hostname.domain.tld hostname

Damit sollte schon mal die Auflösung von „localhost“ funktionieren.

Welchen Nameserver Euer VPS mit Plesk nutzt, könnt Ihr mit dem folgenden Befehl prüfen:

cat /etc/resolv.conf

Ausgabe bei meinem VPS:

nameserver localhost

Als DNS-Resolver wird also der Plesk-Host selbst genutzt, gut so. 127.0.0.1 ist natürlich auch in Ordnung.
Sollte der lokale DNS-Resolver eine DNS-Abfrage nicht beantworten können, dann fragt dieser automatisch DNS-Root-Server ab.

Kommt als Ausgabe ein „fremder“ DNS-Resolver, solltet Ihr das natürlich anpassen. Dazu prüfen wir aber erst, ob die DNS-Auflösung (lokal und über DNS-Root-server) auch funktioniert:

Abfrage über DNS-Root-Server testen (bitte einen DNS-Namen einsetzen, der lokal nicht existiert, hier google.de):

dig @localhost google.de

und die dazu richtige Ausgabe dazu:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @localhost google.de
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63090
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.de. IN A

;; ANSWER SECTION:
google.de. 300 IN A 216.58.211.99

;; AUTHORITY SECTION:
google.de. 86400 IN NS ns2.google.com.
google.de. 86400 IN NS ns1.google.com.
google.de. 86400 IN NS ns4.google.com.
google.de. 86400 IN NS ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com. 246866 IN A 216.239.32.10
ns1.google.com. 246866 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 246866 IN A 216.239.34.10
ns2.google.com. 246866 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 246866 IN A 216.239.36.10
ns3.google.com. 246866 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 246866 IN A 216.239.38.10
ns4.google.com. 246866 IN AAAA 2001:4860:4802:38::a

;; Query time: 66 msec
;; SERVER: ::1#53(::1)

Abfrage über lokalen DNS-Resolver testen (auf dem Plesk-Host gehostete Domain oder Subdomain nutzen, hier markus-blog.de):

dig @localhost markus-blog.de

und auch hier die Ausgabe:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @localhost markus-blog.de
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50718
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;markus-blog.de. IN A

;; ANSWER SECTION:
markus-blog.de. 7200 IN A 81.169.254.172

;; AUTHORITY SECTION:
markus-blog.de. 7200 IN NS ns3.weingaertner-it.de.
markus-blog.de. 7200 IN NS ns1.weingaertner-it.de.
markus-blog.de. 7200 IN NS ns2.weingaertner-it.de.

;; ADDITIONAL SECTION:
ns1.weingaertner-it.de. 10800 IN A 81.169.254.172
ns1.weingaertner-it.de. 10800 IN AAAA 2a01:238:4334:f00:aa8:a3a1:de08:926a
ns2.weingaertner-it.de. 10800 IN A 5.189.143.209
ns2.weingaertner-it.de. 10800 IN AAAA 2a02:c207:3002:3949::1
ns3.weingaertner-it.de. 10800 IN A 173.212.246.129
ns3.weingaertner-it.de. 10800 IN AAAA 2a02:c207:3002:2316::1

;; Query time: 0 msec
;; SERVER: ::1#53(::1)

Wenn beide Ausgaben passen, gibt es keine Probleme, wenn wir auf den lokalen DNS-Resolver umsteigen.
Dazu bearbeiten wir unsere Netzwerk-Konfig:

nano /etc/network/interfaces

suchen nach dem Eintrag dns-nameservers und passen diesen auf localhost oder 127.0.0.1 an. Konfig speichern (STRG + W) nicht vergessen.

Damit wir nicht sofort neu starten müssen, passen wir die /etc/resolv.conf an und setzen dort ebenfalls localhost oder 127.0.0.1 ein:

nano /etc/resolv.conf

darauf achten, hier heißt der Eintrag nur „nameserver“, also hinter nameserver und einem Leerzeichen localhost oder 127.0.0.1 einsetzen und speichern (STRG + W).

Nun prüfen wir mit dem folgendem Kommando, ob der lokale DNS-Resolver genutzt wird:

dig markus-blog

im unteren Abschnitt seht Ihr welcher Server zur Auflösung genutzt wird:

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

Nun funktioniert die DNS-Auflösung auf dem Plesk-Host so, wie sich das Plesk auch vorgestellt hat 😉

Hinweis 2: Docker DNS

Docker Images nutzen von Haus aus die Einträge aus der /etc/resolv.conf, es sei denn dort steht „localhost“. Alle Einträge dieser Art werden herausgefiltert und wenn kein Eintrag übrig bleibt, dann werden dort die google-DNS-Server verwendet (8.8.8.8 und 8.8.4.4). Details dazu findet Ihr hier.

Um das zu umgehen, haben wir die Möglichkeit, beim Starten des Containers einen DNS-Resolver mitzugeben. Dazu müssen wir bei den „docker run“-Kommandos einfach das Argument --dns=IP_ADDRESS hinzufügen. Als IP-Adresse verwendet Ihr Eure externe IP-Adresse vom Plesk-Host.

Für OnlyOffice lautet das Kommando im Ganzen:

docker run -i -t -d -p 127.0.0.1:9981:80 --dns=extIP-Adresse-Plesk -e JWT_ENABLED='true' -e JWT_SECRET='your-secret-key' --restart=always onlyoffice/documentserver

und für Collabora:

docker run -t -d -p 127.0.0.1:9980:9980 --dns=extIP-Adresse-Plesk -e 'domain=subdomain\\.domain\\.com' -e 'username=Benutzername' -e 'password=Dein-Passwort' --cap-add MKNOD collabora/code

….Fortsetzung folgt…

Falls Ihr Probleme mit der Umsetzung meiner Tutorials habt, dann kommt gerne auf mich zu.

Die entsprechenden Lösungen, versuche ich dann entsprechend hier aufzuführen, damit alle davon profitieren können….

Ansonsten freue ich mich wie immer über Feedback, teilen meiner Beiträge und Anregungen für neue Beiträge…

Bis bald…

Post Views: 5.606

16 Gedanken zu „Troubleshooting Nextcloud in Plesk mit Docker und OnlyOffice- oder Collabora-Image“

  1. Hallo Markus,
    danke für deine gute Anleitung. Ich habe Plesk Version 17.8.11 Update #40 auf CentOS Linux 7.6.1810 (Core)‬ laufen.
    Collabora läuft wie beschrieben im Docker-Container. Über die Nextcloud-Apps von Außen kann ich Dokumente anzeigen und bearbeiten. Wenn ich die Dokumente in Nextcloud selbst anzeigen bzw. bearbeiten möchte lädt er „ins Nirvana“ Folgende Fehlermeldung bekomme ich in der Konsole angezeigt „Content Security Policy: Die Einstellungen der Seite haben das Laden einer Ressource auf inline blockiert („script-src“).“ Kann das mit der DNS-Auflösung zwischen Nextcloud und Docker zusammenhängen?
    Viele Grüße Jürgen

    Antworten

      1. Hallo Markus,

        bei der Nextcloud-Domain habe ich folgende Apache Einstellungen:
        HTTP:

        AllowOverride All

        HTTPS:
        Header always set Strict-Transport-Security „max-age=15552000; includeSubDomains“
        Header set Referrer-Policy „strict-origin-when-cross-origin“
        Header set X-Content-Type-Options „nosniff“
        Header always set X-Frame-Options „SAMEORIGIN“

        und zusätzlich die nginx-Anweisungen:
        ssl_prefer_server_ciphers On;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;

        gzip_proxied any;
        # enable gzip compression
        gzip on;
        gzip_min_length 20;
        gzip_buffers 4 32k;
        gzip_types text/plain text/javascript application/javascript application/x-javascript text/xml text/css application/js;
        gzip_vary on;
        location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|json|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|OGG|OGV|SVG|SVGZ|EOT|OTF|WOFF|MP4|TTF|CSS|RSS|ATOM|JS|JPG|JPEG|JSON|GIF|PNG|ICO|ZIP|TGZ|GZ|RAR|BZ2|DOC|XLS|EXE|PPT|TAR|MID|MIDI|WAV|BMP|RTF)$ {
        expires max; log_not_found off;
        # time out settings
        proxy_connect_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_read_timeout 3600s;
        fastcgi_read_timeout 3600s;
        # webdav rewrite
        rewrite ^/.well-known/carddav /remote.php/dav/ permanent;
        rewrite ^/.well-known/caldav /remote.php/dav/ permanent;
        rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
        rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
        }

        Bei der Collabora-Domain habe ich die zusätzlichen nginx-Anweisungen:
        # static files
        location ^~ /loleaflet {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Host $http_host;
        }

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

        # main websocket
        location ~ ^/lool/(.*)/ws$ {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection „Upgrade“;
        proxy_set_header Host $http_host;
        proxy_read_timeout 36000s;
        }

        # download, presentation and image upload
        location ~ ^/lool {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Host $http_host;
        }

        # Admin Console websocket
        location ^~ /lool/adminws {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection „Upgrade“;
        proxy_set_header Host $http_host;
        proxy_read_timeout 36000s;
        }

        Content-Security-Policy: Habe ich zumindestens nirgends bewusst gesetzt. Da kenn ich mich nicht gut genug aus.
        Gruß Jürgen

        Antworten

        1. Hallo Jürgen,
          Das sollte funktionieren.

          Hast Du in plesk die Web Application Firewall an? Wenn ja, prüf mal in den Logs (findest Du bei den Einstellungen der WAF), ob da etwas aufgezeichnet wird, wenn Du versuchst das Dokument zu öffnen.

          Gruß Markus

          Antworten

          1. Hallo Markus,
            Web Application Firewall ist aus.
            Bin mir nicht ganz sicher, aber ich glaube vor dem letzten automatischen Docker Update hat der Zugriff über den Browser funktioniert. Habe in der letzten Zeit nur per App auf die Dokumente zugegriffen, das hat bisher immer sehr gut funktioniert.
            Gruß Jürgen

          2. Hallo Jürgen,

            Ah, ok. Hast Du den Docker Container nach dem Update nochmal neu gestartet? Manchmal verhält sich Docker bei Updates seltsam und der Restart des Daemons verursacht ungewöhnliche Nebeneffekte.
            Welche Docker-Version und welches Docker-Image von Collabora nutzt Du jetzt?

            Gruß Markus

          3. Hallo Markus,
            habe den Docker Container beendet und nochmals gestartet, leider ist das Problem immer noch da.
            Den Docker hab ich gebaut mit:
            docker run -t -d -p 127.0.0.1:9980:9980 –dns=178.xxx.xx.xxx -e ‚domain=next\\.domain\\.de‘ -e ‚username=user‘ -e ‚password=pw‘ –cap-add MKNOD collabora/code
            Die Docker Version ist:
            Client:
            Version: 18.09.2
            API version: 1.39
            Go version: go1.10.6
            Git commit: 6247962
            Built: Sun Feb 10 04:13:27 2019
            OS/Arch: linux/amd64
            Experimental: false

            Server: Docker Engine – Community
            Engine:
            Version: 18.09.2
            API version: 1.39 (minimum version 1.12)
            Go version: go1.10.6
            Git commit: 6247962
            Built: Sun Feb 10 03:47:25 2019
            OS/Arch: linux/amd64
            Experimental: false

          4. Hallo Jürgen,

            Eventuell musst Du den Container mal aktualisieren. Lösche ihn und das zugehörige Image einfach in der Plesk Oberfläche und dann startest Du ihn mit dem Befehl noch mal. Dann wird das aktuelle Image geladen.
            Gruß Markus

  2. Hallo Markus,

    vielen Dank für diesen Troubleshooting Post. Wie zuvor beschrieben, lädt Collabora nicht in nextcloud, scheint aber zu laufen. Mit dem obigen Vorgehen habe ich herausgefunden, dass bei mir lediglich zwei externe nameserver konfiguriert sind und „dig @localhost“ ins leere läuft. Kannst du mir einen Hinweis geben, wie ich hier am besten weiter vorgehe?

    Vielen Dank und viele Grüße
    Benjamin

    Antworten

    1. Hallo Benjamin,
      Bitte in Plesk nachschauen unter Tools & Settings -> Server Management -> Services Management ob DNS-Server (BIND) installiert und aktiviert ist.
      Wenn nicht, dann nachinstallieren, ansonsten prüfen ob gestartet:
      systemctl status bind9

      Dann nochmal prüfen:

      dig @localhost markus-blog.de

      Welches OS hast Du unter Plesk?

      Gruß
      Markus

      Antworten

      1. Hallo Markus,

        vielen Dank für deine Antwort. Mein Plesk läuft auf Ubuntu 18.04.1. Ich habe jetzt den DNS bind hinbekommen, dadurch wurde mein Problem allerdings nicht behoben.

        Ich habe es inzwischen geschafft, Collabora bei daktiviertem ngnix (mit Apache) in nextcloud zum Laufen zu bringen. Gleichzeitig kann ich bei Benutzung deiner nginx Konfiguration außerhalb von nextcloud auf die Collabora Apps zugreifen – nur in nextcloud werden sie nicht geladen. Skurril.

        Vielleicht hast du ja noch Ideen, alternativ verzichte ich auf ngnix…

        Viele Grüße
        Benjamin

        Antworten

          1. Nein, ich habe tatsächlich den ngnix ausgeschaltet und den Reverse Proxy im Apache konfiguriert. Das funktioniert.

            Ich habe auch in den Logs gesehen, dass der Container bei bestimmten Anfragenin der ngnix Konfiguration 404er wirft, während das mit der Apache Konfiguration funktioniert. Da ich beide Konfigurationen inzwischen weitestgehend von der Collabora Webseite kopiert habe, weiß ich nicht, was Plesk da noch zwischenschiebt, sodass die ngnix Konfiguration nicht funktioniert.

            Da ich servertechnisch nicht so versiert bin, bleibe ich vorerst bei der Apache-only Konfiguration.

            Vielen Dank noch einmal für deine Unterstützung!

  3. Pingback: Troubleshooting Plesk mit Docker und Office-Container | Markus' Blog
  4. Pingback: Troubleshooting Nextcloud on Plesk mit Docker und OnlyOffice- oder Collabora-Image - nerdblog

Schreibe einen Kommentar

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