This chapter provides guidelines and planning information for managing user accounts and groups. This chapter also includes information about customizing the user's work environment.This is a list of the overview information in this chapter:What's New in Managing Users and Groups? What Are User Accounts and Groups? Where User Account and Group Information Is Stored Tools for Managing User Accounts and Groups Customizing a User's Work Environment For step-by-step instructions on managing user accounts and groups, see Chapter 5, Managing User Accounts and Groups (Tasks). This section includes information about new or changed features for managing users and groups in this Solaris release.The useradd command enables you to specify a default shell by using the s option and a default skeldirectory by using the k option.For example:# useradd -D [-s /usr/bin/ksh] [-k /export/home] foo You can now also specify a base directory without using the D option.For example:# useradd [-b /export/home] fooFor more information on these changes, see the useradd1M man page. The following table describes available tools for user account and group management.Tool Name Description For More Information Solaris Management Console Graphical tool that is used to manage users, groups, roles, rights, mailing lists, disks, terminals, and modems. Setting Up User Accounts (Task Map) smuser, smrole, smgroup Commands that are used to manage users, groups and roles. The SMC services must be running to use these commands. Adding a Group and User With the smgroup and smuser Commands useradd, groupadd, roleadd; usermod, groupmod, rolemod; userdel, groupdel, roledel Commands that are used to manage users, groups, and roles. Adding a Group and User With the groupadd and useradd Commands The Admintool is not available in this Solaris release. user accountsuser accountsdescriptionOne basic system administration task 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. The components of user account information are described in User Account Components. 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 group permissions on a file and directory, which allows access only to users who are part of that group. For example, you might have a directory containing confidential files that only a few users should be able to access. You could set up a group called topsecret that includes the users working on the topsecret project. And, you could set up the topsecret files with read permission for the topsecret group. That way, only the users in the topsecret group would be able to read the files.A special type of user account, called a role, is used to give selected users special privileges. For more information, see Role-Based Access Control (Overview) in System Administration Guide: Security Services.user accountsdescriptionThe following sections describe the specific components of a user account. user login namesdescriptionuser accountslogin namesnamesuser logindescriptionlogin names (user)descriptionUser 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 that you create. Consider establishing a standard way of assigning user names so that they are easier for you to track. Also, 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 this 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 this scheme still results in duplicate names, consider using the following scheme to create a user name:The first initial, middle initial, first five characters of the user's last name The number 1, or 2, or 3, and so on, until you have a unique name mail aliasesuser login names vs.aliasesuser login names vs.Each new user name must be distinct from any mail aliases that are known to the system or to an NIS or NIS+ domain. Otherwise, mail might be delivered to the alias rather than to the actual user. For detailed guidelines on setting up user (login) names, see Guidelines for Using User Names, User IDs, and Group IDs. user ID numbersuser accountsID numbersUIDsdefinitionID numbersuserAssociated with each user name is a user identification number (UID). The UID number identifies the user name to any system on which the user attempts to log in. And, the UID number 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 ID number. In that way, the user can easily move files between systems without ownership problems. system accountsmaximumsuser ID numberbin groupID numbersgroupgroupsID numbersgroup ID numbersGIDsdaemon groupnobody user/groupnoaccess user/groupUID numbers must be a whole number that is less than or equal to 2147483647. UID numbers are required for both regular user accounts and special system accounts. The following table lists the UID numbers that are reserved for user accounts and system accounts. UID Numbers User or Login Accounts Description 0 – 99 root, daemon, bin, sys, and so on Reserved for use by the Solaris OS 100 – 2147483647 Regular users General purpose accounts 60001 and 65534 nobody and nobody4 Anonymous users 60002 noaccess Non trusted users ttys (pseudo)pseudo-ttyspseudo user loginspasswd fileuser ID number assignment and/etc/passwd fileuser ID number assignment andttytype pseudo user loginsuser logins (pseudo)uucp groupDo not assign UIDs 0 through 99. These UIDs are reserved for allocation by the Solaris Operating System. 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, such as who, tty, and ttytype, low UIDs so that they fall at the beginning of the passwd file.For additional guidelines on setting up UIDs, see Guidelines for Using User Names, User IDs, and Group IDs.As with user (login) names, you should adopt a scheme to assign unique UID numbers. Some companies assign unique employee numbers. Then, administrators add a number to the employee number to create a unique UID number for each employee.securityuser ID number reuse andID numbersuserUIDsassigninguser accountsID numbersuser ID numbersTo minimize security risks, you should avoid reusing the UIDs from deleted accounts. If you must reuse a UID, “wipe the slate clean” so that the new user is not affected by attributes set for a former user. For example, a former user might have been denied access to a printer by being included in a printer deny list. However, that attribute might be inappropriate for the new user. UIDslargeGIDslargeUIDs and group IDs (GIDs) can be assigned up to the maximum value of a signed integer, or 2147483647.However, UIDs and GIDs over 60000 do not have full functionality and are incompatible with many Solaris features. So, avoid using UIDs or GIDs over 60000.The following table describes interoperability issues with Solaris products and previous Solaris releases.Category Product or Command Issue NFS interoperability SunOS 4.0 NFS software and compatible releases NFS server and client code truncates large UIDs and GIDs to 16 bits. This situation can create security problems if systems running SunOS 4.0 and compatible releases are used in an environment where large UIDs and GIDs are being used. Systems running SunOS 4.0 and compatible releases require a patch to avoid this problem. Name service interoperability NIS name service and file-based name service Users with UIDs greater than 60000 can log in or use the su command on systems running the Solaris 2.5 (and compatible releases). However, their UIDs and GIDs will be set to 60001 (nobody). NIS+ name service Users with UIDs greater than 60000 are denied access on systems running Solaris 2.5 (and compatible releases) and the NIS+ name service. UID or GID Limitations 60003 or greater Users who log in to systems running Solaris 2.5 (and compatible releases) and the NIS or files name service get a UID and GID of nobody. 65535 or greater Systems running Solaris 2.5 (and compatible releases) with the NFS version 2 software truncate UIDs to 16 bits, creating possible security problems. Users who use the cpio command with the default archive format to copy a file see an error message for each file. And, the UIDs and GIDs are set to nobody in the archive. x86 based systems: Users that run SVR3-compatible applications will probably see EOVERFLOW return codes from system calls. x86 based systems: If users attempt to create a file or directory on a mounted System V file system, the System V file system returns an EOVERFLOW error. 100000 or greater The ps -l command displays a maximum five-digit UID. So, the printed column won't be aligned when it includes a UID or GID larger than 99999. 262144 or greater Users who use the cpio command with the -H odc format or the pax -x cpio command to copy files see an error message returned for each file. And, the UIDs and GIDs are set to nobody in the archive. 1000000 or greater Users who use the ar command have their UIDs and GIDs set to nobody in the archive. 2097152 or greater Users who use the tar command, the cpio -H ustar command, or the pax -x tar command have their UIDs and GIDs set to nobody. groupsguidelines for managinggroupsdescriptionUNIX groupsgroupsUNIXA group is a collection of users who can share files and other system resources. For example, users who working on the same project could be formed into a group. A group is traditionally known as a UNIX group.ID numbersgroupgroupsnamesdescriptiongroupsID numbersGIDsdefinitiongroup ID numbersgroupsdescription of namesnamesgroupdescriptionEach group must have a name, a group identification (GID) number, and a list of user names that belong to the group. A GID number identifies the group internally to the system. The two types of groups that a user can belong to are as follows:primary groupsgroupsprimaryPrimary group – Specifies a group that the operating system assigns to files that are created by the user. Each user must belong to a primary group. secondary groupsgroupssecondarymaximumssecondary groups users can belong toSecondary groups – Specifies one or more groups to which a user also belongs. Users can belong to up to 15 secondary groups. For detailed guidelines on setting up group names, see Guidelines for Using User Names, User IDs, and Group IDs.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, might rely on a user's secondary group memberships. For example, a user has to be a member of the sysadmin group (group 14) to use the Admintool software in previous Solaris releases. However, it doesn't matter if group 14 is his or her current primary group.groups commandgroupsdisplaying groups a user belongs togroupschanging primarynewgrp commandThe groups command lists the groups that a user belongs to. A user can have only one primary group at a time. However, a user can temporarily change the user's primary group, with the newgrp command, to any other group in which the user is a member.group ID numbersGIDsassigningstaff groupgroupsdefaultgroupsID numbersID numbersgroupgroupssecondarysecondary groupsgroupsprimaryprimary groupsWhen adding a user account, you must assign a primary group for a user or accept the default group, staff (group 10). The primary group should already exist. If the primary group does not exist, specify the group by a GID number. User names are not added to primary groups. If user names were added to primary groups, 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.NIS+groups andname servicesgroups andgroupsname services andgroupsguidelines for managingGroups can be local to a system or managed through a name service. To simplify group administration, you should use a name service such as NIS or a directory service such as LDAP. These services enable you to centrally manage group memberships. You can specify a password for a user when you add the user. Or, you can force the user to specify a password when the user first logs in. User passwords must comply with the following syntax:Password length must at least match the value identified by the PASSLENGTH variable in the /etc/default/passwd file. By default, PASSLENGTH is set to 6. The first 6 characters of the password must contain at least two alphabetic characters and have at least one numeric or special character. passwords (user)precautionspasswords (user)descriptionminimumsuser password lengthmaximumsuser password lengthpasswords (user)settingpasswords (user)changingby userchanginguser passwordsby userAlthough user names are publicly known, passwords must be kept secret and known only to users. Each user account should be assigned a password. The password can be a combination of six to eight letters, numbers, or special characters.changinguser passwordsfrequency ofchanginguser passwordsby userpasswords (user)changingfrequency ofpasswords (user)changingby userpasswords (user)choosingTo make your computer systems more secure, users should 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.passwords (user)precautionsMany 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 the following: Phrases (beammeup). Nonsense words made up of the first letters of every word in a phrase. For example, swotrb for SomeWhere Over The RainBow. Words with numbers or symbols substituted for letters. For example, sn00py for snoopy. Do not use these choices for passwords:Your name (spelled forwards, backwards, or jumbled) Names of family members or pets Car license numbers Telephone numbers Social Security numbers Employee numbers Words related to a hobby or interest Seasonal themes, such as Santa in December Any word in the dictionary user home directoriesdescriptiondirectorieshomeThe 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, their size, and the number of files that are created. /home file systemuser home directories and/export/home file systemA 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 Task Overview for Autofs Administration in System Administration Guide: Network Services.user home directoriesnonlocal reference to ($HOME)To use the home directory anywhere on the network, you should always refer to the home directory 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 that the links are valid no matter where the home directory is mounted. user accountsname services andNISuser accounts andname servicesuser accounts and/etc filesuser account information anduser accountsstorage of information foruser accountsstorage of information for/etc filesuser account information andname servicesuser accounts andNISuser accounts anduser accountsname services andIf you are managing user accounts for a large site, you might want to consider using a name or directory service such as LDAP, NIS, or NIS+. A name or directory 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 you use a name or directory service for user accounts, users can move from system to system using the same user account without having site-wide user account information duplicated on every system. Using a name or directory service also promotes centralized and consistent user account information. user initialization filesdescriptionBesides 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. These files 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, such as .login, .cshrc, .profile, in the user's home directory. user home directoriesmountingautomountingsystem initialization filesmountinguser home directoriesautomountinginitialization filessystemautomountinguser home directoriesuser accountsguidelines foruser initialization filesdescriptionDo not use system initialization files, such as /etc/profile or /etc/.login, to manage a user's work environment. These files 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, you would have to modify the system initialization files on each system to ensure a consistent environment whenever a user moved from system to system. For detailed information about customizing user initialization files for users, see Customizing a User's Work Environment.Another way to customize user accounts is through role-based access control (RBAC). See Role-Based Access Control (Overview) in System Administration Guide: Security Services for more information. User names, UIDs, and GIDs should be unique within your organization, which might span multiple domains.Keep the following guidelines in mind when creating user or role names, UIDs, and GIDs:minimumsuser login name lengthmaximumsuser login name lengthUser names – They should contain from two to eight letters and numerals. The first character should be a letter. At least one character should be a lowercase letter. Even though user names can include a period (.), underscore (_), or hyphen (-), using these characters is not recommended because they can cause problems with some software products. System accounts – Do not use any of the user names, UIDs, or GIDs that are contained in the default /etc/passwd and /etc/group files. Do not use the UIDs and GIDs, 0-99. These numbers are reserved for allocation by the Solaris Operating System and should not be used by anyone. Note that this restriction also applies to numbers not currently in use.For example, gdm is the reserved user name and group name for the GNOME Display Manager daemon and should not be used for another user. For a complete listing of the default /etc/passwd and /etc/group entries, see Table 4–5 and Table 4–6.The nobody and nobody4 accounts should never be used for running processes. These two accounts are reserved for use by NFS. Use of these accounts for running processes could lead to unexpected security risks. Processes that need to run as a non-root user should use the daemon or noaccess accounts. System account configuration – The configuration of the default system accounts should never be changed. This includes changing the login shell of a system account that is currently locked. The only exception to this rule is the setting of a password and password aging parameters for the root account. Depending on your site policy, user account and group information can be stored in your local system's /etc files or in a name or directory service as follows: The NIS+ name service information is stored in tables. The NIS name service information is stored in maps. The LDAP directory service information is stored in indexed database files. To avoid confusion, the location of the user account and group information is generically referred to as a file rather than as a database, table, or map. Most user account information is stored in the passwd file. Password information is stored as follows:In the passwd file when you are using NIS or NIS+ In the /etc/shadow file when you are using /etc files In the people container when you are using LDAP /etc/passwd filedescriptionaging user passwordsencryption/etc/passwd file/etc/shadow filedescriptionname servicesuser accounts andNISuser accounts andpasswd filepasswords (user)agingpasswords (user)encryptionshadow filedescriptionuser accountsname services andPassword aging is available when you are using NIS+ or LDAP, but not NIS.groupsstorage of information forgroup filedescriptionGroup information is stored in the group file for NIS, NIS+ and files. For LDAP, group information is stored in the group container. passwd filefields in/etc/passwd filefields inThe fields in the passwd file are separated by colons and contain the following information: username:password:uid:gid:comment:home-directory:login-shellFor example:kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/cshFor a complete description of the fields in the passwd file, see the passwd1 man page. The default Solaris passwd file contains entries for standard daemons. Daemons are processes that are usually started at boot time to perform some system-wide task, such as printing, network administration, or port monitoring.root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: uucp:x:5:5:uucp Admin:/usr/lib/uucp: nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico smmsp:x:25:25:SendMail Message Submission Program:/: listen:x:37:4:Network Admin:/usr/net/nls: gdm:x:50:50:GDM Reserved UID:/: webservd:x:80:80:WebServer Reserved UID:/: nobody:x:60001:60001:NFS Anonymous Access User:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:User Name User ID Description root 0 Superuser account daemon 1 Umbrella system daemon associated with routine system tasks bin 2 Administrative daemon associated with running system binaries to perform some routine system task sys 3 Administrative daemon associated with system logging or updating files in temporary directories adm 4 Administrative daemon associated with system logging lp 71 Line printer daemon uucp 5 Daemon associated with uucp functions nuucp 6 Another daemon associated with uucp functions smmsp 25 Sendmail message submission program daemon webservd 80 Account reserved for WebServer access gdm 50 GNOME Display Manager daemon listen 37 Network listener daemon nobody 60001 Account reserved for anonymous NFS access. noaccess 60002 Assigned to a user or a process that needs access to a system through some application but without actually logging in. nobody4 65534 SunOS 4.0 or 4.1 version of the nobody user account shadow filefields inThe fields in the shadow file are separated by colons and contain the following information: username:password:lastchg:min:max:warn:inactive:expireFor example:rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978For a complete description of the fields in the shadow file, see the shadow4 and crypt1 man pages. group filefields ingroupsstorage of information forThe fields in the group file are separated by colons and contain the following information: group-name:group-password:gid:user-listFor example:bin::2:root,bin,daemonFor a complete description of the fields in the group file, see the group4 man page. The default Solaris group file contains the following system groups that support some system-wide task, such as printing, network administration, or electronic mail. Many of these groups having corresponding entries in the passwd file.root::0: other::1: bin::2:root,daemon sys::3:root,bin,adm adm::4:root,daemon uucp::5:root mail::6:root tty::7:root,adm lp::8:root,adm nuucp::9:root staff::10: daemon::12:root smmsp::25: sysadmin::14: gdm::50: webservd::80: nobody::60001: noaccess::60002: nogroup::65534:Group Name Group ID Description root 0 Superuser group other 1 Optional group bin 2 Administrative group associated with running system binaries sys 3 Administrative group associated with system logging or temporary directories adm 4 Administrative group associated with system logging uucp 5 Group associated with uucp functions mail 6 Electronic mail group tty 7 Group associated with tty devices lp 8 Line printer group nuucp 9 Group associated with uucp functions staff 10 General administrative group. daemon 12 Group associated with routine system tasks sysadmin 14 Administrative group associated with legacy Admintool and Solstice AdminSuite tools smmsp 25 Daemon for Sendmail message submission program webservd 80 Group reserved for WebServer access gdm 50 Group reserved for the GNOME Display Manager daemon nobody 60001 Group assigned for anonymous NFS access noaccess 60002 Group assigned to a user or a process that needs access to a system through some application but without actually logging in nogroup 65534 Group assigned to a user who is not a member of a known group The following table lists the recommended tools for managing users and groups. These tools are included in the Solaris Management Console suite of tools. For information about starting and using the Solaris Management Console, see Chapter 2, Working With the Solaris Management Console (Tasks).Solaris Management Tool Purpose Users Manage users accounts User Templates Create a set of attributes for a specific kind of user like students, engineers, or instructors Rights Manage RBAC rights Administrative Roles Manage RBAC administrative roles Groups Manage group information Projects Manage project information Mailing Lists Manage mailing lists Use the Solaris Management Console online help for information on performing these tasks.For information on the Solaris commands that can be used to manage user accounts and groups, see Table 1–6. These commands provide the same functionality as the Solaris management tools, including authentication and name service support.The Solaris user management tools enable you to manage user accounts and groups on a local system or in a name service environment.This table describes the tasks you can do with the Users tool's User Accounts feature.Task Description Add a user Adds a user to the local system or name service. Create a user template Creates a template of predefined user attributes for creating users of the same group, such as students, contractors, or engineers. Add a user with a user template Adds a user with a template so that user attributes are predefined. Clone a user template Clones a user template if you would like to use a similar set of predefined user attributes. Then, change only some of the attributes as needed. Set up user properties Sets up user properties in advance of adding users. Properties include specifying whether a user template is used when adding a user, and whether the home directory or mail box is deleted by default when removing a user. Add multiple users Adds multiple users to the local system or name service by specifying a text file, typing each name, or automatically generating a series of user names. View or change user properties Displays or changes user properties such as login shell, password, or password options. Assign rights to users Assigns RBAC rights to users that will allow them to perform specific administration tasks. Remove a user Removes the user from the local system or the name service. Optionally, you can also specify whether the user's home directory or mailbox is removed. The user is also removed from any groups or roles. For information about adding a user to the local system or name service, see What Are User Accounts and Groups? and User Account Components.Task Description Grant a right Grants a user a right to run a specific command or application that was previously only available to an administrator. View or change existing rights properties Displays or changes existing rights. Add an authorization Adds an authorization, which is a discrete right granted to a role or a user. View or change an authorization Displays or changes existing authorizations. For more information on granting rights to users, see Contents of Rights Profiles in System Administration Guide: Security Services.Task Description Add an administrative role Adds a role that someone would use to perform a specific administrative task. Assign rights to an administrative role Assigns specific rights to a role that enable someone to perform a task. Change an administrative role Adds or removes rights from a role. For more information on using administrative roles, see How to Plan Your RBAC Implementation in System Administration Guide: Security Services.Task Description Add a group Adds a group to the local system or name service so that the group name is available before you add the user. Add a user to a group Adds a user to a group if the user needs access to group-owned files. Remove a user from a group Removes a user from a group if the user no longer requires group file access. For information on adding users to groups, see UNIX Groups.Task Description Create a mailing list Creates a mailing list, which is a list of user names for sending email messages. Change a mailing list name Changes the mailing list after it is created. Remove a mailing list Removes a mailing list if it is no longer used. For information on creating mailing lists, see the Solaris Management Console's online help.Task Description Create or clone a project Creates a new project or clones an existing project if the existing project has attributes similar to what you need for the new project. Modify or view project attributes Displays or changes existing project attributes. Delete a project Removes a project if the project is no longer used. Starting with the Solaris 9 release, users and groups can be members of a project, an identifier that indicates a workload component that can be used as the basis of system usage or resource allocation chargeback. Projects are part of the Solaris resource management feature that is used to manage system resources.Users need to be a member of a project to successfully log in to a system running the Solaris 9 release. By default, users are a member of the group.staff project when the Solaris 9 release is installed and no other project information is configured.User project information is stored in the /etc/project file, which can be stored on the local system (files), the NIS name service, or the LDAP directory service. You can use the Solaris Management Console to manage project information.The /etc/project file must exist for users to log in successfully, but requires no administration if you are not using projects.For more information on using or setting up projects, see Chapter 2, Projects and Tasks (Overview), in System Administration Guide: Virtualization Using the Solaris Operating System. user initialization filesdescriptionuser initialization filescustomizinguser initialization filesBourne shellPart 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 file that you can do in a shell script. However, a user initialization file's 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 the following table. Shell User Initialization File Purpose Bourne $HOME/.profile Defines the user's environment at login .cshrc filedescriptionC shelluser initialization files andC $HOME/.cshrc Defines the user's environment for all C shells and is invoked after login shell .login filedescription$HOME/.login Defines the user's environment at login Korn shelluser initialization files andKorn .profile filedescription$HOME/.profile Defines the user's environment at login $HOME/$ENV Defines user's environment at login in the file and is specified by the Korn shell's ENV environment variable user initialization filesdefault/skel directory/etc/skel directoryThe Solaris environment provides default user initialization files for each shell in the /etc/skel directory on each system, as shown in the following table. Shell Default File C shelluser initialization files anduser initialization filesC local.login file/etc/skel/local.login local.cshrc file/etc/skel/local.cshrc Bourne shelluser initialization filesBourne or Korn local.profile file/etc/skel/local.profile user home directoriescustomized initialization files inskeleton directories (/etc/skel)directoriesskeletonaddinguser initialization filesuser initialization filescustomizingadding customized filesYou can use these files as a starting point and modify them to create a standard set of files that provide the work environment common to all users. Or, you can modify these files to provide the working environment for different types of users. Although you cannot create customized user initialization files with the Users tool, you can populate a user's home directory with user initialization files located in a specified “skeleton” directory. You can do this by creating a user template with the User Templates tool and specifying a skeleton directory from which to copy user initialization files. user initialization filescustomizingoverviewFor step-by-step instructions on how to create sets of user initialization files for different types of users, see How to Customize User Initialization Files.When you use the Users tool to create a new user account and select the create home directory option, the following files are created, depending on which login shell is selected.Shell Files Created C The /etc/skel/local.cshrc and the /etc/skel/local.login files are copied into the user's home directory and are renamed .cshrc and .login, respectively. Bourne and Korn The /etc/skel/local.profile file is copied into the user's home directory and renamed .profile. If you use the useradd command to add a new user account and specify the /etc/skel directory by using the k and m options, all three /etc/skel/local* files and the /etc/skel/.profile file are copied into the user's home directory. At this point, you need to rename them to whatever is appropriate for the user's login shell.user initialization filescustomizingsite initialization filessite initialization filesThe 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 customize 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. 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.You can customize a site initialization file the same way that you customize a user 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.user initialization filesshells andC shelluser initialization files andto reference a site initialization fileTo 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-fileTo reference a site initialization file in a Bourne-shell 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 user initialization filescustomizingavoiding local system referencesuser home directoriesnonlocal reference to ($HOME)You should not add specific references to the local system in the user initialization file. You want the instructions in a user initialization file to be valid regardless of which system the user logs into. 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 instead of /export/home/username/bin. The $HOME variable works when the user logs in to another system and the home directories are automounted. To access files on a local disk, use global path names, such as /net/system-name/directory-name. Any directory referenced by /net/system-name can be mounted automatically on any system on which the user logs in, assuming the system is running AutoFS. C shelluser initialization files andcreatingC shellbasic featuresBourne shelluser initialization filesBourne shellbasic features.cshrc filecustomizingKorn shellbasic features.login filecustomizing.profile filecustomizingshellsbasic featuresuser initialization filesshells andThe following table 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. Feature Bourne C Korn Known as the standard shell in UNIX Applicable N/A N/A Compatible syntax with Bourne shell - N/A Applicable Job control Applicable Applicable Applicable History list N/A Applicable Applicable Command-line editing N/A Applicable Applicable Aliases N/A Applicable Applicable Single-character abbreviation for login directory N/A Applicable Applicable Protection from overwriting (noclobber) N/A Applicable Applicable Setting to ignore Control-D (ignoreeof) N/A Applicable Applicable Enhanced cd command N/A Applicable Applicable Initialization file separate from .profile N/A Applicable Applicable Logout file N/A Applicable Bourne shellbasic featuresC shellbasic featuresshellsbasic featuresN/A variablesenvironmentshellsenvironment variables andshellsenvironment ofenvironment variablesdescriptionA 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: displayingenvironment variablesenv commandEnvironment 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, such as PATH, affects the behavior of the shell itself. shellslocal variablespath shell variablevariablesshell (local)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. set commandC shellshell (local) variables andC shellenvironment variables andsetenv commandIn the C shell, you use the lowercase names with the set command to set shell variables. You use uppercase names with the setenv command to set environment variables. If you set a shell variable, the shell sets the corresponding environment variable. Likewise, if you set an environment variable, the corresponding shell variable is also updated. 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 can use the uppercase variable name equal to some value to set both shell and environment variables. You also have to use the export command to activate the variables for any subsequently executed commands.For all shells, you generally refer to shell and environment variables by their uppercase names. user initialization filescustomizingenvironment variablesshellsenvironment variables andIn 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. The following table shows how to set environment variables in a user initialization file. Shell Type Line to Add to the User Initialization File C shellshell (local) variables andC shellenvironment variables andC shell setenv commandsetenv VARIABLE value MAIL environment variableExample: setenv MAIL /var/mail/ripley Bourne or Korn shell VARIABLE=value; export VARIABLEExample:MAIL=/var/mail/ripley;export MAIL user initialization filescustomizingshell variablesshellslocal variablesshell variablesThe following table describes environment variables and shell variables that you might want to customize in a user initialization file. For more information about variables that are used by the different shells, see the sh1, ksh1, or csh1 man pages.Variable Description CDPATH environment variableCDPATH, 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 first looks 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. history environment variablehistory Sets the history for the C shell. HOME environment variableHOME, or home in the C shell Sets the path to the user's home directory. locale environment variableLANG environment variableLANG Sets the locale. LOGNAME environment variableLOGNAME environment variablesLOGNAME Defines the name of the user currently logged in. The default value of LOGNAME is set automatically 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 environment variableenvironment variablesLPDESTLPDEST Sets the user's default printer. MAIL environment variableMAIL Sets the path to the user's mailbox. MANPATH environment variableMANPATH Sets the hierarchies of man pages that are available. PATH environment variabledescriptiondirectoriesPATH environment variable andPATH, or path in the C shell Specifies, 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. environment variablesPATHAs part of the login process, the default PATH is automatically defined and set as specified in .profile (Bourne or Korn shell) or .cshrc (C shell). 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 shell variableprompt Defines the shell prompt for the C shell. PS1 environment variablePS1 Defines the shell prompt for the Bourne or Korn shell. environment variablesSHELLSHELL environment variableSHELL, or shell in the C shell Sets the default shell used by make, vi, and other tools. TERMINFO environment variableTERMINFO Specifies the path name for an unsupported terminal that has been added to the terminfo file. Use the TERMINFO variable in either the /etc/profile or /etc/.login file. When the TERMINFO environment variable is set, the system first checks the TERMINFO path defined by the user. If the system 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 the system does not find a definition in either location, the terminal is identified as “dumb.” TERM environment variableTERM, or term in the C shell Defines the terminal. This variable should be reset in either the /etc/profile or /etc/.login file. When the user invokes an editor, the system looks for a file with the same name that is defined in this environment variable. The system searches the directory referenced by TERMINFO to determine the terminal characteristics. TZ environment variabletime zone environment variableTZ environment variablesTZuser initialization filescustomizingshell variablesSets the time zone. The time zone 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. PATH environment variabledescriptiondirectoriesPATH environment variable andWhen 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 the command. A default path is set by the system. However, most users modify it to add other command directories. Many user problems related to setting up the environment and accessing the correct version of a command or a tool can be traced to incorrectly defined paths.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 might want to avoid, especially for superuser. 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 that 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 mounted directories to lessen the chance of “hanging” when the NFS server does not respond. This strategy also reduces unnecessary network traffic. This is an example of how to set a user's default path.environment variablesPATH directoriesPATH environment variable andPATH environment variablesetting upThe 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-shell or Korn-shell user initialization file, you would add the following:PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin export PATH LC environment variablesLANG environment variablestty commandThe LANG and LC environment variables specify the locale-specific conversions and conventions for the shell. These conversions and conventions include 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 indicate whether the terminal session will support multibyte characters. The LANG variable sets all possible conversions and conventions for the given locale. 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.The following table describes some of the values for the LANG and LC environment variables.Value Locale de_DE.ISO8859-1 German en_US.UTF-8 American English (UTF-8) es_ES.ISO8859-1 Spanish fr_FR.ISO8859-1 French it_IT.ISO8859-1 Italian ja_JP.eucJP Japanese (EUC) ko_KR.EUC Korean (EUC) sv_SE.ISO8859-1 Swedish zh_CN.EUC Simplified Chinese (EUC) zh_TW.EUC Traditional Chinese (EUC) For more information on supported locales, see the International Language Environments Guide.C shellenvironment variables andLANG environment variableLC environment variablesenvironment variablesdescriptionvariablesenvironmentshellsenvironment variables anduser initialization filescustomizingenvironment variablesThe following examples show how to set the locale by using the LANG environment variables. In a C-shell user initialization file, you would add the following:setenv LANG de_DE.ISO8859-1In a Bourne-shell or Korn-shell user initialization file, you would add the following:LANG=de_DE.ISO8859-1; export LANG filescontrolling access todirectoriescontrolling access tocontrolling file and directory accessuser initialization filescustomizinguser mask settingpermissionsuser maskdisplayinguser maskumask commandWhen 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 is 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 contains the following octal values:The first digit sets permissions for the user The second digit sets permissions for group The third digit sets permissions for other, also referred to as world Note that if the first digit is zero, it is not displayed. For example, if the user mask 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 the following table. This table shows the file and directory permissions that are created for each of the octal values of 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 user initialization filesexamplesThe following sections provide examples of user and site initialization files that you can use to start customizing your own initialization files. These examples use system names and paths that you need to change for your particular site. user initialization filescustomizing C shelluser initialization files and .cshrc filecustomizing .login filecustomizing .profile filecustomizing shellsuser initialization files and user initialization filesshells and (Line 1) PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. (Line 2) MAIL=/var/mail/$LOGNAME (Line 3) NNTPSERVER=server1 (Line 4) MANPATH=/usr/share/man:/usr/local/man (Line 5) PRINTER=printer1 (Line 6) umask 022 (Line 7) export PATH MAIL NNTPSERVER MANPATH PRINTERDefines the user's shell search path Defines the path to the user's mail file Defines the user's Usenet news server Defines the user's search path for man pages Defines the user's default printer Sets the user's default file creation permissions Sets the listed environment variables (Line 1) set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin) (Line 2) setenv MAIL /var/mail/$LOGNAME (Line 3) setenv NNTPSERVER server1 (Line 4) setenv PRINTER printer1 (Line 5) alias h history (Line 6) umask 022 (Line 7) source /net/server2/site-init-files/site.login Defines the user's shell search path. Defines the path to the user's mail file. Defines the user's Usenet news server. Defines the user's default printer. Creates an alias for the history command. The user needs to type only h to run the history command. Sets the user's default file creation permissions. Sources the site initialization file. The following 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 endswThis 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.loginIn this line, the site initialization file is named site.login and is located on a server named server2. This line also assumes that the automounter is running on the user's system.