docker, mailcow, nginx reverse proxy, wordpress

Kann es sein, das mailcow und proxy beide auf Port 80 bzw/und 443 lauschen (bzw das versuchen)?

Die Doku kennst du?

https://mailcow.github.io/mailcow-docker…/firststeps-rp/

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

Quote from snax

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.

Quote from H6G

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.

server {
    listen 80;
    listen 443 ssl http2;
    server_name mail.domain.de autoconfig.domain.de autodiscover.domain.de;

    ssl_certificate /etc/nginx/ssl/domain.de/fullchain.cer;
    ssl_certificate_key /etc/nginx/ssl/domain.de/domain.de.key;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;

    location / {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

    if ($scheme = http) {
        return 301 https://$server_name$request_uri;
       }
    }
}

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.

Du musst die 80/443 einmal ummappen auf z.B. 5080 & 50443 im Compose, oder du arbeitest mit Unix Domain Sockets.

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

[...]
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.

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.

Quote from snax

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

Quote from snax

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:

environment:
...
- VIRTUAL_HOST=${MAILCOW_HOSTNAME}
- VIRTUAL_PORT=8080
- VIRTUAL_PROTO=http
- LETSENCRYPT_HOST=${MAILCOW_HOSTNAME}
- LETSENCRYPT_EMAIL=mail@example.org
...

#      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}"
      expose:
         - "8080"

networks:
        mailcow-network:
          aliases:
            - nginx
        nginx-proxy:
          aliases:
            - mail.example.org

Anpassungen an networks:

nginx-proxy:
external: true

Und in der mailcow.conf:

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

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:

  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:

version: '2.1'
services:
  postfix-mailcow:
    networks:
      mailcow-network:
        aliases:
          - postfix
      sonstiges_netzwerk:
        aliases:
          - mail.domain.de
      proxy-net:

  nginx-mailcow:
    expose:
      - "8080"
    environment:
      - VIRTUAL_HOST=${MAILCOW_HOSTNAME}
      - LETSENCRYPT_HOST=${MAILCOW_HOSTNAME}
      - VIRTUAL_PROTO=http
      - VIRTUAL_PORT=8080
    volumes:
      - /dein_docker_root/proxy/certs/${MAILCOW_HOSTNAME}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
      - /dein_docker_root/proxy/certs/${MAILCOW_HOSTNAME}/key.pem:/etc/ssl/mail/key.pem:ro
    networks:
      mailcow-network:
        aliases:
          - nginx
      proxy-net:
        aliases:
          - mail.domain.de

  dovecot-mailcow:
    volumes:
      - /dein_docker_root/proxy/certs/${MAILCOW_HOSTNAME}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
      - /dein_docker_root/proxy/certs/${MAILCOW_HOSTNAME}/key.pem:/etc/ssl/mail/key.pem:ro

  postfix-mailcow:
    volumes:
      - /dein_docker_root/proxy/certs/${MAILCOW_HOSTNAME}/fullchain.pem:/etc/ssl/mail/cert.pem:ro
      - /dein_docker_root/proxy/certs/${MAILCOW_HOSTNAME}/key.pem:/etc/ssl/mail/key.pem:ro

networks:
  mailcow-network:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.name: br-mailcow
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: ${IPV4_NETWORK:-172.22.1}.0/24
        - subnet: ${IPV6_NETWORK:-fd4d:6169:6c63:6f77::/64}
  sonstiges_netzwerk:
    external: true
  proxy-net:
    external: true

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:

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