|
|
Setting Up Shell Initialization FilesObjective: When you set up user accounts, you can customize each user's session by using initialization files that are referenced each time the user logs in. This chapter describes how to administer each initialization file. As a system administrator, when you're setting up a user's home directory, you need to set up the shell initialization files for the user's login shell (also called user initialization files). A shell initialization file is a shell script that runs automatically each time the user logs in. The initialization file sets up the work environment and customizes the shell environment for the user. The primary job of the shell initialization file is to define the user's shell environment, such as the search path, environment variables, and windowing environment. Each Unix shell has its own shell initialization file (or files), located in the user's home directory, as described in the following sections. C Shell Initialization FilesC shell initialization files run in a particular sequence after the user logs in to the system. For the C shell, initialization files are run in the following sequence:
Although it is not part of the initialization of the shell, when the C shell terminates, it performs commands from the $HOME/.logout file (if that file exists in the home directory). Bourne Shell Initialization FilesBourne shell initialization files run in a particular sequence after the user logs in to the system. For the Bourne shell, initialization files are run in the following sequence:
Korn Shell Initialization FilesKorn shell initialization files run in a particular sequence after the user logs in to the system. For the Korn shell, initialization files are run in the following sequence:
Additional Shells Included with Solaris 10Solaris 10 also includes, as part of the operating environment, the bash, zsh, and tcsh shells. These shells, especially bash and tcsh, are gaining popularity with system administrators and contain extra options and functions. You can find further details about these shells and their additional functionality by consulting the man pages for them. Note The Effect of CDE on Shell Initialization Files Initialization files are executed in the order specified for each of the shells, except when you're logging in to the CDE, where the $HOME/.dtprofile file is also run. If the DTSOURCEPROFILE variable is not set to TRUE in the .dtprofile file, the $HOME/.profile file will not be run. When you're using CDE, it may be necessary to add the following lines in the $HOME/.profile to get the .kshrc file to work properly in the Korn shell: set -ha ENV=$HOME/.kshrc Without this entry, aliases and environment variables might not get passed to subshells (that is, additional shells spawned by the Korn shell). Therefore, when you open a new window in the CDE, alias and environment variables are set in the initial shell but are not set in subsequent shells, even though they are listed in the $HOME/.kshrc file. The preceding entries fix this problem. Default Initialization FilesWhen a user logs in to the system, the user's login shell is invoked. The shell program looks for its initialization files in the correct order for the shell. The shell program then executes the commands contained in each file and, when it is finished, displays the shell prompt on the user's screen. Default user initialization files (such as .cshrc, .profile, and .login) are created automatically in the user's home directory when a new user account is added. You can predefine the contents of these files, or you can choose to use the system default files. The Solaris 10 system software provides default user initialization files for each shell in the /etc/skel directory on each system. These files are listed in Table 4.10.
You can use these initialization files as a starting point and modify them to create a standard set of files that provides a work environment that is common to all users. You can also modify them to provide a working environment for different types of users. Customizing User Initialization FilesWhen a user logs in to a system, the shell initialization files determine the work environment. The shell startup scripts can be modified to set environment variables and directory paths that are needed by a specific user. These startup scripts are located in the user's home directory. When you are setting up user initialization files, it might be important to allow the users to customize their own initialization files. You can do this by having centrally located and globally distributed user initialization files called site initialization files. With these files, you can continually introduce new functionality to all the user work environments by editing one initialization file. The local initialization file, located in the user's home directory, allows user-specific configuration. A local initialization file lets users further customize their own work environment. Site initialization files are located in the /etc directory and can be edited only by root. They are designed to distribute sitewide changes to all user work environments. Individual user initialization files are located in each user's home directory and can be customized by the owner of the directory. When a user logs in, the site initialization file is run first, and then the initialization file located in the user's home directory is run. Note Sitewide Shell Initialization Files You should not use system initialization files located in the /etc directory (/etc/profile, /etc/.login) to manage an individual user's work environment. Files in that folder are site initialization files, which are considered to be global files and are meant to be generic and used to set work environments for all users. The system runs these startup files first and then runs each user's startup files, located in the home directories. The most commonly customized aspects of shell startup scripts are environment variables. Table 4.11 describes the most common environment and shell variables, including some that you might want to customize in user initialization files.
Tip Modifying the Shell Prompt Some users find it helpful to make their login name, the hostname, and the current directory part of the prompt. Here's how you set it up in the Korn shell: PS1="$(whoami)@$(hostname) [\$PWD] #" The resulting prompt looks like this: root@ultra5 [/usr/bin] # Step by Step 4.5 shows how to modify the shell environment by changing some of the variables in the shell startup file. It suggests some changes and shows the shell-specific syntax to use.
The Home DirectoryThe home directory is the portion of a file system that is allocated to a user for storing private files. The amount of space you allocate for home directories depends on the kinds of files the user creates and the type of work performed. An entire file system is usually allocated specifically for home directories, and the users all share this space. As the system administrator, you need to monitor user home directories so that one user does not use more than his or her fair share of space. You can use disk quotas to control the amount of disk space a user can occupy. (Disk quotas are discussed in Chapter 1, "Managing File Systems.") Or you can use soft partitions, which are described in Chapter 10. A home directory can be located either on the user's local system or on a remote file server. Although any directory name can be used for a home directory, it is customary that home directories are named using this convention: /export/home/<username>. When you put the home directory in /export/home, it is available across the network in case the user logs in from several different stations. For a large site, you should store home directories on a server. Regardless of where their home directories are located, users usually access them through a mount point named /home/<username>. When AutoFS is used to mount home directories, you are not permitted to create any directories under the /home mount point on any system. The system recognizes the special status of /home when AutoFS is active. For more information about AutoFS and automounting home directories, see Chapter 9, "Virtual File Systems, Swap Space, and Core Dumps." To access a home directory anywhere on the network, a user should always refer to it as $HOME, not as /export/home/<username>. The latter is machine specific, and its use should be discouraged. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x) so that the links will be valid no matter where the home directory is mounted. The location of user home directories might change. By not using machine-specific names, you maintain consistency and reduce system administration. ProjectsThe concept of projects was introduced in Solaris 8. Projects are included in Solaris 10, and they allow much-improved tracking of resources and usage. The project concept is extremely useful when multiple projects use the same system and are charged for their usage of the system. With projects, it is now simple to identify and subsequently charge each project based on the resources used. In addition, a system administrator supporting multiple projects can perform duties associated with those projects so that his or her time is also booked to the project requesting the service. The system administrator would do this by using the newtask command. (See the newtask man page for further details about this command.) You establish projects by using the configuration file /etc/project. The following example shows the standard /etc/project file: system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: As you can see from this example, all members of the staff group (GID 10) belong to the project group.staff. You can edit this file to create new projects and assign users and groups of users to the projects. Accounting software can produce reports on usage based on the projects specified in the /etc/project file. For further information on projects, see the man page entry for projects as well as the entry for the projects command, which lists the projects a user or group belongs to. Name ServicesIf you are managing user accounts for a large site, you might want to consider using a name service such as Network Information Service (NIS), Network Information Service Plus (NIS+), or Lightweight Directory Access Protocol (LDAP). A name service lets you store user account information in a centralized manner instead of storing it in every system's /etc file. When you use a name service for user accounts, users can move from system to system, using the same user account without having sitewide user account information duplicated in every system's /etc file. Using a name service also promotes centralized and consistent user account information. NIS, NIS+, and LDAP are discussed in Chapter 12, "Naming Services."  |
|
|