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

[Gunnar Wrobel]

Zitat von Gunnar Wrobel <wrobel at kolabsys.com>:

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

Forget this post. The roadmap you just posted answered the questions I had.

Cheers,

Gunnar

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