Ein eigener Mailserver - wie geht das?

  • ThomasL ich hätte noch eine kleine "Verschlankung" deines eventhandler-Scripts anzubieten, vielleicht kannst du sie gebrauchen.

    Code
    $ diff getmail_eventhandler getmail_eventhandler_llutz
    74,77c74,75
    < LinuxUser=$(grep "$VirtUser " -i /etc/dovecot/alias_maps | awk -F ' ' '{ print $2 }')
    < LinuxUser_UID=$(grep $LinuxUser /etc/passwd | awk -F':' '{ printf "%6s", $3}')
    < LinuxUser_UID=${LinuxUser_UID%% }
    < LinuxUser_UID=${LinuxUser_UID## }
    ---
    > LinuxUser=$(/usr/bin/awk -v user="$VirtUser" '$0 ~ user {print $NF;exit}' /etc/dovecot/alias_maps)
    > LinuxUser_UID=$(/usr/bin/id -r -u $LinuxUser)

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Hi Lutz


    Ich freue mich ehrlich über jeden Tipp, der das Projekt besser macht... insofern ein aufrichtiges Danke für diese Überlegung... nur basiert dieser Update-Vorschlag leider auf der Vor-Weihnachtsversion, die bei Rudi zum Fehler geführt hat. Der Ablauf ist jetzt im Script ein anderer.... ich glaube, dass sowohl Abfragen als auch die Plausibilitätsprüfungen stabiler sind als zuvor.... und anscheinend war das bei Rudi jetzt auch erfolgreich.


    Unter anderen war diese Zeile fehlerhaft,

    LinuxUser_UID=$(grep $LinuxUser /etc/passwd | awk -F':' '{ printf "%6s", $3}')


    die nun durch diese ersetzt wurde:

    LinuxUser_UID=$(grep "$LinuxUser:" /etc/passwd | awk -F':' '{ printf "%s", $3}')


    Darüber hinaus -so denke ich- ist die Fehlerbehandlung jetzt besser.


    Wobei mir die letzte Änderung richtig gut gefällt... ich hatte auch schon dran gedacht, mir dann aber überlegt, dem geschenkten Gaul (die schon vorhandene Lösung ) nichts in Maul zu schauen... *fg* ... soll heissen, ich war einfach zu faul mich mit 'id' zu befassen... aber jetzt, wo's da so fertig steht... da sach ich ma danke... *fg*

  • lutz


    Ich habe den erwähnten Teil Deines Vorschlags nun übernommen... und es läuft:

    Was passiert da?


    - VirtUser übernimmt die Umgebungsvariable $USER... mit einem alltrim()

    - Dann wird in der alias_maps gesucht, ob es für den virtuellen einen Linux-User gibt

    - alias_maps enthält z.B. die beiden (Stresstest-)-Einträge:

    toml thomas

    tom thoma (=provozierte Fehlersituation)


    oder umgekehrt

    tom thoma

    toml thomas


    Als letztes wird geprüft, ob der in der alias_maps eingetragene Linuxuser auch wirklich eine UID hat.... also das er wirklich existiert.


    provozierte Fehlersituation = tom und toml sind virtuelle User, 'thomas' ist ein vorhandener Linuxuser, 'thoma' hingegen nicht, den gibts nicht in passwd.


    Mit dem Script oben passieren jetzt nicht diese erwarteten grep-Fehler, auch aus der Reihenfolge der virtuellen User in alias_maps resultiert kein Fehler, sondern nur die korrekte Fehlerbehandlung... also alles so wie es sein soll. Fällt Dir (oder gerne auch jedem anderen 'Prüfer') noch was auf, oder eine Idee, wie ich das Script noch mal "stressen" kann...?... oder ist das so ok? Ich denke, solche Namens-Werke/Kombinationen sind ja typische Fehlerquellen....

    Edited 2 times, last by ThomasL ().

  • Wäre grep -w nicht sinnvoller als das angehängte (schnell bei Änderungen mal wegoptimierte) Leerzeichen, um nicht auf Namensteile zu matchen?


    btw

    $USER enthält keine [[:space:]] (nur den Usernamen), ergo Zeile 1 imho überflüssig

    Wenn du nichts zu sagen hast, sag' einfach nichts.


    Edited 2 times, last by llutz ().

  • Wäre grep -w nicht sinnvoller als das angehängte...

    Guter Hinweis, damit werde ich morgen mal befassen.

    ...ergo Zeile 1 imho überflüssig

    Tja, vor dem Hintergrund, dass $USER hier nichts mit dem üblicherweise enthaltenen Linux-User (nach strenger Namensregelung) zu tun hat, sondern sich auf einen virtuellen Dovecot-User bezieht, kann ich diese Aussage resp. Frage gar nicht einschätzen. Diese Variable wird von Dovecot gesetzt und ich weiß schlichtweg nicht, an welche Restriktionen sich Dovecot für virtuelle Usernames hält und ob es ggf. auch unkonventionelle Namen zulässt. Das hier (siehe Zitat) schafft jedenfalls mehr Unsicherheit als Klarheit... irgend eine Idee dazu?


    https://wiki.dovecot.org/VirtualUsers

    "Usernames and domains

    Dovecot doesn't care much about domains in usernames. IMAP and POP3 protocols currently have no concept of "domain", so the username is just something that shows up in your logs and maybe in some configuration, but they have no direct functionality.


    So although Dovecot makes it easier to handle "user@domain" style usernames (eg. %n and %d variables), nothing breaks if you use for example "domain%user" style usernames instead. However some authentication mechanisms do have an explicit support for realms (pretty much the same as domains). If those mechanisms are used, the username is changed to be "user@realm".

    And of course there's no need to have domains at all in the usernames."



  • $USER ist eine shell-Variable, die mit Dovecot nichts zu tun hat. Das eventhandler-Script ist ein banales Shell-Script (bash) in dessen Kontext auch $USER nicht von Dovecot beeinflusst wird ($(echo "$USER"....ist eine reine Shell-Funktion). Dovecots interne Variablen werden durch Prozent eingeleitet, %n ~name.

    Wenn du nichts zu sagen hast, sag' einfach nichts.


    Edited once, last by llutz: I stand corrected ().

  • Irrtum... (:


    In diesem Fall (schau in den Script-Auszug) enthält $USER als Shell-Variable den virtuellen Dovecot-User.... deswegen das Dilemma mit der Frage überflüssig oder nicht....


    Es handelt sich dabei um eine explizit von Dovecot gestartete Shell (resp. Script als Eventhandler) aufgrund eines Mailuser-Logins in Dovecot... und diese Shell enthält von Dovecot gesetzte Shell-Vars... so eben auch $USER, was hier nix mit Linux-Usern zu tun hat, weil Dovecot gar keine Linux-User kennen muss. Deswegen ja auch meine Brücke mit "alias_maps".

    Edited once, last by ThomasL ().

  • Das ist eine tolle Anleitung. Das Problem mit den fragmentierten Einrichtungstipps im Internet kann ich nur bestätigen.

    Zudem meist auf Englisch. Da ich gerade meinen Ubunturechner upgedated habe, kommt mir die Anleitung wie gerufen, nachdem ich durch wilde rumkonfiguriererei bei gmx geblacklistet wurde und den Fehler einfach nicht eingrenzen konnte. :auslachen::lol::bravo2:

  • Wäre grep -w nicht sinnvoller als das angehängte Leerzeichen,

    Ich habe noch mal damit rumexperimentiert und dabei festgestellt, dass -w tatsächlich die einzig funktionierende Variante ist... so ein Mist... daran habe ich nicht gedacht. Das ergänzende Blank wirkt NUR dann, wenn man es auch wirklich manuell in der alias_maps getippt hat. Hat man stattdessen die Tab-Taste gedrückt und 0x09 wird nicht zu Spaces expandiert, failed meine Variante, mit -w wird es korrekt aufgelöst. :conf:


    Das muss ich heute sofort ändern... Danke für diesen wirklich wichtigen Hinweis.

  • Das Leerzeichen schützt dich auch nicht vor "anna" vs "hanna" etc. pp. Mag ja sein, das solche Namen im eigenen Bereich nicht vorkommen, aber wenn man seine Scripte veröffentlicht....

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Jo, stimmt... aber bei Deinem Background wird dir zweifelsfrei klar sein, dass einzelne Fehler ab einer gewissen Größe der IT-Installationen fast unvermeidlich sind. Und deswegen ist man dabei ja auch immer auf kritische Blicke durch andere angewiesen... weil man selber irgendwann und allzu oft darauf hereinfällt, beim Lesen eher das zu verstehen, was man eigentlich erwartet und dabei weniger die echte Bedeutung erfasst... zumal das ja *hier* bisher gut gelaufen ist. Deswegen kann man nur froh sein, wenn Leute drüber schauen und solche wertvollen Hinweise geben... :thumbup:


    Allerdings hat mir diese Zeile immer noch Kopfzerbrechen bereitet:

    LinuxUser=$(grep -w "$VirtUser" -i /etc/dovecot/alias_maps | awk -F ' ' '{ print $2 }')


    Durch den Parameter '-w' ist jetzt die Frage mit Space und Tab beim grep geklärt, das Ergebnis ist immer eindeutig. Aber das hat ja nicht zwangsläufig das gegebene Blank ' ' im awk-Statement eingeschlossen. Aber dabei haben jetzt alle Tests ergeben, dass (egal ob Tab oder Blank) die Rückgabe von Feld 2 konstant richtig ist. Ist das noch etwas, was Beachtung bedarf oder kann man das so akzeptieren? :conf: Wie ist Deine Meinung?


    Ganz losgelöst davon, habe ich es jetzt trotzdem erst mal aktualisiert hochgeladen... ohne weiteren Extra-Vermerk wegen des Updates. Ich habe drauf verzichtet, weil dieses Thema ja gerade erst gestern mit einem Update-Vermerk zum 2.1.20 versehen wurde.

  • Lass das -F einfach weg, awk benutzt default whitespace/tab ( [ \t]+ ) als Trenner. Ich meine damit bist du dann auf der sicheren Seite.

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Genau daran erkennt man den Unterschied zwischen Optimal und Über-Optimal.... und es ist der Beweis dafür, dass Über-Optimal keine Verbesserung ist, sondern tatsächlich eher schädlich ist.


    Ich habe das echt nicht gewusst... Danke für diesen Hinweis... ich habs schon umgebaut... jetzt fehlt nur noch der Update zur Web-Seite.

  • So ein Mist... :denker:... das Problem ist deutlich anspruchsvoller.... wie sich jetzt nach Wegfall der zwei Blanks gezeigt hat. Es rappelt nur so mit Fehlermeldungen.... deshalb hier folgend noch mal die Entwicklungsschritte zusammengefasst.


    Ursprünglich mit den 2 Blanks, aber mit der Gefahr bei tabstops zu failen:

    LinuxUser=$(grep "$VirtUser " -i /etc/dovecot/alias_maps | awk -F ' ' '{ print $2 }')


    Die geänderte Variante ohne die zwei Blanks;

    LinuxUser=$(grep -w "$VirtUser" -i /etc/dovecot/alias_maps | awk '{ print $2 }')


    Und genau die failed nun bei folgender Situation in der alias_maps, also wenn der virtueller Dovecot-User gleich mit dem Linux-User ist und der User zusätzlich mehrere Postfächer hat ... also wenn die alias_maps so aussieht:

    Code
    #virtuser: linuxuser:
    otto otto
    ottofake otto
    dummyotto otto
    liselore otto

    Hier wird nach dem virtuellen User "otto" gegrept, der bei dem Inhalt allerdings 5 mal gefunden wird... was ein verrückter Mist..... :wallbash:


    Ich habe jetzt als Lösung diese Variante gefunden, die das ursprüngliche Blank (am virtuser) ersetzt und den virtuser nun mit () einklammert.

    LinuxUser=$(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VirtUser)" | awk '{ print $2 }')


    So ein hintenrum-gewürge....aber damit scheinen jetzt alle Varianten zu klappen... :conf:... welche üblen Fallen man sich selber programmieren kann....


    lutz.... bitte noch mal um Hilfe... und einen kritischen Blick.....

  • Versuche mal bitte

    Code
    LinuxUser=$(/usr/bin/awk -v user="$VirtUser" '$1 ~ user {print $NF;exit}' /etc/dovecot/alias_maps)

    Wenn du nichts zu sagen hast, sag' einfach nichts.


    Edited once, last by llutz ().

  • Die geänderte Variante ohne die zwei Blanks;

    LinuxUser=$(grep -w "$VirtUser" -i /etc/dovecot/alias_maps | awk '{ print $2 }')


    Und genau die failed nun bei folgender Situation in der alias_maps, also wenn der virtueller Dovecot-User gleich mit dem Linux-User ist und der User zusätzlich mehrere Postfächer hat ... also wenn die alias_maps so aussieht:

    Versuch mal

    Code
    LinuxUser=$(grep -w "^$VirtUser" -i /etc/dovecot/alias_maps | awk '{ print $2 }')

    BTW, sind die virtuellen Userkennungen wirklich case insensitive (Option "-i")?

  • BTW, sind die virtuellen Userkennungen wirklich case insensitive (Option "-i")?

    Dovecot unterscheidet Gross-/Kleinschreibung (beliebtes Problem beim Einsatz eines Webmailers, dem es egal ist), deswegen setzt man meist in der config auth_username_format = %Lu um alle lowercase zu haben.

    Wenn du nichts zu sagen hast, sag' einfach nichts.


  • Versuche mal bitte

    Code
    LinuxUser=$(/usr/bin/awk -v user="$VirtUser" '$1 ~ user {print $NF;exit}' /etc/dovecot/alias_maps)

    Ist fehlerhaft... (hier also ein provozierter Fehler), denn den User "tom" gibts nicht, sondern nur "toml"... und führt zu folgender Falsch-Ausgabe

    Code
    # echo $(/usr/bin/awk -v user="tom" '$1 ~ user {print $NF;exit}' /etc/dovecot/alias_maps)
    thomas


    Versuch mal

    Code
    LinuxUser=$(grep -w "^$VirtUser" -i /etc/dovecot/alias_maps | awk '{ print $2 }')

    BTW, sind die virtuellen Userkennungen wirklich case insensitive (Option "-i")?

    Das sieht erst besser aus und führt zu 2 korrekten Ausgaben, aber dann zum gleichen Fehler wie oben, siehe das Otto-Problem. Der Linux-User "thomas" hat mehrere Postfächer (virt.user) und eines von denen heisst auch "thomas", ein weiteres "toml".

    Code
    # echo $(grep -w "^tom" -i /etc/dovecot/alias_maps | awk '{ print $2 }')
    # echo $(grep -w "^toml" -i /etc/dovecot/alias_maps | awk '{ print $2 }')
    thomas
    # echo $(grep -w "^thomas" -i /etc/dovecot/alias_maps | awk '{ print $2 }')
    thomas thomas thomas thomas


    :conf: Meine cat-Variante mit der Einklammerung unterscheidet das im Moment ... ich konnte noch keine weiteren Fehler provozieren.


    Code
    # export VUSER="tom"; echo $(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VUSER)" | awk '{ print $2 }')
    # export VUSER="toml"; echo $(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VUSER)" | awk '{ print $2 }')
    thomas
    # export VUSER="thomas"; echo $(cat /etc/dovecot/alias_maps | awk '{ printf "(%s) %s\n", $1, $2 }' | grep -w "($VUSER)" | awk '{ print $2 }')
    thomas

    In der aktuellen Version habe ich '-i' entfernt, um auch da mehr Eindeutigkeit zu erzwingen... siehe oben 3. (die letzte) Variante in #35.

    Edited 2 times, last by ThomasL ().

  • st fehlerhaft... (hier also ein provozierter Fehler), denn den User "tom" gibts nicht, sondern nur "toml"... und führt zu folgender Falsch-Ausgabe

    Mein Fehler,

    Code
    LinuxUser=$(/usr/bin/awk -v user="$VirtUser" '$1 == user {print $NF;exit}' /etc/dovecot/alias_maps)

    Wenn du nichts zu sagen hast, sag' einfach nichts.