response 32 of 73:

Dec 31 05:00 UTC 2003

Is that supposed to be 2 and 3 MB, Ryan?

response 40 of 73:

Jan 7 10:23 UTC 2004

quotas and e-mail need special consideration.  without quotas on the
mail spool abusers will just e-mail themselves things, perhaps even work
within the spool if it's user writable (i forget if obsd uses a mode
1777 spool).  but if the spool has a quota then there is a way for a
user's quota to be exceeded which is not interactive and thus invisible
to the user, and in fact happens as a result of forces typically outside
their control, i.e., spam, worms and abusive action can disable e-mail
reception -- staff could not even deliver a warning without an enhanced
remote access mechanism or some fancy footwork quota-wise.

as it happens i favor having quotas over not having them, but you need
sufficient status visibility in all reading modes.  unfortunately such
visibility is not available by default in popular and free tools, thus
would require some custom patches or spending money.  these days spam/
worm containment with a much higher (perhaps shared) quota is also
necessary, but again care is required otherwise abusers will try to
store things in the quarantine.

response 42 of 73:

Jan 24 15:03 UTC 2004

Can you put a limit on the number of new items a user can create in one day,
for instance 3 or 5?  I don't see why you need to limit the number of files
if you are limiting disk usage already.

response 44 of 73:

Jan 24 17:23 UTC 2004

Ryan is correct - under Unix, each disk partition has a set maximum
number of files, equal to the number of slots in the "inode table".
So a possible denial-of-service attack would be for a user to fill
up the inode table.  Then no other user on that disk partition
could create new files, even if there were plenty of free space
on the disk.

So it sounds like we should set a maximum number of files per user.
I'm assuming the quota system lets us do that.  On NextGrex as
currently configured, the user partitions /a and /c combined have
over 5 million inodes, so even being generous and assuming that
we grow to 20000 users with an average of 50 legitimate files
apiece, that would take up less than 20% of the inode space.
So the limit could be pretty generous and still avoid a problem.
If we set the maximum at, say, 5000, a twit would have to create
a few hundred accounts to run the system out of inodes.  That's
a pretty good deterrent, and even if they persisted and tried,
the activity would be noticed and stopped long before the
limit was reached.

response 46 of 73:

Jan 24 20:29 UTC 2004

I think I have between 50 and 100 files which I thought was a lot.
2M disk space and 1000 files would be 2K average per file - do people have
that many small files?

response 48 of 73:

Jan 25 02:59 UTC 2004

compilations can create a "lot" of files, but any compilation that would
create that many files would surely hit a 2MB limit before an inode limit.
someone might have a one-file-per-entry type of webboard, which could create
lots of small "ROTFL!!!" and "LOL OMG WOT U SAY?" response files.  there's
probably a few other practical-ish cases where this would happen, but not that
many.

response 50 of 73:

Jan 25 03:34 UTC 2004

Like disk space, inodes have both soft and hard limits.  How about 4000 soft
and 5000 hard?

response 52 of 73:

Jan 25 14:15 UTC 2004

Big packages like eggdrop tend to use up a bit more than 1Mb, and have
hundreds of files even before compilation.

response 54 of 73:

Jan 25 17:21 UTC 2004

I support the higher limits proposed by me.  :)

My philosophy in setting limits is to set them so as to avoid system
problems but to make them as generous as possible within that constraint.
What do we gain by making them any smaller?