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.

  • Ist einfach eine Frechheit einiger Entwickler Produkte so zu designen als seien sie die einzigen auf nem Server ohne an Koexistenz zu denken.

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

  • 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.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • 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 :)

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • 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
    [...]
    nginx-mailcow
     environment:
      - VIRTUAL_HOST=${MAILCOW_HOSTNAME}
      - VIRTUAL_PORT={HTTP_PORT:-80}
      - LETSENCRYPT_HOST=${MAILCOW_HOSTNAME}
    [...]
    # ports:
    # "Portbinding 80"
    # "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'

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • 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
    nginx-proxy:
    external: true

    Und in der mailcow.conf:

    Code
    HTTP_PORT=8080
    HTTP_BIND=127.0.0.1
    
    HTTPS_PORT=8443
    HTTPS_BIND=127.0.0.1
    
    SKIP_LETS_ENCRYPT=y

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

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


    Ist vielleicht ein bisschen Denkarbeit, aber kein Hexenwerk.

  • Vielen Dank, @DatAres

    Das hat bei mir auch funktioniert.


    Es kann allerdings sein, dass man beim Update Probleme bekommt, wenn man was an der docker-compose.yml ändert. Deswegen hab ich die (fast) nicht angetastet. Dort habe ich nur die Portbindings für `nginx-mailcow` auskommentiert, wie von dir beschrieben:


    Code
      nginx-mailcow:
         #ports:
         #- "${HTTPS_BIND:-0.0.0.0}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
         #- "${HTTP_BIND:-0.0.0.0}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"


    Um Updateprobleme nicht herauszufordern kann man eine Datei docker-compose.override.yml schreiben, in der dann alle Anpassungen stehen. Dabei ist es wichtig, wenn man Netzwerke hinzufügt, alle vorhandenen auch nochmal mitzunehmen:





    In den Dateipfaden konnte ich die Environment Variablen nutzen, als alias in den Netzwerken war das aber bei mir nicht möglich.


    Eine nette Spielerei am Rande: anderes_netzwerk ist ein beliebiges anderes Docker-Netzwerk. Damit ist es Containern aus anderen Projekten möglich, lokal über postfix Mails zu versenden. Weil hier die URL als alias verwendet wird dürfte es auch nicht zu Zertifikatsproblemen kommen.


    Vielen Dank an den "Chefentwickler" (glaube ich) von Mailcow, André, der hat mir den Tipp mit der override Datei gegeben.

  • Hi,

    ich bin mal euren Vorgaben gefolgt @DatAres  void und stoße jetzt jedoch auf den Fehler:


    Code
    ERROR: Network nginx-proxy declared as external, but could not be found. Please create the network manually using `docker network create nginx-proxy` and try again.

    Könnt ihr mir sagen, was ich falsch gemacht habe? Es scheint, als hätte ich etwas vergessen.


    Viele Grüße

    Tobi