HP-UX Virtual Partitions

By Marty Poniatowski

As you may have guessed by now, performing system administration functions on your HP-UX system is easy; the planning is what takes time and effort. Setting up users and groups is no exception. Thanks to SAM, doing just about anything with users and groups is simple.

One exception exists to this easy setup: HP (Common Desktop Environment) CDE customization. SAM doesn't really help with HP CDE customization and it can be quite tricky to modify one's HP CDE setup manually. I have Chapter 13 to assist you with HP CDE customization.

You need to make a few basic decisions about users. Where should users' data be located? Who needs to access data from whom, thereby defining "groups" of users? What kind of particular startup is required by users and applications? Is there a shell that your users prefer?

You will want to put some thought into these important user-related questions. I spend a lot of time working with my customers, rearranging user data, for several reasons. It doesn't fit on a whole disk (for this reason, I strongly recommend using Logical Volume Manager or Veritas Volume Manager); users can't freely access one another's data, or even worse, users can access one another's data too freely.

We will consider these questions, but first, let's look at the basic steps to adding a user, whether you do this manually or rely on SAM. Here is a list of activities:

• Select a user name to add

• Select a user ID number

• Select a group for the user

• Create an/etc/passwd entry

• Assign a user password (including expiration options)

• Select and create a home directory for user

• Select the shell the user will run (I strongly recommend the default POSIX shell)

• Place startup files in the user's home directory

• Test the user account

This list may seem like a lot of work, but there is nothing to it if you run SAM and answer the questions. Most of what you do is entered in the /etc/passwd file, where information about all users is stored. You can make these entries to the /etc/passwd file with the /usr/sbin/vipw command. Figure 6-3 is a sample /etc/passwd entry.

Here is a description of each of these fields:

name. The user name you assign. This name should be easy for the user and other users on the system to remember. When sending electronic mail or copying files from one user to another, the easier it is to remember the user name the better. If a user has a user name on another system, you may want to assign the same user name on your HP-UX system. Some systems don't permit nice, easy user names, so you may want to break the tie with the old system and start using sensible, easy-to-remember user names on your HP-UX system. Remember, no security is tied to the user name; security is handled through the user's password and the file permissions.

password. This is the user's password in encrypted form. If an asterisk appears in this field, the account can't be used. If it is empty, the user has no password assigned and can log in by typing only his or her user name. I strongly recommend that each user have a password that he or she changes periodically. Every system has different security needs, but at a minimum, every user on every system should have a password. When setting up a new user, you can force the user to create a password at first login by putting ,.. in the password field. Password aging can easily be set in SAM.

Some features of a good password are:

• A minimum of six characters that should include special characters such as a slash (/), a dot (.), or an asterisk (*).

• No words should be used for a password.

• Don't make the password personal such as name, address, favorite sports team, etc.

• Don't use something easy to type such as 123456, or qwerty.

• Some people say that misspelled words are acceptable, but I don't recommend using them. Spell-check programs that match misspelled words to correctly spelled words can be used to guess at words that might be misspelled for a password.

• A password generator that produces an intelligible passwords works the best.

user ID (UID). The identification number of the user. Every user on your system should have a unique UID. There are no conventions for UIDs. SAM will assign a UID for you when you add users, but you can always change this. I would recommend that you reserve UIDs less than 100 for system-level users.

group ID (GID). The identification number of the group. The members of the group and their GID are in the /etc/group file. You can change the GID assigned if you don't like it, but you may also have to change the GID of many files. As a user creates a file, his or her UID is assigned to the file as well as the GID. This means if you change the GID well after users of the same group have created many files and directories, you may have to change the GID of all these elements. I usually save GIDs less than 10 for system groups.

optional user info. In this space, you can make entries, such as the user's phone number or full name. SAM asks you for this information when you create a user. You can leave this blank, but if you manage a system or network with many users, you may want to add the user's full name and extension so that if you need to get in touch with him or her, you'll have the information at your fingertips. (This field is sometimes referred to as the GECOs field.)

home directory. The home directory defines the default location for all the users' files and directories. This is the present working directory at the time of login.

shell. This is the startup program the user will run at the time of login. The shell is really a command interpreter for the commands the user issues from the command line. I recommend using the default POSIX shell (/ usr/bin/sh), but there are also three traditional, popular shells in the HP-UX environment: the C shell (/usr/bin/csh); Bourne shell (/usr/old/bin/sh); and Korn shell (/usr/bin/ksh). Shell programming for the system administrator is covered in Chapter 6.

The location of the user's home directory is another important entry in the /etc/passwd file. You have to select a location for the user's "home" directory in the file system where the user's files will be stored. With some of the advanced networking technology that exists, such as NFS, the user's home directory does not even have to be on a disk that is physically connected to the computer he or she is using! The traditional place to locate a user's home directory on an HP-UX system is the /home directory in HPUX 11.x.

The /home directory is typically the most dynamic area in terms of growth. Users create and delete files in their home directory on a regular basis. This means you have to do more planning related to your user area than in more static areas, such as the root file system and application areas. You would typically load HP-UX and your applications and then perform relatively few accesses to these in terms of adding and deleting files and directories. The user area is continuously updated, making it more difficult to maintain.

Assigning Users to Groups

After defining all user-related information, you need to consider groups. Groups are often overlooked in the HP-UX environment until the system administrator finds that all his or her users are in the very same group, even though from an organizational standpoint, they are in different groups. Before I cover the groups in general, let's look at a file belonging to a user and the way access is defined for a file:

$ ll -rwxr-x--x 1 marty users 120 Jul 26 10:20 sort

For every file on the system, HP-UX supports three classes of access:

• User access (u). Access is granted to the owner of the file

• Group access (g). Access granted to members of the same group as the owner of the file

• Other access (o). Access granted to everyone else

These access rights are defined by the position of r (read), write (w), and execute (x) when the long listing command is issued. For the long listing (ll) above, you see the permissions in Table 6-1.

You can see that access rights are arranged in groups of three. Three groups of permissions exist with three access levels each. The owner, in this case, marty, is allowed read, write, and execute permissions on the file. Anyone in the group users is permitted read and execute access to the file. Others are permitted only execute access of the file.

These permissions are important to consider as you arrange your users into groups. If several users require access to the same files, then you will want to put those users in the same group. The trade-off here is that you can give all users within a group rwx access to files, but then you run the risk of several users editing a file without other users knowing it, thereby causing confusion. On the other hand, you can make several copies of a file so that each user has his or her personal copy, but then you have multiple versions of a file. If possible, assign users to groups based on their work.

When you run SAM and specify the groups to which each user belongs, the file /etc/group is updated. The /etc/group file contains the group name, an encrypted password (which is rarely used), a group ID, and a list of users in the group. Here is an example of an /etc/group file:

root::0:root other::1:root, hpdb bin::2:root,bin sys::3:root,uucp adm::4:root,adm daemon::5:root,daemon mail::6:root lp::7:root,lp tty::10: nuucp::11:nuucp military::25:jhunt,tdolan,vdallesandro commercial::30:ccascone,jperwinc,devers nogroup:*:-2:

This /etc/group file shows two different groups of users. Although all users run the same application, a desktop publishing tool, some work on documents of "commercial" products while others work on only "military" documents. It made sense for the system administrator to create two groups, one for commercial document preparation and the other for military document preparation. All members of a group know what documents are current and respect one another's work and its importance. You will have few problems among group members who know what the other members are doing and you will find that these members don't delete files that shouldn't be deleted. If you put all users into one group, however, you may find that you spend more time restoring files, because users in this broader group don't find files that are owned by other members of their group to be important. Users can change group with the newgrp command.