ADDXUSERS(ADM) UNIX System V
Name
addxusers - creates new user accounts given a traditional
password file
Syntax
/tcb/bin/addxusers [ -esuv ] [ -t type ] [ file ]
Description
addxusers reads the specified file, which should be in
traditional passwd(F) format (as found on XENIX systems),
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.
With the -u option, addxusers expects file to contain a list
(one per line) of usernames to add to the Protected Password
database. Each user must already have an entry in
/etc/passwd, which is used to make an equivalent entry for
the user in the Protected Password database. The user's
password file entry should be in traditional passwd(F)
format (the encrypted password is preserved and aging
information is translated into expiration parameters). This
allows the system administrator to manually add entries to
the /etc/passwd file, then easily correct the protected
password database to reflect these additions. This facility
is used by the passwdupd(ADM) command.
The -v option displays a ``being processed'' message (which
includes the username) for each user addxusers attempts to
add to the system.
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.|
|_______|____________|____________________|____________________________________|
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). (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 /).
2. Make a copy of /etc/passwd and /etc/group from the
XENIX system. (Do not back these files up with
absolute path names either.)
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 a
mounted filesystem 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
...
(If the /tcb/bin is not in the root PATH variable, you
must specify the full pathname.) 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), passwdupd(ADM), rmuser(ADM), su(C),
sysadmsh(ADM), tar(C), tee(C), unretire(ADM)
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 unsecure 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, the nice value is supported, but
sublogins are not in SCO System V and cause a warning.
Value Added
addxusers is an extension of AT&T System V provided by the
Santa Cruz Operation.
(printed 1/7/91) ADDXUSERS(ADM)