rmid - Unix, Linux Command
NAME
rmid - RMI activation system daemon
SYNOPSIS
rmid [
options ]
DESCRIPTION
The
rmid tool starts the activation system daemon. Before
activatable objects can be either registered with the activation
system or activated in a Java VM, the activation system daemon
must be started.
See the
RMI Specification and
Activation Tutorials for details on how to
write programs that use activatable remote objects.
The daemon can
be started by executing the
rmid command, and specifying a security policy file, as follows:
example% rmid -J-Djava.security.policy=rmid.policy
Note: When running Sun’s implementation of
rmid, by default you will need to specify a security policy
file so that
rmid can verify whether or not the information in each ActivationGroupDesc is allowed to be used to launch a JVM for an activation group.
Specifically, the command and options specified by the
CommandEnvironment and any
Properties passed to an
ActivationGroupDesc’s constructor must now be
explicitly allowed in the security policy file for
rmid. The value of the
sun.rmi.activation.execPolicy property dictates the policy that
rmid uses to determine whether or not the information in an
ActivationGroupDesc may be used to launch a JVM for an activation group.
Executing
rmid by default
| Tag | Description |
|---|
|
o
|
starts the Activator and an internal registry on the default port,
1098, and
|
|
o
|
binds an
ActivationSystem to the name
java.rmi.activation.ActivationSystem in this internal registry.
|
To specify an alternate port for the registry,
you must specify the
-port option when starting up
rmid. For example,
rmid -J-Djava.security.policy=rmid.policy -port 1099
starts the activation system daemon and
a registry on the registry’s default port,
1099.
Starting rmid from inetd/xinetd
An alternative to starting rmid from the command
line is to configure inetd (Solaris) or
xinetd (Linux) to start rmid on demand.
When rmid starts up, it attempts to obtain an
inherited channel (inherited from inetd/xinetd)
by invoking the System.inheritedChannel method.
If the inherited channel is null, then rmid
was started from the command line,
and it starts up as described above.
If the inherited channel is not an instance
of java.io.channels.ServerSocketChannel, rmid exits.
If the inherited channel is a ServerSocketChannel
instance, then rmid uses the
java.net.ServerSocket obtained from the
ServerSocketChannel as the server socket that
accepts requests for the remote objects
it exports, namely the registry in which the
java.rmi.activation.ActivationSystem is
bound and the java.rmi.activation.Activator
remote object.
The rmid tool, when started from inetd/xinetd,
behaves the same as when it is started from the
command line, except:
| Tag | Description |
|---|
|
o Output printed to System.err is redirected
|
| |
to a file. This file is located in the directory
specified by the java.io.tmpdir system
property (typically /var/tmp or /tmp) with the
prefix "rmid-err" and the suffix "tmp".
|
|
o The -port option is disallowed. If this
|
| |
option is specified, rmid will exit with an error
message.
|
|
o The -log option is required. If this option
|
| |
is not specified, rmid will exit with an error
message.
|
See the man pages for inetd (Solaris) or
xinetd (Linux) for details on how to configure services to
be started on demand.
OPTIONS
| Tag | Description |
|---|
|
-CsomeCommandLineOption |
| |
Specifies an option that is passed as a command-line argument
to each child process (activation group) of
rmid when that
process is created.
For example, you could pass a property to each Java
virtual machine spawned by the activation system daemon:
rmid -C-Dsome.property=value
This ability to pass command-line arguments
o child processes can be useful for debugging.
For example, the following command:
rmid -C-Djava.rmi.server.logCalls=true
will enable server-call logging in all child JVMs.
|
|
-JsomeCommandLineOption |
| |
Specifies an option that is passed to the
java interpreter running
rmid. For example, to specify that
rmid use a policy file named
rmid.policy, the
-J option can be used to define the
java.security.policy property on
rmid’s command line.
For example:
rmid -J-Djava.security.policy=rmid.policy |
|
-J-Dsun.rmi.activation.execPolicy=policy |
| |
Specifies the policy that
rmid employs to check commands and command-line options used to
launch the JVM in which an activation group runs.
Please note that this option exists only in Sun’s
implementation of the RMI activation daemon.
If this property is not specified on the command line,
the result is the same as if
-J-Dsun.rmi.activation.execPolicy=default were specified.
The possible values of
policy can be
default, policyClassName, or
none:
| Tag | Description |
|---|
|
o
|
default (or if this property is unspecified)
The default
execPolicy allows
rmid to execute commands with specific command-line options only if
rmid has been granted permission to execute those commands and options
in the security policy file that
rmid uses.
Only the default activation group implementation
can be used with the
default execution policy.
rmid launches a JVM for an activation group using the
information in the group’s registered activation
group descriptor, an
ActivationGroupDesc. The group descriptor specifies an optional
ActivationGroupDesc.CommandEnvironment which includes the
command to execute to start the
activation group as well as any
command line
options to be added to the command line.
By default,
rmid uses the
java command found in
java.home. The group descriptor also contains
properties overrides that are added to the command line as options defined as:
-Dproperty=value
The permission
com.sun.rmi.rmid.ExecPermission is used to grant
rmid permission to execute a
command, specified in the group descriptor’s
CommandEnvironment to launch an activation group.
The permission
com.sun.rmi.rmid.ExecOptionPermission is used to allow
rmid to use command-line options, specified as
properties overrides in the group descriptor or as options in the
CommandEnvironment, when launching the activation group.
When granting
rmid permission to execute various commands and options,
the permissions
ExecPermission and
ExecOptionPermission need to be granted universally
(that is, granted to all code sources).
| Tag | Description |
|---|
|
ExecPermission | | |
The
ExecPermission class represents permission for
rmid to execute a specific command to launch an activation group.
Syntax
The name of an
ExecPermission is the path name of a command to grant
rmid permission to execute.
A path name that ends in "/*" indicates
all the files contained in that directory (where "/"
is the file-separator character,
File.separatorChar). A path name that ends with "/-" indicates
all files and subdirectories contained in that directory (recursively).
A path name consisting of
the special token "<<ALL FILES>>" matches
any file.
Note: A path name consisting of a
single "*" indicates all the files in the current directory,
while a path name consisting of
a single "-" indicates all the files
in the current directory and
(recursively) all files and
subdirectories contained in the current directory.
|
|
ExecOptionPermission | | |
The
ExecOptionPermission class represents permission for
rmid to use a specific command-line
option when launching an activation group.
The name of an
ExecOptionPermission is the value of a command line option.
Syntax
Options support a limited wildcard scheme.
An asterisk signifies a wildcard match, and it may
appear as the option name itself
(that is, it matches any option),
or an asterisk may appear at the end
of the option name only if the
asterisk follows either a "." or "=".
For example: "*" or "-Dfoo.*" or "-Da.b.c=*" is valid;
"*foo" or "-Da*b" or "ab*" is not.
|
|
|
Policy file for rmid | | |
When granting
rmid permission to execute various commands and options,
the permissions
ExecPermission and
ExecOptionPermission need to be granted universally (that is, granted to all code
sources).
It is safe to grant these permissions
universally because only
rmid checks these permissions.
An example policy file that
grants various execute permissions to
rmid is:
grant {
permission com.sun.rmi.rmid.ExecPermission
"/files/apps/java/jdk1.2.2/bin/java";
permission com.sun.rmi.rmid.ExecPermission
"/files/apps/rmidcmds/*";
permission com.sun.rmi.rmid.ExecOptionPermission
"-Djava.security.policy=/files/policies/group.policy";
permission com.sun.rmi.rmid.ExecOptionPermission
"-Djava.security.debug=*";
permission com.sun.rmi.rmid.ExecOptionPermission
"-Dsun.rmi.*";
};
|
The first permission granted allow
rmid to execute the 1.2.2 version of the
java command, specified by its explicit path names.
Note that by default, the version of the
java command found in
java.home is used (the same one that
rmid uses), and does not need to be
specified in the policy file.
The third permission allows
rmid to execute any command in the
directory
/files/apps/rmidcmds.
The fourth permission granted, an
ExecOptionPermission, allows
rmid to launch an activation
group that defines the security policy file to be
/files/policies/group.policy. The next permission allows the
java.security.debug property to be used by an activation group.
The last permission allows any property in the
sun.rmi property name hierarchy to be used by activation groups.
To start
rmid with a policy file, the
java.security.policy property needs to be specified on
rmid’s command line.
For example:
rmid -J-Djava.security.policy=rmid.policy |
|
o
|
policyClassName
If the default behavior is not flexible enough,
an administrator can provide, when starting
rmid, the name of a class whose
checkExecCommand method is executed in order to check commands to be executed by
rmid.
The
policyClassName specifies a public class with a public,
no-argument constructor and an
implementation of the following
checkExecCommand method:
public void checkExecCommand(ActivationGroupDesc desc,
String[] command)
throws SecurityException;
|
Before launching an activation group,
rmid calls the policy’s
checkExecCommand method, passing it the activation group descriptor
and an array containing the complete
command to launch the activation group.
If the
checkExecCommand throws a
SecurityException, rmid will not launch the activation group
and an
ActivationException will be thrown to the caller attempting to activate the object.
|
|
o
|
none
If the
sun.rmi.activation.execPolicy property value is "none", then
rmid will not perform any
validation of commands to launch activation groups.
|
|
|
-log dir |
| |
Specifies the name of the directory the activation
system daemon uses to write its database and
associated information.
The log directory defaults to creating a directory,
log, in the directory in
which the
rmid command was executed.
|
|
-port port |
| |
Specifies the port
rmid’s registry uses.
The activation system daemon binds the
ActivationSystem, with the name
java.rmi.activation.ActivationSystem, in this registry.
Thus, the
ActivationSystem on the local machine can be obtained using
the following
Naming.lookup method call:
import java.rmi.*;
import java.rmi.activation.*;
ActivationSystem system;
system = (ActivationSystem)
Naming.lookup("//:port/java.rmi.activation.ActivationSystem");
|
|
|
-stop |
Stops the current invocation of
rmid, for a port specified by the
-port option.
If no
port is specified, it will stop the
rmid running on port
1098. |
ENVIRONMENT VARIABLES
| Tag | Description |
|---|
|
CLASSPATH |
Used to provide the system a path to user-defined classes.
Directories are separated by colons.
For example,
example% .:/usr/local/java/classes
|
|
SEE ALSO
See (or search
java.sun.com) for the following:
