Linuxmuster-mailcow: Fragen rund um den neuen Mail-Server

Michael · 21. Mai 2022 um 07:53

Hi.
Ich habe die Gunst der Stunde direkt genutzt und unseren eMail-Container (mailcow-dockerized) als „early adopter“ um den neuen linuxmuster-mailcow-Container ergänzt.

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

Michael · 21. Mai 2022 um 08:14

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

dorian · 21. Mai 2022 um 09:21

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.

VG,
Dorian

Michael · 21. Mai 2022 um 09:30

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

Viele Grüße,
Michael

dorian · 21. Mai 2022 um 10:37

Dafür gibt es in den Schuleinstellungen eine Option, um die email Domain zu ändern.

VG,
Dorian

Michael · 21. Mai 2022 um 10:44

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:

[type.project]
# projects 
        MAILDOMAIN = kurzer-name.de

ebenso bei allen anderen: [role.student] …

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!?

dorian · 21. Mai 2022 um 10:59

Nein. Dercontainer benutzt nur das mail Attribut:

github.com

linuxmuster/linuxmuster-mailcow/blob/4409c726ebbea794f1ea6481684dd3c54339d0e0/src/syncer.py#L110

    
      
              logging.error(e)
              logging.critical("!!! A connection error occured, is mailcow still starting up? !!!")
              return False
          except Exception as e:
              logging.exception("An exception occured: ", exc_info=e)
              return False
          
          
logging.info("Step 3: Calculating deltas between AD and Mailcow")
          
          
for user in adUsers:
              mail = user["mail"]
              maildomain = mail.split("@")[-1]
              aliases = []
          
          
    if "proxyAddresses" in user:
                  if isinstance(user["proxyAddresses"], list):
                      aliases = user["proxyAddresses"]
                  else:
                      aliases = [user["proxyAddresses"]]
          
          
    if not self._addDomain(maildomain, mailcowDomains):

Schau doch mal bitte in den Logs, ob er richtig synct.

VG,
Dorian

Michael · 21. Mai 2022 um 11:37

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?!


mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:36 - [INFO] === Starting sync ===
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:36 - [INFO] Step 1: Loading current Data from AD
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:36 - [INFO]     * Binding to ldap
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:36 - [INFO]     * Loading users from AD
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:37 - [INFO]     * Loading groups from AD
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:37 - [INFO] Step 2: Loading current Data from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:37 - [INFO]     * Loading current domains from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:37 - [INFO]     * Loading current mailboxs from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:50 - [INFO]     * Loading current aliass from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:50 - [INFO]     * Loading current filterss from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:52 - [INFO] Step 3: Calculating deltas between AD and Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO] * Found deltas:
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO]     * Going to add 0 domains, update 0 domains and kill 0 domains
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO]     * Going to add 0 mailboxes, update 11 mailboxes and kill 1350 mailboxes
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO]     * Going to add 0 aliases, update 0 aliases and kill 0 aliases
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO]     * Going to add 0 filters, update 0 filters and kill 0 filters
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO] Step 4: Syncing deltas to Mailcow
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:21:55 - [INFO]     * killing 1350 mailboxs


mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:25 - [INFO]     * updating 11 mailboxs
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:25 - [INFO]         * updating mailbox 1/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:25 - [INFO]         * updating mailbox 2/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:25 - [INFO]         * updating mailbox 3/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:26 - [INFO]         * updating mailbox 4/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:26 - [INFO]         * updating mailbox 5/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:26 - [INFO]         * updating mailbox 6/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:27 - [INFO]         * updating mailbox 7/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:27 - [INFO]         * updating mailbox 8/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:27 - [INFO]         * updating mailbox 9/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:28 - [INFO]         * updating mailbox 10/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:28 - [INFO]         * updating mailbox 11/11
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:28 - [INFO] === Sync finished successfully ==
mailcowcustomized_linuxmuster-mailcow | 2022-05-21 11:33:28 - [INFO] sleeping 300 seconds before next cycle

(nur nebenbei: Die Uhrzeit im Container stimmt oder wird falsch angezeigt nicht … die des docker-Hosts aber schon!)

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 ?

Michael · 21. Mai 2022 um 16:12

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

dorian · 22. Mai 2022 um 08:32

Was für Meldungen gibt es bei docker-compose logs -f sogo-mailcow?

Michael · 22. Mai 2022 um 10:13

Hi.

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:

operation bind failed: Can't contact LDAP server (0xFFFFFFFF) INFO:{"error_code" = "-1"; login = "CN=global-binduser,OU=Management,OU=GLOBAL,
DC=linu...

oder auch gerne mal:

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?!?

Viele Grüße,
Michael

dorian · 22. Mai 2022 um 10:25

Kannst du vielleicht eine Version der Fehlermeldung posten, die nicht abgeschnitten ist? Wäre hilfreich, mal die Fehlermeldung zu sehen…

Michael · 22. Mai 2022 um 10:38

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

jrichter · 22. Mai 2022 um 10:46

Hallo Michael,

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.

Hast Du mal in die Logs auf dem Server geschaut?

Beste Grüße

Jörg

Michael · 22. Mai 2022 um 10:52

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:

ldapsearch  -b "ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine-domain,dc=de" 
            -H ldaps://server.linuxmuster.meine-domain.de  (hier funktioniert auch ldap://)
            -x -D global-binduser@linuxmuster.meine-domain.de 
            -w super-geheim
            '(&(!(sophomorixAdminClass=attic))(|(sophomorixRole=teacher)))' |grep -e sAMAccountName

Aber die BASE_DN in der override-Datei sieht lediglich so aus:

 - LINUXMUSTER_MAILCOW_LDAP_BASE_DN=DC=linuxmuster,DC=meine-domain,DC=de

garblixa · 23. Mai 2022 um 05:14

Hallo Michael,

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?

Viele Grüße
Klaus

Michael · 23. Mai 2022 um 07:56

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?

Viele Grüße,
Michael