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

> Gunnar Wrobel wrote:
>> 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.
>>
>
> I think there is also the 'threshold' - the "do not increase quota if current
> usage is under X% or there is still Y megabytes left".
>
> The "current quota" is stored in Cyrus (maybe from "whatever" attribute in
> LDAP was used to synchronize that quota from including 'cyrus-quota' as well
> as 'mailQuota'). For this, no LDAP schema changes would be required. The
> program, however, may want to consider the attribute used to be configurable.
>
> The other config-value needed ($%-float / $int) does not have to be stored in
> LDAP either if it applies to an environment; the value can be set in a
> configuration file. If however (see below) this needs to be tracker on a per-
> user basis, then yes, these users are in LDAP and so their user-specific
> attributes should go in LDAP. I would, to prevent creating administrative
> overhead, consider creating what's called 'Class of Service' policies and
> (role-) templates.

So having groups of users with the same settings? Seems reasonable to  
me and should probably solve most use cases. Did you have a rough  
schema layout in mind?

>
>> > 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?
>>
>
> I think they were meant to *apply* to a single user, but did not need to be
> configured on a per-user basis.

Gavin, can you clarify again if there is indeed a need for per-user  
quota increses or if that can be generalized into groups or even  
system wide settings?

Cheers,

Gunnar

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