[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 Gavin McCullagh <gavin.mccullagh at gcd.ie>:
>> > I propose to introduce a simple linear quota increase scheme in our
>> > organisation.  A new user starts with a standard quota of C.  Then, each
>> > fixed period (probably month), we increase the quota by a standard amount
>> > M.
>> > 	Q(t) = M*t + C
>> >
>>
>> The script managing the quota probably would not be the problem. What
>> I'm not certain about is adding the "M" value as a new LDAP attribute.
>> Changes to the LDAP schema usually don't make me too happy. They are
>> easy to add but usually also need to be maintained. The are many
>> configuration variables one could set for a user but whether keeping
>> these in LDAP in really a sensible approach is another matter.
>>
>> Of course the kolabInetOrgPerson already offers the quota setting
>> "cyrus-userquota". So it seems natural adding such a new setting close
>> to it.
>>
>> 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.

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

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

> Maybe you only want this
> for road warriors, or any other subset of the LDAP entries, maybe you want it
> per domain. I think it's better to avoid storing such in LDAP.

I tend to disagree. I'm not against storing this in LDAP per se. I was  
just searching for a better approach rather than adding just another  
attribute to kolabInetOrgPerson. I was thinking in terms of an  
auxiliary class or something like that.

Cheers,

Gunnar

>
> Kind regards,
>
> [1] http://www.ietf.org/proceedings/43/I-D/draft-srivastava-ldap-mail-00.txt
>
> --
> 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.