[Kolab-devel] (fwd) how to deal with quotas / suggested feature "monthly quota increase"
wrobel at kolabsys.com
Thu Sep 2 20:32:19 CEST 2010
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
>> 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,
>>> > as, maybe, mailQuota from "LDAP Schema for Internet Mail" - or the
>>> > schema.
>>> > 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
>>> > 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
>> such as people upgrading from 2.x, and organizations that have LDAP in place
> 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
>> When I said "the routine", I meant the calculation made with which to
>> increase/decrease/bloat/remove/double the quota value. I think that
>> 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.
>> 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
> 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
Developer, Kolab Systems AG
e: wrobel at kolabsys.com
t: +49 700 6245 0000
pgp: 9703 43BE
This message was sent using IMP, the Internet Messaging Program.
More information about the devel