docker, mailcow, nginx reverse proxy, wordpress

  • Hi,

    ich möchte auf meinem vserver docker installieren und


    folgende Konstellation installieren:

    Das ganze soll über ein nginx-proxy ausgeliefert werden.


    Aktuell kriege ich den proxy und mailcow nicht verheiratet.

    Hat jemand zufällig eine laufende config?


    Viele Grüße Stefan

  • @heavygate: Die "Doku" kannst teilweise in der Pfeife rauchen. Ist einfach eine Frechheit einiger Entwickler Produkte so zu designen als seien sie die einzigen auf nem Server ohne an Koexistenz zu denken.


    icecast : Nutzt du zufällig die Reverse Proxy Config von jwilder? Dafür hab ich ne lauffähige Config.

  • Würde mich auch mal interessieren an welcher Stelle die Doku denn so mies sein soll und vorallem wieso du dann noch keinen Pull Request gestellt hast, um das zu ändern. Ich finde eher deine Unterstellungen sind eine Frechheit, schließlich geht es hier um Software die Menschen in ihrer Freizeit entwickelt und kostenlos zur Verfügung stellen. Zumal der andryyy echt krassen Support leistet im IRC und mit seinen regelmäßigen Commits, wofür ihn auch keiner bezahlt.

  • Welche Behinderungen gibt es denn bei einer Software die ausschließlich als Container bereitgestellt wird?

    Frag ich mich auch gerade, ... ist doch eigentlich optimal. Die Container kannst laufen lassen wo immer du willst.

  • Wie wäre es, wenn du mal deine aktuelle Config postest. Eigentlich lässt sich mailcow relativ easy hinter nem nginx reverse proxy betreiben. Hier mal meine Config - stimmt eigentlich zu 99% mit der aus der Doku überein.



    Musst halt nur angeben, auf welchem Port deine Mailkuh horcht. SSL Zertifikate läuft bei mir nicht über Mailcow, sondern achme.sh auf nem anderen Server (hierbei dran denken, die passenden container beim update zu restarten)


    Edit: an die mailcow config hast du gedacht oder? Steht eigentlich am Anfang der Doku :)

  • Betreibe ich einen manuellen nginx reverse proxy: Ja dann kann man sich die Config zurecht schreiben. Nutzt man aber einen semi-automatischen nginx, der sich aus einem Template die Config zieht, dann sieht das anders aus.

    "Mein" nginx z.B. lauscht per read-only auf der docker api am localhost. In die compose files schreibe ich rein "virtual_host: subdomain.example.com". Nein nginx sieht dies, generiert für den virtual_host die config und holt sich die zertifikate. Klappt wunderbar mit nextcloud, wordpress, usw.

    Vorteil der Lösung: ein zentraler Punkt wo ich die Zertifikate besorge, ein zentraler Punkt wo ich einmalig im Template sauber die header bereinigen/anpassen kann, die tls cipher configs setze usw.

    Ich erwarte von einem Docker Container, der einen Webdienst bereit stellt, dass dieser "einfach" nur einen expose 80/443 hat und nicht, dass sich der Container direkt Richtung Internet öffnet. Für Umgebungen, wo man nur und ausschließlich mailcow betreiben will ohne weitere Webseiten oder zentralen "Einstiegspunkt" wie einen reverse proxy, klappt das Setup auch direkt out of the box. Will ich aber noch parallel auf 80/443 eine nextcloud auf selben Host betreiben, dann kommen sich die beiden Webserver in die Quere oder ich habe manuellen Aufwand bei der Pflege der Config des Reverse Proxys, habe zwei acme-clients laufen usw. usf. Das ist meiner Meinung nach Verschwendung von Ressourcen.


    geekmonkey Hast du bei deinem reverse proxy HSTS aktiv? Falls ja wie hast du das "Problem" gelöst, dass sowohl dein reverse proxy als auch der von Mailcow HSTS macht?


    Vielleicht hab ich da auch zu sehr die it-security Brille auf bzw denke zu sehr an Skalierbarkeit mit einem guten Template und lasse mich da gern eines besseren belehren.

  • Oder ich lasse den Webserver von mailcow gar keine Ports öffnen und mache in der docker-compose.yml:

    Code
    1. [...]
    2. nginx-mailcow
    3. environment:
    4. - VIRTUAL_HOST=${MAILCOW_HOSTNAME}
    5. - VIRTUAL_PORT={HTTP_PORT:-80}
    6. - LETSENCRYPT_HOST=${MAILCOW_HOSTNAME}
    7. [...]
    8. # ports:
    9. # "Portbinding 80"
    10. # "Portbinding 443"

    Der nginx-mailcow container muss dann natürlich noch in das Netz meines eigenen reverse proxies damit die mit einander "sprechen" können.

    Zusätzlich habe ich den mailcow Containern in der compose.yml wo es notwendig ist die Pfade zu den Zertifikaten per :ro eingebunden und in der mailcow.conf natürlich letsencrypt deaktiviert da sich ja bereits mein eigener reverse proxy darum kümmert und in der nginx.conf von mailcow eben HSTS auskommentiert.

    Die Config lief/läuft auch soweit nur dass seit ein paar Tagen der mailcow-dovecot Container alle 10-15 Sekunden beendet und nicht mehr mitspielen will und ich aktuell noch absolut keinen Ansatz dafür habe.:(

  • Ich habe auch rum experimentiert.
    Und habe aktuell auch das Problem das der dovecot nicht mehr hoch kommt, bzw. im 10sek. Takt restartet.

    Ich habe jetzt soviel auf dem System getestet und div. howto probiert das ich erst mal alles auf null setze und neu probiere.

    Glücklicherweise habe ich einen Testserver aufdem ich alles probiere bevor ich meinen vserver plätte um die config dann live zu nehmen.

  • Habe Mailcow inzwischen aufgegeben da der Aufwand, das hinter einem bestehenden Reverse Proxy zu betreiben, in keinster Weise gerechtfertigt ist ggü. dem Nutzen. Verwende inzwischen Mailu als Mailserver-Lösung, da ich auf den SoGo Teil verzichten kann, das übernimmt meine Nextcloud.

  • Habe Mailcow inzwischen aufgegeben da der Aufwand, das hinter einem bestehenden Reverse Proxy zu betreiben, in keinster Weise gerechtfertigt ist ggü. dem Nutzen. Verwende inzwischen Mailu als Mailserver-Lösung, da ich auf den SoGo Teil verzichten kann, das übernimmt meine Nextcloud.

    Solange du Mailu und Nextcloud zum laufen bekommst spricht da sicher nichts gegen. Wobei der Arbeitsaufwand bei der Mailkuh bei knapp 3 Minuten liegen dürfte.


    Du musst halt nur gucken, welche Aufgaben du von mailcow übernehmen lässt, wie z.B. den acme client, und auf welchen ports mailcow hochen soll. Sowohl config als auch docs von Andre sind eigentlich selbst erklärend. Also wenn man das nächste Mal an einer Aufgabe scheitert, die 99% der User mit ein wenig Eigenleistung hinbekommen, ... sollte man vielleicht nicht das ganze System verteufeln, ... *just sayn'

  • Bei einem Standalone Server oder Systemen wo nicht schon ein automatisierter Reverse Proxy inkl. acme (o.ä.) läuft stimme ich dir zu, ja, da ist Mailcow wirklich schnell aufgesetzt und genutzt. Für den Einsatzzweck ist es perfekt, ja.


    Ich nutze aber z.B. das "Setup" von jwilder. Damit habe ich einen Reverse Proxy, der einiges an Security bzgl. Filterung unsicherer HTTP Header, Nutzung nur moderner Ciphers etc mit bringt und wo es in der Regel sehr simpel ist einen weiteren (Web-)Dienst zur Verfügung zu stellen indem man den virtual host, exposed Port des Containers und Name des Zertifikats angibt, den Container startet und nach einer Minute habe ich:

    - Den Dienst unter der gewünschten Subdomain erreichbar

    - ein Zertifikat von LE dafür

    - ein A+ Rating bei Qualys SSL-Test

    - muss keine große manuelle Config der Virtual Hosts von Hand anlegen

    - eine saubere Trennung der Dienste voneinander da jedes Projekt in einem eigenen Docker-Netzwerk liegt


    Mailcow erfordert in diesem Umfeld aber enorme Anpassungen: Ich muss das mailcow-eigene acme raus nehmen und ihm die Zertifikate von meinem eigenen reverse proxy umbennen und "unterjubeln". Sowohl bei Github bei jwilder als auch bei mailcow gibt es unzählige Threads zu Usern mit Problemen in dem Setup.

    Wer eine brauchbare docker-compose.yml hat die mailcow mit jwilder-nginx komplett lauffähig hat: immer gerne her damit

  • Mailcow erfordert in diesem Umfeld aber enorme Anpassungen: Ich muss das mailcow-eigene acme raus nehmen und ihm die Zertifikate von meinem eigenen reverse proxy umbennen und "unterjubeln". Sowohl bei Github bei jwilder als auch bei mailcow gibt es unzählige Threads zu Usern mit Problemen in dem Setup.

    Wer eine brauchbare docker-compose.yml hat die mailcow mit jwilder-nginx komplett lauffähig hat: immer gerne her dami

    Bin ein bisschen late zu der Party, aber sorry, das stimmt nicht. Wer sich die Doku von jwilder + mailcow anschaut, bekommt das denke ich relativ gut hin. Mir ist es zumindest (damals) ohne große Docker-Erfahrung gelungen :)


    An alle Googler:

    Anpassung am mailcow nginx-Container:

    Anpassungen an networks:

    Code
    1. nginx-proxy:
    2. external: true

    Und in der mailcow.conf:

    Code
    1. HTTP_PORT=8080
    2. HTTP_BIND=127.0.0.1
    3. HTTPS_PORT=8443
    4. HTTPS_BIND=127.0.0.1
    5. SKIP_LETS_ENCRYPT=y

    Die Zertifikate, die vom Letsencrypt Companion erstellt wurden, werden dann in die benötigten Container gemounted (dovecot, postfix, nginx):

    Code
    1. volumes:
    2. - /etc/nginx/certs/mail.example.org/fullchain.pem:/etc/ssl/mail/cert.pem:ro
    3. - /etc/nginx/certs/mail.example.org/key.pem:/etc/ssl/mail/key.pem:ro


    Ist vielleicht ein bisschen Denkarbeit, aber kein Hexenwerk.