On Thu, 2 Apr 1998, Nathan E Norman wrote: > On Thu, 2 Apr 1998, Pete Templin wrote: > > : > : Hi: > : > : In the process of debugging a variety of quota problems visible in > : procmail-based mail delivery and qpopper-based mail pickup, I believe I've > : identified an interaction problem between chown and quota. Essentially, > : if a program running as superuser creates/appends/edits a file which would > : put the user over soft quota, and then chown's it to the appropriate user, > : the user is considered over soft quota with NO grace period. I've already > : found this to be problematic in the following situations: > : > : 1) I use sendmail with procmail as the local delivery agent. If an > : incoming message would put the user over soft quota, the message is > : returned undeliverable with the message "overquota". IMHO, this shouldn't > : happen unless the user would exceed hard quota or has expired his/her > : grace period. The tricky part is I use a perl script run out of cron to > : notify people if they're over quota...unfortunately I notify via email. > > Hmm, I hadn't noticed this (yet). I will test and try to confirm. > > : 2) I use qpopper to offer email to our customers. Quotas are enforced > : (10M soft, 21M hard) on the /var partition, which therefore limits both > : the user's mailbox and the corresponding copy which qpopper creates > : beneath /var/spool/pop . Since the user's mailbox can't exceed 10M (see > : problem 1, above), the user can't (easily) exceed 20M of disk usage while > : qpopper has the /var/spool/pop/username.pop file in use, so the user can't > : exceed their hard quota. Some of our users are unable to POP their mail > : because of the following error: > : > : Apr 1 13:15:59 webhost in.qpopper[8981]: [EMAIL PROTECTED]: -ERR Unable > : to copy mail spool file, quota exceeded (122) > > Since quotas are filesystem based, you must plan your filesystem > layout accordingly. The only easy way around this is to either insure > that /var/spool/mail and /var/spool/pop are seperate filesystems, or > grab the qpopper sources and make popper put its tempfiles somewhere > other than /var/spool/pop ... preferably a seperate filesystem. I don't > think you can blame the second problem on qpopper.
This would solve problem 2, but not problem 1. I have a wonderful workaround for problem 2: NFS mount /var/spool/mail on another server, install qpopper, and change the IP address of pop.jdweb.com. However, this only works if management & store staff (which are the same two people) used the correct hostnames in everyone's setup. :) I figure the problem is somewhere between the chown system call and quota, but I'm not sure. Looking forward to your ideas and suggestions, or directions towards what to file a bugreport on... Pete -- Peter J. Templin, Jr. Systems and Networks Administrator JD-WEB Computer Sales and Service 429 Market St. [EMAIL PROTECTED] Lewisburg, PA 17837 (717)523-6800 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
