[Kolab-devel] (fwd) how to deal with quotas / suggested feature "monthly quota increase"

[Gunnar Wrobel]

Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> Gavin McCullagh wrote:
>> Hi,
>>
>
> Hey Gavin,
>
> so what do you think of a concept such as Hierarchical Storage Management, if
> anything?
>
>> The problem is not really the workload of increasing quotas (though it
>> would be nice to reduce that).  It's what happens when someone goes over
>> (or nears) their quota.  They ring the helpdesk expecting to increase the
>> quota.  The person on the helpdesk who answers the phone has no information
>> to evaluate whether the increase is justifiable or not.  They can say
>> "please delete some mail" but that might be unfair on the user who may
>> already have tried.  They can try and look back through the history to
>> figure out when that person's last increase was, but that's a pain.  The
>> result is that the helpdesk person probably just increases the quota
>> without discussion.  So we quickly end up with meaningless quotas that just
>> increase as quickly as people consume space.  You can ask the helpdesk
>> person to be more pushy, but they have no real way to decide who is just
>> being careless and who simply can't delete any more mail.  The absolute
>> disk usage isn't really a good guide to this.
>>
>
> On helpdesks I've worked (with), approval was necessary from the budget
> holder. Facts remain of course, that the budget holder isn't necessarily in
> any capacity to judge on whether a quota increase is justifiable,  
> and that not
> all organizations out there work with similar procedures.
>
> Judging from your numbers, based on our conversation, and my thoughts /
> preference, would it be reasonable for a script to:
>
> - Iterate LDAP users,
> - Compare their current quota setting to the actual mailbox volume,
> - Possibly, given a margin percentage (70% of quota?), trigger a quota
> increase,
>   - Such increase using a formula such as "+20MB" or "+25%",
> - Enter the new value in LDAP,
> - Send reports to Administrators on quota increase + current mail spool usage
> + current mail spool size assigned in cumulative quotas,
>   - Possibly limited to when mail spool usage approaches X% or Y% one way or
> the other
>
> For such a script, I would see the following milestones;
>
> 1) Iterate LDAP users.
>
> 1.a) Report each users' current quota setting
> 1.b) Report each users' actual quota usage
> 1.c) Report in both size (MB) and percentage.
> 1.d) Bonus points for switches that make the script output something that
> Munin/something can parse.
> 1.e) Additional bonus points for something that something else can  
> parse, like
> a web interface or something that can spit out sexy pie-charts.
>
> This shouldn't be too hard, but there is some work involved. Most
> significantly is the LDAP layout / reuse of filters on the left side -Kolab,
> existing LDAP infrastructure- vs. the right side -Cyrus, Dovecot.
>
> I'll settle for Kolab layout + Cyrus for now as long as it has a  
> certain level
> of abstraction.
>
> 2) Error handling
>
> It's the error handling where things get trickier, I think. No  
> quota, negative
> quota, no such mailbox, quota in Cyrus but no quota in LDAP, etc. come to
> mind, reporting it and recovering from it would be the major deliverable for
> this milestone.
>
> 2) Adjust the LDAP quota setting for the users.
>
> 2.a) Using some formula that is in a configuration file somewhere;
> 2.b) Use the updated values in the report
>
> 3) Send out/show a nice report.
>
> printf for the win! Configurable target email address is a plus, but  
> as far as
> I'm concerned even root at localhost would suffice.
>
>> Like you say, this feature can be done external to kolab, it just seemed to
>> me that this might be quite a useful way to handle quotas in businesses
>> which accumulate email.
>>
>
> What do you think of the above roadmap?

I definitely like it. I would probably skip the bonus points :) but  
thats not important. A question I would have concerning 2.a): Gavin  
required two attributes for his approach. Within 2.2.4 we can use  
cyrus-userquota for one of them but where does the %-increase  
information come from?

Cheers,

Gunnar

>
> --
> Jeroen van Meeuwen
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +316 42 801 403
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.