What Are User Accounts and Groups

One of the basic system administration tasks is to set up a user account for each user at a site. A typical user account includes the information a user needs to log in and use a system (without having the system's root password). User account information consists of four main components:

• User name - A name that a user uses to log in to a system (also known as a login name).
• Password - A secret combination of characters that a user must enter with a user name to gain access to a system.
• User's home directory - A directory that is usually the user's current directory at login. It typically contains most of the user's files.
• User initialization files - Shell scripts that control how the user's working environment is set up when a user logs in to a system.

Also, when you set up a user account, you can add the user to predefined groups of users. A typical use of groups is to set up file and directory access only to users who are part of a group (using the group permissions on a file or directory).

For example, you might have a directory containing top secret files that only a few users should be able to access. You could set up a group called topsecret that included the users working on the top secret project, and you could set up the top secret files with read permission for the topsecret group. That way, only the users in the topsecret group would be able to read the files.

Guidelines for Managing User Accounts

The following sections describe some guidelines and planning information for creating user accounts.

Name Services

If you are managing user accounts for a large site, you may want to consider using a name service such as NIS or NIS+. A name service enables you to store user account information in a centralized manner instead of storing user account information in every system's /etc files. When using a name service

for user accounts, users can move from system to system using the same user account without having site-wide user account information duplicated in every system's /etc files. Using a name service also promotes centralized and consistent user account information.

User (Login) Names

User names, also called login names, let users access their own systems and remote systems that have the appropriate access privileges. You must choose a user name for each user account you create. User names must:

• Be unique within your organization, which may span multiple domains
• Contain from two to eight letters and numerals (the first character must be a letter and at least one character must be a lowercase letter)
• Not contain an underscore or space

It is helpful to establish a standard way of forming user names, and the names should be easy for users to remember. A simple scheme when selecting a user name is to use the first name initial and first seven letters of the user's last name. For example, Ziggy Ignatz becomes zignatz. If that scheme results in duplicate names, you can use the first initial, middle initial, and the first six characters of the user's last name. For example, Ziggy Top Ignatz becomes ztignatz. If that still results in duplicate names, you can use the first initial, middle initial, first five characters of the user's last name, and the number 1, or 2, or 3, and so on, until you have a unique name.

---

Note - Each new user name must be distinct from any mail aliases known to the system or to an NIS or NIS+ domain. Otherwise, mail may be delivered to the alias rather than to the actual user.

---

User ID Numbers

Associated with each user name is a user identification (UID) number. The UID number identifies the user name to any system on which the user attempts to log in, and it is used by systems to identify the owners of files and directories. If you create user accounts for a single individual on a number of different systems, always use the same user name and user ID. In that way, the user can easily move files between systems without ownership problems.

UID numbers must be a whole number less than or equal to 60000, and they are required for both regular user accounts and special system accounts. Table 1-1 lists the UID numbers reserved for user accounts and system accounts.

Table 1-1

User ID Numbers	Login Accounts	Reserved For ...
0 - 99	root, daemon, bin, sys, etc.	System accounts
100 - 60000	regular users	General purpose accounts
60001	nobody	Unauthenticated users
60002	noaccess	Compatibility with previous Solaris 2.x and SVR4 releases

Although UID numbers 0 through 99 are reserved, you can add a user with one of these numbers. However, do not use them for regular user accounts. By definition, root always has UID 0, daemon has UID 1, and pseudo-user bin has UID 2. In addition, you should give uucp logins and pseudo user logins, like who, tty, and ttytype, low UIDs so they fall at the beginning of the passwd file.

As with user (login) names, you should adopt a scheme to assign unique UIDs. Some companies assign unique employee numbers, and administrators add 1000 to the employee number to create a unique UID number for each employee.

To minimize security risks, you should avoid reusing the UIDs from deleted accounts. If you must reuse a UID, "wipe the slate clean" so the new user is not affected by attributes set for a former user. For example, a former user may have been denied access to a printer--by being included in a printer deny list--but that attribute may not be appropriate for the new user. If need be, you can use duplicate UIDs in an NIS+ domain if the supply of unique UIDs is exhausted.

Passwords

Although user names are publicly known, passwords must be kept secret and known only to users. Each user account should be assigned a password, which is a combination of six to eight letters and numbers. You can set a user's password when you create the user account and have the user change it when logging in to a system for the first time.

To make your computer systems more secure, ask users to change their passwords periodically. For a high level of security, you should require users to change their passwords every six weeks. Once every three months is adequate for lower levels of security. System administration logins (such as root and sys) should be changed monthly, or whenever a person who knows the root password leaves the company or is reassigned.

Many breaches of computer security involve guessing a legitimate user's password. You should make sure that users avoid using proper nouns, names, login names, and other passwords that a person might guess just by knowing something about the user.

Good choices for passwords include:

• Phrase (beammeup)
• Nonsense words made up of the first letters of every word in a phrase (swotrb for SomeWhere Over The RainBow)
• Words with numbers or symbols substituted for letters (sn00py for snoopy)

Do not use these choices for passwords:

• Your name, forwards, backwards, or jumbled
• Names of family members or pets
• Car license numbers
• Telephone numbers
• Social Security numbers
• Employee numbers
• Names related to a hobby or interest
• Seasonal themes, such as Santa in December
• Any word in the dictionary

Password Aging

If you are using NIS+ or the /etc files to store user account information, you can set up password aging on a user's password. Password aging enables you to force users to change their passwords periodically or to prevent a user from changing a password before a specified interval. If you want to prevent an intruder from gaining undetected access to the system by using an old and inactive account, you can also set a password expiration date when the account will be disabled.

Home Directories

The home directory is the portion of a file system allocated to a user for storing private files. The amount of space you allocate for a home directory depends on the kinds of files the user creates and the type of work done. As a general rule, you should allocate at least 15 Mbytes of disk space for each user's home directory.

A home directory can be located either on the user's local system or on a remote file server. In either case, by convention the home directory should be created as /export/home/username. For a large site, you should store home directories on a server. Use a separate file system for each /export/homen directory to facilitate backing up and restoring home directories (for example, /export/home1, /export/home2).

Regardless of where their home directory is located, users usually access their home directories 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 automounting home directories, see "Mount Home Directories Automatically" on page 13.

To use the home directory anywhere on the network, you should always refer to it as $HOME, not as /export/home/username. The latter is machine-specific. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x), so the links will be valid no matter where the home directory is mounted.

