smmultiuser(1M) System Administration Commands smmultiuser(1M)NAMEsmmultiuser - manage bulk operations on user accounts
SYNOPSIS
/usr/sadm/bin/smmultiuser subcommand [ auth_args] -− [subcom‐
mand_args]
DESCRIPTION
The smmultiuser command allows bulk operations on user entries in the
local /etc filesystem or a NIS or NIS+ name service, using either an
input file or piped input. Note: Both input files and piped input con‐
tain a cleartext (non-encrypted) password for each new user entry.
subcommands
smmultiuser subcommands are:
add Adds multiple user entries to the appropriate files. To
add an entry, the administrator must have the
solaris.admin.usermgr.write authorization.
delete Deletes one or more user entries from the appropriate
files. To delete an entry, the administrator must have
the solaris.admin.usermgr.write authorization.
modify Modifies existing user entries in the user account
database. To modify an entry, the administrator must
have the solaris.admin.usermgr.write authorization.
Here is the list of what can be modified using the mod‐
ify subcommand:
1. UserName (only under certain conditions; see
Note 2 in NOTES).
2. Password (only under certain conditions; see
Note 3 in NOTES). To modify a password, the
administrator must have the solaris.admin.user‐
mgr.pswd authorization.
3. Description.
4. Primary Group ID.
5. Shell type.
6. FullName.
OPTIONS
The smmultiuser authentication arguments, auth_args, are derived from
the smc(1M) arg set and are the same regardless of which subcommand you
use. The smmultiuser command requires the Solaris Management Console to
be initialized for the command to succeed (see smc(1M)). After reboot‐
ing the Solaris Management Console server, the first Solaris Management
Console connection might time out, so you might need to retry the com‐
mand.
The subcommand-specific options, subcommand_args, must come after the
auth_args and must be separated from them by the -− option.
auth_args
The valid auth_args are -D, -H, -l, -p, -r, -−trust, and -u; they are
all optional. If no auth_args are specified, certain defaults will be
assumed and the user may be prompted for additional information, such
as a password for authentication purposes. These letter options can
also be specified by their equivalent option words preceded by a double
dash. For example, you can use either -D or -−domain.
-D | -−domain domain
Specifies the default domain that you want to manage. The syntax of
domain is type:/host_name/domain_name, where type is nis, nisplus,
dns, ldap, or file; host_name is the name of the machine that
serves the domain; and domain_name is the name of the domain you
want to manage. (Note: Do not use nis+ for nisplus.)
If you do not specify this option, the Solaris Management Console
assumes the file default domain on whatever server you choose to
manage, meaning that changes are local to the server. Toolboxes can
change the domain on a tool-by-tool basis; this option specifies
the domain for all other tools.
-H | -−hostname host_name:port
Specifies the host_name and port to which you want to connect. If
you do not specify a port, the system connects to the default port,
898. If you do not specify host_name:port, the Solaris Management
Console connects to the local host on port 898. You may still have
to choose a toolbox to load into the console. To override this
behavior, use the smc(1M)-B option, or set your console prefer‐
ences to load a "home toolbox" by default.
-l | -−rolepassword role_password
Specifies the password for the role_name. If you specify a
role_name but do not specify a role_password, the system prompts
you to supply a role_password. Passwords specified on the command
line can be seen by any user on the system, hence this option is
considered insecure.
-p | -−password password
Specifies the password for the user_name. If you do not specify a
password, the system prompts you for one. Passwords specified on
the command line can be seen by any user on the system, hence this
option is considered insecure.
-r | -−rolename role_name
Specifies a role name for authentication. If you do not specify
this option, no role is assumed.
-−trust
Trusts all downloaded code implicitly. Use this option when running
the terminal console non-interactively and you cannot let the con‐
sole wait for user input.
If using piped input into any of the smmultiuser subcommands, it
will now be necessary to use the -−trust option with the -L logfile
option. See EXAMPLES.
-u | -−username user_name
Specifies the user name for authentication. If you do not specify
this option, the user identity running the console process is
assumed.
-−
This option is required and must always follow the preceding
options. If you do not enter the preceding options, you must still
enter the -− option.
subcommand_args
Note: Descriptions and other arg options that contain white spaces must
be enclosed in double quotes.
· For subcommand add:
-h
(Optional) Displays the command's usage statement.
-i input_file
Specifies the input file containing the user account informa‐
tion. After the command is executed, the input file is
removed. The input file must follow the /etc/passwd file for‐
mat. If you do not specify the -i input_file option, you must
include a piped_input operand immediately before the command.
See EXAMPLES.
-L logfile
(Optional) Specifies the full pathname to the text file that
stores the command's success/failure data. Note: This text
file is an ASCII—formatted log file; it is different from and
unrelated to the output of the normal logging mechanism that
also occurs within the Log Viewer tool. The -L logfile option
is used to dump additional logging information to a text file.
· For subcommand delete:
-h
(Optional) Displays the command's usage statement.
-i input_file
Specifies the input file containing the user account informa‐
tion. After the command is executed, the input file is
removed. The input file must follow the /etc/passwd file for‐
mat. If you do not specify the -i input_file option, you must
include a piped_input operand immediately before the command.
See EXAMPLES.
-L logfile
(Optional) Specifies the full pathname to the text file that
stores the command's success/failure data.
· For subcommand modify:
-h
(Optional) Displays the command's usage statement.
-i input_file
Specifies the input file containing the user account informa‐
tion. After the command is executed, the input file is
removed. The input file must follow the /etc/passwd file for‐
mat. If you do not specify the -i input_file option, you must
include a piped_input operand immediately before the command.
See EXAMPLES. Note: When modifying passwords, use the piped
input, since it is more secure than keeping passwords in a
file. See Note 1 in NOTES.
-L logfile
(Optional) Specifies the full pathname to the text file that
stores the command's success/failure data.
OPERANDS
The following operands are supported:
piped_input You must include piped_input if you do not specify an
input_file. Include the piped input immediately before
the command. The piped input must follow the
/etc/passwd file format. See EXAMPLES. Note: Use the
-−trust option when using piped input with the -L log‐
file option to avoid the user prompt from the Security
Alert Manager, which normally asks the user whether the
log file should be created. Without the -−trust option,
the piped input is improperly taken as the answer to
the prompt before the user can answer "Y" or "N", and
the logging operation will probably fail.
EXAMPLES
Example 1: Creating multiple user accounts
The following reads in user account data from the /tmp/foo file and
creates new user accounts on the local file system. The input file is
formatted in the /etc/passwd format.
./smmultiuser add -H myhost -p mypasswd -u root ---i /tmp/foo
Example 2: Deleting multiple user accounts
The following reads in user account data from the /tmp/foo file and
deletes the named user accounts from the local file system:
./smmultiuser delete -H myhost -p mypasswd -u root ---i /tmp/foo
Example 3: Creating a log file with piped input
The following example shows the use of the smc(1M) -−trust option that
is required when creating a log file. It is applicable to the delete
and modify subcommands also.
cat /tmp/users.txt | smmultiuser add --trust -- -L /tmp/mylog.txt
ENVIRONMENT VARIABLES
See environ(5) for a description of the JAVA_HOME environment variable,
which affects the execution of the smprofile command. If this environ‐
ment variable is not specified, the /usr/java location is used. See
smc(1M).
EXIT STATUS
The following exit values are returned:
0 Successful completion.
1 Invalid command syntax. A usage message displays.
2 An error occurred while executing the command. An error mes‐
sage displays.
FILES
The following files are used by the smprofile command:
/etc/passwd Contains the file format to use for the
input_file and piped_input. See passwd(4).
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Availability │SUNWmga │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOsmc(1M), passwd(4), attributes(5), environ(5)NOTES
1. The file format used by both the add and modify subcommands is the
/etc/passwd format. But there is an allowance for a mutated version
of this file format that contains an extra field at the end of each
line to be used for the Full Name. If the extra field is appended
to the end of each line, it will be used for the Full Name value,
but if it is omitted, it will be assumed that no FullName modifica‐
tion is being done. The extra field is separated with a colon (:),
just like all the other fields.
Example of regulation /etc/passwd entry:
rick2:x:101:10:description1:/home/rick2:/bin/sh
Example of /etc/passwd variant entry:
rick2:x:101:10:description1:/home/rick2:/bin/sh:Ricks_fullname
2. The modifies are all done based on lookups of the user name in the
user tables. If a user name can not be found in this lookup, a sec‐
ondary check will be made to see if the uid and FullName can be
found in the user tables. If they are both found, assume that a
user rename has occurred. If neither can be found, assume that the
user account does not exist and cannot be modified.
3. If no password is supplied, assume that there is no change to the
password information. If a password is being changed, it should be
supplied in cleartext as piped input, although this is not
required. The password can be supplied in the input file also. Once
read in, the password will be changed accordingly.
SunOS 5.10 5 Jan 2001 smmultiuser(1M)
