Anleitung: nextcloud mit nginx reverse proxy und LetsEncrypt auf Docker

Beachtet unsere überarbeiteten Forenregeln vom 29.01.2019 !
  • 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
    1. 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:


       



    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



    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
    1. 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
    1. volumes:
    2. - 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 ()