Vielen Dank! Mit dem neuen Script ist die Fehlermeldung aus mail.err verschwunden, die Mails von meinen verschiedenen ISP kommen wie gewünscht an! Danke nochmal!
Ein eigener Mailserver - wie geht das?
-
WinterUnit16246 -
26. Juli 2017 um 17:06 -
Erledigt
Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
-
-
Ein eigener Mailserver - wie geht das?? Schau mal ob du hier fündig wirst!
-
@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)
-
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*
-
Ich habe den erwähnten Teil Deines Vorschlags nun übernommen... und es läuft:
Code
Alles anzeigenVirtUser=$(echo "$USER" | sed 's/^[ \t]*//;s/[ \t]*$//') LinuxUser=$(grep "$VirtUser " -i /etc/dovecot/alias_maps | awk -F ' ' '{ print $2 }') if [ -z "$LinuxUser" ]; then echo "$msg0 Virtuser=$VirtUser" | systemd-cat -t "thlu:$(basename $0)" -p "warning" else LinuxUser_UID=$(/usr/bin/id -r -u $LinuxUser 2>/dev/null); if [ -z "$LinuxUser_UID" ]; then echo "$msg2 VirtUser=$VirtUser" | systemd-cat -t "thlu:$(basename $0)" -p "warning" exit else .... mach normalen job fi fi
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....
-
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 -
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. -
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".
-
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.
-
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.
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....
-
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...
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? 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.
-
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... ... 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:
Hier wird nach dem virtuellen User "otto" gegrept, der bei dem Inhalt allerdings 5 mal gefunden wird... was ein verrückter Mist.....
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... ... welche üblen Fallen man sich selber programmieren kann....
lutz.... bitte noch mal um Hilfe... und einen kritischen Blick.....
-
-
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
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.
-
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
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
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.
-
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,
-
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!