| Converting Existing UNIX Accounts with uss | ||
|---|---|---|
 | Chapter 11. Creating and Deleting User Accounts with the uss Command Suite |  |
| Converting Existing UNIX Accounts with uss | ||
|---|---|---|
| | Chapter 11. Creating and Deleting User Accounts with the uss Command Suite | |
This section discusses the three main issues you need to consider if there are existing UNIX accounts to be converted to AFS accounts.
As previously mentioned, AFS users must have an entry in the local password file on every client machine from which they access the AFS filespace as an authenticated user. Both administration and use are much simpler if the UNIX UID and AFS UID match. When converting existing UNIX accounts, you have two alternatives:
Make the AFS UIDs match the existing UNIX UIDs. In this case, you need to assign the AFS UID yourself as you create an AFS account:
If using the uss add command, include the -uid argument.
If using the uss bulk command, specify the desired UID in the uid field of the add instruction in the bulk input file.
Because you are retaining the user's UNIX UID, you do not need to alter the UID in the local password file entry. However, if you are using an AFS-modified login utility, you possibly need to change the password field in the entry. For a discussion of how the value in the password field affects login with an AFS-modified login utility, see Creating Local Password File Entries with uss.
If now or in the future you need to create AFS accounts for users who do not have an existing UNIX UID, then you
must guarantee that new AFS UIDs do not conflict with any existing UNIX UIDs. The simplest way is to set the
max user id counter in the Protection Database to a value higher than the largest
existing UNIX UID. See Displaying and Setting the AFS UID and GID Counters.
Change the existing UNIX UIDs to match the new AFS UIDs that the Protection Server assigns automatically.
Allow the Protection Server to allocate the AFS UIDs automatically as you create AFS accounts. For instructions on creating a new entry for the local password file during account creation, see Creating Local Password File Entries with uss.
There is one drawback to changing the UNIX UID: any files and directories that the user owned in the local file system before becoming an AFS user still have the former UID in their owner field. If you want the ls -l and ls -ld commands to display the correct owner, you must use the chown command to change the value to the user's new UID, whether you are leaving the file in the local file system or moving it to AFS. See Moving Local Files into AFS.
Existing UNIX accounts already have an entry in the local password file, probably with a (scrambled) password in the password field. You possibly need to change the value in the field, depending on the type of login utility you use:
If the login utility is not modified for use with AFS, the actual password must appear (in scrambled form) in the password field of the local password file entry.
If the login utility is modified for use with AFS, choose one of the acceptable values, each of which affects the login utility's behavior differently. See Creating Local Password File Entries with uss.
If you choose to place an actual password in a local password file entry, then you can define a dummy password when you use a template file E instruction to create the entry, as described in Creating One-Line Files with the E Instruction. Have the user issue the UNIX password-setting command (passwd or equivalent) to replace the dummy with an actual secret password.
New AFS users with existing UNIX accounts probably already own files and directories stored in a machine's local file system, and it usually makes sense to transfer them into the new home volume. The easiest method is to move them onto the local disk of an AFS client machine, and then use the UNIX mv command to transfer them into the user's new AFS home directory.
As you move files and directories into AFS, keep in mind that the meaning of their mode bits changes. AFS ignores the second and third sets of mode bits (group and other), and does not use the first set (the owner bits) directly, but only in conjunction with entries on the ACL (for details, see How AFS Interprets the UNIX Mode Bits). Be sure that the ACL protects the file or directory at least as securely as the mode bits.
If you have chosen to change a user's UNIX UID to match a new AFS UID, you must change the ownership of UNIX files and directories as well. Only members of the system:administrators group can issue the chown command on files and directories once they reside in AFS.
| |  | |
| Creating Local Password File Entries with uss |  | Constructing a uss Template File |