dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (11/19/88)
In a previous posting I made a reference to our disk quota system. Craig Paul <paul@kuhub.cc.ukans.edu> asked about it so I will describe it. We have a 100+ node network with 17 gigabytes of disk but we also have 2000+ student users. Thus the need for a quota system. At the 1986 ADUS conference, Christa Decker gave a presentation on a disk quota system that she had devised as the sys_admin at Bucknell University. We took her ideas as a starting point and adapted them to fit our system. This has been a continual project, improving and adapting, fixing bugs that show up as our system grows. It works, sort of, but it requires a major support effort. Here are the basic elements of it: Periodically the "watchdog" program runs (we run it every night). It reads the registry to find the home directory of every user. It skips those users listed in an exemption table. For each non-exempt user it finds the disk space used in the home directory with '/systest/lst'. The quota for each user is determined by a set of tables. (We organize our accounts based upon the group: faculty, staff, student, ...) If the user is above his/her quota then action is taken. A first time offender is logged and a login warning message is put in his/her account. If the offense continues for more than a preset grace period, (we give 3 days) the account is frozen. An account is frozen by changing the ACLs on all its directories. The user's "p" and "cal" rights are removed, just the "d" and "rse" rights are left. This prevents the user from creating any new objects, he/she can only read or delete them. The "unfreeze" program is used to extricate frozen users. The unfreeze program first checks the user's disk usage to see if they are below quota. If so, it removes them from the log and restores their directory owner ACLs. This system has some major limitations: It assumes that a user can only create objects (files & directories) in their home directory. It must be run set-uid to root. It requires support by a skilled programmer. When it runs it puts a major load on the system. It does not prevent a user from filling up the disk, it catches them after the fact. It depends upon pre-SR10 ACLs, it will be broken at SR10. It uses some undocumented system calls (unreleased interfaces) that are NOT supported by Apollo. We use it because we've not found anything better and it works, sort of, at our site. It does prevent the disks from becoming completely full and it keeps the backups from becoming obscene. We are trying to find a work-around for it at SR10, we probably won't go to SR10 until we do. Because of the previously listed limitations (particularly the last one) I am reluctant to hand out copies of these programs. I will be happy to talk to people about what we did and provide suggestions. Dave Funk University of Iowa