Beiträge von xgadscu

    Hallo Micha,


    die Images und Container kann man normalerweise über die Containerstation-App löschen. Da wir die nextcloud-Container aber nicht über die Containerstation-Oberfläche, sondern über docker-compose erzeugt haben, ist dies offensichtlich nicht mehr möglich. Ich meine, das hätte früher funktioniert.

    Macht aber nichts. Ich verwende für das Container-Management den frei verfügbaren portainer. Der läuft in allen Docker-Umgebungen, während die Containerstation proprietär nur für qnap läuft. Der portainer ist schnell per docker-compose eingerichtet:


    Den portainer kann man nach Einrichtung im Browser über Port 9000 aufrufen. Dort lassen sich Container stoppen/starten usw. und ebenso Container und Images verwalten.


    Da wir bei unserem nextcloud-Containern die Daten über Volumes persistent halten, geht beim Löschen von Containern und Images nichts verloren. Aktualisierte Container greifen automatisch auf die vorhandenen Daten zu. Ein nextcloud-Major-Update erkennt die alte Version der Daten und migriert sie automatisch auf die neue Version. Dabei darf man immer nur um 1 Version höher gehen (also z.B. von 15 auf 16).


    LG xgadscu

    Hallo Micha,


    meine Aussage stimmt nicht beim Umstieg auf eine neue Major-Version. Normalerweise hängt man bei der Image-Angabe ein Tag latest an. Zu nextcloud gibt es aber sehr viele verschiedene Images, die entsprechend getagged sind (siehe Ausschnitt von https://hub.docker.com/_/nextcloud/) :




    Das latest-Tag bezieht sich in diesem Fall auf die apache-Version. Das Tag fpm bezieht sich auf die aktuelle fpm-Version. Das ist also richtig.


    Du musst beim Umstieg auf eine neue Major-Version (wie auch unter obigem Link beschrieben) leider den Container stoppen, den Container und das Image löschen und dann den Pull absetzen.


    Gruß xgadscu

    Hallo quasimodoz,


    Danke für Deinen Bericht. In meinem Fall hat mich insbesondere die Abhängigkeit von qnap gestört, in die ich geraten bin, als das Gehäuse defekt war und meine 4 8 TB-Festplatten für mich vollkommen wertlos waren. Ich konnte nicht mehr auf meine Daten zugreifen. Wenn ich den Zugriff über ein eigenes Linux-System versucht hätte, hätte ich möglicherweise noch mehr verloren. Also habe ich 3 Monate gewartet, bis QNAP mir endlich ein Austauschgerät geschickt hat. Dass ich dann immer noch nicht an meine Daten kam und es selbst QNAP-Experten nur mit großen Schwierigkeiten gelungen ist, war die nächste bittere Erfahrung.


    Mir ist dabei bewusst geworden, dass man RAID5 für den privaten Bereich eigentlich nicht unbedingt benötigt. 24*7 ist nicht erforderlich. Man muss dann allerdings die Daten redundant halten. Dafür erspart man sich die oben beschriebene Komplexität und Abhängigkeit.

    Ich halte nun permanente Backups meiner Daten auf jeweils separaten Platten und synchronisiere mit rsync mit jeweils passenden Zeitplänen.


    In dem Zusammenhang habe ich Syncthing entdeckt. Dieses Tool ist grandios. Damit lassen sich Realtime-Syncs und -Backups über alle möglichen Plattformen (Linux, Windows und Android) realisieren. Auf den diversen Linux-Systemen (inklusive QNAP und jetzt auch Odroids mit OMV) betreibe ich Syncthing in Docker-Containern. Die Synchronisation ist schnell und vor allen Dingen sehr verlässlich.


    Das Wichtigste aber ist: Ich kontrolliere die Verwaltung meiner Daten selbst und bin nicht abhängig von proprietären QNAP-Firmwares und -Apps.


    Gruß

    xgadscu

    Schön, dass meine Anleitungen so vielen Leuten geholfen haben.


    Nach langer Zeit melde ich mich als Autor dieses Threads mal wieder.

    Ich habe eine lange Leidenszeit hinter mir. Kurz vor Weihnachten 2018 ist mein QNAP ausgefallen. Ursache des Totalausfalls war ein defekter Lüfter (also Pfennigkram). Das Gerät war noch kein Jahr alt. QNAP hat für den Garantiefall 3 Monate gebraucht. Man sagte mir, es würde nur schneller gehen, wenn ich ARS (Advanced Replacement Service) dazu gekauft hätte. Ich hatte gedacht, ich hätte ein professionelles NAS gekauft. Anderswo gibt es im Problemfall einen Vorabaustausch!!


    Die Migration der Daten in das Austauschgerät war dann auch noch problematisch und konnte nicht einmal vom QNAP-Support direkt durchgeführt werden. Erst durch eine HelpDesk-Session waren die Daten von QNAP-Spezialisten am nächsten Tag wieder restauriert (obwohl die 4 Platten (RAID5) ja eigentlich gar nicht betroffen waren). Eigentlich hatte ich gedacht: neues Gerät vom selben Modell, Platten rein und läuft wieder. Aber: weit gefehlt.


    Ich kann nur sagen: Nie wieder QNAP!!!


    Ich steige nun sukzessive um auf Odroid-HC2 bzw. HC1. Darauf nutze ich Openmediavault als NAS. Unter OMV laufen die Docker-Container, u.a. nextcloud. Von diesen Geräten betreibe ich mehrere (immer noch günstiger als ein einziges QNAP-System). RAID5 hat mir ja im obigen Garantiefall nur Probleme gemacht. Daher halte ich die Daten redundant und synchronisiere u.a mit Syncthing (geniales Tool für Synchronisation über mehrere Plattformen (Windows, Android, Linux (Docker))). Die Aktualisierung der Docker-Container übernimmt ein spezieller Container: Watchtower. Die Verwaltung der Container erfolgt mit portainer.io.


    Also: keine unnötige Komplexität durch den ganzen Schnickschnack im QNAP, sondern maßgeschneiderte OpenSource-Lösungen, die ich ohne fremde Hilfe betreiben kann.


    Viele Grüße
    xgadscu

    Hallo pci,


    ich kenne mich mit dem Bridge-Mode leider nicht so aus. Mich hatte anfangs hauptsächlich gereizt, eine eigene Cloud mit oben beschriebenen Leistungsmerkmalen hinzubekommen. Das war mir schließlich über Port-Mapping gelungen. Eine Lösung mit Hilfe des Bridge-Modes kann ich mir aber auch vorstellen. Entscheidend ist, dass die Subdomain auf die selbst vergebene IP-Adresse zeigt und LetsEncrypt diese über Port 443 erreichen kann.

    Es wäre toll, wenn Du das hinkriegen würdest und uns Deine Konfiguration (ggfs. auf Grundlage meiner Konfig und Nomenklatur) hier zur Verfügung stellen könntest. Ein solcher Ansatz würde den Aufbau der Container noch einmal vereinfachen, weil die Ports nicht frei geschaufelt werden müssten.


    Gruß xgadscu

    Hallo boeth,


    ich hatte zugegebenermaßen anfangs auch das Problem, dass der COPY der config-Datei nicht funktioniert hat und ich sie dann manuell per cp auf das Volume gebracht habe. Irgendwann hat es dann funktioniert und jetzt funktioniert es immer (d.h. bei jeder Aktualisierung). Ich weiß leider nicht, woran das gelegen hat und ob ich sonst noch irgendetwas gemacht haben, was den Knoten gelöst hat.

    Sinnig ist nur, dass offensichtlich schon einige Leute mit meiner Konfiguration erfolgreich gearbeitet haben.


    mfg xgadscu

    Hallo Boeth,


    eigentlich sind die nötigen Einstellungen in meiner Konfiguration enthalten. Das sind m.M. die client_max_body_size und die manuelle Einstellung auf der nextcloud-Oberfläche.

    Hast du die Server neu gestartet?


    Gruß xgadscu

    Hallo quasimodoz,


    den Menüpunkt zum Apps-Installieren findet man rechts oben unter dem User-Kürzel-Icon. Dies allerdings nur, wenn man als Admin angemeldet ist.


    Gruß xgadscu

    Hallo quasimodoz,


    aus Deinem Log ist ersichtlich, dass der Port 80 bereits anderweitig verwendet wird. Da die Portweiterleitung auf der Fritzbox offensichtlich bei Port 80 keinen Konflikt gemeldet hatte, musste es das QNAP-System selbst sein. Der Port 80 ist dort standardmäßig beim Webserver eingestellt. Du hättest den Port also auch unter Systemsteuerung/Anwendungen/Webserver umstellen können. So hatte ich es auch gemacht. Das Script Qthttpd.sh brauchte nicht angepasst zu werden.


    Gruß xgadscu

    Hallo Dirk,


    man braucht eine zusätzliche SubDomain. Ich habe geschrieben:

    Zitat

    Neu hinzugekommen ist eine Subdomain für collabora. Ich habe sie mal office.example.com getauft. Du musst diesen Namen in allen Konfigurationsdateien und einmal als Dateiname auf die von Dir erstellte SubDomain umbenennen.

    Das meinte ich auch so. Die Betonung liegt auf "allen". Das heißt insbesondere, dass der Copy-Step im proxy/Dockerfile angepasst werden muss. In deinem Fall wird natürlich proxy/office.example.com nicht gefunden.


    Gruß xgadscu

    Tipp: WebDAV-Zugriff über das lokale Netz


    Normalerweise kann man bei obiger Konfiguration über die URL


    https://cloud.example.de/remote.php/dav/files/<<user>>


    per WebDAV auf die Nextcloud zugreifen.


    Wenn man sich im internen Netz befindet, geht das aber viel schneller über


    http://xxx.xxx.xxx.xxx:4080/remote.php/dav/files/<<user>>


    Hierbei ist xxx.xxx.xxx.xxx durch die lokale IP-Adresse des QNAP-Systems und <<user>> durch den nextcloud-Benutzer zu ersetzen.

    Hierfür hatte ich in der web-Section des docker-compose.yml-Files den Port 4080 externalisiert.


    Gruß xgadscu

    Hallo boeth,


    schön, dass die Anleitung auch bei Dir funktioniert hat.


    Zu Deinen ersten 3 Fragen: Gegenstand dieser Anleitung ist, dass man eine von außen erreichbare private Cloud bekommt, mit der man sicher kommunizieren kann. Mit LetsEncrypt werden die erforderlichen Zertifikate automatisch erzeugt und turnusmäßig aktualisiert. Wenn Du rein im Heimnetz per https kommunizieren möchtest, muss Du nach anderen Lösungen suchen. Da bin ich außen vor.

    Bzgl. der Dateien in nginx-certs muss Du wohl mal die Suchmaschinen bemühen. Da gibt es schon genügend Antworten.

    Zur letzten Frage: Die unbedingte Nutzung des Ports 443 ist wie in der Anleitung beschrieben leider (noch) eine Restriktion von LetsEncrypt. Entsprechende Anfragen wurden meines Wissens nach bislang nicht umgesetzt. Das kann sich natürlich ändern. Bis dahin benutzt LetsEncrypt den Port 443 für die Validierung der Sub-Domain per ACME-Protokoll und das auch bei der Aktualisierung der Zertifikate.


    Die Sicherheit der eigenen Cloud kann man übrigens über https://scan.nextcloud.com testen.


    mfG
    xgadscu

    Hallo HerrJott,


    ich hatte wohl zwischendurch auch mal solche Meldungen. Es gibt dazu eine Diskussion im nextcloud-Forum: https://help.nextcloud.com/t/r…-child-processes/12209/25


    Am Ende heißt es, man solle nach einem Update in den Collabora-Online-Einstellungen unter nextcloud noch einmal den Apply/Anwenden-Button drücken. Das würde ich an Deiner Stelle mal versuchen und ggfs. den Container restarten.


    Viele Grüße
    xgadscu

    Hallo coyotekarl,


    im Anhang findest Du meine neutralisierten Konfigurationsdateien für die Kombi:


    8 Docker-Container auf einem QNAP hinter einem Internet-Router

    • Nginx-Reverse-Proxy
    • Lets-Encrypt-Companion
    • Web-Server
    • nextcloud
    • Maria-DB
    • redis
    • cron
    • collabora

    Neu hinzugekommen ist eine Subdomain für collabora. Ich habe sie mal office.example.com getauft. Du musst diesen Namen in allen Konfigurationsdateien und einmal als Dateiname auf die von Dir erstellte SubDomain umbenennen.


    Wenn alles angepasst ist, heißt es wieder: Build and Run


    Danach muss in der Cloud zunächst Collabora als App aktiviert werden. Dann erscheint unter den Einstellungen ein Menüpunkt "Collabora Online". Hier muss man dann den Collabora Online Server einstellen, d.h. nach meiner Anleitungs-Nomenklatur wäre das https://office.example.com.


    Viel Erfolg. Schön wäre auch eine Rückmeldung hier im Forum, ob alles geklappt hat.


    xgadscu

    Hallo cunctator,


    wenn Du Dich gemäß QNAP-Standard mit dem admin-User auf der ssh-Konsole anmeldest, sollten die Rechte ok sein. Ich habe jedenfalls nichts anderes gemacht als oben beschrieben.

    Aus Deinen Log-Auszügen kann ich nicht unbedingt die Ursache für Deine Probleme ersehen. Dazu müsste man die zugrundeliegende Konfiguration und ggfs. weitere Log-Auszüge haben.

    Zunächst einmal kann ich Dir folgende Tipps geben:

    Beim Starten müssen sich die Container aufeinander einspielen. Der eine ist von dem anderen abhängig usw. Aus diesem Grund kann es anfangs auch zu Fehlermeldungen kommen. Daher würde ich zunächst einmal alle Container stoppen und neu starten.

    Falls es beim Umsetzen meiner Anleitung zwischendurch mal Fehler gegeben haben sollte, könnte es sein, dass irgendetwas nicht zusammen passt. Dann kannst Du, und das ist das Schöne daran, alle Container und ggfs. sogar alle Images einfach löschen (über die ssh-Konsole oder über die QNAP-Container-Station). Der Docker-Compose baut ja alles wieder auf.


    Viel Erfolg
    xgadscu


    PS: Ich habe meine Konfiguration übrigens schon vor 2 Wochen erweitert um 3 weitere Container:

    • redis
    • cron
    • collabora

    Soeben habe ich ganz einfach die Versionen auf den neuesten Stand gebracht. Einfach Build and Run erneut ausführen und Schwupp, alles ist frisch :)

    Anleitung: nextcloud mit nginx reverse proxy und LetsEncrypt auf Docker

    Beschreibung

    Diese Anleitung beschreibt, wie man auf einem Docker-fähigen QNAP-System nextcloud mit folgenden Leistungsmerkmalen installiert:

    • 5 Docker-Container auf einem QNAP hinter einem Internet-Router
      • Nginx-Reverse-Proxy
      • Lets-Encrypt-Companion
      • Web-Server
      • nextcloud
      • Maria-DB
    • verschlüsselter Aufruf über eine Subdomain, Portangabe nicht erforderlich
    • SSL-Verschlüsselung auf Basis von kostenlosen LetsEncrypt-Zertifikaten, die automatisch verlängert werden.
    • einfache Installation über ein docker-compose-File und ein paar Konfigurationsfiles
    • einfache Aktualisierung der Docker-Container über 2 Befehle
    • Daten und Konfigurationen bleiben auf Docker-Volumes erhalten
    • Die Docker-Container können auch über die QNAP Container-Station gemanaged werden. Leider sind nicht alle Einstellungen aus dem docker-compose-File sichtbar.

    Grundlagen

    Diese Anleitung basiert auf folgendem Beispiel:

    https://github.com/nextcloud/d…h-nginx-proxy/mariadb/fpm

    Da wir hier in einem QNAP-Forum sind, ist die Anleitung und die angehängte Musterkonfiguration auf QNAP-Verhältnisse abgestimmt. Die Anleitung lässt sich aber sicher z.B. auch auf einem Ubuntu-System umsetzen.


    Voraussetzungen

    1. Dockerfähiges QNAP-System hinter einem Internet-Router
      Bei mir ist es eine Fritzbox.
    2. Subdomain einrichten
      Die Subdomain (z.B. cloud.example.com) muss mit einem Typ A- oder Typ CNAME-Record auf die feste IP oder die DynDns-Adresse des Netzwerks zeigen, in dem sich auch das QNAP-System befindet. Eine einfache Weiterleitung funktioniert nicht!
    3. Ports 80 und 443 freimachen
      Die Ports 80 und 443 sind möglicherweise auf dem Router und dem QNAP bereits belegt. Sie müssen dort durch andere Ports ersetzt werden, da sie später vom ACME-Protokoll des LetsEncrypt-Containers benötigt werden. Diese lassen sich meines Wissens aktuell (noch) nicht überschreiben. Ich hatte zu Anfang immer mit Port-Mappings gearbeitet. Dann hat aber das Generieren der Zertifikate nicht funktioniert.
    4. Portweiterleitung im Router für Ports 80 und 443
      Im Router muss jetzt eine Portweiterleitung für die Ports 80 und 443 auf die IP des QNAP-Systems eingerichtet werden. Auf diese Ports wird später der nginx-Reverse-Proxy lauschen.
    5. Freigabe-Ordner auf QNAP
      Die spätere Konfiguration basiert darauf, dass auf dem QNAP folgende Freigabe-Ordner angelegt sind:

      Docker-Configs: für Docker-Konfigurationen
      Docker-Volumes: für die persistenten Daten der Docker-Container

    Konfiguration

    1. ssh-Zugang zum QNAP-System starten
      Ich arbeite hierfür gerne mit MobaXterm.
    2. Musterkonfiguration herunterladen
      Die angehängte Musterkonfiguration nextcloud.zip herunterladen und im Freigabe-Ordner Docker-Configs als Ordner nextcloud entpacken.
    3. Musterkonfiguration anpassen
      In der Musterkonfiguration muss nun im File db.env das Passwort für die nextcloud-DB eingetragen werden. User nextcloud und DB-Name nextcloud bleiben unverändert.
      Als nächstes wird das docker-compose.yml-File angepasst. Hier müssen folgende Werte geändert werden:
      - <<meinPasswort>> > Master-PW für mariaDB
      - cloud.example.com > Subdomain-Name
      - <<name>>@example.com > User für LetsEncrypt-Benachrichtigungen

    Build and Run

    1. Container erstellen
      Auf der ssh-Konsole in den Konfigurationsordner wechseln
      cd /share/CACHEDEV1_DATA/Docker-Configs/nextcloud/ 
      und den Build aufrufen
      docker-compose build --pull
    2. Container starten
      docker-compose up -d

    Nach der Installation

    1. Warten
      Nachdem die Docker-Container erstellt und gestartet wurden, sollte man erst einmal ca. 10 Minuten warten, bis sich die Container initialisiert haben. Insbesondere die Generierung des LetsEncrypt-Zertifikats für die Subdomain dauert eine Weile.
      Die Volumes werden autmatisch angelegt und erscheinen unter /share/CACHEDEV1_DATA/Docker-Volumes/nextcloud/.
      Insbesondere wird die Konfigurationsdatei für den nginx Reverse Proxy erzeugt. Man kann das Ergebnis unter /share/CACHEDEV1_DATA/Docker-Volumes/nextcloud/nginx-conf.d/default.conf ansehen.
      Den Initialisierungsprozess kann man auch über die QNAP-Container-Station beobachten.
    2. Abschließen der nextcloud-Installation
      Um die nextcloud-Installation abzuschließen, ruft man jetzt die Subdomain über einen Browser auf. Auf der nun erscheinenden Anmeldemaske gibt man UserID und Passwort für den Admin-User ein und muss anschließend noch einmal eine Weile warten, bis im Hintergrund die nextcloud-Datenbank fertig eingerichtet ist.

    Aktualisierung und Wartung

    1. Aktualisierung
      Neue Containerversionen installiert man einfach durch erneutes Aufrufen der Schritte 1 und 2 unter Build and Run. Die Daten bleiben über die Volumes erhalten.
    2. Spezielle Konfigurationen
      Besonderheiten insbesondere für den nginx Reverse Proxy können über spezielle Templates/Includes nachkonfiguriert werden. Wie das geht, kann man unter https://hub.docker.com/r/jwilder/nginx-proxy/ nachlesen.
    3. Container-Station
      Über die Container-Station lassen sich Container stoppen und starten. Außerdem können weitere Informationen über Container, Images und Volumes eingesehen werden.
      Spezielle Details bekommt man mit Hilfe von Original-Docker-Befehlen über die die ssh-Konsole.

    Viel Erfolg beim Nachbauen
    xgadscu

    Hallo zusammen,


    bei mir läuft es jetzt auch. Es lag tatsächlich daran, dass ich die Ports 80 und 443 nicht auf andere Portnummern mappen durfte.

    Ich habe jetzt folgende Lösung:

    • 5 Docker-Container auf einem QNAP hinter einer Fritzbox als Router
      • Nginx-Reverse-Proxy
      • Lets-Encrypt-Companion
      • Web-Server
      • nextcloud
      • Maria-DB
    • verschlüsselter Aufruf über eine Subdomain, Portangabe nicht erforderlich
    • SSL-Verschlüsselung auf Basis von kostenlosen LetsEncrypt-Zertifikaten, die automatisch verlängert werden.
    • einfache Installation über ein docker-compose-File und ein paar Konfigurationsfiles
    • einfache Aktualisierung der Docker-Container über 2 Befehle
    • Daten und Konfigurationen bleiben auf Docker-Volumes erhalten
    • Die Docker-Container können auch über die QNAP Container-Station gemanaged werden. Leider sind nicht alle Einstellungen aus dem docker-compose-File sichtbar.

    Wenn noch Interesse besteht, kann ich auch gerne eine Anleitung dazu schreiben.


    Gruß xgadscu

    Hallo pastor,


    ich weiß, dass ich den ssl-Port für nginx auf eine andere Portnummer mappen und diese auf extern weiterleiten kann. Ich habe nur den Verdacht, dass 443 in den Templates der Docker-Gen von JWilder (Bestandteil von docker/nginx-proxy) hart verdrahtet ist und deshalb in meiner generierten nginx-Konfiguration auf Basis von 2443:443 die ssl-Verarbeitung nicht enthalten ist. Es fehlt dort bei mir "listen *443 ssl" bzw. "ssl on" und die Angaben für die Zertifikate usw.

    Da muss ich jetzt mal weiter forschen und wahrscheinlich ein eigenes Template einsetzen. Das wird aber eine Weile dauern, weil ich noch andere Dinge zu tun habe. Wenn ich eine Lösung finden sollte, melde ich mich zurück.


    Gruß xgadscu