ADDUSER(8)                                                          ADDUSER(8)



NAME
       adduser - procedure for adding new users

DESCRIPTION
       A  new  user must choose a login name, which must not already appear in
       _/_e_t_c_/_p_a_s_s_w_d_.  An account can be added by editing a line into the passwd
       file;  this  must  be  done with the password file locked e.g. by using
       _v_i_p_w(8).

       A new user is given a group and user id.  User id’s should be  distinct
       across a system, since they are used to control access to files.  Typi‐
       cally, users working on similar projects will be put in the same group.
       Thus  at  UCB  we  have groups for system staff, faculty, graduate stu‐
       dents, and a few special groups for large projects.   System  staff  is
       group “10” for historical reasons, and the super-user is in this group.

       A skeletal account for a new user “ernie” would look like:

              ernie::235:20:&
              Kovacs,508E,7925,6428202:/mnt/grad/ernie:/bin/csh

       The  first  field  is  the  login  name “ernie”.  The next field is the
       encrypted password which is not given and  must  be  initialized  using
       _p_a_s_s_w_d(1).   The  next  two fields are the user and group id’s.  Tradi‐
       tionally, users in group 20 are  graduate  students  and  have  account
       names  with  numbers  in  the  200’s.  The next field gives information
       about ernie’s real name, office and office phone and home phone.   This
       information is used by the _f_i_n_g_e_r(1) program.  From this information we
       can tell that ernie’s real name is “Ernie Kovacs” (the & here serves to
       repeat “ernie” with appropriate capitalization), that his office is 508
       Evans Hall, his extension is x2-7925, and this his home phone number is
       642-8202.   You  can modify the _f_i_n_g_e_r(1) program if necessary to allow
       different information to be encoded in this field.  The UCB version  of
       finger  knows several things particular to Berkeley - that phone exten‐
       sions start “2-”, that offices ending in “E” are in Evans Hall and that
       offices  ending  in  “C”  are  in Cory Hall. The _c_h_f_n(1) program allows
       users to change this information.

       The final two fields give a login directory and  a  login  shell  name.
       Traditionally,  user  files  live on a file system different from /usr.
       Typically the user file systems are mounted on  a  directories  in  the
       root  named sequentially starting from from the beginning of the alpha‐
       bet, eg /a, /b, /c, etc.  On each such file system there are  subdirec‐
       tories  there  for each group of users, i.e.: “/a/staff” and “/b/prof”.
       This is not strictly necessary but keeps the number of files in the top
       level directories reasonably small.

       The login shell will default to “/bin/sh” if none is given.  Most users
       at Berkeley choose “/bin/csh” so this is usually  specified  here.  The
       _c_h_s_h(1)  program allows users to change their login shell to one of the
       shells in the approved list given in /etc/shells.

       It is useful to give new users some help in getting started,  supplying
       them  with a few skeletal files such as _._p_r_o_f_i_l_e if they use “/bin/sh”,
       or _._c_s_h_r_c and _._l_o_g_i_n if they use “/bin/csh”.  The directory “/usr/skel”
       contains skeletal definitions of such files.  New users should be given
       copies of these files which, for instance, arrange to use _t_s_e_t(1) auto‐
       matically at each login.

FILES
       /etc/passwd         password file
       /usr/skel           skeletal login directory

SEE ALSO
       passwd(1), finger(1), chsh(1), chfn(1), passwd(5), vipw(8)

BUGS
       User  information  should  be stored in its own data base separate from
       the password file.



4th Berkeley Distribution        May 23, 1986                       ADDUSER(8)