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

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> >> Jeroen, you have been looking at improving the LDAP schema lately. Can
> >> I get your opinion here?
> >>
> >
> > Let's forget about cyrus-userquota. *POOF*! Just like that.
> 
> Lets be realistic: We have cyrus-userquota in 2.2.4 it will most  
> likely be in 2.3 so I'm kind of sceptic about "*POOF*" ;) I assume  
> this still has some lifetime.
> 

Yes. Any target that removes anything from LDAP is not going to be implemented 
in 2.x.y. When I said *POOF*, I actually meant to say; We could reconsider the 
use of LDAP attributes and/or schema extensions as part of the move forward 
with Kolab 3.0.

> >
> > Let's take a more generic name for the quota the mail environment uses, 
such
> > as, maybe, mailQuota from "LDAP Schema for Internet Mail" - or the 
Netscape
> > schema[1].
> >
> > For the purpose of OP, let's have a look at this message:
> >
> >   http://lists.andrew.cmu.edu/pipermail/info-cyrus/2009-July/031300.html
> >
> > The combination of cyrus_get_quota.pl and cyrus_ldap_quota.pl should get 
you
> > started.
> 
> How does this relate to the functionality Gavin was suggesting? As far  
> as I understand it the schema also only offers a quota setting. So in  
> terms of our ability to manage the quota we don't gain anything by  
> that change.
> 

The trick is that the attribute used for the quota value must end up being a 
configurable. It's 'cyrus-userquota' for now, it's 'mailQuota' somewhere else, 
and possibly we do require a 'kolabQuota' attribute in 3.0 for some or the 
other reason I can't think of right now. Case in point is while Kolab may 
provide something of it's own, it doesn't mean it's being used as such, or at 
all, and that different means may be available in an existing infrastructure, 
such as people upgrading from 2.x, and organizations that have LDAP in place 
already.

> > Storing the routine in LDAP though is not feasible;
> 
> Why not? Fact is that the Kolab server managed the quota in LDAP for  
> quite some time. The schema you linked to allows to manage quotas via  
> LDAP. As far as I know people are quite happy with the feature. All  
> Gavin is suggesting is to add a second variable (attribute) into the  
> equation.
> 

When I said "the routine", I meant the calculation made with which to 
increase/decrease/bloat/remove/double the quota value. I think that addresses 
your concern, as you seem to be thinking I didn't want the actual quota value 
to be stored in LDAP?

Kind regards,

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