UNIX System Administration Handbook - Evi Nemeth [61]
Make sure the startup files contain defaults that are reasonable for unsophisticated users. However, don’t confuse users by “protecting” them from UNIX; entries such as
alias dir ls -l
alias rm rm -i
alias cp cp -i
are in poor taste.
Depending on the user’s shell, /etc may contain system-wide startup files that are processed before the user’s own startup files. For example, all of our example systems’ Bourne shells (sh) read /etc/profile before processing ~/.profile. For other shells, see the man page for the shell in question for details.
The command sequence for installing startup files for the new user tyler would look something like this:
# cp /usr/local/lib/skel/.[a-zA-Z]* ~/tyler
# chmod 644 ~tyler/.[a-zA-Z]*
# chown tyler ~tyler/.[a-zA-Z]*
# chgrp staff ~tyler/.[a-zA-Z]*
Note that we cannot use
# chown tyler ~tyler/.*
because tyler would then own not only his own files but also the parent directory “..” (/home/staff) as well. This is a very common and dangerous sysadmin mistake.
Setting the user’s mail home
It is convenient for each user to receive email on only one machine. This scheme is often implemented with an entry in the global aliases file /etc/mail/aliases or the sendmail userDB. See Chapter 19 for general information about email; the various ways to implement mail homes are discussed starting on page 549.
Editing the /etc/group file
To continue the processing of the new user tyler, we should add his login name to the list of users in group 100, since that was the default group to which we assigned him in the /etc/passwd file. Strictly speaking, tyler will be in group 100 whether he is listed in /etc/group or not, because his passwd entry has already given him this membership. However, this information should be entered in /etc/group so that you always know exactly which users belong to which groups.6
Suppose we also wanted to put tyler in the group “wheel”. On some systems, users must be in this group to use the su command. We would simply make the following changes to /etc/group:
wheel:*:0:root,evi,garth,scott,trent,tyler
csstaff::100:lloyd,evi,tyler
Setting disk quotas
If your site uses disk quotas, you should set quota limits for each new account with the edquota command. edquota can be used interactively, but it is more commonly used in “prototype” mode to model the quotas of the new user after those of someone else. For example, the command
# edquota -p proto-user new-user
sets new-user’s quotas to be the same as proto-user’s. This way of using edquota is especially useful in adduser scripts.
Since disk space is cheap these days, we’re not big proponents of disk quotas. They often seem to cause more problems than they solve, and they impose an additional support burden on administrators. Back when we used quotas (many years ago), we maintained several accounts that existed only to serve as user quota prototypes.
Verifying the new login
To verify that a new account has been properly configured, first log out, then log in as the new user and execute the following commands:
% pwd /* To verify the home directory */
% ls -la /* Check owner/group of startup files */
You will need to notify new users of their login names and initial passwords. This is also a good time to point users towards additional documentation on local customs if you have any.
If your site requires users to sign a written contract, be sure this step has been completed before releasing the account. This check will prevent oversights and strengthen the legal basis of any sanctions you might later need to impose.
See page 782 for more information about written user contracts.
Be sure to remind new users to change their passwords immediately.
6.7 REMOVING USERS
When a user