Once upon a time, some members of the technical staff strove to solve the problem of disk usage among the hordes of introductory CS students. Their simple solution was fsh: the shell that lets you work, but insists you clean up when you are done. fsh has served the department well for several years but has a few shortcomings.
Along with fsh, in the times of old, policy was created around the idea of a "course account." These were handy, but quickly piled up upon a new CS concentrator: cs016185, cs031067, cs022113 (code space, what's code?), cs032056, cs141089, cs051075, etc until the user received a "named account." Only in the past year were "modules" (docs in ps and pdf format) introduced to standardize account setup and allow courses like CS32 do without a "course account" for every user.
Now, to address troubles with fsh, do away with many email addresses never-checked, and create new bureaucracy (while reducing the old), tstaff is proud to introduce "The 1-Account(TM)." The 1-Account(TM) will forever erase the troublesome restore requests (you keep your stuff!) and other juggling that multiple accounts creates. From now on, all CS accounts will last for the duration of a student's Brown career. They will become active when needed (courses, research, employment in the dept) and will have fluctuating usage limits depending on account status. TAs will have access to relevant source code directories.
Enter "the identity system." Each user will get identities based on what s/he is doing in the department. Identities mainly exist to dole out resources. Our first use is to coordinate disk space limits with account status.
Limits will be enforced by fsh. Login is denied if the user is over 'fsh usage.' Usage is determined by the identities a user possesses. fsh2 has a limited shell that pops up if you are over your limit to facilitate account cleanup (previously, access to someone else's account was necessary for an 'su').
Hard quotas will go to 100 megabytes to contain any out-of-control activity and allow rapid access to current usage information via the quota system.
Tstaff is still accepting suggestions for identities which will receive disk space. Currently we anticipate:
To beta-test this new system, tstaff is calling for volunteers. Each will receive /usr/local/bin/fsh2 for a shell and be added to the identity map with some identities granting some amount of disk space.
A new, mandatory mapping is also being created called 'brownid'. Eventually, we hope to use this mapping for kerberos. Anyone who wants to test this system needs to send us their CIS/Brown netID and say "give me fsh2!" We'd also like to hear what identities you think you should have.
Most people won't need to modify their dot-files; the existence of a .fshshell file lets you choose any shell from /etc/shells. Unsupported shells should be started from /bin/csh or /bin/sh. Finger will soon support the .fshshell file.
Questions/comments should go to software@cs.brown.edu. Volunteer offers should go to admin@cs and serious problems (requiring immediate attention) should go to problem@cs.
See the fsh beta page for more information.
tstaff wanted one account per person but knew that each person was different. Rather than adding accounts to a person, we decided to add privileges to just one account. The identity system looks vaugely like the unix group database but is much more generic. It helps to think about being "given" an identity as opposed to being "added to" or "being a member of" a unix group.
Here is the ypmap for identities: testing concentrator cs17s cs017student cs15s cs015student avd15 cs015student cs5s cs005student,concentrator vbg tstaff,grad stp ta,tstaff,ugrad,concentrator scs tstaff,ugrad,spoc,cs167student,concentrator mgb concentrator,ugrad,rtrsch,fshbeta jsb tstaff djm DLT,tstaff,fred kd concentrator,ugrad,sprrsch,fshbeta dl tstaff,spoc,cs017ta,concentrator,cs295student
Most of the entries are semi-ficticious, but the are used to create the usage map (some identities, but not all, give you disk space):
testing 5000 avd15 1500 vbg 22500 scs 28000 jsb 520000 djm 20000 dl 25000 cs17s 1000 cs15s 1500 cs5s 6000 stp 26000 mgb 15000 kd 15000
The above were fetched with ypcat -k
Identities can be used for just about anything. tstaff hopes to automate unix group addition and quota changes just by adding an identity. For example, in the future, being given the identity "illus" would automatically put you in unix groups graphics & illus, as well as giving the user any identities necessary to log into special graphics machines or adding the user to a mailing list.
Some identities, such as 'ugrad' will not grant any permissions, but simply identify an account. C and perl libraries will be available to access the information, but yp maps contain most of the data directly as shown above. A new version of 'sunlist' is planned which will leverage the identity database to show why the lab is full. Other identities may be used by department groups where unix groups might have been used before. The system can be secure and there is no limit to the number of identities you can have (like there is for the number of groups you can be in).The meta-TA has been working to insure that courses no longer need access to dotfiles beyond a module that is sourced. Each course will now emphasize the shell a bit more because the module affects the PATH and the shell is where that matters. Because students will keep accounts, we expect them to care a little bit more about them and learn a bit more about them. Most courses will have a "csXXXsetup" script that will change the module load line in the dotfiles and create a /u/user/src/csXXX directory that is in the TA group for the course with permissions at least 750. Permissions on /u/user and /u/user/src will be most likely be 711 so a TA can get to the src directory without the student having to 'su' (though this may remain the preferred way to access code if code has to be accessed at all.