ADDXUSERS(ADM) UNIX System V
Name
addxusers - create new user accounts given a XENIX-style
password file
Syntax
/tcb/bin/addxusers [ -e ] [ -s ] [ -t type ] [ file ]
Description
addxusers reads the specified file, which should be in XENIX
passwd(F) format, and creates the indicated accounts by
making equivalent entries in the system's /etc/passwd file
and Protected Password database. The auth subsystem and
chown kernel authorizations are required to run addxusers.
If no file is given, addxusers does not attempt to add any
new users and only performs certain consistency checks on
the existing user accounts. A file of - means that the
standard input should be read.
Login names must begin with a lower case letter, must not
already exist, must not contain a slash (``/''), and must
not be longer than 8 characters.
Numeric user IDs must not be already assigned, and must be
in the range 0 to 60000 (inclusive).
Numeric group IDs must be in the range 0 to 60000
(inclusive). Groups which are missing from the file
/etc/group are warned about, as is membership in a group
associated with a protected subsystem.
Encrypted passwords are preserved; that is, users will be
able to use their old XENIX passwords to log onto the new
system.
Any password aging information which is present is
translated into the equivalent expiration parameters.
The comment field, initial working directory (home
directory), and shell program are preserved. Missing or
inaccessible directories and shells are warned about, as are
non-absolute pathnames. Users should not share home
directories.
The -t option sets the type of each created user; if
omitted, each user is classified as an ``individual''
person. The legal type values are:
_______________________________________________________________________________
| User type values | |
| Number| Equivalent names | Comments |
|_______|____________|____________________|____________________________________|
| 0 | root | superuser | All-powerful user (numeric ID 0). |
|_______|____________|____________________|____________________________________|
| 1 | operator | | |
|_______|____________|____________________| Various classifications of |
| 2 | sso | security officer | anonymous system administration |
|_______|____________|____________________| accounts. |
| 3 | admin | administrator | |
|_______|____________|____________________|____________________________________|
| 4 | pseudo | pseudo-user | General-purpose anonymous user. |
|_______|____________|____________________|____________________________________|
| 5 | general | individual | A human's personal account. |
|_______|____________|____________________|____________________________________|
| 6 | retired | | An account which is no longer used.|
|_______|____________|____________________|____________________________________|
A ``retired'' user cannot log in and cannot be un-retired.
No user may su(C) to an ``individual'' account.
Normally, only minimal checks for corruption are done on the
existing /etc/passwd file before the new users are added:
Checks are only done for duplicated login names or numeric
user IDs, and bad format. (These are all fatal errors, and
prevent any new users from being added.) The -e option
causes the same checks which are applied to new users to be
applied to the existing users (except for membership in a
protected subsystem group). The -s option checks the
existing users for being a member of a protected subsystem
group. As with new user accounts, not all of the problems
which may be discovered are fatal (many are only warnings).
Duplicated group names or numeric group IDs in the
/etc/group file are warned about. However, if a protected
subsystem group is so corrupted, this is a fatal error (no
users are added).
Example
The following steps should be performed when migrating a
community of users from a XENIX system:
1. Back up the home directories of the users on the XENIX
system using cpio(C) or tar(C).
2. Make a copy of /etc/passwd and /etc/group from the
XENIX system. (Do not back up these files using
absolute pathnames. For example, if your accounts are
in /usr, run your backup command from that directory,
not from /.)
3. After making certain you are in single user mode,
extract the backup of the user's home directories on
the new system. For example, if your user accounts
reside in /usr, the files should be extracted in /usr
on the new system. (Note that if you are using /u for
your accounts, you must mount it before extracting your
backups.)
4. Extract the copy of the passwd and group files in a
temporary directory; for example, /tmp/passwd and
/tmp/group. Be careful not to overwrite the
/etc/passwd and /etc/group files on the new system.
5. Edit /tmp/passwd to remove ``system'' accounts (such as
root and bin) and any accounts that already exist on
the new system.
6. Separate the remaining accounts in /tmp/passwd (which
are to be added to the new system) into different files
by user type. For example, place all ``pseudo-users''
in a file called /tmp/pseudo and all ``individual''
humans in /tmp/individual.
7. In your sorted /tmp account files, you should then
change login names, numeric user IDs, numeric group
IDs, initial working directories, and shell programs as
necessary to prevent conflicts with any accounts
already on the new system. (If any numeric user or
group IDs are changed, it may be desirable to chown(C)
or chgrp(C) the appropriate home directories on the new
system and their contents.)
8. Merge /tmp/group (the saved copy of the XENIX system's
/etc/group) with the new system's /etc/group; see
group(F). Again, make certain you are still in
single-user mode; if /etc/group is modified while in
multi-user mode, no-one will be allowed to log in.
9. Run addxusers :
addxusers -t pseudo-user /tmp/pseudo 2>&1 | tee -a
/tmp/errors
addxusers -t individual /tmp/individual 2>&1 | tee -a
/tmp/errors
...
It is advisable to save the standard output and error
output of addxusers (as shown above) for later analysis
and correction.
Finally, use the Accounts->User->Examine menu of
sysadmsh(ADM) to customize the newly-created accounts as
needed.
The authorizations may need customization, and accounts
which are neither individuals nor retired should have an
``account which may su'' assigned.
See Also
authcap(F), chgrp(C), chown(C), cpio(C), group(F),
passwd(F), su(C), sysadmsh(ADM), tar(C), tee(C)
Notes
When logging in, XENIX truncates passwords to eight (8)
characters; SCO System V does not. Therefore, the user must
not type more than eight characters when the password from
the XENIX system is in effect.
Passwordless accounts and other liberties XENIX allows are
more restricted in SCO System V. To continue to use such
poor security practices requires customizing the system
defaults or the insecure accounts.
Some standard accounts shipped with the system provoke
warnings when the -e or -s options are specified.
Some vendor's systems support specifying a nice(S) value in
the comment field, or doing a chroot(S) to the home
directory (called a sublogin). Both constructions are
understood by addxusers, albeit sublogins are not supported
in SCO System V and cause a warning.
(printed 5/24/90) ADDXUSERS(ADM)