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

[Jeroen van Meeuwen (Kolab Systems)]

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?

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