Re: [qmailadmin] Domain pooled quota on qmailadmin-1.0.10

[tonix (Antonio Nati)]

Hi Brian,

usually I keep patches running on my system for months, before publishing them.

This time I published a fresh patch, because I saw a lot of request from people that wants a domain quota, but does not want an OS quota solution.

I hope other will help to find bugs I could not find, and, mainly, suggest how to extend the general quota features. I see a lot of technical discussions, but I don't see analisys discussions on how to make a workable solutions easy to handle for all. So I hope this may help the discussions.

At 19/02/03 19/02/03 -0500, you wrote:

> >Just make sure this new enhancement does not disturb
> >the current domain quotas as specified in the qmailadmin-limits
> >API. Make sure you add a new attribute rather than change the usage
> >of the current implementation. I actually use these to implement real
> >quotas on my system. We ensure that all users of a domain get at least
> >50 Meg each, but the domain starts at 150M through gigabytes.
> >Most users rarely exceed 10 Meg (at least in my sampling, but
> >this arrangement allows them to get large TIFF files and consume
> >typically 30-40M each. They can get one or two, then download/delete
> >them and get more.
>
> I use standard "setuserquota()" function, already used in qmailadmin, so
> this schema is pretty compliant with all qmailadmin, vpopmail and qmail
> requests.
> Pooled way is an analitic solution that uses only standard qmailadmin
> features. 100% natural.

Thats fine to set the user quota, however nothing new.
Thats what Jason's patch already did.


I agree with you on the most you wrote, but the original Jason's patch could not fit my requirements, because I cannot give unlimited space to my customers. I need to handle a fixed space for a domain, giving customers the freedom to tail their mailboxes as they need.

This "pooled" way is much more easy to setup than OS based quotas. Not expert people may use it, without studying OS quotas, adding new "system" users, changing sticky bits in executables.

I'm just concerned that you'll sum up the user quotas
to not exceed the per domain limits "diskquota" or "maxmsgcount"
parameters, which are already used/defined as a "per domain limit"
and not a "pooled user limit". I'm just suggesting that you
add an additional parameter "pooledquota" and "pooledmsgcount".


The exceeding of system quotas is up to the system administrator. I don't use OS quotas.

What's the importance of msgcount? It's not handled in Jason original patch.

Also something missing from Jason's patch is to specify the
max messages a user is allowed to consume. With the 1.0.9 the
user quota is set from the defaults which set both the space
and max msgs.


Again, what is the importance of setting a max message number? I don't care if my customers receive too many messages, until they are in the quota.

>
> >The pooled limits in my opinion doesn't fit how most of my
> >customers use email. System quotas (set from scripts) allow you
> >to easily enforce quota restrictions with optimized O/S monitoring.
> >And having a soft and hard limit, you can set the soft limit at
> >some percentage, say 75% and then send them an email when their
> >domain quota.
>
> Pooled quota it's not the unique solution, but it's another solution that
> may be provided together with system quotas, not limited quotas and fixed
> quotas. It's another answer to customers (and providers) needs.

Agreed, but just make sure its an enhancement, and not a change
to the current implementation. I've already written code for
vdelivermail to enforce the domain limits (both real quotas and
Maildir quotas). I haven't submitted the patch yet as I'm still
running it in my production system to ensure the bugs are worked out.

> Most of my customers want single user quotas, not a unique domain quota.
> The "pooled" way let them manage their single quotas as they want, and let
> me control the space I give them.

Thats fine. It just makes you increase the allotment for the domain.
If a domain has 200 Meg quota, and 50 users, your scheme would impose
an average of 4 meg each, pretty much unacceptable. However, these
limits are typical for many of my domains, and only one out of hundreds
ever reached the domain limit. We set a per-user quota to just make
sure no one user can hog up the whole quota due to bad settings
in their mail client (i.e. leave mail on server).


Why? You may have a 50 MB mailbox, some 1 MB mailbox, other 4 MB, tailoring it to your needs. I hope I used the right word (pooled). I'm not english motherlaguage, please correct me if the word is wrong.

>
> >System quotas are also more reliable in that it enforces
> >the quota even from external sources such as .qmail files
> >or any other local delivery agent.
>
> I agree with you, but what you say may be told against any kind of not
> system based quotas, not only this pooled way.
>
> Ciao,
>
> Tonino
>
> >Thanks,
> >
> >Brian
> >
> > >
> > > Following the qmailadmin-1.0.10, and using (thanks!!!) Justin
> > Hopper's code
> > > as starting framework, I've just realized a domain pooled quota
> > management,
> > > that I'ld like could be integrated in the standard qmailadmin code.
> > >
> > > I followed the advice someone did a lot of time ago in this list. I
> > cannot
> > > find those messages, so I don't know who I should thank.
> > >
> > > The base idea is the following:
> > >
> > > postmaster has the pooled quota against which all user's quota are
> > > subtracted or added. So, when a domain is created, postmaster has the
> > whole
> > > domain's quota. Each time a user is added, the user's quota is
decreased
> > > from postmaster's quota. The contrary when a user is deleted. Same
> > > adjustements when a user's quota is modified, increasing or decreasing
> > > postmaster's quota depending on user modifications. Minimum quota for
> > each
> > > user or postmaster is 1 MB.
> > >
> > > This mechanism helps providers giving customers a fixed amount of
> > space for
> > > the domain, then each domain administrator may manage users' quota as
he
> >needs.
> > >
> > > It works if "--enable-quota=y" is specified, and
"disable_pooled_quota"
> > > does not exist in .qmailadmin-limits.
> > >
> > > Additionally, a small bug on quota handling have been fixed and a
> > couple of
> > > additional .qmailadmin-limits flags ("bounce_mail" and
> > "disable_smtp") have
> > > been added.
> > >
> > > I've published both the integral tar, with all original sources and
> > > changes, and the tar with patches only, in:
> > >
> > > www.interazioni.it/qmail
> > >
> > > All is strictly based on qmailadmin-1.0.10.
> > >
> > > I'ld like that Ken and Bill could insert these features in a next
public
> > > version of qmailadmin.
> > >
> > > Tonino
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------
> > > Inter@zioni Interazioni di Antonio Nati
> > > http://www.interazioni.it [EMAIL PROTECTED]
> > > ------------------------------------------------------------
> > >
> > >
>
>
> ------------------------------------------------------------
> Inter@zioni Interazioni di Antonio Nati
> http://www.interazioni.it [EMAIL PROTECTED]
> ------------------------------------------------------------
>



Brian
Galaxy Networks, Inc.

------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [EMAIL PROTECTED]
------------------------------------------------------------