A network of fast, highly connected systems without "users" is a pleasant daydream for many system administrators....
The reality would probably be boring, though; no need for new technologies, no amusement at the replies to the "is it plugged in" question, and no war stories about amazing technological ineptitude to tell at meetings and conferences.
Let's face it: We are stuck with users and new computers, and that means that eventually we'll have to move users' home directories to new disks or machines. You may not have had to do this yet, or you might have done it and had problems. In either case, here are the primary issues to which you must pay attention.
You either must (or should) preserve:
- User and group ID (ownership);
- Date and time stamps
for all objects.
The user and group owner names that show up in an "ls -l" are not stored with objects (files and directories). Only the UID and GID numbers are stored in the VTOCE block on disk. The "ls" command looks up these numbers and reports the matching names from the passwd and group databases (e.g., whatever technique you are using: files, nis, etc.).
If the users' files are moving onto a machine that uses the same databases (e.g., is within the NIS domain, on the same server, etc.), then all you must do is preserve the object's ownership.
If you're moving the user to a machine using a different password/group database, things are more complex. In this situation, you must either create a new user and group on the new machine with the same UID/GID numbers, or change the numbers on all files to whatever you give the new account (chown -R UID:GID). What you do will probably depend on whether the user's UID is already in use on the new machine. To find a user's UID/GID, either issue the "ID" command when logged in as that user, or look the username up in the passwd database.
When adding a new user, most LINUX systems have some variety of "useradd" or "userconf," which will allow you to specify the UID and GID to be used.
When you do the actual move of the files, be sure to use the correct options to preserve permissions and date/time stamps. Most commands accept options to the "restore" part of the command for this purpose (tar has "-p," pax has "e," unzip has "-X," etc.).
Losing date and time stamps is mostly a nuisance, but losing permissions can cause both security and application problems.
Fred Mallett is founder of FAME Computer Education, which provides standup delivery of educational classes on a variety of UNIX, Linux and Win32 related subjects. Reach him at email@example.com.