Beiträge von snax

Zitat von m_ueberall

[...] (besserer Adressat wäre der Support) oder man wird selbst aktiv.

1. Ticket ist seit dem 22.11. offen und bisher kam keinerlei Reaktion vom Support und das Problem besteht weiterhin. Für ein Problem was seit längerem bekannt ist, ist das ein Armutszeugnis.

2. Wenn netcup einen Service anbietet, in dem Fall die Verwaltung meiner DNS Records, dann kann man als Kunde auch erwarten, dass es netcup schafft diesen Service stabil zu betreiben. Fehler können auftreten und passieren, da habe ich volles Verständnis für. Das Verständnis hört aber auch wenn der Fehler immer und immer und immer wieder auftritt und man als Kunde angelogen wird, dass angeblich Schritte unternommen wurden um das Problem zukünftig zu verhindern. Dann soll netcup halt aufhören so einen Service anzubieten und dazu stehen, dass sie auf dem Gebiet nicht ausreichende Expertise haben.

Afaik meine ich auch hier im Forum gelesen zu haben, dass eine Migration zu einem anderen DNS Provider fehl schlägt solange das Problem besteht. Selbst wenn ich wollte, könnte ich also aktuell nicht migrieren. Ja ich könnte es jetzt testen aber dafür muss ich meine Zeit opfern weil netcup seine Technik nicht unter Kontrolle hat und lieber seine Kunden belügt?

Als Knaller kommt hinzu, dass die Hotline nicht einmal grob abschätzen kann wann das Problem/Ticket bearbeitet wird...

Wir haben November 2022 und netcup hat das Problem scheinbar immer noch nicht im Griff? Das ist jetzt das zweite Mal dieses Jahr(!), dass eine bei netcup liegende Domain diesen Fehler hat.

Vielleicht solltet ihr ernsthaft in Erwägung ziehen, das Feature nicht mehr anzubieten und bei dem zu bleiben, was man technisch beherrscht und/oder eine dicke fette Warnung an DNSSEC zu machen, dass es hier in der Vergangenheit Probleme gab und aktuell weiter geben wird also nur für Testzwecke verwendet werden sollte.

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:

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

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.