Mit diesem Update ändert sich sehr viel bei der Nutzerverwaltung. Dadurch ist es sehr wahrscheinlich, dass das linuxmuster-mailcow Tool mit der neuen Version nicht mehr richtig funktioniert.
Ich selbst benutze Mailcow aktuell nur privat und nicht in Verbindung mit linuxmuster-mailcow, deshalb kann ich das nicht verifizieren.
Falls ihr linuxmuster-mailcow weiter benutzen wollt, würde ich euch empfehlen, die legacy Branch von Mailcow zu verwenden: ./update.sh --legacy
Hallo
Nachdem ich mich gerade im anderen Thread über dieses Thema ausgelassen habe, Dorian mich auf diesen hier hingewiesen hat, mach ich dann hier mal weiter
Die Situation ist doof, hier erkenne ich jetzt einen Vorteil der Nutzung von Einzelpaketen ggü. eines Komplettpaketes, bei dem man wie hier jetzt etwas eingeschränkter ist.
Aber vielleicht kommen wir mit einem blauen Auge davon:
In den Releasenotes des März-Updates steht nämlich bei „new features“, dass es ab sofort eine LDAP-Anbindung gibt.
Und das ist ja erstmal prima.
Das müsste man jetzt ausprobieren und sehen, welche Funktionen hier schon out of the box vorhanden sind.
User-Email bestimmt (aber kann man einfach umstellen, oder zerfleischt es einem dann die Mailboxen)
soweit ich es verstanden habe, kann die neue LDAP-Integration in Mailcow Benutzer importieren und auch eine Benutzeranmeldung über LDAP ist nun möglich. Das ist hervorragend, denn das war bisher sehr „hacky“.
Probleme, die mir auf den ersten Blick einfallen:
Es ist unklar, wie das Löschen/Deaktivieren von nicht mehr existierenden Nutzern gehandhabt wird
Es ist unklar, ob die Verknüpfung zwischen Nutzer und Mailbox noch funktioniert, wenn ein Nutzer versetzt wird
Es ist unklar, ob die Synchronisation des Anzeigenamens eines Nutzers möglich ist
Synchronisation der sophomorixMailQuotaCalculated ist nicht möglich
Synchronisation von Aliasadressen (aka proxyAddresses) ist nicht möglich
Synchronisation von Listen ist nicht möglich
Ich glaube, die beste Lösung wäre es, das linuxmuster-mailcow Paket so anzupassen, dass es mit der neuen Mailcow Version funktioniert und nur noch die Aufgaben übernimmt, die Mailcow selbst (noch) nicht kann.
Ich denke, das ist an sich eine sehr gute Veränderung, da vor allem die Anmeldung von LDAP Nutzern mit dem Update deutlich sauberer wird. Es muss sich nur jemand finden, der das linuxmuster Paket entsprechend anpasst.
Die Mailbox bleibt vorhanden, man kann sich aber nicht mehr anmelden. Die (unaufdringlich in einem kleinen temporären Feld) ausgegebene Fehlermeldung:
Ein unerwarteter Serverfehler ist aufgetreten. Bitte kontaktieren Sie Ihren Administrator.
---
Anmeldung fehlgeschlagen
WIll man sich mit einem existierenden Nutzer aber falschem Passwort anmelden, kommt nur „Anmeldung fehlgeschlagen“.
Das Funktioniert problemlos. Die Anmeldung ist unabhängig von der Klassenbezeichnung.
Das klappt out of the box (und lässt sich gar nicht verhindern. Es gibt keine Einstellmöglichkeit dafür)
Offensichtlich sucht mailcow in den Standard-AD-Feldern.
Stimmt. Und - was für mich noch schlimmer ist: Man kann über ein Attribut (z.B. sophomorixRole) verschiedene Mailbox-Vorlagen verwenden und so Lehrkräften z.B. 10GB geben und SuS 200MB, aber die werden bei jedem Sync wieder angewendet, so dass manuelle Änderungen nicht möglich sind.
Wenn man den Haken bei „Vollsynchronisation“ entfernt, werden die schon vorhandenen Nutzer nicht wieder zurückgesetzt und man kann wenigstens manuell die Quotas anpassen bei Bedarf.
Das ist leider auch korrekt.
Hier könnte man aber vermutlich leicht über die API arbeiten, wie es bisher auch schon war. Wenn man die Skripte aus linuxmuster-mailcow versteht ist es vielleicht sehr einfach, das Nutzer-Anlegen und Login-Logik patchen wegzulassen und sich auf das Löschen nicht mehr vorhandener Nutzer und das Setzen der Quotas und das Anlegen der Listen zu beschränken.
Was denkst du?
LG Jesko
Das schon, aber wenn ein Nutzer versetzt wird, ändern sich sein DN. Wenn Mailcow den zur Verknüpfung benutzt, geht die Verknüpfung verloren. Kann aber auch sein, dass Mailcow den sAMAccountName/cn nimmt, dann ists egal.
Wenn man es quick and dirty macht, gehts vermutlich schnell. Es gibt aber schon ein paar Sachen, die etwas aufwändiger sein könnten. Zum Beispiel die automatische Migration der existierenden Mailboxen.
Wenn es jemand macht, schaue ich mir gerne die Pullrequest an und gebe da support.
Alles, was ich oben geschrieben habe, habe ich vorher ausprobiert… also mein „kein Problem“ ist tatsächlich verifiziert. Das Feld, was zu Rate gezogen wird, um den Nutzer zu bestimmen, muss eine eMail-Adresse enthalten. Im Standardfall also einfach das Feld mail. In meinem Fall das Feld sophomorixCustom1, weil ich da etwas eingreifen will.
Meine Konfiguration, die funktioniert habe ich mal fotografiert.
Das überblicke ich nicht wirklich, aber in meinem Horizont, liefert die API ja bei den Mailbox-Namen nur email-Adressen zurück, so dass diese gar nicht migriert werden müssten, weil sie ja schon korrekt angelegt sind.
Aber wie gesagt,… ich blicke das nicht.
Ich kann leider auch nichts wesentliches zum Pull-Request beitragen. Die python-Skripte hab ich mir angeschaut und erkenne kein Muster, mit dem ich was anfangen kann
welcher pythonista kann da helfen? @jrichter hast du Kapaziät, da mal rein zu schauen?
Liebe Grüße
Hi nochmal…
für Menschen, die sich vorstellen könnten, linuxmuster-mailcow mal anzuschauen, den Aufwand aber scheuen, eine Mailcow zu installieren, habe ich hier ein ansible-playbook, welches diese Aufnahme übernimmt, während man sich einen Kaffee holt. Dazu einfach:
irgend einen Testserver erstellen / schon haben
DNS-Eintrag auf diesen Server setzen
mit git o.g. repo clonen
ansible-playbook install-mailcow.yml -i fqdn.deines.servers,
und dann 5-10min warten (oder in der Zeit schonmal die python-skripte sichten.
Die Kuh ist dann mit den default-Credentials erreichbar unter fqdn.deines.servers/admin
(admin:moohoo)
Hallo @Jesko ,
ich krame diesen Thread nochmal nach vorne, da die Rolle des E-Mail-Servers bei uns demnächst wichtiger wird und alle Schüler verbindlich ein eigenes Postfach benötigen (es geht dabei um die Zusendung von Lizenzcodes an die (einheitliche) Schul-E-Mail-Adresse).
Bisher läuft die linuxmuster-mailcow-Lösung stabil bis auf die Tatsache, dass der linuxmuster-docker-Container bzw das Script python3 syncer.py nach wie vor regelmäßig aussteigt. Aktuell: „Created: 2 months ago. Exited (137): 3 weeks ago“
Daher kann es dann vorkommen, dass neue Schüler oder solche, bei denen es Änderungen gab, kein Postfach besitzen. Man muss den Container bzw den Sync zum v7-Server zunächst neu starten, bevor das wieder läuft.
Meine Frage ist daher: Läuft deine Lösung mit der direkten Anbindung an das LDAP/AD stabil und sind die o.g. Bedenken nun alle behoben? Anders gefragt: Ist diese Lösung der neue Weg?
Ich frage das auch deswegen, weil ich ein paar Bedenken habe, wie man vorgehen muss, wenn man die bestehenden Postfächer behalten will. Reicht es dann aus, nur die Konfiguration auf dem Mail-Server anzupassen und alles andere läuft weiter wie gewohnt?
Ich hab noch keine weiteren Erfahrungen, bei mir läuft ebenfalls noch das System mit dem zusätzlichen Container.
Ich kann leider auch grad nicht nachschauen, ob bei mir das sync script stabil läuft, weil heute Nacht der Server neu gestartet wurde…
Aber mir ist nichts negatives aufgefallen…
zu Deinem Stabilitätsthema kurz mein Erfahrungsbericht: ich hatte auch das Problem, dass der linuxmuster-mailcow-Container immer mal wieder nicht mehr lief (mit den von Dir geschilderten Auswirkungen). Ich hatte hier darüber berichtet. Da sich in der Folge das Problem nicht wirklich eingrenzen ließ (oder was anderes wichtiger wurde), habe ich mir mit einem cron-Job geholfen, der einfach jede Nacht ausgeführt wird. Läuft seit dem ohne jegliche Klage:
Hallo Jens,
Ich habe das bei uns auch gerade eingefügt… allerdings nutzen wir hier „docker-compose“ und nicht „docker compose“. Ansonsten ist das als quick&dirty-Lösung 'ne gute Sache.
Mir macht das nächste große Update und meine Fragen von oben aber weiterhin ein paar Bauchschmerzen
