ADDXUSERS(ADM) UNIX System V
Name
addxusers - Create new user accounts given a XENIX-style
password file
Syntax
addxusers [ -e ] [ -t type ]
Description
addxusers reads the standard input, 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.
Login names must begin with a lower case letter, must not
already exist, must not contain a slash (``/''), and must
not be longer than 12 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 minimual 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. 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. Backup the home directories of the users on the XENIX
system using cpio(C) or tar(C).
2. Make a copy of the /etc/passwd and /etc/group from the
XENIX system. (Do not backup these files using
absolute pathnames!)
3. Extract the backup of the user's home directories on
the new system.
4. Extract the copy of the passwd and group files in a
temporary directory; say, /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 which already exist on
the new system.
6. Separate the remaining accounts (all of which are to be
added to the new system) into distinct files by user
type; say, all ``pseudo-users'' into /tmp/pseudo and
all ``individual'' humans into /tmp/individual.
7. Change login names, numeric user IDs, numeric group
IDs, initial working directories, and shell programs as
necessary. (If any numeric user or group IDs are
changed, it may be desirable to chown(C) or chgrp(C)
the appropriate home directories 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). Note that editing the /etc/group file must
be done only while in single-user mode; if the file is
modified while in multi-user mode, no-one may be able
to log in afterwards.
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.
10. 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 option is 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 1/23/90) ADDXUSERS(ADM)