HEDRICK@RUTGERS.ARPA (06/29/84)
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> We have a Pyramid Unix system which will be populated mostly by students doing coursework. A given student may be taking more than one course. We would like to be able to know how much time each course is using (so we can sit on faculty who give unreasonable assignments). On the DEC-20, there are three separate object: users directories accounts Each student has his own userid and directory. Each course has an account. When a student logs in, he specifies both. We are not so naive as to believe we can get entirely accurate data from students on which project they are working on, but the results seem fairly reasonable. As far as I can see, Unix does not have anything like an account. We are considering two approaches. I wonder whether anyone has a better idea, or sees any problems with these approaches: 1) add account strings to Unix: Will involve modifying LOGIN to ask for an account, somebody (the shell?) to remember which was specified, and whoever writes the WTMP file at logout to add an account field to WTMP. Then of course every program that plays with WTMP, and all the accounting software, must be changed to know about the account. 2) encode it in the user name. If Smith is registered for courses 431 and 510, the password file will contain smith:*:123:1000:John Smith:/usr/smith 431.sss::123:431:John Smith:/usr/smith 510.sss::123:510:John Smith:/usr/smith Where sss are his initials. The idea is that he will log in by using his course and initials, but the directory and mail will all use the real name. As all incarnations of a user have the same uid, he will have access to all files at all times. We will have to modify MAIL to that all incarnations of a user read the main mail file. That's the only change I see so far, except to the program that prints our final usage reports. -------
dan@haddock.UUCP (07/11/84)
#R:sri-arpa:-146000:haddock:16700028:000:1019 haddock!dan Jul 9 21:27:00 1984 Accounts for courses: solution (1), adding account strings, is too much work. Solution (2) isn't bad except for the 8-char limit on user names (unless Pyramid has fixed that). Better than either, though, is to use UNIX groups. The accounting software already knows about groups, so you won't have to change it (except to add better reporting options if you want). The student can change from one course assignment to another just by saying 'newgrp', and/or change the default group assignment in /etc/passwd (through a suitable program, of course--if you don't have one already, it's easy to write). Groups have the additional advantage that if you want, you can enforce their use by making key files for each course readable only by the appropriate group. If you're already using groups for something else (like separating students from teachers), it doesn't matter; since Pyramid has 4.2bsd, it supports multiple simultaneous groups. Thus a professor can be in groups "staff" and "algorithms" at the same time.
mwm@ea.UUCP (07/13/84)
#R:sri-arpa:-146000:ea:13400008:000:987 ea!mwm Jul 12 17:48:00 1984 We had a similar problem: we do consulting work, and need to charge CPU time back to clients (Gotta pay for the VAX somehow). We used the group codes to handle it. Everybody logs into a program called project, which asks for an account number to bill this session to. It then sets the group ID to that number (after checking that it's a valid number) and execl's a shell. Project can also be run interactively to fire up multiple shells to work on different projects, etc. The only thing after that was a program to read /usr/adm/acct (thanks to uokvax!raymond), and an awk script to turn what falls out of the program into hours. The problem is, you either have to be running a system with mutli-group processes (4.2), or give up group protection for the ids involved. We run 4.2 so the project program would have to be modified to handle non-multi-group systems. This all works with no changes to the system, etc. I'll post/mail the three programs involved if someone asks. <mike