Das ganze lief gut an und die neue Datei docker-compose.override.yml wurde anstandslos eingebunden. Anschließend konnte ich in den Log-Files (docker-compose logs -f linuxmuster-mailcow) beobachten, dass mittlerweile alle Postfächer synchronisiert wurden. Das Setup scheint also zu passen und die LDAP-Verbindung zum Server ist da!
Nun kommen die Fragen:
Da mittlerweile alle Mailboxen angelegt wurden, wollte ich mich unter SoGO anmelden. Das funktioniert aber leider nur so halb, denn obwohl nach etlichen Sekunden Wartezeit der Login möglich ist, steht dort: Keine Mailbox ausgewählt.
Der Server gibt einen Fehler aus unter Konfiguration → Systeminformation → Protokolle → Dovecot. Dort steht:
Das wundert mich, denn die ldap-Verbindung ist offensichtlich vorhanden. Ich kann von dem mail-Server auch mit ldapsearch den Server abfragen (sowohl ldap:// als auch ldaps:// )
Die zweite Frage betrifft den Domainnamen: Das Feld mail hat bei uns einen Eintrag, den ich nicht für die eMail der Teilnehmer verwenden möchte. Stattdessen sollte der Eintrag von sophomorixCustom1 verwendet werden.
Wie/wo ändere ich das im Setup?
Ist noch jemand von Euch an einer ähnlichen Stelle hängen geblieben und hat einen guten Tipp?
Viele Grüße,
Michael
(Im Menu oben rechts unter Konfiguration → Serverinformation konnte ich sehe, dass ausgerechnet der Container ldap-mailcow neben dem Button „Neustart“ als einziger einen roten und keinen grünen Punkt hatte. )
Das ergibt nicht so wirklich viel Sinn, denn der Mailserver soll ja nur die Schuleigenen Andressen verwalten. Wenn jetzt im sophomorixCustom1 sowas wie „werauchimmer@gmail.com“ drinsteht, dann geht das ja garnich.
Hallo Dorian,
ok, da hast Du Recht - allerdings ist unser Server so installiert, dass intern wie extern der gleiche FQDN verwendet wird. Im Feld mail steht also sowas wie @linuxmuster.meine-domain.de
Das ist als Schul-eMail ungünstig und zu lang. Ich hätte da gerne einen anderen Domainnamen.
Was das andere Problem angeht: Das scheint irgendwo in den Tiefen von mailcow zu liegen
Falls Du damit die Einstellungen unter /etc/linuxmuster/sophomorix/default-school/school.conf meinst … das sieht bei uns bereits unter jedem der [type.XY]-Einträge so aus:
Im Feld mail steht auch die kurze Adresse, wie ich mit sophomorix-user -i -u <login> festellen kann. Dennoch heißen die Mailboxen / Adressen unter MailCow login@langer-domainname.de
Das kann doch nur eine Einstellung im docker-Container sein!?
Also gerade hat er genau das Gegenteil gemacht und alle Mailboxen gekillt – jetzt geht das Spielchen offenbar von vorne los und alle werden wieder neu angelegt?!
Sobald ich auf „Neustart“ klicke und der Button wieder grün wird, werden die Mailboxen erneut synchronisiert. Im Moment sind wieder 325 Mailboxen da – aber alle wieder unter dem langen Domainnamen.
Ist das so zerbrechlich wie es scheint oder täuscht das: Wenn der Dienst nicht läuft, werden die Boxen gekillt ?
Gerade nochmal drauf geschaut und den Button „ldap-mailcow“ nicht weiter beachtet. Dafür aber das Quota für die Domain hochgesetzt und den Container nochmal neu gestartet. Und siehe da: Nun wurden alle Mailboxen synchronisiert (es sind jetzt ~1300 Mailboxen mit dem richtigen Domainnamen!)
(Das sind nur fast alle, denn ein Projekt, das ich kürzlich angelegt hatte, hat weiterhin die falsche Adresse; außerdem alle Schüler unter extrastudents.csv. Die verwenden alle weiterhin den langen Domainnamen!)
Ein Login an der SoGO-Oberfläche ist weiterhin nicht möglich. Es bleibt bei den Fehlermeldungen dovecot: auth: Error: ldap(/etc/dovecot/ldap/passdb.conf): Can't connect to server: ldap://server.linuxmuster....
und Error: /var/run/dovecot/auth-userdb: passdb lookup failed (to see if user is proxied, because doveadm_port is set)
Zwei Ideen:
Kann das ein Firewall-Problem sein?
Kann das ein Lets-Encrypt-Problem sein, da der mailcow-Server offenbar im Moment sein eigenes Zertifikat verwendet (CN = mail.example.org)?
Bei uns ist die mailcow-Installation relativ alt. Ich habe aber das update.sh-Script laufen lassen, bevor ich mit dem linuxmuster-mailcow weitergemacht habe. Der Container meldet solche Dinge wie:
sogod [66]: [ERROR] <0x0x5573b81d8770[LDAPSource]> Could not bind to the LDAP server ldap://serve
r.linux.... (389) using the bind DN: CN=global-binduser,OU=Management,OU=GLOBAL,DC=linu....
Bei uns läuft der Mail-Server in der DMZ. Der Zugriff für die Ports 389 und 636 auf den Server ist aber über die OPNSense geregelt und erlaubt – sonst könnten die Konten ja auch nicht synchronisiert werden. ldapsearch von der DMZ zum Server funktioniert problemlos auf beiden Ports 389 und 636.
Was aber in diesem Zusammenhang sein könnte: Ich habe auf der Firewall Zugriff aus dem DMZ-Netzwerk erlaubt, aber nicht ausdrücklich nochmal aus dem „docker-Netzwerk“, das auf dem Mailserver läuft. Kann das ein Problem sein oder wird das eh ge-NAT-ed?!?
Hier nochmal vollständig nach einem gescheiterten SoGO-Login. Der Aufruf ist dieses Mal von einem Client erfolgt, den ich ebenfalls direkt in die DMZ gehängt habe. Bis auf die Server-Anfrage bleibt also alles im gleichen Subnetz (nur falls das ein Problem sein kann)
sogo-mailcow_1 | May 22 12:25:52 1232825f31d0 sogod [66]: 172.17.17.45 "GET /SOGo/ HTTP/1.0" 200 8667/0 0.042 35470 75% 0 - 11
sogo-mailcow_1 | May 22 12:27:18 1232825f31d0 sogod [9]: [WARN] <0x0x5573b810d7a0[WOWatchDogChild]> pid 66 has been hanging in the same request for 1 minutes
sogo-mailcow_1 | May 22 12:28:18 1232825f31d0 sogod [9]: [WARN] <0x0x5573b810d7a0[WOWatchDogChild]> pid 66 has been hanging in the same request for 2 minutes
sogo-mailcow_1 | May 22 12:28:28 1232825f31d0 sogod [66]: [ERROR] <0x0x5573b81d8770[LDAPSource]> Could not bind to the LDAP server ldap://server.linuxmuster.meine-domain.de (389) using the bind DN: CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=meine-domain,DC=de
sogo-mailcow_1 | May 22 12:28:28 1232825f31d0 sogod [66]: [ERROR] <0x0x5573b81d8770[LDAPSource]> <NSException: 0x5573b7e44510> NAME:LDAPException REASON:operation bind failed: Can't contact LDAP server (0xFFFFFFFF) INFO:{"error_code" = "-1"; login = "CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=meine-domain,DC=de"; }
sogo-mailcow_1 | May 22 12:28:28 1232825f31d0 sogod [66]: SOGoRootPage Login from '172.17.17.45' for user '<mein-login>@kurzer-domainname.de' might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0
sogo-mailcow_1 | May 22 12:28:28 1232825f31d0 sogod [66]: 172.17.17.45 "POST /SOGo/connect HTTP/1.0" 403 34/95 130.537 - - 0 - 12
Du gehst über ldap in Port 393. Wird dann noch TLS angeworfen? Ansonsten wird die Abfrage eventuell abgelehnt. Die Fehlermeldung ist da oft irreführend.
Ich habe beides versucht – in der override-Datei hatte ich auch schon ldaps:// (Port 636) verwendet. Lief leider ebenfalls nicht.
Welche Log-Files auf dem Server sind das? Im syslog steht nix.
Dass die LDAP-Fehlermeldungen mitunter „kryptisch“ sind, habe ich auch schon öfter festgestellt. Es gibt übrigens einen Unterschied bei den BASE-DN-Einträgen. Wenn ich die (erfolgreiche!) Abfrage per ldapsearch verwende, sieht das so aus:
manchmal klappt der Sync, manchmal nicht, dann kann der Container den LDAP Server kontaktieren, dann wieder nicht. Sieht für mich evtl. nach DNS Problemen aus. Du nutzt ja intern eine öffentliche Domain, so wie ich es verstanden habe.
Kann es sein, daß der Container manchmal intern nach dem DNS Namen fragt, manchmal extern?
Hallo.
Mittlerweile bin ich einen Schritt weiter … und zwar habe ich folgendes gemacht: Anstelle des FQDN habe ich in den docker-compose-Konfigurationen bei der ldap(s):// Einstellung direkt die IP-Adresse des Servers verwendet (bei uns 10.16.1.1). Damit lief logischerweise nur ldap:// über Port 389 und nicht ldaps://
(das Zertifikat ist ja nur für den Namen und nicht für die IP-Adresse ausgestellt…)
Ende vom Lied war: Ich konnte mich erstmals am SoGO-WebUI anmelden. Allerdings dauerte das wieder sehr lange. Daraufhin habe ich die Firewall beobachtet und alles mitgeschnitten, was auf Port ldap/389 eine Verbindung aufbaut. Und jetzt kommt’s: Es gingen weiterhin viele (aber scheinbar nicht alle?!) Verbindungsversuche zum Domainnamen draußen. Ich habe ja schon öfter bereut, dass wir hier intern wie extern den gleichen FQDN verwenden – in diesem Fall verstehe ich aber nicht, warum der Host das macht, denn wenn ich host mail.meine-domain.de intern aufrufe, wird immer die richtige interne IP-Adresse aufgelöst (172er Subnetz, DMZ).
Das habe ich sowohl vom docker-Host, als auch vom Server als auch von der Firewall aus ausprobiert: Alle zeigen auf die richtige interne IP in der DMZ!
Dennoch versucht es der docker-Container offenbar direkt im Internet, wo er natürlich beim falschen Host anklopft. Die Frage ist nun also: Warum?
Ich habe übrigens bereits eine eMail von einem web.de Konto zum mailcow-Container geschickt. Die kam an! So ganz falsch kann der Aufbau also nicht mehr sein … die DNS bzw Routing-Probleme sind mir aber trotzdem nicht klar. Vielleicht kann mich jemand von Euch erleuchten?
verstehe ich die Beschreibungen auf github richtig, dass ich diesen Container auf einer bestehenden Mailcow-dockerized-Instanz anflanschen kann und sich das Ding dann nur um die Domains aus linuxmuster.net7 kümmert? Also ich kann die anderen Domains, die ich da verwalte trotzdem noch selbst verwalten und die werden nicht gelöscht?
