Das mit den Domain-ALIAS hatte ich vermutet, dass das vermutlich möglich ist. Könnte mit LDAP hinten dran halt etwas komplexer sein.
Ach da gibts so Config_Dateien für SOGO, DOVECOT und co. Da kann man das sicher rein packen. Wir haben das mal einen Kunden gemacht, der sich mit vorname.nachname@ und ldap-Benutzernname anmelden wollte (oder so ähnlich).
Könnte aber sicherlich auch angenehmer sein, seine Nutzer entsprechend umzugewöhnen :-).
auch wenn sich hier jetzt etwas mehrere Aliase für eine Mailadresse und Mailverteiler mischen, antworte ich mal auf diese Frage (zumindest den webUI-Teil):
Das machen wir (LMN 7.2, Mailcow) über die Schulkonsole als Projekte, denn das Sync-Script erstellt auch für jedes Projekt eine Mailadresse mit allen Projektteilnehmern.
@Jesko Das klingt echt super und genau nach dem, was man haben will. Schon mal vorab Danke fürs Angebot!
Frage nebenbei: hat sonst noch jemand das Problem, dass linuxmuster-mailcow immer mal wieder unerwartet nicht mehr läuft? Alle anderen mailcow-Container laufen bei mir super stabil, nach ein paar Tagen/Wochen läuft linuxmuster-mailcow (ohne dass ich bisher was in Logs finden könnt) nicht mehr.
Ist kein großes Problem (ein cronjob hilft schon) aber ja auch nicht im Sinne des Erfinders.
Ja, kann ich bestätigen – ist bei uns auch so und ich weiß nicht warum. Könnte mir aber vorstellen, dass das mit dem syncer zusammenhängt, der so viel CPU Last erzeugt?
Hmmm… der syncer erzeugt ja nicht viel Last auf dem Server auf dem er läuft, sondern die Abfragen erzeugen Last auf dem LDAP/AD-Server.
Ich glaube nicht daran, dass die Last da Problem ist.
Der Syncer ist auch so aufgebaut, dass er bei Fehlern abbricht und nach 30s neu probiert…
Schau doch mal ins Log rein, was die letzten Meldungen waren, bevor der Container den Dienst eingestellt hat. Dazu musst du den Container erst neu starten und er darf natürlich vorher nicht durch docker-compose down gelöscht worden sein.
Aber wenn er abgestürzt ist, ist er noch da…
cd /pfad/zur/mailcow
docker-compose start linuxmuster-mailcow
docker-compose logs --tail=50 linuxmuster-mailcow
Ich komm heute vermutlich nicht dazu… es ist einfach Gartenwetter
Spätestens zweite nächaste Wochenhälfte mach ich das (da bin ich in Esslilngen beim Linux-Workshop…)
Da kommt leider nichts raus. Bevor ich gestern den cronjob aufgesetzt habe, war der linuxmuster-mailcow mal wieder abgestürzt (und das seit mehr als einem Monat), bevor ich ihn händisch neu gestartet habe. Hier der Ausschnitt aus dem Log:
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] === Starting sync ===
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] Step 1: Loading current Data from AD
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] * Binding to ldap
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] * Loading users from AD
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] * Loading groups from AD
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] Step 2: Loading current Data from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] * Loading current domains from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:01 - [INFO] * Loading current mailboxs from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:02 - [INFO] * Loading current aliass from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:02 - [INFO] * Loading current filterss from Mailcow
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:02 - [INFO] Step 3: Calculating deltas between AD and Mailcow
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:04 - [INFO] * Everything up-to-date!
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:04 - [INFO] === Sync finished successfully ==
mailcowcustomized_linuxmuster-mailcow | 2024-03-09 11:12:04 - [INFO] sleeping 300 seconds before next cycle
mailcowcustomized_linuxmuster-mailcow | 2024-04-12 13:57:26 - [INFO] CONFIG:
mailcowcustomized_linuxmuster-mailcow | 2024-04-12 13:57:26 - [INFO] * LDAP_SOGO_USER_FILTER : (sophomorixRole='student' OR sophomorixRole='teacher')
mailcowcustomized_linuxmuster-mailcow | 2024-04-12 13:57:26 - [INFO] * LDAP_USER_FILTER : (|(sophomorixRole=student)(sophomorixRole=teacher))
Sieht für mich nach einem erfolgreichen Durchlauf und anschließend einem „sang- und klanglosem Verschwinden“ aus.
Ok, da hab ich jetzt nur eine kleine Vermutung:
Hast du in deiner docker-compose.override.yml stehen, dass der Container immer starten soll?
restart = always
?
Ansonsten kommt irgend ein Update oder ein Serverneustart oder sonst irgendwas, was die Container kurz beendet und dann fährt der eine halt nicht mehr hoch.
Ist also dann nicht abgestürzt, sondern tut halt, was ihm gesagt wurde
das ist jetzt quick and dirty. Aber vielleicht hat @dorian kurz Muße, drüber zu schauen, ob da irgendwas ins offizielle Repo zurückwandern könnte…
Ich habe die zusätzlichen Dateien außerhalb von mailcow-dockerized gelegt, weil ich schiss hatte, dass zusätzliche Dateien in dem Verzeichnis beim nächsten Mailserver-Update Seiteneffekte haben… vielleicht ist das übervorsichtig. Wenns jemand weiß, bin ich für Rückmeldung dankbar.
Nein, das stand bei mir nicht drin. Ich hatte nach Anleitung seinerzeit eine docker-compose.override.yml kopiert, in der das nicht vorkam. Ich habe es dann vor drei Wochen nach Deinem guten Hinweis ergänzt (und auch die mailcow komplett neu gestartet), musste aber heute feststellen, dass der linuxmuster-mailcow-Container wieder nicht lief. Ich habe also erst mal wieder meinen cronjob angeworfen, der den Container jede Nacht neu startet, bin aber gern bereit bei der Fehlersuche weiter zu helfen.
ich hab jetzt nach Tagen wieder mal in den Container reingeschaut und gesehen, dass er vor 4min gesynct hat.
Also ich kann nicht bestätigen, dass der Container unzuverlässig läuft.
→ scheint kein allgemeines Problem zu sein, sondern irgendeine Spezialität.
Ich weiß jetzt nicht, ob es sich lohnt, das Problem zu finden, oder ob der Workaround, den Container einfach zwischendurch (vielleicht auch automatisch) neu zu starten weniger Stress ist.
Aber wenn der Fehler gefunden werden soll, dann würde ich damit beginnen, in dem Sync-Script an verschiedenen Stellen debug-meldungen auszugeben.
Das Skript heißt „syncer.py“
Du kannst es aus dem Container herauskopieren:
cd /pfad/zur/mailcow
docker cp mailcowcustomized_linuxmuster-mailcow:syncer.py ./
dann in docker-compose.override.yml in den container zurück mounten:
Hi zusammen,
ich weiß, dass das hier ein Monster-Thread ist.
Das hat mich gestört.
Ich habe die Option --set-proxy-addresses aus sophomorix-user nach sophomorix-class und sophomorix-project portiert, siehe hier:
kann das jemand außer mir testen (@dorian ? @Till ?)
@jeffbeck : kannst du drüberschauen und gerne Mergen + neu veröffentlichen?
Ich habe die anderen Optionen --add-proxy-addresses und --remove-proxy-addresses noch nicht implementiert. Wenn das die Bedingung wäre, dass es gemerged wird, würde ich es machen.