addxusers(ADM)


addxusers -- create new user accounts given a traditional password file

Syntax

/tcb/bin/addxusers [ -efsuv ] [ -t type ] [ 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).


-t type
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.

 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:

  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 pathnames 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'' users in /tmp/individual.

  7. 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.)

  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 login.

  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 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(TM) 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.

See also

authcap(F), chgrp(C), chown(C), cpio(C), group(F), passwd(F), prpw(F), rmuser(ADM), su(C), useradd(ADM), tar(C), tee(C), unretire(ADM)

Standards conformance

addxusers is not part of any currently supported standard; it is an extension of AT&T System V provided by The Santa Cruz Operation, Inc.
© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 03 June 2005