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

Ah, so you meant we should take into account that "cyrus-userquota"  
might not be the one and only attribute out there that might actually  
be used for the purpose of setting quotas. And if we are working in  
that area and add a new quota management script we should keep that in  
mind? Makes sense to me. In fact I believe it is even possible to  
configure the attribute name at the moment. Never tried that though.

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

Ah, yes, I did indeed misunderstand you then as I thought you'd like  
to avoid having this in LDAP.

As Gavin is using 2.2.4 at the moment I assume he is also targeting  
2.2.4. So what I'm looking for is a suggestion for our LDAP schema  
that supports the quota routine suggested by Gavin, can be applied to  
2.2.4 now but at the same time has a high chance of surviving the  
transition to a potentially new LDAP schema for Kolab server 3.0. So  
if possible it should just be a hack :)

Based on that a stand-alone quota management script would be great as  
this would also decouple this feature from perl-kolab. Right now this  
is firmly embedded in the code there. Probably not much of a problem  
as people who don't want to manage their quota via "cyrus-userquota"  
probably won't use the attribute at all. Nevertheless - having  
separate modules usually makes sense in the long term.

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.