Adding users to the SP/2

Before grokking this document, please read the first few sections of the Introduction to the SP/2 document. It contains important background knowledge.

AFS and the SP/2

Because of the way
  1. The department uses Kerberos and AFS
  2. Authentication is implemented on the SP/2
the first thing to take care of when adding a user to the SP/2 is to ensure that they are installed in the AFS kerberos database. Two steps are necessary to do this.

Database Update

The database must be changed ... the "AFS" flag for the user must be set. While you are at it, you should add sp2-cw to the list of hosts the user has an account on. Ask Jerel or Jim for help about this.

AFS Kerberos Update

If the user doesn't already have an AFS kerberos instance, one will need to be created for them. To do this you will need the password for afsadmin. Note if you wait overnight, the database update will do the AFS instance creation auto-magically. Then, all you have to do is set their AFS password with kas's setpassword command. 
me% /usr/afsws/etc/kas -admin afsadmin
Administrator's (afsadmin) Password: <afsadmin's password>
To determine if the user already has an AFS Kerberos instance use the examine command. 
ka> examine username
If they don't exist in AFS, you'll see the following: 
examine: user doesn't exist getting information for username.
and you will need to use the create command to create their instance, and set their initial password. You need the user present to do this, or you can use the setpassword command to do it later. 
ka>> create username
initial_password: 
Verifying, please re-enter initial_password:

If the user is already present in the AFS Kerberos database, you'll see the following instead: 

User data for username
  key (0) cksum is #########, last cpw: <some date here>.
  password will never expire.
  An unlimited number of unsuccessful authentications is permitted.
  entry never expires.  Max ticket lifetime 25.00 hours.
  last mod on <some date here> by <somebody>
In this case the user is already to go. You may need to run kas's setpassword command if the user doesn't remember their AFS Kerberos password. I advise them to make it the same as their departmental Kerberos password, as there are just too many passwords involved with using the SP/2.

Adding the user to the SP/2

I have a few notes to make about the SP/2 before I demonstrate how to add a user.
  1. Only the SP/2 Control Workstation has AFS installed. One implication of this is that users can only log into the Control Workstation. To login to a node, they must use the SP/2 parallel tools.
  2. All SP/2 users must have their home directory on the SP/2 Control Workstation. Due to the way the SP/2 parallel tools work there is no other alternative at this time. A user can access their files through AFS on the CW, but it can't be their home directory.
  3. The SP/2 usurps /u for its own purposes, for use with the SP/2 parallel tools. To refer to a user's AFS directory, the qualified path of /afs/cs.wisc.edu/u/u/s/username.

SMIT

The tool of choice for adding users to the SP/2 is smit, the System Management Interface Tool. The various smit capabilities implement creating users on all SP/2 nodes.

To execute smit to add users to the SP/2, you must be logged in as root. Smit uses a hierarchically structured set of menus to direct the user to leaf nodes where functions can be executed. To shortcut the description of the smit menu systems, I'll illustrate paths through the menu system with '/' seperated menu item names. For example 

Security & Users / Groups
will descend to a node of the tree which allows you to select actions to perform on unix groups.

To select a menu item, move the hilite cursor to the menu item with the arrow keys, and hit return.

To backup a level in the menu hierarchy, or to STOP during the filling out of an action menu, use F3 or the ESC+3 key sequence. To exit smit at any time, F10 or ESC+0 may be used.

Once inside an "action" menu, a menu which actually does something, return will EXECUTE the entire menu. Be sure to use the arrow keys to move between the fields to be filled in on the menu. I mention this, as I constantly keep forgetting about it.

Once return is hit in an action menu, smit will do the desired task. When it is complete it will present a new page that has any output the commands smit uses may have generated. Once this "OK" page is shown, you can backout of the menu structure or exit smit.

Preliminary Information

You will need the following information to add users to the SP/2. You can collect this info either from the CS Departmental Database, or from the /etc/passwd database on a system which uses AFS.
  1. Username and Uid
  2. Groupname and Gid
  3. Fullname

Adding a group

The first step to perform when adding a new user is to add their group to the group database. To do this, use the following path through smit: 
Security & Users / Groups / Add a Group
Fill in the fields for Group Name and Group ID from the data you gathered. Leave the other fields with their default values. Do Not add the username to the USER list field for the group.

Adding a user

Once the group or groups a user will need is inplace, the user may be added. To do this, navigate to the following action menu: 
Security & Users / 9076 SP Users / Add a User
Fill in the fields for User NAME, and User ID from the information you have gathered. Set the PRIMARY group to the user's group (same as the username). Initialize the Secondary GROUPS field to any other groups the user may need. Usually this is not needed.

The HOME directory field should be set to /home/username. It will be automagically changed to something else as the user is added, so do not be alarmed if you notice that change.

The Initial PROGRAM should be set to /bin/csh and User INFORMATION to the user's fullname from the gecos field.

Hit return, wait, and voila! the user is added to the SP/2.

Adding the user to the SP/2 Kerberos Database

The user needs to be present for this stage so they can set their password. An alternative is to set the password to some string, and tell the user to change it when they login. The information you will need to perform this step is the username, their password, and the master key to the SP/2's kerberos database.

The user must be added to the SP/2's Kerberos Database so they can use the SP/2's parallel tools. This isn't done by smit. Instead, a Kerberos tool, kdb_edit is used to directly modify the database. kdb_edit is fairly straight forward to use, so I'll just present a script of a session as an example. Use the default values for every option, and use a null instance.

When you are done adding users to the Kerberos database, generate an EOF (C-d) at the Principal name: prompt. 

sp2-cw# /usr/kerberos/etc/kdb_edit
Opening database...

Enter Kerberos master key: <sp/2 kerberos master password>

Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: username
Instance:

<Not found>, Create [y] ? 

Principal: username, Instance: , kdc_key_ver: 1
New Password: <the users's password>
Verifying, please re-enter 
New Password: 

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? 
Max ticket lifetime [ 255 ] ? 
Attributes [ 0 ] ? 
Edit O.K.
Principal name: ^d

Update /etc/group on the Nodes

The SP/2 tools have a problem updating /etc/group on the nodes. I hope to fix the, but in the meantime ... ~bolo/SP2/update_group will distribute changes to /etc/group from the control workstation to the nodes. It must be run as root, and valid kerberos tickets for the root.admin principal. 
sp2-cw# /usr/kerberos/bin/kinit root.admin
Kerberos Initialization for "root.admin"
Password: 
sp2-cw# ~bolo/SP2/update_group
/usr/kerberos/bin/rcp /etc/group sp2-01:/etc/group
...
SP/2 Information
Bolo's Home Page
Last Modified: Tue Dec 19 15:09:01 CST 1995
bolo (Josef Burger) <bolo@cs.wisc.edu>