why do you speak of quota replacemente? I'm not replacing anything, nor changing any qmail quota schema.
I simply use setuserquota() in the same way it was used in the code I've found. If there are any problems, they are already in the original code.
I've found "--enable_modify_quota" in the base configure tool, and for it I've added a "enable_quota_admin" line, enabling the code on a "per domain" basis and not for all as before. I don't see nothing strange with it. My specific code is affected by a specific line "disable_pooled_quota". I followed this security schema on the enabling logic: no_quota_change -> pooled -> uncontrolled change.
Probably I explained it in the wrong way, probably I used the wrong word (pooled). Please, take a look more detailed to the code and help me to use the right words.
I'm only sorry that the original idea is not mine! :-).
About releasing, this software is on my production system and my customers are entusiastic of it, so I preferred to release it immediately. This is free and open software, and I expect others to find bugs and extend it.
Ciao,
Tonino
At 19/02/03 19/02/03 -0500, Brian Kolaci wrote:
Quotas were talked about *alot*, before and after the limits
API patches I submitted. I've had the domain quota using system
quotas over a year. What was asked for was a solution to implement
domain quotas (not pooled allocation scheme), which I've had running
for a bit over a month (which takes into account maildir quotas).
It was *easy* to implement, extending Bill's code (who ported Sam's code).
I don't believe in rushing things out the door just because many people
keep asking for it, otherwise you get something like the software from
Micro$oft, which requires years of patches just to get it running again.
I think your idea may benefit some people. I just don't think its
the correct solution for the intent. I believe it can be used as long
as it is an "extension" and not "replacement" for the quota handling that
is in there and has been for quite some time. i.e. "--enable-quota"
is a bad name for what you have. Quotas are already in there, but
you're adding something more like "--enable-quotapooling". I also
believe this approach forces people to do extra work as a postmaster
or administrator which most beginner admins won't appreciate. The current
approach works fine for all, you just need vdelivermail to enforce the
domain limitations, which is extra processing, but easy to comprehend
and doesn't add work to the end user (i.e. postmaster).
First and foremost you need to make sure you do not break any existing
installations. If you used *any* existing elements in the limits API,
then you would break existing installations. I haven't looked at the
patch, but need to make sure to "extend" the structure in libvpopmail.a
(where the qmailadmin-limits file or table is maintained). It is no
longer accessed as a flat file in qmailadmin, but uses the vget_limits()
and vset_limits() API.
Thanks,
Brian
> 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]
> > ------------------------------------------------------------
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [EMAIL PROTECTED]
------------------------------------------------------------