addxusers --
create new user accounts given a traditional password file
Syntax
/tcb/bin/addxusers
[ -efsuv ]
[ -ttype ]
[ file ]
Description
addxusers reads the specified password file,
and creates the indicated user accounts by making equivalent entries
in the /etc/passwd file and Protected Password database.
file should be in traditional
passwd(F)
format (as found on XENIX® systems).
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.
addxusers reads from the standard input
if file is specified as ``-''.
Login names must begin with a lowercase letter
(this may be overridden using the -f option),
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
(this may be overridden using the -f option),
and must be in the range 0 to 60000 (inclusive).
Numeric group IDs must be in the range 0 to 60000 (inclusive).
Groups that are missing from the file /etc/group
generate a warning; membership in groups associated
with protected subsystems also generate warnings.
Encrypted passwords are preserved; users are able to use
their old XENIX passwords to log onto the new system.
Any password aging information that is present is
translated into the equivalent expiration parameters.
The comment field, initial working directory (home directory),
and login shell are preserved. addxusers warns about
missing or inaccessible directories and shells, and
non-absolute pathnames. Users should not share home directories.
addxusers takes the following options:
-e
Applies the same checks to existing users as those
for new users (except for membership in
a protected subsystem group).
Normally, only minimal checks for corruption are carried out on
the existing /etc/passwd file before the new users are added:
checks are only performed for duplicated login names or
numeric user IDs, and bad format.
These are all fatal errors, and prevent any new users from being added.
-f
Forces addxusers to allow multiple accounts with the
same UID, or accounts with names beginning with a
digit or non-alphanumeric character. addxusers also
displays a warning message.
-s
Checks the existing users for membership
in a protected subsystem group. As with new user accounts,
not all of the problems that may be discovered are fatal
(many are only warnings).
Duplicate group names or numeric group IDs in the
/etc/group file generate warnings.
However, if a protected subsystem group is corrupted in this way,
this is a fatal error (no users are added).
-ttype
Sets the type of each created user;
if omitted, each user is classified as an ``individual''.
The legal type values are:
Number
Name in prpw
Name in authsh
Comment
0
root
superuser
All-powerful user (UID 0).
1
operator
operator
Various classifications of
2
sso
security officer
anonymous system
3
admin
administrator
admininstration accounts.
4
pseudo
pseudo-user
General-purpose anonymous user.
5
general
individual
An individual's personal account.
6
retired
retired
An account that is no longer used.
You can specify type as a number, a name from the
Protected Password database
prpw(F),
or as the name reported by
authsh(ADM).
-u
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 XENIX format in
/etc/passwd; this is used to make an equivalent entry
for the user in the Protected Password database.
This allows the system administrator to add entries manually to the
/etc/passwd file, then easily correct the protected password database
to reflect these additions.
-v
Displays a ``being processed'' message (which
includes the username) for each user addxusers attempts to add
to the system.
addxusers preserves any Network Information Service
(NIS) entries in /etc/passwd and file.
These entries are recognized by lines beginning with ``+''
or ``-''.
Examples
The following steps should be performed when migrating a
community of users from a XENIX system:
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 /.)
Make a copy of /etc/passwd and /etc/group
from the XENIX system.
(Do not back these files up with absolute pathnames either.)
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.)
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.
Edit /tmp/passwd to remove ``system'' accounts (such as
root and bin)
and any accounts that already exist on the new system.
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'' users in /tmp/individual.
In your sorted /tmp account files, you should 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 and their contents on the new system.)
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 login.
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 rootPATH
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 manager or
usermod(ADM)
to customize the newly created accounts as needed.
The authorizations may need customization. Accounts that are neither
individuals nor retired should be assigned ``account which may su''.
Limitations
When logging in, XENIX truncates passwords to eight characters;
the SCO OpenServer system does not.
Therefore, the user must not type more than
eight characters when the password from the XENIX system is in effect.
Accounts without passwords and other liberties that XENIX allows
are more restricted in UNIX 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 vendors' systems support specifying a
nice(S-osr5)
value in the comment field, or doing a
chroot(S-osr5)
to the home directory (called a sublogin).
Both constructions are understood by addxusers,
and the nice value is supported, but sublogins are not in
UNIX System V and cause a warning.
Authorization
The auth subsystem and
chown kernel privileges are required
to run addxusers.
system does not.
Therefore, the user must not type more than
eight characters when the password from the XENIX system is in effect.