On Friday 07 March 2003 08:01, Brian Kolaci wrote:
> > OK OK. Brian had me thinking that the quota was stored in a database
> > with
>
> all of that talk about pw_shell and limits API calls.
>
> > I now see that (as I originally thought), the quota is actually stored
> > in
>
> the 'maildirsize' file. (I opened it up and looked at it
>
> > in my maildir)
>
> It is used from the file *only* if you use maildrop. If you use vpopmail
> the info is stored either in the password file or the database.
>
> <snip>
>
> > SO: Would anyone be opposed to moving the 'domain' quota out of the
>
> qmailadmin limits file (I'm assuming it's stored there since
>
> > Brian said it was) and into a separate 'domainquota' file?
>
> Yes. Many people use other tools in addition to qmailadmin
> that manipulate the database directly to control these things.
First off, I downloaded the 3.19 distribution from Bill Shupp's
site and read README.quotas. With that in mind, here are my comments:
OK. I see the pw_shell field in my domain tables.
Is the user quota value in the maildirsize file ever re-syncronized
with the pw_shell variable?
If so... when? And if you change the pw_shell variable, does it
automatically re-sync the quota value in the maildirsize file?
*IF* vpopmail re-syncs the 'maildirsize' file with the value of
the pw_shell variable, then I don't care if people modify the
pw_shell variable from their scripts.
All I care about is that file being correct so that external NON-
vpopmail programs can correctly enforce the user quota.
*IF* vpopmail does NOT re-sync the 'maildirsize' file with the
value of the pw_shell variable, then I think this needs to be
implemented.
> I know I'm not alone. There have been several other posts by
> others using the database that manipulate the db directly. Doing
> this would require *another* file to be opened and maintained
> by the admin tools and again puts a "limit" into the control of
> the end user. I use the limits from the db, and enforce them
> with system quotas.
I'm not trying to make things harder for admins, I'm just trying to
make the maildir quotas readily enforcable by third party apps, like
maildrop and courier-IMAP. (And others if they support Maildir++ AND
our domainquotas)
Firstly, I'd like to note that your quota patch doesn't yet appear to
be included in the main vpopmail development branch. This makes
your argument about putting a 'limit' into the control of the end
user not applicable. If it ain't included in the distribution yet then
it's still up for change. And frankly, if it isn't in a production
release yet, it's up for change as well.
Now, as I said before, I'm ALL FOR letting the end user modify these
limit values easily.
However, I'm still a little unclear about exactly what happens if the
user specifies --enable-mysql-limits at configure time. The README.quotas
file states that everything in the .qmailadmin-limits file would now be
stored in a limits table in the database.
I have NO PROBLEM with that. However, lets create another file called
'domainquota' for each domain quota that gets synchronized with the
database whenever changes are made. This wouldn't require any changes
to the vpopmail API, but rather changes to the internals that the API
calls.
And if the user doesn't specify --enable-mysql-limits, then the file
will STILL exist, but it can either be read directly, or syncronized
with an identical value in the .qmailadmin-limits file ("quota 50", etc...).
Does this sound reasonable? I'm not trying to kill functionality here!
I'm trying to save it by allowing third party apps to easily enforce
domain quotas!
>
> This is for both user quotas and domain quotas.
>
> Brian
--
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v) 423-559-5145 (f)
http://www.wingnet.net
We are actively looking for companies that do a lot of long
distance faxing and want to cut their long distance bill by
up to 50%. Contact [EMAIL PROTECTED] for more info.
