Moin! On 16.04.21 15:19, Ralph Lindner wrote: > Ich möchte auf einem root-server (VM von Netcup) mehrere lxc mit z. B. > Webservern oder Nextcloud einrichten. Damit die URL beim richtigen lxc > landen, benötige ich natürlich einen reverse proxy. Soweit so klar. Bingo. > Es sollte aber auch möglich sein nachträglich sowohl das lxc-Ziel (einer > Domain) zu ändern, als auch die Webadresse des lxc. Das sind ja die Einstellungen des Reverse-Proxy. Also so ungefähr. (www.)domain1.de → 192.168.1.101 (www.)domain2.de → 192.168.1.102 Die genauen Domains und Ziele müssen ja in der Config des RevProxy hinterlegt werden. > - Ersteres z. B. um auf einen Mirror umzustellen oder nach einem > Relaunch auf ein neues System. Würde in den Beispielen bedeuten, die (Ziel-)IP-Adresse des LXContainer anzupassen. > - Zweites um aus einer Entwicklungsumgebung ein Produktivsystem zu > machen. [z. B. wenn ein lxc zuerst als Entwicklungsumgebung (erreichbar > z. B. unter https://kunde1.dev.example.com) genutzt wird und > anschließend als Produktivsystem (unter https://kunde1.com)] Umstellung/Ergänzung der Domain(s) im RevProxy. Und evtl. noch Anpassung(en) im Backend, damit Links&Co. mit den richtigen URLs/Domains generiert werden. > Wegen dieser beiden Anforderungen erscheint es mir ratsam die > letsencrypt-Zertifikate vom reverse proxy verwalten zu lassen und nicht > vom lxc. Ist das plausibel und sehe ich das richtig? Das ist ein bisschen Konzept-Frage. *ICH* halte es für ausreichend, wenn SSL auf dem RevProxy terminiert (und dort auch verwaltet wird, z.B. Lets-Encrypt oder sowas) und nach hinten einfach HTTP gesprochen wird - wenn jemand den Traffic dort abgreifen kann, kann er's auch im Container. Außerdem kann man dann mit dem RevProxy ggf. auch noch die Header/Inhalte fixen/hinzufügen/... Ja, BTDT, weil immer wieder WebApps davon ausgehen, dass sie den ganzen Server für sich haben 🙄 Auf der anderen Seite gibt es aber auch die Möglichkeit, anhand von SNI "Server Name Indication", dem "Host:"-Header von SSL/TLS den Backend-Server auszuwählen. Dann wäre HAProxy, sniproxy oder nginx (nicht Apache) Dein RevProxy. Irgendwas davon konnte dann keine Wildcard-Zertifikate, irgendwas nur einen (Teil-)Domainnamen je Backend-Server, auch deswegen hab ich das Thema aufgegeben. Mag aber sein, dass sich da auch schon wieder was getan hat. Bonus-Frage: Soll der ReverseProxy auf dem Host oder ebenfalls in einem Container laufen? Und schon wieder: Religionsfrage 😁 > Wenn ja, welche Software sollte man als reverse proxy einsetzen? > nginx oder apache oder gleich große Geschütze wie HAProxy? Den, mit dem Du Dich am meisten auskennst. Nein, kein Witz früher oder später wirst Du an Stellen kommen, wo Du nacharbeiten musst. Und das "Nacharbeiten" ist dann halt vom jeweiligen Server abhängig. Teilweise ist es sogar so, dass Du Fehler mit einem der Server hast, mit einem anderen gar nicht, weil er irgendwas von vorne herein anders macht. BTW, HAProxy ist kein großes Geschoss. Ist halt ein Reverse-Proxy/Loadbalancer und das beherrschen sowohl Apache als auch nginx ebenfalls. Und falls jetzt gleich wieder ein nginx-Jünger um die Ecke kommt: Nein, damit ist nicht alles einfach einfach und funktioniert out-of-the-box 😜 > Für HAProxy habe ich eine Anleitung zur zentralen Verwaltung der > Zertifikate mit certbot gefunden > (https://kevinbentlage.nl/blog/lets-encrypt-with-haproxy/). Dass ich kein Freund von certbot bin, sollte hier ja hinlänglich bekannt sein. In meinen Setups läuft entweder dehydrated.io (nach wie vor mein Favorit) oder acme.sh (in Kombination mit haproxy). Aber grundsätzlich gilt auch hier: Der LE-Client, mit dem Du Dich auskennst. Das Setup aus dem Link funktioniert grundsätzlich. BTDT, mit certbot und acme.sh - dehydrated.io bräuchte dann halt 'nen zusätzlichen Web-Server, deswegen nehm ich das an dieser Stelle nicht. > Allerdings bevorzuge ich in diesem Fall unbedingt die EINFACHSTE Lösung, > denn ich habe bisher noch nie reverse proxy konfiguriert und bin auch > mit lxc noch Anfänger. > Welches Vorgehen würdet ihr mir empfehlen? Ganz klar: Apache auf dem Host, mit Deinem favorisierten LE-Client. Warum? Weil Du schon mit Apache gemacht hast, die grundsätzliche Konfiguration kennst, es viele Möglichkeiten gibt Einfluss zu nehmen und - WICHTIG - Du findest zu fast allen Problemen Lösungen im Netz. Und ob Dein VHost nun Reverse-Proxy ist oder Dateien direkt ausliefert ist für SSL/TLS-Dinge egal, hier findest Du also auch bestimmt bei Problemen Hilfe im Netz. Und wenn ich dran denke 😝 , dann erweitere ich nochmal die Lösung im LUSC-Wiki zum RevProxy! Bye Sven -- -- Leukämie → http://de.wikipedia.org/wiki/Leuk%C3%A4mie Heilung → http://de.wikipedia.org/wiki/Knochenmark#Knochenmarkspende Typisierung → https://akb.de/registrierung/ https://zkrd.de/de/adressen/ Fragen? → sven@velt.de -- Mailing-Liste der Linux User Schwabach (LUSC) e.V. Vor und beim Posten bitte => http://lusc.de/List-Netiquette <= und => http://lusc.de/List-Howto <= beachten. Danke!