Posts by snax

    Bist du sicher, dass du wirklich im Stande bist, einen einen Server zu administrieren und zu verstehen was da passiert? Du bist dir der Risiken und der Haftung bewusst, der du als Mieter des Servers unterliegst?

    Vielleicht wäre ein reines Webhosting-Paket für dich sinnvoller wenn du nur eine Nextcloud o.ä. nutzen möchtest?

    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

    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.

    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.:(

    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.

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