| [ Team LiB ] |
|
Adding User AccountsBefore you add users to the network, the users' systems must be installed and configured. When appropriate, NIS+, LDAP, or NIS software should be installed and running on the network. Adding users so that they can log in and start working has two parts: setting up the user account and providing the user with a working environment. When you set up a user account, you perform the following tasks.
The next sections provide background information. Refer to the Solaris Management Console Tools book for detailed instructions on how to create and manage user accounts in a networked environment. Editing the /etc/passwd FileYou must be root or have the appropriate rights before you can edit the local /etc/passwd file. You need the following information for each user you plan to add.
User ID NumberA UID is always associated with each user name and is used by systems to identify the owners of files and directories and to identify the user at login. If you create user accounts for a single individual on more than one system, always use the same user name and UID. In that way, the user can easily move and copy files between systems without ownership problems. A UID must be a whole number less than or equal to 2147483647. The maximum UID was increased from 60000 to 2147483647 starting with the Solaris 2.5.1 release. UIDs are required for both regular user accounts and special system accounts. Table 33 lists the UIDs that are reserved for user accounts and system accounts.
CAUTION. Be careful when using UIDs in the 60000 to 2147483647 range. These numbers do not have full functionality and are incompatible with many Solaris subsystems. See Table 34 for more information. Even though UIDs 0 through 99 are reserved for use by system accounts, you can add a user with one of these UIDs. You should not, however, use these UIDs for regular user accounts. Use the numbers 0 through 99 to assign system accounts, uucp logins, and pseudouser logins. Large User IDs and Group IDsPrevious Solaris Operating Environments used 32-bit data types to contain UIDs and GIDs. UIDs and GIDs were constrained to a maximum useful value of 60000. The limit on UID and GID values has been raised to the maximum value of a signed integer, or 2147483647 starting with the Solaris 2.5.1 release. Table 34 lists the interoperability issues with the Solaris Operating Environment products and commands.
Table 35 summarizes the limitations of using large UIDs and GIDs.
Creating a Home DirectoryThe home directory is that portion of a file system that is allocated to an individual user for storing private files. The amount of space you allocate for a home directory may vary, depending on the kinds of files the users create and the type of work they do. You should probably allocate at least 15 Mbytes of disk space for each user's home directory. A user's home directory can be either on the local system or on a remote file server. In either case, by convention the home directory is created as /export/home/ login-name. Note that this convention is new with the Solaris Operating Environment. The server name is no longer included as part of the user's home directory path. On a large server that supports a number of users' home directories, there may be a number of directories under /export—such as home1, home2, home3, and so on—with directories for different users under them. Regardless of where their home directory is located, users access their home directory through a mount point named /home/ login-name. Always refer to the home directory as $HOME, not as /home/ login-name. In addition, use relative paths to create any symbolic links in a user's home directory (for example, ../../../x/y/x) so that the links are valid no matter where the home directory is mounted. This section describes the default procedure for the Solaris Operating Environment; the procedure assumes that the user's system is on a network and that the automounter is used to make the home directory accessible. Whether the home directory originates on a server or on the local system, you need to make it accessible to other systems by using the share command to export the file system so that the user can access the home directory from other systems on the network. In addition, you must define how the home directory is mounted. Use one of the following ways.
To support automatic mounting of home directories, the Solaris Operating Environment includes the following entry in the /etc/auto_master file. /home auto_home -nobrowse This entry tells the automounter to mount the directories specified in the auto_home database onto the /home mount point on the local system. The entries in auto_home use the following format. login-name system-name:/export/home/login-name When a user logs in with login-name, the automounter mounts the specified directory (/export/home/ login-name) from the specified system (system-name) onto the /home/ login-name mount point on the system to which the user is logged in. This method works even when the home directory is stored on the same system to which the user has logged in. But more importantly, the user can log in to any other system and have his or her home directory mounted on /home/ login-name on that system.
NOTE. When the automounter is used to mount home directories, you are not permitted to create any directories under the /home mount point on the user's system. The system recognizes the special status of /home when the automounter is active. To create a home directory, you must already have created the user's account. You need the following information.
All the following steps apply regardless of whether the home directory is created on the local system or on a remote file server.
The following steps describe how to share a home directory from a Solaris server.
NOTE. If your network is not running NIS, NIS+, or LDAP, you need to add the home directory server's Internet Protocol (IP) address and system name to the /etc/hosts file on the user's system. After you have created the user's home directory, you must make it available. You make the home directory available by adding it to the appropriate NIS, NIS+, or LDAP database or by adding an entry to the /etc/vfstab file on the user's system for NFS mounting. NFS-Mounting the Home DirectoryIf the directory (disk space) for a user's home directory is located on another system and the automounter is not being used to make that space available, use the following steps to NFS-mount the home directory.
Defining the User's EnvironmentTo completely set up the user account, you must also perform the following tasks.
Defining Initialization FilesWhen a user logs in, the login program sets a number of variables, such as HOME, LOGNAME, and TZ. Then, the user's shell is launched and runs a file called the system profile (initialization file) to set systemwide defaults such as PATH, message of the day, and umask. Finally, the user profile initialization file (or files) that sets variables specific to the user is run. For example, the user profile can modify the PATH to include applications run by only that user. Each shell has its own initialization file (or files), as shown in Table 36.
The Solaris Operating Environment provides default user initialization files for each shell in the /etc/skel directory, as shown in Table 37.
The default /etc/skel/local.login file is shown below.
# @(#)local.login 1.5 98/10/03 SMI
stty -istrip
# setenv TERM `tset -Q -`
#
# if possible, start the windows system. Give user a chance to bail out
#
if ( "'tty'" == "/dev/console" ) then
if ( "$TERM" == "sun" || "$TERM" == "sun-color" || "$TERM" == "AT386" )
then
if ( ${?OPENWINHOME} == 0 ) then
setenv OPENWINHOME /usr/openwin
endif
echo ""
echo -n "Starting OpenWindows in 5 seconds (type Control-C to interrupt)"
sleep 5
echo ""
$OPENWINHOME/bin/openwin
clear # get rid of annoying cursor rectangle
logout # logout after leaving windows system
endif
endif
The default /etc/skel/local.cshrc file is shown below.
# @(#)cshrc 1.11 89/11/29 SMI
umask 022
set path=(/bin /usr/bin /usr/ucb /etc .)
if ( $?prompt ) then
set history=32
endif
The default /etc/skel/local.profile file is shown below.
# @(#)local.profile 1.8 99/03/26 SMI
stty istrip
PATH=/usr/bin:/usr/ucb:/etc:.
export PATH
#
# If possible, start the windows system
#
if [ "`tty`" = "/dev/console" ] ; then
if [ "$TERM" = "sun" -o "$TERM" = "sun-color" -o "$TERM" = "AT386" ]
then
if [ ${OPENWINHOME:-""} = "" ] ; then
OPENWINHOME=/usr/openwin
export OPENWINHOME
fi
echo ""
echo "Starting OpenWindows in 5 seconds (type Control-C to interrupt)"
sleep 5
echo ""
$OPENWINHOME/bin/openwin
clear # get rid of annoying cursor rectangle
exit # logout after leaving windows system
fi
fi
As you can see, these files define a minimal environment. To minimize the need to edit the customization files for each user, you can customize the files in /etc/skel to set as many systemwide default variables as you want. Creating Site Initialization FilesIt is important that both the administrator and the user are able to customize the user initialization files. You can create site initialization files by locating the initialization files centrally and distributing them globally. With site initialization files, you can continue to introduce new functionality to the user's work environment and also enable the user to customize individual user initialization files. You create a site initialization file and add a reference to it in the user's initialization file. When you reference a site initialization file in a user initialization file, all updates to the site initialization file are automatically reflected when the user logs in to the system or when a user starts a new shell. You can do any customization in a site initialization file that you can do in a user initialization file. Site initialization files typically reside on a server or a set of servers and appear as the first statement in a user initialization file. Each site initialization file must be the same type of shell script as the user initialization file that references it. Thus, you have site initialization files for each shell used at your site. To reference a site initialization file for a C shell user initialization file, put a line similar to the following example at the beginning of the user initialization file.
source /home/site-files/site-init-files
To reference a site initialization file in a Bourne or Korn shell user initialization file, put a line similar to the following example at the beginning of the user initialization file.
. /home/site-files/site-init-files
Example of a Site Initialization FileThe following example shows a C shell site initialization file named site.login in which a user can choose a particular version of an application. # @(#)site.login main: echo "Application Environment Selection" echo "" echo "1. Application, Version 1" echo "2. Application, Version 2" echo "" echo -n "Type 1 or 2 and press Return to set your application environment: " set choice = $< if ( $choice !~ [1-2] ) then goto main endif switch ($choice) case "1": setenv APPHOME /opt/app-v.1 breaksw case "2": setenv APPHOME /opt/app-v.2 endsw You would reference the site.login site initialization file located on a server named server2 in a user's .cshrc file (C shell users only) with the following line. The automounter must be running on the user's system. source /home/site-init-files/site.login Avoiding Local System References in Site Initialization FilesDo not add specific references to the local system in the user's initialization file. Instructions in a user initialization file should be valid regardless of the system to which the user logs in. To make a user's home directory available anywhere on the network, always refer to the home directory with the variable $HOME. For example, use $HOME/bin instead of /home/ login-name/ bin. $HOME automounts the user's home directory when the user logs in to another system. To access files on a local disk, create an indirect map that mounts only this file system, for example /home/site-init-files or /site/init-files. Such directories can be mounted automatically on any system to which the user logs in, assuming the system is running the automounter. Setting Up User Initialization FilesTo set up user initialization files, you must already have created the user's home directory and know which shell (C, Bourne, or Korn) is set in the user's account entry in the Passwd database. Use the following steps to set up the user's initialization files.
Use the following steps to edit the user's initialization file (or files).
The LANG variable and LC environment variables determine the locale-specific conversions and conventions the shell uses. These conversions and conventions include time zones, collation orders, and formats of dates, time, currency, and numbers. If necessary, set these variables in the user's initialization file. LANG sets all possible conversions and conventions for a given locale. If you have special needs, you can set various aspects of localization separately by using the LC variables LC_COLLATE, LC_CTYPE, LC_MESSAGES, and LC_NUMERIC. Table 39 shows the values for several locales.
If the system needs to support multibyte characters (for example, Japanese), add the following command to the system initialization file (/etc/profile or /etc/.login). stty cs8 defeucw The preceding command sets character size to the maximum (cs8) and sets the width of multibyte characters to the default values for the locale specified by LC_CTYPE. When the initialization files are complete, log out of the user's account. Setting Up a User's Mail AccountEach user has a mailbox either on a local system or on a mail server and a mail alias in the /etc/mail/aliases file or in an NIS, NIS+, or LDAP nameservice database that points to the location of the mailbox. Use the following steps to set up a mail client with a mailbox on a mail server.
NOTE. Thesendmail program automatically creates mailboxes in the /var/mail directory the first time a message is delivered. You do not need to create individual mailboxes for your mail clients. If you are using NIS+, use the following steps to set up mail aliases for the user.
Alternatively, when you have created a nameservice domain toolbox for SMC, you can use SMC/System Configuration/Users/Mailing Lists to edit network mail aliases. Setting Up a User's PrinterAfter adding users to a system, make sure they have access to a printer. See Chapter 11, "Administering Printing," for information on how to set up printing services. Creating a PasswordPasswords are an important part of system security. Each user account should be assigned a password of 6 to 10 characters as a combination of letters and numbers.
In the Solaris Operating Environment, the encrypted password and associated password aging information are stored in the nameservice password or shadow database or in the local /etc/shadow file. Permissions for the /etc/shadow file are -r--------. Only root can read the /etc/shadow file, and only the passwd command can write to the file. The following example shows the contents of an /etc/shadow file. root:4ZfnV.kupl.SA:11081:::::: daemon:NP:6445:::::: bin:NP:6445:::::: sys:NP:6445:::::: adm:NP:6445:::::: lp:NP:6445:::::: uucp:NP:6445:::::: nuucp:NP:6445:::::: listen:*LK*::::::: nobody:NP:6445:::::: noaccess:NP:6445:::::: nobody4:NP:6445:::::: winsor:OVHZsESoDAEwk:11081:::::: ray:::::::: des:::::::: rob::11080:::::: ppp:*LK*::::::: ignatz:::::::: Users can create or change their own passwords at any time. You must be root to create the initial password for any other user. In addition, to create a nameservice password, you must have the appropriate privileges and you must have established the necessary networkwide credentials. Use the following steps to create a local password.
NOTE. You can also use passwd to define, change, and view password attributes, such as password aging. You can use password aging for the file, NIS+, and LDAP nameservices, but not for NIS. See the passwd (1) manual page for more information. Changing a local password is similar to adding a new password. When prompted to do so, type the old password, and then type the new password two times, as prompted.
Disabling User AccountsOccasionally, you may need to temporarily or permanently disable a login account. You should have good reason for taking such action. For example, the user may be on leave of absence or you may have strong evidence that the account is being misused or security is being violated. The easiest way to disable a login account is to lock the account. You can lock an account in SMC from the General tab of the user properties for the user account. Refer to the Solaris Management Console Tools book for instructions. On a local system, you can control access to a user's account by requiring password aging, by setting an expiration date for the login account, or by requiring that a user access the account at regular intervals. Another way that you can disable a login is to temporarily change the password.  |
| [ Team LiB ] |
|
Secondary groups.