Hinweise zum neuen linuxmuster-Mailserver (mailcow-dockerized)

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

Hallo Tobias,

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.

Damit dann niemand an p_kollegium@meine-schule.de schreiben muss, sondern kollegium@meine-schule.de verwenden kann, proxyAddresses mit dem Apache Directory Studio manuell bearbeiten, wie hier von Dorian beschrieben.

Beste Grüße,
Jens

Hi :slight_smile: @dorian

Ich hab das schon verstanden.
Aber die Aliasse kann man auch andersrum einsetzen (oder gemischt)

Ich hab jetzt das syncer-script aus dem linuxmuster-mailcow so erweitert, dass:

(Das hier ist schon gewesen:)

  • Lehrer haben eine (oder mehrere) Adressen
  • Schüler haben auch eine
  • Projekte sind bei Bedarf Mailinglisten

(Das hier ist neu)

  • Externe / Sonderaccounts können über eine einfache Datei angelegt werden
  • unabhängige Listen können über eine einfache Datei hinzugefügt werden
  • Aliasse jeglicher Form ebenfalls über eine Datei.

Damit ist das Teil jetzt für mich die eierlegende Wollmilchsau :slight_smile:

Ich muss das nochmal ordnen… dann kann es haben wer will :slight_smile:

LG Jesko

Hallo zusammen,

@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.

Beste Grüße,
Jens

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

Vielleicht steht da was erhellendes :slight_smile:
LG Jesko

Ich komm heute vermutlich nicht dazu… es ist einfach Gartenwetter :slight_smile:
Spätestens zweite nächaste Wochenhälfte mach ich das (da bin ich in Esslilngen beim Linux-Workshop…)

Hallo Jeske,

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.

Beste Grüße,
Jens

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 :wink:

Hi zusammen, hi @Jens

hier hab ich das mal für den Moment hochgeladen: az/custom-linuxmuster-mailcow - AZ-IT Forgejo: Beyond coding. We forge.

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.

Liebe Grüße Jesko

Hallo zusammen,

@Jesko: Vielen Dank! Bin noch nicht zum Ausprobieren gekommen, werde ich aber definitiv tun!

Zum Post oben:

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.

Beste Grüße,
Jens

Hallo Jens,

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:

  linuxmuster-mailcow:
    ...
    volumes:
      ...
      - ./syncer.py:/syncer.py:rw

anschließend Container neu starten:

docker-compose up -d

Jetzt kannst du mit

vim syncer.py ; docker-compose restart linuxmuster-mailcow ; docker-compose logs -f linuxmuster-mailcow

Änderungen vornehmen und sie gleich aktivieren.

LG Jesko

[EDIT: es war ein Punkt zuviel im Volume-Pfad…]

1 „Gefällt mir“

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.

sophomorix-class -c 3b_2324 --set-proxy-addresses 3b@meine-schule,tolle_klasse@meine-schule.de --maillist
sophomorix-class -c 3b_2324 -i

1 „Gefällt mir“