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

Gunnar Wrobel wrobel at kolabsys.com
Mon Sep 20 09:13:17 CEST 2010


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

> Gunnar Wrobel wrote:
>> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
>> > 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
>> >
>>
>> 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?
>>
>
> Which two attributes would that be?

The current quota ($cg) and the monthly increase ($percent-float or  
$static) - see below.

>
> One is the interval, which;
>
> - Either directly aligns with the cronjob run interval, or
>
> - Requires additional tracking of "latest update timestamp"
>
> The other one is the actual formula:
>
> Q($cq) = ($cq * $percent-float) + ($cq + $static)
>
> Where:
>
> - $cq is the current quota value,
> - $percent-float is ($conf-value / 100) || 0
> - $static is a static increase in MB, configurable of course

Where should the script get these values from? They were meant to be  
set per user so I assume they would also come from LDAP right?

Cheers,

Gunnar


>
> If you run it every first of the month, you have a predictable trend without
> tracking when the latest update had been made.
>
> If you run it every day, then you need the intended interval hidden in such
> function or in the code/config somewhere, but, more significantly, you would
> also need to track when the latest quota increase on each account had been
> made; either with an LDAP attribute, major code changes, or in a local
> database.
>
> What the code running once a month can more easily do by itself, however, is
> take the old quota value and compare it to the current usage percentage, to
> see if it matches a threshold or not; it doesn't require additional tracking
> of transactional data.
>
> 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
>
> _______________________________________________
> 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.




More information about the devel mailing list