Managing Users Across Multiple Systems

Maintain unique, “global” user IDs across systems.

You need to ensure that each login name has a unique user-ID number (uid) across all the systems on which the user logs in; otherwise one user may be able to read another user’s private files. This is a serious potential problem whether or not the home directory is NFS-mounted.

SAM (the menu-driven System Administration Manager) will warn you if you choose a uid that is not unique on the local system, but this may not be enough. For example, if user jack has a uid of 215 and gid (group id) of 20 on his own system, and you set him up with the same uid and gid on a remote system (for example by cutting and pasting his /etc/passwd entry from the local to the remote system), and user jill on the remote system already has uid 215 and gid 20, then jack will be able to read jill’s private files.

Conversely, suppose you use SAM to make sure that jack has a unique ID on each system. SAM verifies that uid 215 is unique on jack’s local system, and that 301 is unique on jill’s system. Both systems have a directory named /common_stuff NFS-mounted from a file server. When jack logs in to jill’s system, he may find he cannot read some of his own files under /common_stuff; he in fact won’t be able to read any files he has saved on his own system with user-read-write or user-read-only permissions.

This comes about because HP-UX looks strictly at the uid and gid fields when checking who has permission to do what to a file; the user name is irrelevant.

Some sites have an automated service that assigns uids that are unique site-wide. If your site offers such a service, use it; otherwise, you will have to devise your own method of checking that the uid you assign each new login is unique across all the systems the user will have access to.

Distributing mail directories from a central point allows you to set up a mail hub for the group, simplifying mail maintenance.

This is often a good idea. Users will need accounts, with their “global” uid’s, on the mail server, whether or not they log into it. See “Networking Topographies” for more information.

Distributing home directories from the file server simplifies backup and allows each user to log in on any workstation in the workgroup (see “Should You Share Users’ Home and Mail Directories?”).

This may or may not be desirable, depending on such factors as your hardware budget, maintenance budget (if you pay for backup services), patterns of use, and site or department security policies.

If you plan to centralize users’ home directories in this way, you should make sure each user has at least a minimal home environment on his or her local disk, so that they can log in and do at least some work even if the file server is down.

One way to do this is to create the user’s home directory on the local disk first, then import the “real” home directory from the server. When the server is up, only the “real” (imported) directory will be visible; when the server is down, the directory on the local disk will once again become visible and the user will still be able to log in.

backup

Even if you instruct your users not to leave important data in their home directories, or in their mail boxes, they will probably do it anyway, so these directories will need to be backed up each day. It is much easier to back them up from one central location than to back up each workstation individually.

mail configuration and maintenance

It often makes sense to configure one system in the workgroup as the group’s mail hub, and in this case some users may want to import /var/mail so they can run their mailer on their local system rather than logging in to the mail server.

If you are using a mail hub, you must ensure that each user has an account on the mail hub (whether or not they ever log in to it) and that their user id (uid) and group id (gid) are the same on the hub as on their local workstation. Otherwise mail will not be routed correctly.

See “Networking Topographies” for further discussion.

workstation sharing

If you export users’ mail and home directories to other workstations in the group, and maintain identical entries for each user in each /etc/passwd file, then any user will be able to log in to any workstation - useful if users come in at different times or on different shifts and you don’t have enough hardware for everyone, or if some workstations in the group have hardware or software that you want people to use by logging in to the workstation in question