Survey ( Administering large numbers of users )

[Russell J Fulton;ccc032u]

I agree that the issues Frank Peter raised all need discussion and that this
group seems a good place to start. I would like to comment on a couple of
point he raises.

fwp1 at CC.MsState.Edu (Frank Peters) writes:

>(2)  Tape device management.  Another capability supported in
>     mainframe operating systems is the ability to gain exclusive
>     control of a tape device, request that a tape be mounted, and
>     release the device when the user is finished with it.  We would
>     like to have this capability in our UNIX environment as well.

This is very important to us particularly as it affect our backup operations
at te moment the operators leave backups running when they leave at midnight
and the tapes are vuneralble to overwriting until they are unmounted in
the morning. We change the protection on all the device drivers but its a
messy solution. I have seen reference to systems that control access to devices
but have never had time to follow them up. I would be interested in hearing
from people who have  used such systems.

>(4)  Userid management.  Most UNIX boxes come with instructions about
>     which several files should be edited to add a user to the system.
>     We are developing programs to manage the addition of userids in a
>     relatively bullet proof way so that non-technical personnel can
>     add new users.  While there are programs to do that around very
>     few address the large system issues such as password file locking
>     and batch additions of large groups of users like a class roll.

This is one area where we may have something to offer. We are currently 
converting out user data base management program from our vax cluster to
our new UNIX system. It is called ZUMP (Zeno Users Management Program,
Zeno was a student computing system we implemented on a DEC 10 about 10
years ago, the name has stuck.) 

Firstly a little background, we are cronically short of staff and hence we
try and distribute as much of the work for administration of our systems
out to the deptartment that use them. When we got the DEC 10 it was our
first interacive machine for student users. Which meant that each of about
5000 students would need individual usercode, diskspace allocation, etc.
Also with that many student at least 10 will forget their password on any 
given day :-) anyway it all adds up to a lot of administration.

What we did was to write a program that managed a hierarchical data base of
users. At the top we had the computer centre, under that we had depts and
under dept we had classes. Each class had a supervisor. 
The program allowed resources, process time, connect time, etc. to be passed
down the tree. It also had the concept of capabilities that could also be
passed on to users below. The most important capability was that of supervision.
Thus we created the departments and gave them supervisor capabilities and 
resources and it was then up to the departments to create the classes and share
out the resources as they saw fit. The departmental supervisor could creat a
class and delegate the supervision of that class to somebody else.

Somebody with supervisor status could move resources around for people under 
them and perform tasks such as setting passwords.

When the DEC 10 was replaced by a vax cluster we move zump to the vaxes and 
exteneded it to take files from the administration computer to automatically
create userids for whole classes. It was also tranlated into C at this time.

We recently replaced our IBM VM system (which is used for research) with a
SGI 4D/240S UNIX system and we decided to start using zump for controlling
administration on it. We hope to have all user administration handled by zump
next year. We now have a basic version going that tracks usage and will
allow supervisors to change password. 

There are issues that still need resolving, inparticular we require users of
our research systems to sign a statement saying that they have read the
'Computer Centre Regs' and agree to abide by them. Thus we cannot completely
distribute the creation of usercodes to the departments. What we are thinking
of doing is having zump create a skeleton user and add another capability
which turns it into a real user. Thus the department does the donkey work of 
entering the details and fowards the signed form to us. We then activate the
userid with a single command.

We have been using zump in various guises for nearly 10 years and have found 
it very satistfactory.

We would be happy to distribute the source to anybody who wanted it but I 
suggest that we wait until the UNIX version has stabalised.

Has anybody else tried anything like this? 
--