The original question was:
How do you handle user accounts (>500), in an heterogeneous
environment with more than one system administrator?
- Home directory structure. [/home/{ugrad,grad,faculty,staff}/username]
- UNIX uid assignation. [staff is between 1000 and 1100]
- Distribution of passwd entries.
- Replacement for NIS. [was yellow page]
- Public domain software that you use.
First a few remarks. The Public domain software item intended for the
handling of user account so I will not mention other software. The
question is a difficult one and answering it is a time consuming task,
I which to thank all of you who took the time to answer. You are:
Stacey L C Clark <stacey@ecn.purdue.edu>
Mike Bauer <bauer@cns.ucalgary.ca>
Jacques Beigbeder <beig@frulm63.bitnet>
Michael Helm <mike@inti.lbl.gov>
Jeff Nieusma <nieusma@eclipse.colorado.edu>
Sumant Hattikudur <hattikud@buster.cps.msu.edu>
Tony Dale <tony@cosc.canterbury.ac.nz>
Richard Elling <elling@eng.auburn.edu>
Upkar Singh Kohli <upkar@wsu-eng.eng.wayne.edu>
Ron Vasey <vasey@mcc.com>
G. Roderick Singleton <gerry@jtsv16.jts.com>
Steve Simmons <scs@lokkur.uucp>
Ron Madurski <ron@drd.com>
Mike Raffety <oconnor!porsche!miker@oddjob.uchicago.edu>
Timothy G. Smith <timsmith@sun.com>
Craig Everhart <Craig_Everhart@transarc.com>
Here is a short summary of the most significant answers. I hope none
of the poster will find my editing outrageous, I did my best. I will
be happy to mail the unabridged version to anybody who request it.
The long version is 50K and only mailer trace and repetition of the
original question have been removed.
Purdue U. uses ACmaint, a locally developed package. Others use
SUN's NIS and Automount which does not address the mutltivendor
problem. Some uid assignment policies are presented. The Usenix LISA
IV conference proceedings has 5 papers on the subject, I was there and
I read them, I wanted to know what YOU are doing.
Here goes... "[ ]" shows edition.
From: Stacey L C Clark <stacey@ecn.purdue.edu>
[USE ACmaint]
1.) On the suns home directories reflect the machine (server)
names... ie, goldengate=> pwd
/home/goldengate/stacey
We use automount and NFS to access home directories, so this
provides good information.
2.) uid 's - nothing special is done. We use part of the paswd file
with these descriptors:
Department Code ID
Aerospace Engineering aae a
Agricultural Engineering agen A
Civil Engineering ce C
Classification Codes
Code Definition Code Definition
c Taking classes S ECN System Account
C Course Account t Clerical Staff
f Faculty u Undergraduate Student
g Graduate Student U Unclassified
l Lab Account v Visiting Scholar
N New, unassigned x Special Permission
s Staff
[Example of Passwd entry and finger output removed]
3.) [Distribution] We use an in-house program called "ACmaint"[...]
5.) [SOFTWARE] I believe that the "old" version of ACmaint is going to
be public domain, but the newest version, they are going to copywrite.
it is truly wonderful, because I can change ALL of the person's
accounts with one command. We just use the "honor" system to not tred
on each other's machines. For example, there was some problem in the
beginning with people doing global deletes, but we set up guidelines
and don't do things on each other's machines unless it is a)an
emergency or b)innocuous.
ex. a) possible security problem, need to disable all of a person's
accounts.
b) 2 administrators deal with the same people, finding out
information like phone number changes, make a global change for
the person. (Or if their name is spelled incorrectly, etc.)
[...] The sofware support person in charge of ACmaint is Sam Kimery
(kimery@ecn.purdue.edu)
[More info requested on ACmaint]
ACmaint is only used by root, and it controls all the passwd files.
Some of the commands it uses are:
ah> help
! - execute shell command
# - a comment, the entire line is ignored
= - set a default value or assign a value to a
variable
? - see help
add - add a user to new host(s)
add_group - add user(s) to a group
admin - enter database administration mode
change - change user information by field
change_group - change group information by field
copy - copy a user from one host to other host(s)
create - create a new user
create_group - create a new group
disable - disable an account
edit - edit last command and re-execute
enable - enable a disabled account
help - print help
log - manipulate log files
message - set a message on an account
quit - quit, exit ah
read - execute commands from a file
remove - remove a user from host(s)
remove_group - remove user(s) from a group
show - show user information
show_group - show group information
show_host - show host information
show_hostnum - show host number information
show_sid - show sid information
terminate - remove a user from all hosts
terminate_group - eliminate a group
unmessage - remove a message from an account
[...] "ah" is the front end of ACmaint, and it is very friendly,
prompting you for information if you don't give data for every field
needed...
[Example deleted]
From: Mike Bauer <bauer@cns.ucalgary.ca>
For what it's worth, this is how I have set things up at my site (we
have a heterogenous, all Sun network that is administered by several
people in different labs. Each lab has it's own fileserver and several
dataless clients, but we require that any person should be able to sit
down at any workstation and get an environment identical to any other
workstation):
I use "/home/username" autmounted from the server via a map "auto.home"
this is really nice because every user has to have a unique username
anyways, and this way you don't have to remeber which machine they are
one, which group they are in, etc.
I use NIS, with several backup master servers and the ypxferd high-speed
transfer daemon. It requires that any time a user is added/deleted,
the "administrator" for that particular person must log on to the NIS
master and update the database. Basically, each fileserver in each lab
acts as a slave NIS master, since all users from that lab have their
home directories on the lab's fileserver. In this way, each lab is
independant of others, in the event that a fileserver in another lab
goes down.
[ local software distribution through automount. Deleted ]
Using the automounted /vol and /home directories is a really big plus
in my experience. If a disk is getting too full, I just copy stuff to
another disk, rearrange the auto.vol map entries, and viola! a home
directory or a volume is moved to another fileserver, but the path name
remains exactly the same.
[ Mike send me his map files, they are included in the full report ]
From: beig@frulm63.bitnet
[...me too... multivendor]
For historic reasons, home dir. are /users/groupe_name/user_name. I
put no restrictions on login for all the hosts. So everyone everywhere
can log, thanks to automount. Of course, the directory for the
standard user of each host is hard-mounted.
[Description of local mail aliasing deleted]
To avoid duplication in uid/gid, we assign sets of uid/gid to each
part of the site. For instance, mathematics have uid 100 to 1999,
biology have 2000-3999, etc.
[ local software, distribution of files and of scripts deleted ]
From: Michael Helm <mike@inti.lbl.gov>
I'm not speaking for LBL, just for me, & in part these are observations
of what I see here at LBL.
[home]
I personally use the structure /home/machine/group/username in reality
practice this is now /export/home/machine/unit/group/username but it
looks more or less like the 1st via automounter & symlinks
[uid]
LBL has a uid server based somewhat on the netlib server. Basically,
we seem to be trying to keep login names, id's, group names, id's
constant over the whole lab. This mostly works (people forget to use
it, but it's a good ad hoc solution).
[distribution... NIS]
From: Jeff Nieusma <nieusma@eclipse.colorado.edu>
- we use the automounter and /machine/users/homedir
- we have a unique UID daemon that keeps track of all uids and
usernames so none are duplicated. You must contact "uniqid" to add a
user to a machine to make sure the name/uid is available...
[See also "Uniqname" in LISA IV... uniqname_request@ifs.umich.edu]
- Right now we use rdist to distribute system files.
we have the same passwd file on all machine because of our naming
conventions and use of the automounter
- don't use NIS... You may want to look into using my new libc.so
( let me know if you didn't get the message yesterday. )
- sudo, adduser, addhost, bind, sendmail5.64
If you'd like a better description of any of these, let me know.
[ Sorry for the signature, I will be in touch soon.]
From: Sumant Hattikudur {manager} <hattikud@buster.cps.msu.edu>
[home] /home/machine-name/users = home directories of all users
[uid]
Userids assigned by a central authority. Individual departments have
slots for uids (say 10000- 19999). All system administrators first
check to see whether a user has a password entry in the Central
database. (passwd file of central authority). If this exists, just
grep the entry and insert into local passwd file and make changes to
home-directory, shell etc. If entry does not exist, then use one uid
from locally assigned block of uids, and create a unique username
(again making sure that the central passwd file does not contain such
a username). Once the passwd entry has been created, mail it to the
central authority for inclusion in the central database. This has
just worked fine for us.
From: tony@cosc.canterbury.ac.nz
[me too deleted]
[home]
This is based on a /users/<department_name> structure. Thus, the Computer
Science Dept is under /users/cosc, maths under /users/maths, etc... Under
/users/cosc is /users/cosc/undergrad, /users/cosc/postgrad and
/users/cosc/staff - all separate 500 Mbyte filesystems.
[uid range by dept.]
[distribution achieved through NIS + merging of passwd file]
From: Richard Elling <elling@eng.auburn.edu>
[ 130 Sparc and 150 PC shares NIS, Vax VMS special, 1450+ users]
[/home/{ugrad,grad,faculty,staff}/username]
This is a pretty good setup. It is good to separate undergrads from others
since they tend to do silly things which fill up disks fast. Also, we "clean"
undergraduate accounts between quarters to get rid of the megabytes worth of
duplicate games, GIF files, audio files, etc. We make an additional division
based on department for faculty and grad students: CSE, EE, etc. So our actual
implementation looks something like: /home/u1 (undergrads), /home/cse_h1, etc.
We do not differentiate between faculty/staff/grads for disk allocation. Also,
you will definitely want to use logical names for home directories, not machine
names.
[Use of automounter to share subdir for class. deleted]
[uid]
Each user here has an account which is to be used for instructional purposes.
As a result, there is one master passwd database. We use NIS for this so that
users can change their own passwords easily. To cut down on network traffic
due to NIS updates, we have each NIS server do a ypxfr once per hour to grab
the latest passwd and group databases. The only complaint from the users here
is that it takes up to 1 hour for any password changes to be propagated through
the network. Another affect of this implementation is that all accounts must
be created on the master server so that the databases are kept intact. We have
created shell scripts for adding users which will do everything necessary. As
a result, it takes about 1 minute to type in the user data, generate a new user
id, create the necessary passwd/group/alias entries, and create the home directory.
I initially had each department start at a different base user id. So CSE's
started user id's at 8000 for instance. Upon reflection, this doesn't matter
much. It is more important to get a reasonable group database going. So we
have groups setup for each department, as well as special purpose groups. Also
remember that students tend to change majors and classification (some actually
go on to grad school :-) often, so you don't want to have to change a userid,
when a change of group id can handle it.
[Right on, this is what we call the graduation problem :-)]
[Use of NIS... and love it, and centralization of mail deleted]
Hope this helps... we probably need a usenet group for large
installation system administration...
[I agree]
From: Upkar Singh Kohli <upkar@wsu-eng.eng.wayne.edu>
[intro deleted]
User Accounts:
PATH=/mnt/uranus/files/TYPE/NAME/USER_NAME
All on uranus (580 MB) [ General hard quota: 5 MB; ~116 users ]
Type Dept. Name GID UID (range)
---- ----- ---- --- -----------
Staff - staff 10 11 - 100
Others - other 20 201 - 300
ECE ecef 110 1101 - 1200
MECH mecf 120 1201 - 1300
CIVIL civf 130 1301 - 1400
Faculty CHEM chef 140 1401 - 1500
INDUS indf 150 1501 - 1600
BIO biof 160 1601 - 1700
E-TEC entf 170 1701 - 1800
ECE eces 1100 11001 - 12000
MECH mecs 1200 12001 - 13000
CIVIL civs 1300 13001 - 14000
Students CHEM ches 1400 14001 - 15000
INDUS inds 1500 15001 - 16000
BIO bios 1600 16001 - 17000
E-TEC ents 1700 17001 - 18000
[Distribution of passwd file with ftp and rsh deleted]
From: Ron Vasey <vasey@mcc.com>
Here's a draft of a "policy" our corporate sysadmin committee developed
to provide all users transparent access to "their" files regardless of
where they were located (projects, hosts, fileservers, domains, etc.).
We're completely decentralized, so it's all by voluntary cooperation.
So far it's worked out pretty well.
Most probably not completely applicable in your situation, but it might
provide food for thought. We are heavily into Suns and NFS cross-mounts.
[ Policy by Jim Knutson knutson@mcc.com ]
This is the proposal for a unified UID strategy within MCC.
I There will be an initial allocation of UIDs to each program.
[I still think 1000 per program is enough... JK ]
II Allocations will start at 5000. UIDs between 0 and 4999 will not
be allocated on the assumption that they are already in use.
III UIDs between 0 and 1000 are to be site/program specific...for
system software related UIDs NOT associated with employee logins.
IV All new accounts will be created under the program's allocation
of UIDs for which the person is working (i.e. has the head count).
V Old accounts will be converted to the new UID scheme by...June 1990.
VI ...Employees which work for more than one program are allocated by:
1. mutual agreement between the programs
2. an allocated uid block for temporaries.
[ What about shareholder accounts? JK ]
VII Persons with accounts on more than one machine will use the UID
of the program they work for on all machines.
VIII The first UID of each range will be given a name signifying the
ownership of the range, lest we forget who has what.
IX The highest UID to be allocated will be 32767. Any UID greater
than this or less than 0 is assumed to be system related.
X The following programs will be allocated an initial range of UIDs:
Program 1K Scheme 2K Scheme
ACT 5000-5999 5000-6999
CAD 6000-6999 7000-8999
CP 7000-7999 9000-10999
ES-KIT 8000-8999 11000-12999
PKG 9000-9999 13000-14999
STP 10000-10999 15000-16999
From: "G. Roderick Singleton" <gerry@jtsv16.jts.com>
When I was at Sun, I, as system manager, allocated blocks of 1000 numbers
to each of the admins for using as uids. As far as I know, they're still
using things this way. Let me give you an example; the uids 1-999 are
assigned to admin, 1000-1999 to sales and 2000-2999 to service. If you
can get everyone to agree, this might be a solution. I have to admit, I
used the MCP admin package to manage things but it can e handled manually.
I should also point out that the telcos assinge telephone numbers in this
manner as well so there is a precedent.
Let me know if I can be of more help,
From: Steve Simmons <scs@lokkur.uucp>
From: Ron Madurski <ron@drd.com>
[ Look at the USENIX LISA IV proceedings ]
ACMaint ACinfo-request@ecn.purdue.edu
jrs@ecn.purdue.edu (one of the authors)
UDB - a users database system vasoll@a.cs.okstate.edu
newu: Multihost user setup sps@mcnc.org
[ GAUD: RAND's Group and User Database urban@rand.ORG ]
From: Mike Raffety <oconnor!porsche!miker@oddjob.uchicago.edu>
Use NIS. Too many people knock it who haven't even looked at it. It
really does work quite well.
From: "Timothy G. Smith Technical Consultant Sun Baltimore" <timsmith@sun.com>
[ Get all departments to agree on a site policy... I would love to. ]
From: Craig_Everhart@transarc.com
I'd consider AFS, myself, but I am biased. The installation at
Carnegie Mellon supports about 10,000 users, and of course there are
several administrators.
[The End]
I will try to get the ACmaint package and to come up with a good
policy for my department. The ideal would be a Concordia wide setup
but that may be out of reach. Again thank you all.
Paul
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:00 CDT