Hallo... habe gerade mal versucht die Nextcloud in der ContainerStation zu installieren. Unter http läuft alles problemlos... ich bekomme aber ums verrecken Nextcloud nicht als https geöffnet. Fehler = ERR_CONNECTION_REFUSED 
Der Container selber hat ne eigene IP als Bridge...
Jemand vielleicht eine Idee ?
Gruss pastor
Hast Du bei der Installation die Weiterleitung des Ports 443 in den Container auch eingerichtet?
Ich werde das Thema vermutlich morgen angehen. Wenn es funktioniert kann ich ja gerne eine Anleitung erstellen.
hallo, wenn Du einen Container erstellst, kannst Du das unter Netzwerk tun.
Unbenannt.PNG
Aber Du hast Port 80 und Port 443 duchgeleitet? Benutzt Du die DB des Systems?
Hallo,
habe das gleiche Problem. In der Apache Konfiguration kann man doch sicherlich alles ändern? Wo ist die Apacheconfig eigentlich im Containerverzeichnis auf der QNAP??
Moin,
HTTPS funktioniert mit dem offiziellen NextCloud-Image nicht ohne weiteres "out of the box". Der dahinterliegende Webserver ist nur für HTTP konfiguriert. Um HTTPS trotzdem zu ermöglichen muss der lokale Apache der Qnap als Reverse-Proxy zum Docker-Container konfiguriert werden. Leider kann ich dir da nicht helfen, da ich das selbst noch nie umgesetzt habe und nur weiß, dass es theoretisch funktionieren müsste. Auf dem Docker-Hub findest du unter NextCloud die passende Hilfestellung. Dort gibt es eine extra Sektion für HTTPS. Ich hoffe, das hilft dir etwas weiter.
Ein anderer Weg wäre, dir ein lokales, eigenes Image auf Basis des offiziellen Images zu bauen und dann dieses als Grundlage für deinen Container zu verwenden. Diesen Weg fahre ich bei all meinen verwendeten Containern. Damit habe ich etwas mehr Möglichkeiten ein Image an meine Anforderungen anzupassen. Es handelt sich dabei allerdings um den komplizierteren Weg.
Ciao
ariaci
Ich werde das Thema vermutlich morgen angehen. Wenn es funktioniert kann ich ja gerne eine Anleitung erstellen.
Hmmm -ich stehe vor demselben Problem, allerdings mit ownCloudX (was da aber keinen Unterschied machen sollte). Die Idee, einen NGINX / LetsEncrypt mit Docker parallel aufzusetzen und den dann zu nutzen, hat (noch) nicht hingehauen.
Wie könnte man das doch ans Laufen kriegen?
Gruß, St.
ich bin gerade dabei einen nextcloud/nginx kombi zu installieren...
Moin,
stehe vor demselben Problem mit dem Reverse Proxy.
Hat es jemand hinbekommen und evtl. ein Tutorial dafür 
?
Danke
Todde
Jetzt bin ich aber gespannt. Wie hast Du es denn zum Laufen bekommen. Kannst Du uns z.B. ein Docker-Compose-File schicken? Das wäre super...
Hallo,
ich versuche mal einen Schnelldurchlauf, zur Konfiguration eines Apache-Webservers, der einen spezifischen Host zur einem anderen Server als Proxy durchleitet ...
Folgenden Inhalt hat meine Konfiguration des php-apache-Containers:
#######################################
# Vhost
#######################################
<VirtualHost *:80>
ServerName hostname.domain.tld
ServerAlias hostname
UseCanonicalName Off
<IfVersion < 2.4>
Include /opt/docker/etc/httpd/vhost.common.d/*.conf
</IfVersion>
<IfVersion >= 2.4>
IncludeOptional /opt/docker/etc/httpd/vhost.common.d/*.conf
</IfVersion>
Redirect permanent "/" "https://hostname.domain.tld/"
</VirtualHost>
<VirtualHost *:443>
ServerName hostname.domain.tld>
ServerAlias hostname
UseCanonicalName Off
<IfVersion < 2.4>
Include /opt/docker/etc/httpd/vhost.common.d/*.conf
</IfVersion>
<IfVersion >= 2.4>
IncludeOptional /opt/docker/etc/httpd/vhost.common.d/*.conf
</IfVersion>
Include /opt/docker/etc/httpd/vhost.ssl.conf
ProxyPreserveHost On
ProxyPass / http://destinationhostname.destinationdomain.tld:destinationport/
ProxyPassReverse / http://destinationhostname.destinationdomain.tld:destinationport/
</VirtualHost>Der erste VirtualHost-Part hört auf Port 80 aller eingehenden Verbindungen und konfiguriert die Weiterleitung von HTTP auf HTTPS. Damit wird quasi eine direkte HTTP-Verbindung unmöglich. Der zweite VIrtualHost-Part beschreibt dann die gekapselte HTTPS-Verbindung. Sämtliche über den Port 443 eingehenden Verbindungen werden nach "ProxyPass" geleitet. Antworten des dort konfigurierten Proxy-Ziels werden über "ProxyPassReverse" aufgelöst. In der hier sichtbaren Konfiguration werden alle unter Root liegenden Dateien direkt 1:1 in beide Richtungen weitergeleitet. Damit wird sichergestellt, dass die Verzeichnisstrukturen des Proxies mit dem Nicht-HTTPS-Ziel übereinstimmen.
Vielleicht klärt dies einiges zum Thema Apache-Proxy auf.
Ciao
ariaci
Ich denke mal nicht das irgendeine *.config so als Anleitung für ein Reverse-Proxy ausreicht... hat vielleicht nicht jeder soviel Berührungspunkte mit so etwas...
Erstmal grundsätzlich beruht mein Proxy aus den folgenden Anleitungen anderer ... und läuft auch nicht auf Docker sondern als VM mit Nginx und Letsencrypt ... erreichbar unter der jeweiligen Subdomain ...
Ich versuch mal die Erstellung und Einrichtung meiner VM als Reverse-Proxy kurz zusammenzufassen...
...also als
1. VM mit Ubuntu 16.04 lts angelegt - nicht dickes, ich hab ein Kern mit 512MB Arbeitsspeicher und 25 GB Festplatte zugewiesen... hilfreich nach der Installation war bei mir eine feste IP und die Vergabe eines Root-Passwortes sowie die Installation des ssh-Servers
2. dieser Anleitung https://blog.friedlandreas.net…1/lets-encrypt-mit-nginx/ für die Installation von Nginx und Letsencrypt folgen, aber die angebotene Webseiten-Konfig den eigenen Bedürfnissen anpassen (s. Punkt 3)
3. für die Anpassung der Webseiten-Konfig fand ich diese Anleitung sehr hilfreich... https://prezer.de/nginx-als-reverseproxy-11.html. Muss aber natürlich für die eigenen Bedürfnisse geändert werden.
Hier mal meine Webseiten-Konfig für Nextcloud (Subdomain1) und UniFi (Subdomain2) - (laufen beide im Bridgemodus als Docker auf der selben QNAP) :
# Ein Listener auf Port 80 sorgt dafür, dass Anfragen an http automatisch über ein HTTP 301 an https umgeitet werden
server {
listen 80;
server_name SubDomain1.Domain.de Subdomain2.Domain.de; # Hier sind alle betriebenen Domains/Subdomains einzutragen.
return 301 https://$host$request_uri;
}
# Web-Applikation 1
server {
listen 443 ssl;
server_name Subdomain1.Domain.de; # Domain für die erste Web-Applikation
include /etc/nginx/snippets/letsencrypt.conf;
ssl on;
ssl_certificate /etc/letsencrypt/live/Subdomain1.Domain.de/fullchain.pem; # Zertifikatsbundle für erste Web-Applikation
ssl_certificate_key /etc/letsencrypt/live/Subdomain1.Domain.de/privkey.pem; #Zertifikatsschlüssel für erste WebApplikation
# Manche Web-Applikationen leiten einen auf http:// um. Die nachfolgende Anweisung leitet http:// anfragen an Port 443 auf https:// um
error_page 497 = https://$server_name:$server_port$request_uri;
location /
{
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://192.168.2.xxx:80; # Interne IP und Port von Nextcloud
error_log /var/log/nginx/nextcloud-error.log;
access_log /var/log/nginx/nextcloud-access.log;
}
}
# Web-Applikation 2
server {
listen 443 ssl;
server_name Subdomain2.Domain.de; # Domain für die erste Web-Applikation
include /etc/nginx/snippets/letsencrypt.conf;
ssl on;
ssl_certificate /etc/letsencrypt/live/Subdomain2.Domain.de/fullchain.pem; # Zertifikatsbundle für erste Web-Applikation
ssl_certificate_key /etc/letsencrypt/live/Subdomain2.Domain.de/privkey.pem; #Zertifikatsschlüssel für erste WebApplikation
# Manche Web-Applikationen leiten einen auf http:// um. Die nachfolgende Anweisung leitet http:// anfragen an Port 443 auf https:// um
error_page 497 = https://$server_name:$server_port$request_uri;
location /wss/ {
proxy_pass https://192.168.2.xxx:8443;# IP und Port von UniFi
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_read_timeout 86400;
}
location /
{
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass https://192.168.2.xxx:8443; # Interne IP und Port hier auch von UniFi
error_log /var/log/nginx/unifi-error.log;
access_log /var/log/nginx/unifi-access.log;
}
}4. anlegen einer SubDomain bei deinem Hoster (vorhandensein vorausgesetzt) - danach DNS Zone für die SubDomain ändern auf CNAME und als Ziel deine DDNS von myqnapcloud eintragen ( also xxx.myqnapcloud.com) - warten bis die Änderung im DNS umgesetzt wurde (kann wohl bis zu 24h dauern).
5. im Router Portweiterleitungen für die Ports 80 und 443 auf das NAS einstellen
Wenn alles so ohne Fehler erfolgt ist sind die SubDomains durch die Weiterleitung auf die internen IP's mit einem sauberen Letsencrypt-Zertifikat zu erreichen...
Gruss pastor
Hallo pastor,
ich weiß, dass nicht irgendeine *.config ausreicht. Ich habe das nur so lapidar geschrieben, weil Du selbst diesen Thread eröffnet hast und plötzlich unvermittelt schreibst: "Hab mich letzte Woche mal damit beschäftigt und läuft auch..."
Also: Ich habe 38 Jahre als IT-Architekt gearbeitet, dies aber vornehmlich in der Anwendungsarchitektur und kenne mich in der Netzwerkkonfiguration nicht so perfekt aus.
Jetzt habe ich privat den Ehrgeiz, Nextcloud im Docker-Container mit nginx als Reverse Proxy auf dem QNAP zum Laufen zu bringen und über eine externe Subdomain sicher aufrufbar zu machen.
Der vielversprechendste Ansatz war für mich bisher Jwilder/nginx-proxy in Zusammenhang mit diesem nextcloud-example .
Ich arbeite also unter QNAP mit docker-compose und das Ganze funktioniert wunderbar auf einem auf 80 gemappten Port ohne SSL.
Mein aktueller Stand ist folgender:
- ich brauche für meine SubDomain einen anderen Port als 443, weil der schon von QNAP belegt ist.
- auf dem nginx braucht man SSL-Termination, weil nextcloud nur auf Port 80 hört
- das Problem liegt offensichtlich in der Docker-Gen. Im Template nginx.tmp ist zwar ssl behandelt, im Generat kommt es aber nicht an. Da muss ich mich jetzt mal weiter reinknien.
Vielen Dank für Deine Anleitungen. Die werde ich auch noch studieren. Entscheidend ist aber, dass ich mit einem leichtgewichtigen Docker-Container arbeiten möchte.
Viele Grüße
xgadscu
Hallo xgadscu,
wenn du jetzt nicht auch "ariaci" bist bezog sich mein Teil mit der *.config nicht wirklich auf dich. Du hattest gefragt wie ich das erreicht habe...eine kurzen Überblick dazu habe ich erstellt. Ich bin da aber auch noch am prüfen ob die Zertifikatserneuerung so funktioniert und wie es mit der Sicherheit bestellt ist.
Docker ist leider so gar nicht mein Ding... sag mir wie ich aus der VM ein Docker-Compose-File erstelle und ich kann das gerne machen.
Für mich persönlich war es halt egal wie ich ohne weiterer separater Hardware einen Reverse-Proxy aufsetze ... hier mal der Ressourcenverbrauch der VM, empfinde ich eigentlich auch noch als "leichtgewichtig".
Bildschirmfoto 2018-05-09 um 23.33.20.png
Wenn du für deine Subdomain einen anderen Port als den 443 (gehe jetzt mal davon aus das du extern meinst) nutzen möchtest, kannst du doch eigentlich mit Hilfe der Portweiterleitungen und einer angepassten Webseiten-Konfig das Problem lösen, oder?
Gruss pastor