HP OpenVMS Systems Documentation
DECnet-Plus for OpenVMS
If you wish to have site-specific NCL commands in scripts, create files called NET$APPLICATION_LOCAL.NCL, NET$EVENT_LOCAL.NCL, and NET$MOP_CLIENT_LOCAL.NCL in the SYS$MANAGER directory. If these files exist, the network startup procedure executes these scripts immediately after the NET$APPLICATION_STARTUP.NCL, NET$EVENT_STARTUP.NCL, and NET$MOP_CLIENT_STARTUP.NCL scripts supplied by DIGITAL are executed.
If you do not need to modify the DIGITAL-supplied scripts, place your
site-specific NCL commands in these user-defined NCL scripts. These
user-defined scripts will not be overwritten or deleted by
NET$CONFIGURE.COM because they are maintained by the user.
6.3 Defining Logical Names That Modify Network Startup
$ define/system net$routing_startup - _$ sys$sysroot:[sysmgr.network_scripts]net$routing_startup.ncl
If you want the operating system to define these logicals before
starting the network, place these system logical definitions in the
SYS$MANAGER:NET$LOGICALS.COM file. (If you do not have the
SYS$MANAGER:NET$LOGICALS.COM file on your system, you can
create one using SYS$MANAGER:NET$LOGICALS.TEMPLATE.)
6.4 Creating DECnet-Plus Network Server Processes
On the OpenVMS operating system, all DECnet Phase V applications run as processes. Unless a currently running process has declared itself to be a numbered network application or a named network application (with number 0), the network ancillary control program (NET$ACP) must invoke a process to receive the connect request.
When the logical link request comes in, a standard procedure called NET$SERVER.COM runs, which in turn causes NET$SERVER.EXE to be executed. This program works in concert with NET$ACP to invoke the proper program for the requested application. Then, when the logical link is disconnected, the application program (such as file access listener (FAL)) terminates, but the process is not deleted. Instead, control returns to the NET$SERVER.EXE program, which asks NET$ACP for another incoming logical link request to process. This cycle continues until NET$SERVER is deleted after a specified time limit. The default is 5 minutes. To use a different default time limit, define the system logical name NETSERVER$TIMEOUT in SYS$MANAGER:NET$LOGICALS.COM, using an equivalence string in the standard OpenVMS delta time format:
For example, to set the time limit to 30 minutes, use the following command:
$ define/system netserver$timeout "0 0:30:0"
The effect of NET$SERVER is to reuse network server processes for more than one logical link request, eliminating the overhead of process creation for an often-used node. The network ancillary control program (NET$ACP) reuses a NET$SERVER process only if the access control on the connect request matches that used to start the process originally.
When NET$ACP creates a process to receive the connect request, the process runs like a batch job. The sequence is as follows:
Because NET$SERVER.LOG files are not required for network
server processes, you can explicitly inhibit all log files in your
default nonprivileged DECnet-Plus account by setting the default
directory for the account to a nonexistent directory. The effect of
this action is to suppress all log files, while allowing network jobs
6.5 Deleting Network Entities
To delete an entity, you must usually disable that entity first. Disabling an entity means you are putting the entity into the off state. You must also delete entities in order. That is, you must delete a child entity before you can delete the parent entity. After deleting the child entity, you can delete the parent. Then the entity is completely deleted. In some cases, the DECnet-Plus software automatically deletes entities. The DECnet-Plus Network Control Language Reference indicates which commands support the various entities.
The following sections describe these levels of control for
7.1 Required Rights Identifiers
To perform any kind of network activity, all network users must have TMPMBX and NETMBX privileges and certain rights identifiers enabled. You can define a user's rights and privileges with the OpenVMS Authorize utility (see Section 7.3.4). For more information about using this utility, refer to the OpenVMS System Management Utilities Reference Manual.
Identifiers are created in the rights database during installation. Table 7-1 lists the rights identifiers that you and network users need.
|NET$DECLAREOBJECT||Declares an application|
|NET$DECNETACCESS||Gives $IPC users access to the network in the absence of the NETMBX privilege|
|NET$DIAGNOSE||Permits use of network diagnostics|
|NET$EXAMINE||Permits display of the attributes of an entity|
|NET$MANAGE||Permits display, creation, or modification of an entity|
|NET$POSTEVENT||Permits posting of events|
|NET$REGISTERDNSOBJECT||Permits registration or deregistration of a DECdns object|
|NET$SECURITY||Permits setting a user name for session control or session control application|
|NET$TRACEALL||Permits tracing of entire messages on a local node|
|NET$TRACEALLREMOTE||Permits tracing of entire messages on a remote node|
|NET$TRACEHEADERS||Permits tracing of message headers on a local node|
|NET$TRACEHEADERSREMOTE||Permits tracing of message headers on a remote node|
DECnet-Plus for OpenVMS uses OpenVMS rights identifiers to perform access checks on all manageable entities. This differs from the Phase IV software, which used OpenVMS privileges for access to the permanent database and for write access. Read access to the volatile database in Phase IV was unprotected.
In DECnet-Plus for OpenVMS, the rights identifier NET$EXAMINE grants a user read access to the network configuration data. The NET$MANAGE rights identifier grants read and write access to the network configuration data, and NET$SECURITY grants the ability to set default accounts. These new rights allow the network manager to restrict access to network parameters. Access is granted to an individual user by means of the Authorize utility on OpenVMS. The following command examples grant access.
UAF> grant/id net$examine Joe ! Grant user Joe read access to local network data
UAF> grant/id net$manage Joe ! Grant user Joe read/write access to local network data
UAF> grant/id net$security Joe ! Grant user Joe ability to set default accounts
In lieu of NET$MANAGE rights, the BYPASS privilege will grant read and write access.
When issuing NCL commands to the remote node (for example, ncl show node remote-node-name all or ncl set ncl default entity node remote-node-name), a connection is established to the Common Management Information Protocol (CMIP) Management Listener (CML) application on the remote node. Access checks performed on the remote node depend on the account the remote CML application is running in (on an OpenVMS node). When the connection comes into an OpenVMS machine, a process is created to run the CML application. Which account is used is determined in the following order:
If the account that runs the CML application does not have the NET$EXAMINE for read access, or NET$MANAGE identifier for read and write access, then the access is denied by the management agent.
The manager of the remote node must take explicit action to allow an individual user access to the network configuration information. For example:
The last option is one of the selections offered by
NET$CONFIGURE when configuring the application database. If
you select to have a default account for the CML application,
NET$CONFIGURE will grant the NET$EXAMINE right to
that account by default.
7.3 Access Control
Whenever a DECnet node attempts to connect to a remote DECnet-Plus node, it sends access control information to the session control entity on the remote node. Access control allows you to control connections between nodes. Access control information can come from a number of sources. The following list shows the hierarchy of access control from highest to lowest priority:
Finally, if none of these sources supply valid access control information, the connection fails.
In DECnet-Plus, nonprivileged means having NET$DECNETACCESS rights and TMPMBX and NETMBX privileges. These are the minimal rights and privileges necessary for any network activity. Privileged means any rights and privileges in addition to NET$DECNETACCESS rights and TMPMBX and NETMBX privileges.
In Phase IV, nonprivileged means NETMBX and TMPMBX privileges only. NETMBX and TMPMBX are the minimal requirement for any network activity. Privileged means any privileges in addition to NETMBX and TMPMBX.
ncl> show session control non privileged user
ncl> show session control application fal user name
You can request the configuration command procedure, NET$CONFIGURE.COM, to establish the default nonprivileged DECnet account and directory for you automatically. If you want to add a default nonprivileged DECnet account manually, see Section 7.3.4.
You do not need to use access control information when a connection to a program has declared an application name and has started independently of DECnet.
Instead, you need NET$DECLAREOBJECT rights to declare that you want to accept incoming connections.
If you want to execute an NCL command on a remote node, you can do so by supplying explicit access control information. The access control information contains a user name and password and provides access to a specific account on the remote system. To supply explicit access control information, you can use either a standard OpenVMS node specification (node"username password") or you can use the NCL prepositional phrase by with a user name and password. For more information about a standard OpenVMS node specification, refer to the OpenVMS DCL Dictionary.
In the following example, you can display all characteristics information about the application statistics on the remote node toronto by specifying a user name and password with the prepositional phrase by.
ncl> show node toronto session control application - _ncl> statistics all characteristics, by user a_johnston, - _ncl> password general
Proxy login enables a user logged in at a remote node to be logged in automatically to a specific account at the local node, without having to supply any access control information. Note that proxy login is not the same as interactive login. Proxy login means that specific network access operations can be executed. By contrast, interactive login requires a user to supply a user name and password before the user can perform any interactive operations.
To establish proxy login on the local node (without specifying any access control information), the remote user must have a default proxy account on the local node that maps to a local user name. The remote user assumes the same file access, same rights, and same privileges as the local user name. You can use the proxy login capability to increase security, because it minimizes the need to specify explicit access control information in node specifications passed over the network or stored in command procedures.
If you are going to have access to more than one proxy account from the same node and login name, indicate which proxy account should be the default.