Re: [vchkpw] new quota support question
On Friday 07 March 2003 12:29, Bill Shupp wrote: > On Friday, March 7, 2003, at 07:15 AM, Jesse Guardiani wrote: > > So, Bill, why don't you think Ken might not sign off on this? > > Because I can't read his mind. I put together what I think is > appropriate. That doesn't mean he will agree. Since he was the one to > implement vadddomain -u to support system quotas, I don't know he needs > non-system quotas. Gotcha. I need them, for what it's worth. :) Thanks for the info. > > Bill -- 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.
Re: [vchkpw] new quota support question
On Friday, March 7, 2003, at 07:15 AM, Jesse Guardiani wrote: So, Bill, why don't you think Ken might not sign off on this? Because I can't read his mind. I put together what I think is appropriate. That doesn't mean he will agree. Since he was the one to implement vadddomain -u to support system quotas, I don't know he needs non-system quotas. Bill
Re: [vchkpw] new quota support question
On Friday 07 March 2003 10:13, Jesse Guardiani wrote: > On Friday 07 March 2003 09:47, Jesse Guardiani wrote: > > On Friday 07 March 2003 08:01, Brian Kolaci wrote: > > Hang on. I think I just realized what I've been missing > the entire time: > > The USER QUOTAS still work! That means that maildrop and > courier still enforce them. So, Bill, why don't you think Ken might not sign off on this? > > But when you create a domain, you can specify a domain > quota and vpopmail internally limits the size of each > user quota based on the domain quota. > > Maildrop STILL WORKS with domain quotas. Everything is > compatible as long as your domain admins use qmailadmin > to set up domain quotas. > > I'm truely sorry about all of that. I get it now. > > I feel really really silly. > > Thanks for your patience! -- 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.
Re: [vchkpw] new quota support question
On Friday 07 March 2003 09:47, Jesse Guardiani wrote: > On Friday 07 March 2003 08:01, Brian Kolaci wrote: Hang on. I think I just realized what I've been missing the entire time: The USER QUOTAS still work! That means that maildrop and courier still enforce them. But when you create a domain, you can specify a domain quota and vpopmail internally limits the size of each user quota based on the domain quota. Maildrop STILL WORKS with domain quotas. Everything is compatible as long as your domain admins use qmailadmin to set up domain quotas. I'm truely sorry about all of that. I get it now. I feel really really silly. Thanks for your patience! -- 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.
Re: [vchkpw] new quota support question
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.
>
>
>
> > 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.
Re: [vchkpw] new quota support question
> 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. > 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. 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. This is for both user quotas and domain quotas. Brian
Re: [vchkpw] new quota support question
- Original Message - From: "Bill Shupp" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 6:56 PM Subject: Re: [vchkpw] new quota support question > On Thursday, March 6, 2003, at 01:40 PM, Brian Kolaci wrote: > > > I guess I wasn't explicit enough. I assumed people already > > knew how the quota's are stored. The "user quota" for vpopmail > > is stored in the pw_shell attribute of the vqpasswd structure. > > Where this information is stored (db, cdb, file) doesn't matter. > > You use an API to get at it. In courier, a different place is used. > > The "domain quota" is now currently stored in the qmailadmin limits > > information, which is now retrieved using the vget_limits() function. > > Again, where it is actually stored doesn't matter. > > The important thing to remember is that Sam's approach now is to set > the quota with maildirmake -q. The quota is stored ONLY in the > maildirsize file itself. It is the responsibility of any Maildir++ > aware applications to honor the quota established in that file. > > I only used pw_shell for backwards compatibility with the old vpopmail > quotas. 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) I haven't read enough about 'maildirmake -q', so I don't know if that program actually makes USE of the quota stored in 'maildirsize', but at least now I know that the 'user' quota CAN be read by third party programs. 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? We could then add a line to each user's 'maildirsize' file that gives the file location of 'domainquota', and I could talk with Sam, or write a patch that allows courier-IMAP and maildrop to use the 'domainquota' file as well as the 'maildirsize' file if it exists in the 'maildirsize' file. This would instantly solve my problem with maildrop and courier not being compatible with the new domain wide quotas, AND it would make Sam more likely to accept the code since it doesn't deal with vpopmail specific files like the qmailadmin limits file. Is there ANYTHING I am still wrong about? Does the above make sense? What do you think, Bill? Thanks for having patience with me! > > Regards, > > Bill Shupp > > >
Re: [vchkpw] new quota support question
On Thursday, March 6, 2003, at 01:40 PM, Brian Kolaci wrote: I guess I wasn't explicit enough. I assumed people already knew how the quota's are stored. The "user quota" for vpopmail is stored in the pw_shell attribute of the vqpasswd structure. Where this information is stored (db, cdb, file) doesn't matter. You use an API to get at it. In courier, a different place is used. The "domain quota" is now currently stored in the qmailadmin limits information, which is now retrieved using the vget_limits() function. Again, where it is actually stored doesn't matter. The important thing to remember is that Sam's approach now is to set the quota with maildirmake -q. The quota is stored ONLY in the maildirsize file itself. It is the responsibility of any Maildir++ aware applications to honor the quota established in that file. I only used pw_shell for backwards compatibility with the old vpopmail quotas. Regards, Bill Shupp
RE: [vchkpw] new quota support question
> -Original Message- > From: Jesse Guardiani [mailto:[EMAIL PROTECTED] > Sent: Friday, 7 March 2003 9:09 AM > To: [EMAIL PROTECTED] > Subject: Re: [vchkpw] new quota support question > As far as I can tell, maildirsize is only recalculated from > scratch when it doesn't exist. The maildirsize file is totally recalc'ed periodically You can read about this at http://inter7.com/courierimap/README.maildirquota.html Look for the section titled : "Calculating the quota for a Maildir++" Michael.
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 16:40, Brian Kolaci wrote: > > If vpopmail stores the actual user quota in a database, and the > > maildirsize file just stores the current size of the maildir (which IS > > a file based system, BTW), then doesn't that mean that Maildrop has > > NEVER been capable of enforcing maildir++ with vpopmail? > > I guess I wasn't explicit enough. I assumed people already > knew how the quota's are stored. The "user quota" for vpopmail > is stored in the pw_shell attribute of the vqpasswd structure. > Where this information is stored (db, cdb, file) doesn't matter. That depends on what you want to do with it. If you want courier and vpopmail to use the same quota system so that both applications can enforce the same quota, then it does matter. And what is so wrong with that? Why are you so opposed to the idea of courier and vpopmail sharing the same quota system? I don't see that idea as anything but a good thing. Are you worried that I want YOU to implement it? I don't. Rest assured. I don't care if you do, but I'm not trying to convince you to implement anything. > You use an API to get at it. In courier, a different place is used. > The "domain quota" is now currently stored in the qmailadmin limits > information, which is now retrieved using the vget_limits() function. > Again, where it is actually stored doesn't matter. Again, that depends on what you're trying to accomplish. > > Now the "usage" of maildir++ quotas is stored in the filename. There > is a cache file in the Maildir called maildirsize that caches all the > file sizes in one file. > > > All of the docs on the web seem to suggest that maildrop IS compatible > > with maildir++. Does "compatible" in that sense only mean that maildrop > > can manipulate the maildirsize file? But that it doesn't actually have > > a clue when a user's quota is exceeded? I guess I never understood that > > properly. > > I'm sure it is "compatible" in that sense. I don't know the rules > of how it enforces the quota nor where it gets the user quota from. > I doubt it gets it from vpopmail Well, if it doesn't get the quota from vpopmail then it can't enforce the quota. That's not good. > and the vqpasswd file as vdelivermail > does, but I may be wrong. > > > Also, I don't see why implementing "soft" quotas with another file > > inside the maildir would be such a bad idea. The maildirsize file is > > already vulnerable to user modification, so it ONLY works when the user > > doesn't have shell access to their own maildir. Also, EMAIL is backed > > up from the file system, so what's wrong with backing up the quota that > > applies to that email with it? > > The maildirsize file is auto-recreated or re-evaluated when mail > is deleted. I don't think putting the quotas within the grasp > of the user is a good idea. What are you talking about? maildirsize is already within the grasp of the user. And you're right, it's "re-evaluated". That means that any user with access can simply change the value up or down and their quota will be different as reported by vuserinfo. As far as I can tell, maildirsize is only recalculated from scratch when it doesn't exist. > > > > I'd say we beat this topic to death though. Since you're using > > > maildrop, then why not create a patch for it. Then the patch itself > > > could be included in the vpopmail distribution, or kept separate as > > > its own distribution. > > > > Sure, I could do that, but then I'd have to maintain a patch, and > > that's messy. I'd much rather implement a standard that everyone can > > work with. > > What exactly is "everyone"? Any software that writes to a vpopmail maildir. > Its just vpopmail & courier. You just > happen to have a specialized installation that is using both. It > sounds like for you, the features of courier outweigh the features > of vpopmail, so you should probably just convert to courier > and not use vpopmail. If you think the features of vpopmail are > more important, then think about putting what you like better in > courier into vpopmail. You're trying to mix qmail/vpopmail and > courier. I'm tempted to curse here. Of coarse I'm trying to mix qmail/vpopmail and courier! What else would I be trying to do? What do you think you're doing when you use courier for IMAP or POP3 access? You're mixing it. > > > Please bare with me here. I'm starting to realize that I didn't really > > understand how these quotas work, and that there is a great possibility > > that maildrop was never really capable of enforcing maildir++ quotas > > (because maildir++ doesn't really have much to do with the quota > > itself, but rather the size of the maildir) > > True. It may enforce it, however I would say with its own user storage > and rules. And that's what I'd like to change. I'd like courier to be able to read a userquota file, (just like it now reads 'maildirsize'), that contains the user quota
Re: [vchkpw] new quota support question
> If vpopmail stores the actual user quota in a database, and the maildirsize > file just stores the current size of the maildir (which IS a file based > system, BTW), then doesn't that mean that Maildrop has NEVER been capable > of enforcing maildir++ with vpopmail? I guess I wasn't explicit enough. I assumed people already knew how the quota's are stored. The "user quota" for vpopmail is stored in the pw_shell attribute of the vqpasswd structure. Where this information is stored (db, cdb, file) doesn't matter. You use an API to get at it. In courier, a different place is used. The "domain quota" is now currently stored in the qmailadmin limits information, which is now retrieved using the vget_limits() function. Again, where it is actually stored doesn't matter. Now the "usage" of maildir++ quotas is stored in the filename. There is a cache file in the Maildir called maildirsize that caches all the file sizes in one file. > > All of the docs on the web seem to suggest that maildrop IS compatible with > maildir++. Does "compatible" in that sense only mean that maildrop can > manipulate the maildirsize file? But that it doesn't actually have a clue > when a user's quota is exceeded? I guess I never understood that properly. I'm sure it is "compatible" in that sense. I don't know the rules of how it enforces the quota nor where it gets the user quota from. I doubt it gets it from vpopmail and the vqpasswd file as vdelivermail does, but I may be wrong. > Also, I don't see why implementing "soft" quotas with another file inside > the maildir would be such a bad idea. The maildirsize file is already > vulnerable to user modification, so it ONLY works when the user doesn't > have shell access to their own maildir. Also, EMAIL is backed up from the > file system, so what's wrong with backing up the quota that applies to that > email with it? The maildirsize file is auto-recreated or re-evaluated when mail is deleted. I don't think putting the quotas within the grasp of the user is a good idea. > > I'd say we beat this topic to death though. Since you're using > > maildrop, then why not create a patch for it. Then the patch itself > > could be included in the vpopmail distribution, or kept separate as > > its own distribution. > > Sure, I could do that, but then I'd have to maintain a patch, and that's > messy. I'd much rather implement a standard that everyone can work with. What exactly is "everyone"? Its just vpopmail & courier. You just happen to have a specialized installation that is using both. It sounds like for you, the features of courier outweigh the features of vpopmail, so you should probably just convert to courier and not use vpopmail. If you think the features of vpopmail are more important, then think about putting what you like better in courier into vpopmail. You're trying to mix qmail/vpopmail and courier. > Please bare with me here. I'm starting to realize that I didn't really > understand how these quotas work, and that there is a great possibility > that maildrop was never really capable of enforcing maildir++ quotas > (because maildir++ doesn't really have much to do with the quota itself, > but rather the size of the maildir) True. It may enforce it, however I would say with its own user storage and rules. You can't just assume when user information is stored in one place that software developed for another project will use it. > I really need a way to filter email on the server side, so unless that > functionality makes it's way into vdelivermail in the near future, I'd > really like to discuss the possibility of expanding the maildir++ > specification to include user and domain quotas. I don't even want to touch that... > I'd be willing to write code for this too, so it's not like you're talking > to someone who's just mouthing off and whining for functionality. This > is how Open Source works: When a developer has an itch, he scratches it, > and everyone benefits, right? > > Lets talk. If you're willing to help me hammer out an idea that works, > then I'll pitch it to Mr. Sam. If we do a good job and it makes sense, > then I doubt he'll object as long as I do most of the coding and he > doesn't have to. Sorry, but I still don't think you should store limits information within control of end users. A quota is just another limit, as is the other information used by qmailadmin. Thanks, Brian
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 14:15, Brian Kolaci wrote: > > So the domain quotas aren't stored in a file, but rather in whatever > > Good luck trying to get everyone to swap to a file based system. > I personally like *everything* in the database rather than filesystem. > All the information (other than message store & cache info) is in the > database for easy backup/recovery. Could you clarify something for me? If vpopmail stores the actual user quota in a database, and the maildirsize file just stores the current size of the maildir (which IS a file based system, BTW), then doesn't that mean that Maildrop has NEVER been capable of enforcing maildir++ with vpopmail? All of the docs on the web seem to suggest that maildrop IS compatible with maildir++. Does "compatible" in that sense only mean that maildrop can manipulate the maildirsize file? But that it doesn't actually have a clue when a user's quota is exceeded? I guess I never understood that properly. Also, I don't see why implementing "soft" quotas with another file inside the maildir would be such a bad idea. The maildirsize file is already vulnerable to user modification, so it ONLY works when the user doesn't have shell access to their own maildir. Also, EMAIL is backed up from the file system, so what's wrong with backing up the quota that applies to that email with it? > > I'd say we beat this topic to death though. Since you're using > maildrop, then why not create a patch for it. Then the patch itself > could be included in the vpopmail distribution, or kept separate as > its own distribution. Sure, I could do that, but then I'd have to maintain a patch, and that's messy. I'd much rather implement a standard that everyone can work with. Please bare with me here. I'm starting to realize that I didn't really understand how these quotas work, and that there is a great possibility that maildrop was never really capable of enforcing maildir++ quotas (because maildir++ doesn't really have much to do with the quota itself, but rather the size of the maildir) I really need a way to filter email on the server side, so unless that functionality makes it's way into vdelivermail in the near future, I'd really like to discuss the possibility of expanding the maildir++ specification to include user and domain quotas. I'd be willing to write code for this too, so it's not like you're talking to someone who's just mouthing off and whining for functionality. This is how Open Source works: When a developer has an itch, he scratches it, and everyone benefits, right? Lets talk. If you're willing to help me hammer out an idea that works, then I'll pitch it to Mr. Sam. If we do a good job and it makes sense, then I doubt he'll object as long as I do most of the coding and he doesn't have to. > > 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.
Re: [vchkpw] new quota support question
> So the domain quotas aren't stored in a file, but rather in whatever database > backend you happen to be using? They are stored in either the .qmailadmin-limits file, or MySQL, if enabled. The "user" quota is stored in the "pw_shell" attribute of the password entry for the user. > > I'd think that if the domain quotas could be stored in a file, that a ratification > could be made to the maildir++ standard. Perhaps the maildirsize file could contain > a reference to the location of the domain quota file. This would be quite flexible > I'd think. > > What do you think? > > Either way, I think this functionality needs to be implemented in a way > that Courier-IMAP and other programs can live with. It should be standardized, > otherwise vpopmail will be implementing a feature that no-one else can > realistically use without linking vpopmail's libraries into their code > (which I mentioned in another thread as being a bit of a pain sometimes). Yes, but I don't think that courier has a need or care for domain based quotas, just as Bill said. Most people use system quotas. If you use courier, then you'll wind up using its own SQL implementation (he doesn't use files either). BTW, maildir++ quotas isn't really a "standard". First, there was courier, where it started. Bill then updated vpopmail to also conform since there's no down-side to it, but you can get benefit from it. Good luck trying to get everyone to swap to a file based system. I personally like *everything* in the database rather than filesystem. All the information (other than message store & cache info) is in the database for easy backup/recovery. I'd say we beat this topic to death though. Since you're using maildrop, then why not create a patch for it. Then the patch itself could be included in the vpopmail distribution, or kept separate as its own distribution. Brian
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 13:49, Brian Kolaci wrote: > > > I'd be curious to see if Mr. Sam accepts such patches. I personally > > > think that this new non-system domain quota feature is unnecessary, > > > when system quotas are available, easily implemented, and a better > > > solution. But enough people seemed to want it for some reason, and > > > Brian did a very nice job of implementing it cleanly with his other > > > vlimits functions, so I included it in my devel version. Notice that > > > Ken has not yet signed off on this, so there's no guarantee that it > > > will make it in the official release, anyway. So you might hold off > > > on patching anything else, unless you (or anyone else) are prepared > > > to maintain it. > > > > Noted. I personally hope it makes production. Sounds like a good idea > > to me, it just seems to require a ratification to the maildir++ > > standard. > > Seems unlikely. courier has no provision to store "domain" quotas, > only user quotas. Like I said in my last email, it requires getting > the domain quota from somewhere, and vdelivermail uses the vget_limits() > API out of libvpopmail.a. So the domain quotas aren't stored in a file, but rather in whatever database backend you happen to be using? I'd think that if the domain quotas could be stored in a file, that a ratification could be made to the maildir++ standard. Perhaps the maildirsize file could contain a reference to the location of the domain quota file. This would be quite flexible I'd think. What do you think? Either way, I think this functionality needs to be implemented in a way that Courier-IMAP and other programs can live with. It should be standardized, otherwise vpopmail will be implementing a feature that no-one else can realistically use without linking vpopmail's libraries into their code (which I mentioned in another thread as being a bit of a pain sometimes). > > 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.
Re: [vchkpw] new quota support question
> > I'd be curious to see if Mr. Sam accepts such patches. I personally > > think that this new non-system domain quota feature is unnecessary, > > when system quotas are available, easily implemented, and a better > > solution. But enough people seemed to want it for some reason, and > > Brian did a very nice job of implementing it cleanly with his other > > vlimits functions, so I included it in my devel version. Notice that > > Ken has not yet signed off on this, so there's no guarantee that it > > will make it in the official release, anyway. So you might hold off on > > patching anything else, unless you (or anyone else) are prepared to > > maintain it. > > Noted. I personally hope it makes production. Sounds like a good idea > to me, it just seems to require a ratification to the maildir++ standard. Seems unlikely. courier has no provision to store "domain" quotas, only user quotas. Like I said in my last email, it requires getting the domain quota from somewhere, and vdelivermail uses the vget_limits() API out of libvpopmail.a. Brian
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 13:20, Bill Shupp wrote: > On Thursday, March 6, 2003, at 10:05 AM, Jesse Guardiani wrote: > I'd be curious to see if Mr. Sam accepts such patches. I personally > think that this new non-system domain quota feature is unnecessary, > when system quotas are available, easily implemented, and a better > solution. But enough people seemed to want it for some reason, and > Brian did a very nice job of implementing it cleanly with his other > vlimits functions, so I included it in my devel version. Notice that > Ken has not yet signed off on this, so there's no guarantee that it > will make it in the official release, anyway. So you might hold off on > patching anything else, unless you (or anyone else) are prepared to > maintain it. Noted. I personally hope it makes production. Sounds like a good idea to me, it just seems to require a ratification to the maildir++ standard. > > Regards, > > Bill Shupp -- 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.
Re: [vchkpw] new quota support question
On Thursday, March 6, 2003, at 10:05 AM, Jesse Guardiani wrote: Thanks, Bill, but Brian was kind enough to answer most of my questions directly. Last time I checked, mailing lists were a good place for open discussion. Of course they are. But reading documentation can reduce unnecessary traffic, too. Especially when the ChangeLog clearly indicates that new documentation is available on the changes you discovered in the ChangeLog. Yes, and using maildrop will totally keep domain based quotas from working properly. Looks like someone needs to patch the courier-imap and friends. I'd be curious to see if Mr. Sam accepts such patches. I personally think that this new non-system domain quota feature is unnecessary, when system quotas are available, easily implemented, and a better solution. But enough people seemed to want it for some reason, and Brian did a very nice job of implementing it cleanly with his other vlimits functions, so I included it in my devel version. Notice that Ken has not yet signed off on this, so there's no guarantee that it will make it in the official release, anyway. So you might hold off on patching anything else, unless you (or anyone else) are prepared to maintain it. Regards, Bill Shupp
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 11:28, Bill Shupp wrote: > On Thursday, March 6, 2003, at 06:16 AM, Jesse Guardiani wrote: > > Howdy list, > > > > I'm just wondering a few things about the new domain wide quotas: > > > > Are these quotas implemented in vdelivermail? > > > > Or are they implemented with system quotas? > > > > Will I still be able to use maildrop to filter my mail? > > I addresses the above questions in README.quotas. Please take the time > to read it before posting to the list, that's why I took the time to > write it. Thanks, Bill, but Brian was kind enough to answer most of my questions directly. Last time I checked, mailing lists were a good place for open discussion. > > > When are the quotas recalculated? (If maildrop deletes a message, > > will it throw the quotas off?) > > It calculates based on maildirsize files, which greatly increases > performance. (Brian's original implementation used a du like function > that delayed delivery by as much as several seconds). So it does > follow the Maildir++ standard, it's just a cumulative approach. Yes, and using maildrop will totally keep domain based quotas from working properly. Looks like someone needs to patch the courier-imap and friends. Any takers? I'm swamped. > > Regards, > > Bill Shupp -- 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.
Re: [vchkpw] new quota support question
On Thursday, March 6, 2003, at 06:16 AM, Jesse Guardiani wrote: Howdy list, I'm just wondering a few things about the new domain wide quotas: Are these quotas implemented in vdelivermail? Or are they implemented with system quotas? Will I still be able to use maildrop to filter my mail? I addresses the above questions in README.quotas. Please take the time to read it before posting to the list, that's why I took the time to write it. When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) It calculates based on maildirsize files, which greatly increases performance. (Brian's original implementation used a du like function that delayed delivery by as much as several seconds). So it does follow the Maildir++ standard, it's just a cumulative approach. Regards, Bill Shupp
Re: [vchkpw] new quota support question
> > > Or are they implemented with system quotas? > > > > You can do that also if you wish, however you'll need to > > supply your own scripts for that. > > So, basically, no? What would I have to supply to use system > quotas? If you wish to use system quota's, you'll need to write a script to update the system quota. I'm on solaris, so I use a script that sends some commands to "edquota". On linux, it may be different. > > > Will I still be able to use maildrop to filter my mail? > > > > I'm unsure about maildrop. If it delivers the mail via > > vdelivermail, then yes, but if it writes directly to the > > file system, it needs to be patched to enforce the quotas. > > I've updated libvpopmail.a to include the quota code, so > > you should be able to patch it if needed. > > Maildrop is maildir++ compatible. I assume that this new code > deviates from the maildir++ standard? Yes, however only for "user" quotas. There's no concept of "domain" quotas in courier that I'm aware of. This code is maildir++ compliant, but now vdelivermail uses the "limits" API to retrieve the per-domain limits (disk quota & max msg count) and enforce it by making a check at the current usage (which calculates usage by summing up the usage for each mailbox within a domain). > > > When are the quotas recalculated? (If maildrop deletes a message, > > > will it throw the quotas off?) > > > > The domain quota code recalculates the quota each time on the fly. > > One big benefit now is its use of the maildirsize files, if they're > > there. This is a big performance gain. But if you don't have anything > > creating & maintaining these files (and they don't exist), then the > > performance would be pretty bad if people "leave mail on server", and > > you constantly have to sum up thousands of files. I haven't used maildrop, > > and I see the maildirsize files in each user's Maildir so I assume > > vdelivermail is maintaining them. You'll need to try it out and see > > what kind of performance you get. In my copy, I have syslog()'s > > logging the clock over these and I typically see about 0.001s > > when the cache files are there, and up to 7s when they're not (but > > then they suddenly appear, so it must be creating them by default). > > The 7 seconds was due to a user with a few thousand messages still in there > > and no maildirsize file. > > OK. So, when vdelivermail delivers a message to the maildir, it just > modify's the quota based on the email's size, correct? It doesn't > actually recalculate the entire quota? I believe it checks if the file is there and recalulates the entire maildir if its missiing. If its there, it just appends the quota information to the maildirsize file. > What happens when an IMAP or POP server deletes a message from the > maildir? Is the quota then incorrect? I use Courier-IMAP. I use courier-imap as well as the courier pop3 daemon. I believe the imap server recalculates the quota for the maildir. I'm not sure whether it recalculates the whole user maildir, or just removes one entry from the file. You'll have to check the code. > Is there a way to recalculate a user's maildir quota via command line? > (For instance, so that all of my user's quotas could be recalculated at > 4 AM from scratch via a shell script or Perl script?) Not that I'm aware of. I think you automatically get it if its not there during a delivery. Since maildrop is part of courier (I assume it is), then it probably manages the maildirsize files already as vdelivermail does. It probably enforces "user" quotas, but I'm not sure. It won't enforce domain quotas without patching it to retrieve & enforce a domain level quota. You'll need the vget_limits() function from the vpopmail library for that. > Thanks for all the info! No prob. Good luck. Brian
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 09:49, Brian Kolaci wrote: > > Howdy list, > > > > I'm just wondering a few things about the new domain wide quotas: > > > > Are these quotas implemented in vdelivermail? > > Yes. Ok. > > > Or are they implemented with system quotas? > > You can do that also if you wish, however you'll need to > supply your own scripts for that. So, basically, no? What would I have to supply to use system quotas? > > > Will I still be able to use maildrop to filter my mail? > > I'm unsure about maildrop. If it delivers the mail via > vdelivermail, then yes, but if it writes directly to the > file system, it needs to be patched to enforce the quotas. > I've updated libvpopmail.a to include the quota code, so > you should be able to patch it if needed. Maildrop is maildir++ compatible. I assume that this new code deviates from the maildir++ standard? > > > When are the quotas recalculated? (If maildrop deletes a message, > > will it throw the quotas off?) > > The domain quota code recalculates the quota each time on the fly. > One big benefit now is its use of the maildirsize files, if they're > there. This is a big performance gain. But if you don't have anything > creating & maintaining these files (and they don't exist), then the > performance would be pretty bad if people "leave mail on server", and > you constantly have to sum up thousands of files. I haven't used maildrop, > and I see the maildirsize files in each user's Maildir so I assume > vdelivermail is maintaining them. You'll need to try it out and see > what kind of performance you get. In my copy, I have syslog()'s > logging the clock over these and I typically see about 0.001s > when the cache files are there, and up to 7s when they're not (but > then they suddenly appear, so it must be creating them by default). > The 7 seconds was due to a user with a few thousand messages still in there > and no maildirsize file. OK. So, when vdelivermail delivers a message to the maildir, it just modify's the quota based on the email's size, correct? It doesn't actually recalculate the entire quota? What happens when an IMAP or POP server deletes a message from the maildir? Is the quota then incorrect? I use Courier-IMAP. Is there a way to recalculate a user's maildir quota via command line? (For instance, so that all of my user's quotas could be recalculated at 4 AM from scratch via a shell script or Perl script?) Thanks for all the info! > > Thanks, > > 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.
Re: [vchkpw] new quota support question
> Howdy list, > > I'm just wondering a few things about the new domain wide quotas: > > Are these quotas implemented in vdelivermail? Yes. > Or are they implemented with system quotas? You can do that also if you wish, however you'll need to supply your own scripts for that. > Will I still be able to use maildrop to filter my mail? I'm unsure about maildrop. If it delivers the mail via vdelivermail, then yes, but if it writes directly to the file system, it needs to be patched to enforce the quotas. I've updated libvpopmail.a to include the quota code, so you should be able to patch it if needed. > > When are the quotas recalculated? (If maildrop deletes a message, > will it throw the quotas off?) The domain quota code recalculates the quota each time on the fly. One big benefit now is its use of the maildirsize files, if they're there. This is a big performance gain. But if you don't have anything creating & maintaining these files (and they don't exist), then the performance would be pretty bad if people "leave mail on server", and you constantly have to sum up thousands of files. I haven't used maildrop, and I see the maildirsize files in each user's Maildir so I assume vdelivermail is maintaining them. You'll need to try it out and see what kind of performance you get. In my copy, I have syslog()'s logging the clock over these and I typically see about 0.001s when the cache files are there, and up to 7s when they're not (but then they suddenly appear, so it must be creating them by default). The 7 seconds was due to a user with a few thousand messages still in there and no maildirsize file. Thanks, Brian