The User's Work Environment

Besides having a home directory to create and store files, users need an environment that gives them access to the tools and resources they need to do their work. When a user logs in to a system, the user's work environment is determined by initialization files that are defined by the user's startup shell, such as the C, Korn, or Bourne shell.

A good strategy for managing the user's work environment is to provide customized user initialization files (.login, .cshrc, .profile) in the user's home directory. See "Customizing a User's Work Environment" on page 23 for detailed information about customizing user initialization files for users. After you create the customized user initialization files, you can add them to a user's home directory when you create a new user account.

A recommended one-time task is to set up separate directories, called skeleton directories, on a server (you can use the same server where the user's home directories are stored). The skeleton directories enable you to store customized user initialization files for different types of users.

---

Note - Do not use system initialization files (/etc/profile, /etc/.login) to manage a user's work environment, because they reside locally on systems and are not centrally administered. For example, if Autofs is used to mount the user's home directory from any system on the network, then you would have to modify the system initialization files on each system to ensure a consistent environment when a user moves from system to system.

---

Guidelines for Managing Groups

A group is a collection of users who can share files and other system resources. For example, the set of users working on the same project could be formed into a group. A group is traditionally known as a UNIX group.

Each group must have a name, a group identification (GID) number, and a list of user names that belong to the group. A GID identifies the group internally to the system. There are two types of groups that a user can belong to:

• Primary group - Specifies a group that the operating system will assign to files created by the user. Each user must belong to a primary group.

• Secondary groups - Specifies one or more groups to which a user also belongs. Users can belong to up to 16 secondary groups.

Sometimes a user's secondary group is not important. For example, ownership of files reflect the primary group, not any secondary groups. Other applications, however, may rely on a user's secondary memberships. For example, a user has to be a member of the sysadmin group (group 14) to use the Solstice AdminSuite software, but it doesn't matter if group 14 is his or her current primary group.

The groups command shows the groups a user belongs to. A user can have only one primary group at a time. However, the user can temporarily change the primary group (with the newgrp command) to any other group in which he or she is a member.

When adding a user account, you must assign a primary group for a user or accept the default: staff (group 10). The primary group should already exist (if it doesn't exist, specify the group by a GID number). User names are not added to primary groups. If they were, the list might become too long. Before you can assign users to a new secondary group, you must create the group and assign it a GID number.

Groups can be local to a system or can be managed through a name service. To simplify group administration, you should use a name service like NIS+, which enables you to centrally manage group memberships.

Tools for Managing User Accounts and Groups

In previous Solaris releases, you may have used the Solaris commands or Administration Tool to manage user accounts and groups. In the Solaris 2.5 release, there are three ways to manage user accounts and groups:

• Solaris commands - The commands useradd and groupadd are provided with Solaris to set up user accounts and groups on a local system only. The commands do not change name service maps or tables.
• Admintool - A new tool to manage /etc files on local systems. This tool should not be used in a name service environment.
• Solstice AdminSuite - Includes the tools User Manager and Group Manager to set up users and groups in the NIS or NIS+ name service and on a local system (/etc files).

You should use the Solstice AdminSuite tools User Manager and Group Manager to manage user account and group information in a networked and name service environment. User Account and Group Manager offer ease of use and provides support for the following name services:

• NIS+ tables
• NIS maps
• Local /etc files

To show you the benefits of the Solstice AdminSuite tools over using the commands, Table 1-2 lists the tasks that the User Manager and Group Manager can perform and the equivalent Solaris commands they replace.

Table 1-2 (1 of 3)

Task	If You Use This Name Service	Then Use These Commands
Add a User Account	NIS+	nistbladm nisclient
	NIS	useradd make
	None	useradd
Modify a User Account	NIS+	nistbladm
	NIS	usermod make
	None	usermod

Table 1-2 (2 of 3)

Task	If You Use This Name Service	Then Use These Commands
Delete a User Account	NIS+	nistbladm nisclient
	NIS	userdel make
	None	userdel
Copy an Existing User Account	NIS, NIS+ or None	--not available--
Set Up User Account Defaults	NIS+	--not available--
	NIS	useradd -D make
	None	useradd -D
Disable a User Account	NIS+	nistbladm
	NIS	vipw make
	None	vipw
Change a User's Password	NIS+	nispasswd
	NIS	yppasswd
	None	passwd
Sort User Accounts	NIS+	niscat sort
	NIS	ypcat sort
	None	awk sort
Find a User Account	NIS+	nismatch
	NIS	ypmatch
	None	grep
Add a Group	NIS+	nistbladm
	NIS	groupadd make
	None	groupadd

Table 1-2 (3 of 3)

Task	If You Use This Name Service	Then Use These Commands
Modify Users in a Group	NIS+	nistbladm
	NIS	groupmod make
	None	groupmod
Delete a Group	NIS+	nistbladm
	NIS	groupdel make
	None	groupdel

What You Can Do With User Manager

User Manager is a graphical user interface that enables you to set up user accounts on a local or remote system or in a name service environment. With a name service like NIS+, you can manage user accounts in a centralized manner so that important user account information, such as user names, do not have to be duplicated on every system in the network.

Mount Home Directories Automatically

One of User Manager's key features is setting up automounting of the user's home directory. The AutoHome Setup option enables users to log in to any system and have their home directories immediately available. To use this feature, make sure the automount entry in the target system's /etc/nsswitch.conf file is configured to use a name service. If you do not choose to set up automounting, you must manually set up the mounting required to make a user's home directory available on the network.

To support automatic mounting of home directories, the Solaris 2.x system software includes the auto_master file, which has the following entry:

/home auto_home

This entry tells Autofs to mount the directories specified in the auto_home file on the /home mount point on the local system. The entries in auto_home have the following format:

username system-name:/export/home/username

When a user logs in with username, Autofs mounts the specified directory (/export/home/username) from the server (system-name) on the /home mount point on the system where the user has just logged in. Autofs works even when the home directory is stored on the same system the user has logged in to.

Add New Users Quickly

Through the Copy User feature, User Manager can save you time when adding a new user. The Copy User feature enables you to copy parameters from an existing user account, such as a user account's group membership, default shell environment, home directory location, mailbox location, and other useful information. So, when you add a new user, you don't have to fill in the parameters that contain the copied values.

Set Default Settings for Adding Users

Through the Set Default feature, User Manager can save you time when adding a new user. The Set Default feature enables you to create default user account parameters such as group membership, default shell environment, password settings, home directory location, mailbox location, and other useful information. So, when you add a new user, you don't have to fill in the parameters that contain the default values.

Modify User Accounts

Unless you define a user name or UID number that conflicts with an existing one, you should never need to modify a user account's login name or UID number. If you do change a user name or UID number, the home directory's ownership is not changed (if a home directory exists for the user). You must manually change the ownership of all files and directories, including the mailbox, that have the old UID number.

One part of a user account that you can change is a user's group memberships. User Manager's Modify User option lets you add or delete a user's secondary groups. Alternatively, you can use Group Manager to directly modify a group's member list.

You can also modify the following parts of a user account:

• Comment
• Login shell
• Passwords
• Home directory
• AutoHome setup
• Credential table setup
• Mail server

Delete User Accounts

When you delete a user account with User Manager, the software deletes the entries in the passwd, group, aliases, cred, and auto_home files. In addition, you can delete the files in the user's home directory and delete the contents of the user's mailbox.

Only the single mail alias that directs mail to the user's mail box is deleted; the user name is not deleted from any other mail aliases. If you want to delete entries from mail aliases other than the one set up to direct mail to your mailbox, you must delete them by hand.

Add Customized User Initialization Files

Although you can't create customized user initialization files with User Manager, you can populate a user's home directory with user initialization files located in a specified "skeleton" directory.

When adding a user account with User Manager, you can specify a global path name (such as /net/machine-name/directory-name) to a skeleton directory that contains the customized user initialization files. Autofs mounts the shared directory from the server, and the user's home directory is populated with the user initialization files.

Administer Passwords

You can use User Manager for password administration, which includes specifying a normal password for a user account, enabling users to create their own passwords during their first login, disabling or locking a user account, or specifying expiration dates and password aging information.

---

Note - Password aging is not supported by the NIS name service.

---

Disable User Accounts

Occasionally, you may need to temporarily or permanently disable a login account. Disabling or locking a user account means that an invalid password, *LK*, is assigned to the user account, preventing future logins.

The easiest way to disable a user account is to use User Manager to lock the password for an account. You can also enter an expiration date in the Expiration Date field to set how long the user account is disabled. In addition, if NIS+ is the selected name service and DES entries have been added to the cred table, User Manager removes the DES entries.

Other ways to disable a user account is to set up password aging or by just changing the user's password.

What You Can't Do With User Manager

Table 1-3 shows the limitations of User Manager and their suggested workarounds.

Table 1-3

Limitation	Workaround
If you add a new user, User Manager does not automatically share the user's home directory so the user's system can remotely mount it.	Become root on the system that contains the home directory and either share the home directory or verify that it is already shared. Both of these workarounds can be done through the share command.
If you do not select AutoHome Setup (Autofs) for the user's home directory, User Manager does not set up the user's system to remotely mount the user's home directory.	Become root on the user's system and remotely mount the user's home directory. This can be done manually with the mount command or by editing the system's /etc/vfstab file.

What You Can Do With Group Manager

Group Manager is a graphical user interface that enables you to add or remove users from a group on a local or remote system or in a name service environment. With a name service like NIS+, you can manage group information in a centralized location so that it does not have to be duplicated on every system in the network.

Group Manager enables you to add and delete groups. When projects are finished, groups set up for those projects may no longer be needed, and you may want to delete these groups. Be careful to avoid conflicts if you reuse the GID numbers from deleted groups.

Where User Account and Group Information Is Stored

Depending on your site policy, you can store user account and group information in a name service or a local system's /etc files. In the NIS+ name service, information is stored in tables, and in the NIS name service, information is stored in maps.

---

Note - To avoid confusion, the location of the user account and group information will be generically referred to as a file rather than a file, table, or map.

---

Most of the user account information is stored in the passwd file. However, password encryption and password aging is stored in the passwd file when using NIS or NIS+ and in the /etc/shadow file when using /etc files Password aging is not available when using NIS.

Group information is stored in the group file.

Fields in the Password File

The fields in the passwd file are separated by colons and contain the following information:

username:password:uid:gid:comment:home-directory:login-shell

For example:

kryten:x:101:100:Kryten Series 4000:/export/home/kryten:/bin/csh

Table 1-4 describes the passwd file fields.

Table 1-4 passwd

Field Name	Description
username	Contains the user or (login) name. User names should be unique and consist of 2-8 letters (A-Z, a-z) and numerals (0-9). The first character must be a letter, and at least one character must be a lowercase letter. User names cannot contain underscores or spaces.
password	Contains an x, a placeholder for the encrypted password. (Password is an obsolete field.) The encrypted password is stored in the shadow file.
uid	Contains a user identification (UID) number that identifies the user to the system. UID numbers for regular users should range from 100 to 60000. All UID numbers should be unique.

Table 1-4 passwd(Continued)

Field Name	Description
gid	Contains a group identification (GID) number that identifies the user's primary group. Each GID number must be a whole number between 0 and 60002 (60001 and 60002 are assigned to nobody and noaccess, respectively).
comment	Usually contains the full name of the user. (This field is informational only.) It is sometimes called the GECOS field because it was originally used to hold the login information needed to submit batch jobs to a mainframe running GECOS (General Electric Computer Operating System) from UNIX systems at Bell Labs.
home-directory	Contains user's home directory path name.
login-shell	Contains the user's default login shell, which can be /bin/sh, /bin/csh or /bin/ksh. Table 62-8 on page 918 contains a description of shell features.

Fields in the Shadow File

The fields in the shadow file are separated by colons and contain the following information:

username:password:lastchg:min:max:warn:inactive:expire

For example:

rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978

Table 1-5 describes the shadow file fields.

Table 1-5 shadow

Field Name	Description
username	Contains the user or (login) name.
password	May contain the following entries: a 13-character encrypted user password; the string *LK*, which indicates an inaccessible account; or the string NP, which indicates no password for the account.
lastchg	Indicates the number of days between January 1, 1970, and the last password modification date.
min	Contains the minimum number of days required between password changes.
max	Contains the maximum number of days the password is valid before the user is prompted to specify a new password.
inactive	Contains the number of days a user account can be inactive before being locked.
expire	Contains the absolute date when the user account expires. Past this date, the user cannot log in to the system.

Fields in the Group File

The fields in the group file are separated by colons and contain the following information:

group-name:group-password:gid:user-list

For example:

bin::2:root,bin,daemon

Table 1-6 describes the group file fields.

Table 1-6 group

Field Name	Description
group-name	Contains the name assigned to the group. For example, members of the chemistry department in a university may be called chem. Group names can have a maximum of nine characters.
group-password	Usually contains an asterik or is empty. The group-password field is a relic of earlier versions of UNIX. If a group has a password, the newgrp command prompts users to enter it. However, there is no utility to set the password.
gid	Contains the group's GID number. It must be unique on the local system, and should be unique across the entire organization. Each GID number must be a whole number between 0 and 60002. Numbers under 100 are reserved for system default group accounts. User defined groups can range from 100 to 60000. (60001 and 60002 are reserved and assigned to nobody and noaccess, respectively.)
user-list	Contains a list of groups and a comma-separated list of user names, representing the user's secondary group memberships. Each user can belong to a maximum of 16 secondary groups.

UNIX User Groups

By default, all Solaris 2.x systems have these groups:

root::0:root other::1: bin::2:root,bin,daemon sys::3:root,bin,sys,adm adm::4:root,adm,daemon uucp::5:root,uucp mail::6:root tty::7:root,tty,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon sysadmin::14: nobody::60001: noaccess::60002:

Customizing a User's Work Environment

Part of setting up a user's home directory is providing user initialization files for the user's login shell. A user initialization file is a shell script that sets up a work environment for a user after the user logs in to a system. Basically, you can perform any task in a user initialization files that you can do in a shell script, but its primary job is to define the characteristics of a user's work environment, such as a user's search path, environment variables, and windowing environment. Each login shell has its own user initialization file (or files), which are listed in Table 1-7.

Table 1-7

Shell	User Initialization File	Purpose
Bourne	$HOME/.profile	Defines user's environment at login
C	$HOME/.cshrc	Defines user's environment for all C shells invoked after login shell
	$HOME/.login	Defines user's environment at login
Korn	$HOME/.profile	Defines user's environment at login
	$HOME/$ENV	Defines user's environment at login in the file specified by the Korn shell's ENV environment variable

The Solaris 2.x system software provides default user initialization files for each shell in the /etc/skel directory on each system, as shown in Table 1-8.

Table 1-8

Shell	Default File
C	/etc/skel/local.login /etc/skel/local.cshrc
Bourne or Korn	/etc/skel/local.profile

You can use these as a starting point and modify them to create a standard set of files that will provide the work environment common to all users, or you can modify them to provide the working environment for different types of

users. See "How to Customize User Initialization Files" on page 41 for step-by-step instructions on how to create sets of user initialization files for different types of users.

Use Site Initialization Files

When customizing a user initialization file, it is important that the user initialization files can be customized by both the administrator and the user. This important feature can be accomplished with centrally located and globally distributed user initialization files, called site initialization files. Site initialization files enable you to continually introduce new functionality to the user's work environment, while enabling the user to also customize the user 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. Site initialization files are designed for you to distribute site-wide changes to users' work environments that you did not anticipate when you added the users.

Any customization that can be done in a user initialization file can be done in a site initialization file. These files typically reside on a server (or set of servers), and appear as the first statement in a user initialization file. Also, each site initialization file must be the same type of shell script as the user initialization file that references it.

To reference a site initialization file in a C-shell user initialization file, place a line similar to the following at the beginning of the user initialization file:

source /net/machine-name/export/site-files/site-init-file

To reference a site initialization file in a Bourne- or Korn-shell user initialization file, place a line similar to the following at the beginning of the user initialization file:

. /net/machine-name/export/site-files/site-init-file

Avoid Local System References

You should not add specific references to the local system in the user's initialization file. You want the instructions in a user initialization file to be valid regardless of the system to which the user logs in. For example:

• 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; do not use /export/home/username/bin. $HOME works when the user logs in to another system, when home directories are automounted.
• To access files on a local disk, use global path names, like /net/machine-name/directory-name. Any directory referenced by /net/machine-name can be mounted automatically on any system on which the user logs in, assuming the system is running Autofs.

Shell Features

Table 1-9 lists basic shell features that each shell provides, which can help you determine what you can and can't do when creating user initialization files for each shell.

Table 1-9

Feature	Bourne	C	Korn
Known as the standard shell in UNIX	Yes	No	No
Compatible syntax with Bourne shell	-	No	Yes
Job control	Yes	Yes	Yes
History list	No	Yes	Yes
Command-line editing	No	Yes	Yes
Aliases	No	Yes	Yes
Single-character abbreviation for login directory	No	Yes	Yes
Protection from overwriting (noclobber)	No	Yes	Yes

Table 1-9 (Continued)

Feature	Bourne	C	Korn
Setting to ignore Control-d (ignoreeof)	No	Yes	Yes
Enhanced cd	No	Yes	Yes
Initialization file separate from .profile	No	Yes	Yes
Logout file	No	Yes	No

Shell Environment

A shell maintains an environment that includes a set of variables defined by the login program, the system initialization file, and the user initialization files. In addition, some variables are defined by default. A shell can have two types of variables:

• Environment variables - Variables that are exported to all processes spawned by the shell. Their settings can be seen with the env command. A subset of environment variables, like PATH, affects the behavior of the shell itself.
• Shell (local) variables - Variables that affect only the current shell. In the C shell, a set of these shell variables have a special relationship to a corresponding set of environment variables. These shell variables are user, term, home, and path. The value of the environment variable counterpart is initially used to set the shell variable.

In the C shell, you use the lowercase names with the set command to set shell variables and use uppercase names with the setenv command to set environment variables. If you set a shell variable, the shell sets the corresponding environment variable and vice versa. For example, if you update the path shell variable with a new path, the shell also updates the PATH environment variable with the new path.

In the Bourne and Korn shells, you use the uppercase names with the setenv command to set both shell and environment variables. You also have to use the export command to finish setting environment variables. For all shells, you generally refer to shell and environment variables by their uppercase names.

In a user initialization file, you can customize a user's shell environment by changing the values of the predefined variables or by specifying additional variables. Table 1-10 shows how to set environment variables in a user initialization file.

Table 1-10

If You Want to Set a User's Environment Variables for The ...	Then Add the Following Line to the User Initialization File ...
C shell	setenv VARIABLE value Example: setenv MAIL /var/mail/ripley
Bourne or Korn shell	VARIABLE=value; export VARIABLE Example: MAIL=/var/mail/ripley;export MAIL

Table 1-11 describes environment and shell variables you may want to customize in a user initialization file. For more information about variables used by the different shells, see sh(1), ksh(1), or csh(1).

Table 1-11 (1 of 3)

Variable	Description
ARCH	Sets the user's system architecture (for example, sun4, i386). This variable can be set with ARCH = `uname -p` (in Bourne or Korn shells) or setenv ARCH `uname -p` (in C shell). There is no built-in behavior of the shell that depends on this variable. It's just a useful variable for branching within shell scripts.
CALENDAR	Sets the path to the Calendar executables.
CDPATH (or cdpath in the C shell)	Sets a variable used by the cd command. If the target directory of the cd command is specified as a relative path name, the cd command will first look for the target directory in the current directory ("."). If the target is not found, the path names listed in the CDPATH variable are searched consecutively until the target directory is found and the directory change is completed. If the target directory is not found, the current working directory is left unmodified. For example, the CDPATH variable is set to /home/jean, and two directories exist under /home/jean: bin and rje. If you are in the /home/jean/bin directory and type cd rje, you change directories to /home/jean/rje, even though you do not specify a full path.
DESKSET	Sets the path to the DeskSet executables.

Table 1-11 (2 of 3)

Variable	Description
history	Sets history for the C shell.
HOME (or home in the C shell)	Sets the path to the user's home directory.
LANG	Sets the locale.
LOGNAME	Defines the name of the user currently logged in. The default value of LOGNAME is automatically set by the login program to the user name specified in the passwd file. You should only need to refer to (not reset) this variable.
LPDEST	Sets the user's default printer.
MAIL	Sets the path to the user's mailbox.
MANPATH	Sets the hierarchies of man pages available.
MANSECTS	Sets the hierarchies of man pages available.
OPENWINHOME	Sets the path to the OpenWindows subsystem.
PATH (or path in the C shell)	Lists, in order, the directories that the shell searches to find the program to run when the user types a command. If the directory is not in the search path, users must type the complete path name of a command. The default PATH is automatically defined and set as specified in .profile (Bourne or Korn shell) or .cshrc (C shell) as part of the login process. The order of the search path is important. When identical commands exist in different locations, the first command found with that name is used. For example, suppose that PATH is defined (in Bourne and Korn shell syntax) as PATH=/bin:/usr/bin:/usr/sbin:$HOME/bin and a file named sample resides in both /usr/bin and /home/jean/bin. If the user types the command sample without specifying its full path name, the version found in /usr/bin is used.
prompt	Defines the shell prompt for the C shell.
PS1	Defines the shell prompt for the Bourne or Korn shell.
SHELL (or shell in the C shell)	Sets the default shell used by make, vi, and other tools.

Table 1-11 (3 of 3)

Variable	Description
TERMINFO	Specifies the path name for an unsupported terminal that has been added to the terminfo file. Use the TERMINFO variable in /etc/profile or /etc/.login. When the TERMINFO environment variable is set, the system first checks the TERMINFO path defined by the user. If it does not find a definition for a terminal in the TERMINFO directory defined by the user, it searches the default directory, /usr/share/lib/terminfo, for a definition. If it does not find a definition in either location, the terminal is identified as "dumb."
TERM (or term in the C shell)	Defines the terminal. This variable should be reset in /etc/profile or /etc/.login. When the user invokes an editor, the system looks for a file with the same name as the definition of this environment variable. The system searches the directory referenced by TERMINFO to determine the terminal characteristics.
TZ	Sets the time zone, which is used to display dates, for example, in the ls -l command. If TZ is not set in the user's environment, the system setting is used; otherwise, Greenwich Mean Time is used.

The PATH Variable

When the user executes a command by using the full path, the shell uses that path to find the command. However, when users specify only a command name, the shell searches the directories for the command in the order specified by the PATH variable. If the command is found in one of the directories, the shell executes it.

A default path is set by the system, but most users modify it to add other command directories. Many user problems related to setting up the environment and accessing the right version of a command or a tool can be traced to incorrectly defined paths.

Guidelines

Here are some guidelines for setting up efficient PATH variables:

• If security is not a concern, put the current working directory (.) first in the path. However, including the current working directory in the path poses a security risk that you may want to avoid, especially for root.
• Keep the search path as short as possible. The shell searches each directory in the path. If a command is not found, long searches can slow down system performance.
• The search path is read from left to right, so you should put directories for commonly used commands at the beginning of the path.
• Make sure directories are not duplicated in the path.
• Avoid searching large directories, if possible. Put large directories at the end of the path.
• Put local directories before NFS^(TM) mounted directories to lessen the chance of "hanging" when the NFS server does not respond and to reduce unnecessary network traffic.

Examples--Setting a User's Default Path

The following examples show how to set a user's default path to include the home directory and other NFS mounted directories (the current working directory is specified first in the path). In a C-shell user initialization file, you would add the following:

set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)

In a Bourne- or Korn-shell user initialization file, you would add the following:

PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin export PATH

The Locale Variables

The LANG and LC environment variables specify the locale-specific conversions and conventions for the shell, like time zones, collation orders, and formats of dates, time, currency, and numbers. In addition, you can use the stty command in a user initialization file to set whether the system will support multibyte characters.

LANG sets all possible conversions and conventions for the given locale. If you have special needs, you can set various aspects of localization separately through these LC variables: LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_NUMERIC, LC_MONETARY, and LC_TIME.

Table 1-12 describes the values for the LANG and LC environment variables.

Table 1-12 LANGLC

Value	Locale
de	German
fr	French
iso_8895_1	English and European
it	Italian
japanese	Japanese
korean	Korean
sv	Swedish
tchinese	Taiwanese

Examples--Setting the Locale Using the LANG Variables

The following examples show how to set the locale using the LANG environment variables. In a C-shell user initialization file, you would add the following:

setenv LANG DE

In a Bourne- or Korn-shell user initialization file, you would add the following:

LANG=DE; export LANG

Default File Permissions (umask)

When you create a file or directory, the default file permissions assigned to the file or directory are controlled by the user mask. The user mask should be set by the umask command in a user initialization file. You can display the current value of the user mask by typing umask and pressing Return.

The user mask can be set with a three-digit octal value. The first digit sets permissions for the user; the second sets permissions for group; the third sets permissions for other (also referred to as world). Note that if the first digit is zero, it is not displayed. For example, if umask is set to 022, 22 is displayed.

To determine the umask value you want to set, subtract the value of the permissions you want from 666 (for a file) or 777 (for a directory). The remainder is the value to use with the umask command. For example, suppose you want to change the default mode for files to 644 (rw-r--r--). The difference between 666 and 644 is 022, which is the value you would use as an argument to the umask command.

You can also determine the umask value you want to set by using Table 1-13, which shows the file and directory permissions that are created for each of the octal values of umask.

Table 1-13 umask

umask Octal Value	File Permissions	Directory Permissions
0	rw-	rwx
1	rw-	rw-
2	r--	r-x
3	r--	r--
4	-w-	-wx
5	-w-	-w-
6	--x	--x
7	--- (none)	--- (none)

The following line in a user initialization file sets the default file permissions to rw-rw-rw-.

umask 000

Examples of User and Site Initialization Files

The following sections provide examples of user and site initialization files that you can use to start customizing your own initialization files. Many of the examples use system names and paths that you will have to change for your particular site.

Example--.profile File

(1)PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. (2)MAIL=/var/mail/$LOGNAME (3)NNTPSERVER=server1 (4)MANPATH=/usr/share/man:/usr/local/man (5)PRINTER=printer1 (6)umask 022 (7)export PATH MAIL NNTPSERVER MANPATH PRINTER

Figure 1-1

Example .profile File

(1)

Defines the user's shell search path.

(2)Defines the path to the user's mail file.

(3)Defines the environment variable for the user's Usenet news server.

(4)Defines the user's search path for man pages.

(5)Defines the user's default printer.

(6)Sets the user's default file creation permissions.

(7)Sets the listed environment variables.

Example--.cshrc File

(1)set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin) (2)setenv MAIL /var/mail/$LOGNAME (3)setenv NNTPSERVER server1 (4)setenv PRINTER printer1 (5)alias h history (6)umask 022 (7)source /net/server2/site-init-files/site.login

Figure 1-2

Example .cshrc File

(1)

Sets the user's shell search path.

(2)Sets the path to the user's mail file.

(3)Sets the user's Usenet news server.

(4)Sets the user's default printer.

(5)Creates an alias for the history command (the user will need to type only h to run the history command).

(6)Sets the user's default file creation permissions.

(7)Runs the site intialization file shown in Figure 1-3 on page 35.

Example--Site Initialization File

shows an example site initialization file 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

Figure 1-3 Example Site Initialization File

This site initialization file could be referenced in a user's .cshrc file (C shell users only) with the following line:

source /net/server2/site-init-files/site.login

In this line, the site initialization file is named site.login and it is located on a server named server2. This line also assumes that the automounter is running on the user's system.