Univention Bugzilla – Bug 15220
Mailquota in UGS
Last modified: 2012-07-18 10:40:31 CEST
Derzeit wird die Mailquota als Richtlinie gesetzt. Da wir diese nicht per Listener überwachen wollen, wird im PAM-Stack die Mailquota ausgewertet. Das hat zur Folge, dass zunächst die Mailadresse in den Benutzernamen umgewandelt wird und dann für den Benutzer ein Policy Result gemacht wird. Das sind sehr viele LDAP Abfragen und Verzögerungen beim Login, da ggf. auch noch die Quota per cyradm gesetzt wird. Da das bei jedem Login gemacht wird, ist das sehr aufwendig und wir haben deshalb bei größeren Installationen das automatische Setzen der Quota deaktiviert. Wir sollten die Einstellung beim Benutzer speichern und nicht mehr als Richtlinie. Dann kann die Auswertung per Listener Modul erfolgen. Die Migration ist nicht ganz einfach, aber wenn wir das entsprechend in den Release Notes ankündigen und ein Multi-Edit für das Attribut im UDM erlauben, sollte das auch in einem Minor-Update bspw. zur 2.3 möglich sein. Ich habe iku empfohlen das für OXSE4UCS über ein EA umzusetzen.
Bitte mal anschauen und Patches für die unterschiedlichen Pakete an den Bug hängen.
Created attachment 1921 [details] Adds listener module univention-mail-cyrus-kolab2 Patch
Created attachment 1922 [details] Adds mailquota in udm Patch for univention-directory-manager-modules
Created attachment 1923 [details] Adds mailquota in mail.schema Patch for univention-ldap
Created attachment 1924 [details] Script for migration Script migriert Quota aus Policy in Benutzerattribut. Aufruf über migrate -l listet eingetragene Quota in Policy auf Aufruf über migrate -u User spezifiziert bestimmten User
Created attachment 1925 [details] Script for migration, updated updated script
Es wäre gut, wenn wir das zur 2.4 umsetzen können.
Rücksprache mit Janis. Es gibt jetzt mindestens einen größeren Kunden, der seine Umgebung so angepasst hat, dass die Quota Richtlinien verwendet werden. Vorteil ist, man kann sehr einfach ein paar Quota-Kategorien definieren und wenn der Benutzer seine Quota überschreitet wird er entsprechend in die nächst höhere Quota-Kategorie umgesetzt. Mit der vorgeschlagenen Änderung wäre das nicht mehr umsetzbar. Eine Alternative ist es, dass wir per Default die Quota-Einstellung nur noch einmal pro Zeitintervall auswerten. Das heisst set-quota bleibt im pam-Stack und es wird lokal gespeichert ob die Einstellung für den Benutzer schon einmal ausgeführt wurden. Das alte Verhalten könnte dann wiederhergestellt werden, indem das Zeitintervall auf 0 gesetzt wird. Per Default könnte das Intervall auf eine Stunde gesetzt werden. Pro Benutzer könnte das set-quota-Skript eine Datei in einem cache Verzeichnis per touch anlegen / aktualisieren. Beim nächsten set-quota-Durchlauf müsste dann nur der Timestamp der Datei überprüft werden.
Patches sind obsolet! Es wurde die neue Variable mail/cyrus/imap/quotaintervall eingeführt, welche nun ein Zeitintervall in Minuten setzt, in dem auf Mailquota Einstellungen geprüft und diese ggf. gesetzt werden. Paket gebaut, Changelogeintrag erstellt. fixed
fehlerhafter commit - reopen
nun fixed
*** Bug 18777 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 18777 has been marked as a duplicate of this bug. *** Siehe Beschreibung am Bug #18777.
Das Problem liegt nicht an der Umstellung des Zeitintervalls, in welchem geprüft und ggf. gesetzt werden soll, sondern in der Tatsache, dass bei einer Änderung der Mailquotarichtlinie der Pamstack nicht neu durchlaufen wird und somit das Skript zum Setzen der Quota nicht ausgeführt wird. Nach einem Neustart und der Erstmaligen Anmeldung z.B. am Hordeclient ist die Quota aktuell.
Anmerkung: Wird nach einer Änderung der Mailquota der Pamstack von hand angeworfen, wird die Quota auch korrekt aktualisiert.
Die Ursache an der Stelle ist, dass der saslauthd zwischencached. Ein /etc/init.d/saslauthd an dieser Stelle refreshed den Cache und der Pamstack wird wieder durchlaufen und somit eine neue Quota gesetzt (sofern die Einstellungen des Quotaintervalls dies nicht bewusst verhindern).
(In reply to comment #16) > Die Ursache an der Stelle ist, dass der saslauthd zwischencached. > > Ein /etc/init.d/saslauthd an dieser Stelle refreshed den Cache und der Pamstack > wird wieder durchlaufen und somit eine neue Quota gesetzt (sofern die > Einstellungen des Quotaintervalls dies nicht bewusst verhindern). Habe bzgl. bug 18777 und diesem Kommentar jetzt den UCS-Testfall für bug 18449 entsprechend angepasst, so dass der saslauth nach dem Modifizieren der Quota im UDM neugestartet wird. Die Änderung ist anschließend via IMAP sichtbar (auch ohne das Quota-Intervall abzuwarten). Allerdings scheint das Entfernen der Quota nicht zu funktionieren (auch mit saslauthd-neustarten, abwarten, pamstack ausführen etc.), was wie es aussieht an univention-cyrus-set-quota liegt, das diesen Fall schlichtweg nicht berücksichtigt.
*** Bug 18938 has been marked as a duplicate of this bug. ***
Das Skript wurde um die Möglichkeit erweitert, die Quotaeinstellungen zu entfernen. Verwendet wird hierzu das Keyword "none" -> setquota user/mail none Paket neu gebaut - fixed
Die ucs-tests scripts-45_kolab/08create_modify_remove_mailquota und scripts-40_mail/08create_modify_remove_mailquota schlagen bei mir auf einem auf 2.4 aktualisierten System fehl, und es scheint nicht an den Tests selbst zu liegen. Bei ersterem schlägt das Modifizieren der Quota fehl, bei zweiterem das Entfernen.
scripts-40_mail/08create_modify_remove_mailquota testet auf einem nicht-Kolab System, was für diesen Bug uninteressant ist. Erstes Problem wird unter aktuellem 2.4 nochmal untersucht. Desweiteren sollten die Umstellungen bezüglich Intervallgesteuerter Auswertung auch in den Standard Mailpaketen umgesetzt werden.
Problem lag innerhalb der Testskripte - Anpassung an den Standard Mailpaketen steht noch aus.
(In reply to comment #22) > Anpassung an den Standard Mailpaketen > steht noch aus. Quotaintervall erfolgreich in den Standardmail-Diensten getestet und umgesetzt. fixed
Unsere UCR-Variablennamen sind ja englisch, die Variable sollte also mail/cyrus/imap/quotainterval statt mail/cyrus/imap/quotaintervall heissen.
(In reply to comment #24) > Unsere UCR-Variablennamen sind ja englisch, die Variable sollte also > mail/cyrus/imap/quotainterval statt mail/cyrus/imap/quotaintervall heissen. Reopen.
(In reply to comment #24) > Unsere UCR-Variablennamen sind ja englisch, die Variable sollte also > mail/cyrus/imap/quotainterval statt mail/cyrus/imap/quotaintervall heissen. Ist umgesetzt, univention-mail-cyrus und univention-mail-cyrus-kolab2 sind neu für 2.4 gebaut, der Changelogeintrag wurde angepasst. fixed
(In reply to comment #26) > (In reply to comment #24) > > Unsere UCR-Variablennamen sind ja englisch, die Variable sollte also > > mail/cyrus/imap/quotainterval statt mail/cyrus/imap/quotaintervall heissen. > > Ist umgesetzt, univention-mail-cyrus und univention-mail-cyrus-kolab2 sind neu > für 2.4 gebaut, der Changelogeintrag wurde angepasst. > > fixed Bei univention-mail-cyrus-kolab2 funktioniert es. Beim Paket univention-mail-cyrus wird die Variable mail/cyrus/imap/quotainterval bei einem Update von 2.3-2 nicht gesetzt: if [ "$1" = configure -a -n "$2" ] && dpkg --compare-versions "$2" lt 0.5; then /usr/sbin/univention-baseconfig set mail/cyrus/imap/quota?"yes" /usr/sbin/univention-baseconfig set mail/cyrus/imap/quotawarnpercent?90 /usr/sbin/univention-baseconfig set mail/cyrus/imap/quotawarnkb?0 /usr/sbin/univention-baseconfig set mail/cyrus/imap/quotainterval=60 fi Bei einer Neuinstallation wird sie voraussichtlich auch nicht gesetzt. Installiert war vorher die Version 2.0.9-1.94.201003181120. Beim Paket univention-mail-cyrus-kolab2 wird die Variable immer mit = gesetzt. Ich denke, dass sollte ein ? sein. mail/cyrus/imap/quotainterval=60 ChangeLog Eintrag verfügbar
(In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #24) > > > Unsere UCR-Variablennamen sind ja englisch, die Variable sollte also > > > mail/cyrus/imap/quotainterval statt mail/cyrus/imap/quotaintervall heissen. > > > > Ist umgesetzt, univention-mail-cyrus und univention-mail-cyrus-kolab2 sind neu > > für 2.4 gebaut, der Changelogeintrag wurde angepasst. > > > > fixed > > Bei univention-mail-cyrus-kolab2 funktioniert es. Beim Paket > univention-mail-cyrus wird die Variable mail/cyrus/imap/quotainterval bei einem > Update von 2.3-2 nicht gesetzt: Das ist jetzt angepasst. > > if [ "$1" = configure -a -n "$2" ] && dpkg --compare-versions "$2" lt 0.5; then > /usr/sbin/univention-baseconfig set mail/cyrus/imap/quota?"yes" > /usr/sbin/univention-baseconfig set mail/cyrus/imap/quotawarnpercent?90 > /usr/sbin/univention-baseconfig set mail/cyrus/imap/quotawarnkb?0 > /usr/sbin/univention-baseconfig set mail/cyrus/imap/quotainterval=60 > fi > > Bei einer Neuinstallation wird sie voraussichtlich auch nicht gesetzt. Die Variable wird jetzt per Default gesetzt. Allerdings habe ich den oberen Code-Block nicht geändert. Default ist damit auf einem normalen Mailsystem, dass Quota nicht aktiv ist. > Installiert war vorher die Version 2.0.9-1.94.201003181120. > > Beim Paket univention-mail-cyrus-kolab2 wird die Variable immer mit = gesetzt. > Ich denke, dass sollte ein ? sein. Ja, ist angepasst. > mail/cyrus/imap/quotainterval=60 > > > ChangeLog Eintrag verfügbar
Funktioniert jetzt für den normalen Mail-Dienst und Kolab
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".