response 3 of 65:

Apr 28 03:56 UTC 2003

(my $.02:  inbound FTP probably isn't as useful as it once was, and likely
only serves to bring things onto Grex that won't necessarily make their
way off.  outbound FTP, however, presumably remains useful for moving
archives, mail, etc. off of Grex.  is it possible to affect one process
without affecting the other?)

(other thought:  if disk quotas will be available on the next Grex, would
it make sense to suspend FTP until that time, instead of permanently?)

(BTW, what's involved in manual disk policing?  I'm curious about
volunteering, if only for the interim.)

response 5 of 65:

Apr 28 05:35 UTC 2003

I do use ftp a lot to handle my files, but I could certainly live
with outbound-only ftp, for what that's worth.

response 7 of 65:

Apr 28 05:43 UTC 2003

I vote for turning off inbound FTP as an interim measure until the 
new machine is installed.

response 9 of 65:

Apr 28 10:53 UTC 2003

But ultimately it's probably time for some new staff
members to pick up some of the slack despite our
moving to a new machine.

I can think of one person immediately who would be 
a good fit.  I'm sure there must be others.

response 11 of 65:

Apr 28 12:14 UTC 2003

Regarding #6; It's not terribly difficult to do either #4 or #3; one
can play around with scripts that `wrap' the current FTP and web
clients, and/or quotas.  Could someone work around that?  Perhaps;
but it stops most of the script kiddies, which gives the biggest
bang for the buck.

As for moving email to home directories.  The benefit is that you
(1) eliminate a partition, and (2) aren't left with a situation
where you have $n$ hundreds of megabytes of free space in the mail
partition, but nothing available on the home directory disks.  It
seems pretty silly to have 700+ megs free in /var/spool/mail if
home is filling up.

But speaking of this....  None of the home directory partitions are
more than 45% full.  It hardly seems like we're running out of disk
space, the sky is falling, we have to fix something RIGHT NOW.

response 13 of 65:

Apr 28 13:38 UTC 2003

My recommendation would be to do the same thing on the Sun that we are
planning to do on the new system:  turn on the operating system's hard
disk quotas.

There is a rumor that there are bugs in the quota system in SunOS. 
However, I did some extensive web searching a few years back and
couldn't find a single reference to this.  Lots of people using it, but
none reporting problems.  I suspect these bugs were in some older
version of SunOS and are now long gone.  If there are bugs, likely
they'd be mild enough to be able to live with until we get to the new
system.

Disk quotas would be somewhat negotiable.  If you have some plausible
reason to be using more disk space than the normal quota, contact staff
and we'll increase it.   I would expect us to be fairly liberal with
this, without eggdroppings, we actually do have a *lot* of disk space.

I might suggest that when we do this, we set the hard quotas to
something like double our current limit.  We actually have lots of
disk - there are several 4Meg drives connected to Grex that just need to
be turned on and formatted to make new user partitions.  This wouldn't
help as long as we have no quotas, because the eggdroppers will eat up
any amount of new disk in no time at all, but once we have hard quotas,
it would allow us to set those quotas a bit higher.

response 15 of 65:

Apr 28 16:17 UTC 2003

I think the ultimate solution is going to be quotas.  If we need to turn
off FTP in the interim I'd have no problem with that.  FTP is pretty
much an obsolete protocol anyway.  These days I almost always use scp
instead.

response 17 of 65:

Apr 28 23:13 UTC 2003

What I've heard regarding quotas on our current OS is not that
they're buggy, but rather that they'd seriously impact performance.
Offhand I can't cite a source for this.  I'd be in favor of trying
them at this point -- if they work, they're probably the simplest
solution, and if they cause too many new problems, we can always
back off.

response 19 of 65:

Apr 29 03:39 UTC 2003

Thanks, Valerie (and Scott), for all your hard work keeping the system
usable.

response 21 of 65:

Apr 29 05:18 UTC 2003

   My personal best in terms of reclaming was about 360M; this happaned
when a new version of either acidblood or psybnc came out and we had
hordes of them streaming in, constantly.

   We do not want to implement disk quotas on SunOS.  If we mess anything
up, we'll pay for it in terms of staff time on a new emergency.

response 23 of 65:

Apr 30 15:16 UTC 2003

uh oh