Anleitung: nextcloud mit nginx reverse proxy und LetsEncrypt auf Docker

  • Hey ich bin gerade dabei Nextcloud mit Letsencrypt zu installieren. Ich möchte zusätzlich noch phpmyadmin integrieren, jedoch läuft meine Installation nicht rund.

    Mit dem ersten Feldversuch, habe ich alles ganz normal installiert, dann wird über localhost:port Nextcloud install wizard aufgerufen. Jedoch bekomme ich ab und an Gateway 502 angezeigt. Genauso kann ich nicht mariadb aussuchen sondern kann erst über die Auswahl SQLlite die installation abschließen?!

    Wenn ich das ganze mit phpmyadmin zusätzlich versuche, ist phpmyadmin nur paar minuten erreichbar, danach kommt Gateway 502 die ganze Zeit?

    Hier mal meine docker config:

  • Ich habe exakt das gleiche Problem wie Black_Fry

    Sobald der LE-Companion-Container "./force-renew" aufruft, meldet der Log des proxy-Containers:


    Code

    Code
     failed (13: Permission denied)


    Gibt es ein Lösung zu dem Problem?

  • Hi Guido,


    spannend zu hören.


    Dass das Problem beim ISP liegt, kann ich nach einer Support-Anfrage ausschließen. Die Antwort vom Strato-Support lautet:

    Zitat von Strato-Support

    Let's Encrypt kann lediglich nicht auf den Servern der STRATO Hosting-Pakete verwendet werden. Auf eigenen Systemen gibt es (...) keine Einschränkung dabei (...). Weshalb die von Ihnen genutzte Konfiguration auf der QNAP kein Let's Encrypt Zertifikat erhält, kann ich Ihnen bedauerlicherweise nicht auswerten.

    Unsere DNS-Server antworten auf CAA-Record Requests, dass kein CAA-Record gesetzt ist, also jede CA ein Zertifikat ausstellen darf.

    Sieht aus wie ein Berechtigungsproblem im FileSystem!? Kannst Du feststellen, ob der LE-Client überhaupt die Files anlegt? Vermutlich nicht, wenn er ein "permission denied" meldet. Dann kann natürlich auch die Gegenstelle des Token nicht überprüfen.


    Allerdings ändert die Ausführung von "./force-renew" als root auch nichts (passiert m. E. sowieso). Es ist ebenfalls kein R(ead) O(nly)-Filesystem (lt *.yml).


    Wie sieht es im Network Center bei Euch aus? Das gesamte Setting kommt automatisch hoch und wird geNATtet (siehe Screenshots). Keine Fehler, die Container erreichen sich untereinander:


    01-qnap_nw-center.png   02-qnap_nw-center_virt_switches.png



    Hat jemand eine Idee oder das selbe Problem? Offenbar machen Guido und ich denselben Fehler ohne es zu bemerken. Habe mich allerdings strikt an die Anweisung gehalten. Jede Hilfe ist willkommen :)

  • ich hab mal noch zwei fragen:


    1.)

    Ich verstehe dass mit den subdomains nicht.

    Ich habe über qnap direkt einen ddns eingerichtet.

    meinnas.myqnapcloud.com

    kann ich denn jetzt überhaupt eine subdomain einrichten, und wenn ja wo? oder brauche ich einen ganz anderen anbieter?


    2.)

    ich würde natürlich auch gerne mariadb nutzen wenn es schon im docker image dabei ist ;)

    ich konnte keine verbindung zur mariadb aufbauen beim initialen aufruf von nextcloud


    eingegeben habe ich:

    benutzer: root

    password: "das in der db.env" vergebene

    db name: nextcloud

    ip: 127.0.0.1


    pasted-from-clipboard.png

    3 Mal editiert, zuletzt von Tidle ()

  • Der LE Client legt die Files bei mir an, das ist nicht das Problem. Erst wenn die ACMe challenge läuft und die generierten files abgeholt werden sollen, kommt es zum Fehler. Das NGINX Log file gibt dann auch für jeden host den fehler aus:

    Code
    2018/12/04 19:00:30 [error] 33#33: *34 open() "/usr/share/nginx/html/.well-known/acme-challenge/cMYMeDDKQemuGEcHn-ofn8b9ouB7in7zX2cFi9YgGxc" failed (13: Permission denied), client: 172.68.174.102, server: wiki.***.***, request: "GET /.well-known/acme-challenge/cMYMeDDKQemuGEcHn-ofn8b9ouB7in7zX2cFi9YgGxc HTTP/1.1", host: "wiki.***.***"
  • Kleine neue Erkenntnis:

    • der LE-Container führt ja bekanntlich das letsencrypt-service -Script u. a. via force-renew aus.
      • In dessen Userverwaltung gibt es keinen nginx-user.
      • Das Script läuft als root.
      • Die Validation-Tokens sollen in das Verzeichnis /usr/share/nginx/html/.well-known/acme-challenge geschrieben werden
    • das Verzeichnis /usr/share/nginx/html/.well-known/acme-challenge wird offenbar vom LE-Container und vom proxy-Container verwendet. Änderungen auf der einen Seite sind jeweils auf der anderen Seite unmittelbar vorhanden. (geht auch aus dem Docker*.yml-File eindeutig hervor)
    • der proxy-Container verwaltet den Zugriff auf die Webdateien - also auch den Zugriff auf das o. g. genannte Verzeichnis.
      • Die Zugriffsrechte dieses Verzeichnisses stehen per default auf root:root.
      • Der Web-Zugriff von außen wird hier vom user nginx verwaltet.
        • enstpr der default permissions darf der user nginx nicht auf das Verzeichnis zugreifen: stimmt! Deshalb der Fehler "permission denied" (on open() / stat() / ...)
      • ändert man die Zugriffsrechte bspw auf nginx:root, dann ist der Zugriff via curl / wget von remote Hosts auf alle Files im o. g. Verzeichnis problemlos möglich
    • da das LE-Script auf dem LE-Container allerdings weiterhin als root in das acme-challenge-Verzeichnis schreibt, ist der Zugriff des WebServers inform des nginx-Users weiterhin nicht möglich
    • entgegengesetzt meiner ersten Vermutung hat der ISP rein gar nichts damit zu tun

    Zwei mögliche Ansätze:

    (1) die Files aus dem /app-Verzeichnis des LE-Containers ins /app-Verzeichnis des proxy-Containers kopieren und dort via sudo -u als nginx-User ausführen

    (2) das LE-Script (simp_le) auf dem proxy-Container mit apt-get installieren.


    Beide sind aber recht invasiv und machen den LE-Container mehr oder minder überflüssig. Ich übersehe etwas - das für viele andere hier offensichtlich zu sein scheint!


    Hat jemand eine Idee?

  • Ich habe die Lösung für unser kleines Problem gefunden. Und zwar funktioniert es, wenn ich im LE Container und im NGINX container das html verzeichnis als named volume mounte anstatt als persitent volume. Im docker-compose file sieht das so aus:


    Code
        volumes:
          - html:/usr/share/nginx/html

    Dann funktinoert die Zertifikatgenerierung ohne Probleme.

  • hi xgadscu

    super Anleitung. Ich habe jetzt das ganze Mal in einer ersten Version ohne "collabora" installiert. Hat alles auf Anhieb funktioniert.


    3 Fragen habe ich noch:

    1. Wieso hast du es mit Collabora auf diese Weise gemacht und nicht aus nextcloud heraus installiert/aktiviert?
    2. was passiert wenn ich im config unter collabora diese beiden eingräte auskommentiere?
      - username=<<meinCollaboraUser>> #optional
      - password=<<meinPasswort>> #optional
    3. Wieso hast du redis installiert. wozu verwendest du es?
    4. Wieso cron? kannst du nur so innerhalb der containers cronjobs laufen lassen?

    gruss

    santo

    Einmal editiert, zuletzt von santo ()

  • Kleiner Hinweis für alle, die Schwierigkeiten haben, den system cron zum Laufen zu bringen. Zumindest der Container, der mit dem (im ersten Beitrag verlinkten) Ddocker-File kommt, scheint nicht ganz ohne zusätzliche Konfig zu funktionieren.


    Bei mir führt der Docker-Host (die QNAP) über seinen eigenen crond den folgenden Befehl aus:

    Code
    */15 * * * * /bin/sh docker exec <Name des Nextcloud Containers> sudo -u www-data  php -f /var/www/html/cron.php



    Hinweise zum richtigen Editieren von QNAP's crond findet Ihr hier: https://www.techandme.se/qnap-and-cron/

  • Sehr geehrte QNAP Freunde :)


    zunächst einmal vielen Dank an xgadscu für die Dockerfiles und die Anleitung.

    Ich melde mich jetzt nach vielen, vielen Stunden des Testens auch noch mit einer Thematik, die mir die NextCloud Freude noch vermiest.

    Im Grunde habe ich das gleiche Problem wie quasimodoz: der Qthttpd.sh Service blockiert Port 80.


    Fehlermeldung:

    Also der Reverse-Proxy startet nicht, weil Qthttpd.sh den Port 80 blockiert.

    Wenn ich Qthttpd.sh manuell stoppe

    /etc/init.d/Qthttpd.sh stop

    dann startet der Container.


    Ich habe bereits:

    - Systemport auf Port 5519 konfiguriert

    - Sicheren Systemport auf Port 5520 konfiguriert

    - Webserver Portnummer auf Port 1111 konfiguriert

    - Webserver Sicheren Anschluss auf 2222 konfiguriert

    - UND den Webserver abgeschaltet

    - NAS neu gestartet


    Mein NAS ist ein TS-253 Pro

    Meine Firmware das aktuelle QTS 4.3.6.0875


    Dann habe ich den QNAP Support angeschrieben. Der war leider überhaupt nicht zu gebrauchen. Aussage:

    Ihr Gerät wird nicht mehr supportet.

    Es gibt keine Möglichkeit Qthttpd.sh dauerhaft zu deaktivieren.


    Daher wende ich mich jetzt hilfesuchend an euch und hätte folgende Fragen:

    Wisst ihr eine Lösung, wie man Qthttpd.sh dauerhaft, also auch nach Neustart des Geräts, deaktivieren kann?

    Gäbe es theoretisch eine Möglichkeit alle NextCloud / Collabora Container über den zweiten Netzwerkanschluss laufen zu lassen (andere IP-Adresse) und zu verhindern, dass Qthttpd.sh auf dem zweiten Anschluss herumwildert?

    Ist euch ein Bug bekannt, der am TS-253 Pro verhindert, den Port 80 aus Qthttpd.sh herauszukonfigurieren und gibt es einen Workaround?

    Fällt euch eine andere Lösung ein?


    Vielen Dank schonmal für die Unterstützung und beste Grüße aus dem Ländle.

  • Vielen Dank für die super Erklärung und die Skripte. Ich kann schon mal bestätigen, dass der Setup auf einem QNAP Ts 253Be läuft.
    Leider habe ich ein kleines Problem, das scheinbar zu einem bottleneck beim Upload vieler kleiner Dateien führt.
    Wenn ich mir das log des nextcloud:fpm container in der container station ansehe, so erscheint immer wieder die Meldung:

    Code
    WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

    Ich hab mich jetzt schon einige Tage umgesehen um diese Einstellung zu ändern, jedoch großartig gescheitert.
    Anscheinend muss man im php-fpm file nur die Einträge


    Code
    pm = dynamic  
    pm.max_children = 25  
    pm.start_servers = 10  
    pm.min_spare_servers = 5  
    pm.max_spare_servers = 20  
    pm.max_requests = 498

    ändern bzw. auf das system anpassen. Leider finde ich dieses php-fpm.config file jedoch nicht.
    ev. hat jemand eine Idee, wie man dieses Problem angehen kann?

    Schonmal besten Dank,

    Eterra

  • Es gibt keine Möglichkeit Qthttpd.sh dauerhaft zu deaktivieren.

    Hi theHELL,


    hast Du eine Lösung für Dein Problem gefunden? Ich bin ähnlich verzweifelt: Mittlerweile habe ich alle Apps deinstalliert die in irgend einer Form das qthttpd.sh aufrufen könnten. Dennoch startet es immer wieder nach einem Neustart.


    Für Tipps bin ich dankbar!


    LG


    quick

  • - Webserver Portnummer auf Port 1111 konfiguriert

    - Webserver Sicheren Anschluss auf 2222 konfiguriert

    - UND den Webserver abgeschaltet

    Das ist der Fehler. Wenn der Webserver abgeschaltet wird, dann wird qthttp mit den Defaults initialisiert.


    Also :arrow: Ports ändern und den Webserver eingeschaltet lassen. Dann wird qthttp mit den eingestellten Ports konfiguriert und der Port 80 taucht nirgends mehr auf.

  • Also :arrow: Ports ändern und den Webserver eingeschaltet lassen. Dann wird qthttp mit den eingestellten Ports konfiguriert und der Port 80 taucht nirgends mehr auf.

    Das war schon mal super hilfreich! Jetzt hänge ich nur noch an einer letzten Sache: Nachdem ich gewartet habe und mich das erste mal versuche einloggen muss ich einen Admin-User anlegen. Nachdem ich User-Namen und Passwort vergeben habe dauert es ca. 30 Sekunden und dann erscheint ein:

    Code
    502 Bad Gateway

    nginx/1.15.12

    Woran kann das liegen?


    1000 Dank für Eure Hilfe!

  • Hallo quick,

    ich habe das gleich Problem.

    Mach ich ein F5 auf der Seite kommt:


    Code
    Fehler
    Dieser Benutzername existiert bereits


    Geb ich einen anderen Benutzer an, stehe ich wieder vor dem

    Code
    502 Bad Gateway

    nginx/1.15.12


    Danke schon einmal für Eure Hilfe!

  • Yes, genau so ist es bei mir auch.


    Mal eine grundsätzliche Frage zur NextCloud-Installation auf einer QNAP: Ist es eigentlich soooo schwer eine native NextCloud-Lösung anzubieten? Ich verstehe schon die Vorteile von Docker, aber eine native NextCloud Installation hätte ja auch Vorteile. Z.B. ein automatisches Update-Skript. Mir ist klar, dass hier viele weitere Tools aktualisiert werden müssten um dies zu realisieren, aber es wäre doch prinzipiell möglich, oder mache ich hier einen Gedanken-Fehler?


    LG


    quick

  • es gibt doch ne qpkg...


    Nur willst du das dann einfach so ans Netz hängen? Da finde ich die Containerlösung schon besser...


    Und es zwingt dich ja keiner, das mit nginx uns co. zu machen... Zwei einfache Container, einmal DB, einmal nextcloud funktionieren auch...

  • es gibt doch ne qpkg...

    Ja die habe ich schon gesehen (und auch gekauft ;-)) aber auch die ermöglicht mir ja keine nativen Updates. Ich bin tatsächlich auch ein totaler Laie was Linux angeht ich dachte nur mit einer QNAP muss es doch möglich sein alle notwendigen Pakete (also Apache, PHP, einen ReverseProxy und was sonst noch so nötig ist) up to date zu bekommen um dann das original NextCloud Release zu installieren.


    Aber wie gesagt: Ich habe viel zu wenig Ahnung um mir eine Meinung zu erlauben... verstehen würde ich es dennoch gerne. Bzw.: Gibt es denn eine Out of the Box-NAS-Lösung die das einfacher ermöglicht?


    LG und danke für Euren Support!