HP OpenVMS Systems Documentation

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

Prior to starting the network with NET$STARTUP.COM, you can modify components of the network by using the following system logical names:

• NET$ENTITY-NAME_STARTUP
  Specifies a logical name that points to an alternate file location for the network startup .ncl scripts. For example, enter the following to redefine NET$ROUTING_STARTUP:

  $ define/system net$routing_startup - _$ sys$sysroot:[sysmgr.network_scripts]net$routing_startup.ncl

• NET$IGNORE_DECNET
  Values can be either true or false.
  If set to true, the network software is not started. If not defined, or set to false, the network starts normally.
• NET$STARTUP_QUIET_NCL
  Values can be either true or false.
  If set to true or not defined, NCL output is suppressed during the startup sequence. A message indicates that an NCL script is being executed. If set to false, all NCL output is displayed.
• NET$STARTUP_MOP
  Values can be either true or false.
  If set to true, MOP is started. If not defined, or false, MOP is not started.

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:

dddd hh:mm:ss.cc

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:

1. The process is logged in according to information found in the user authorization file (UAF). The key to this file is the user name, which is part of the access control information. For information about access control information, see Section 7.3.
2. DECnet-Plus automatically creates a log file in SYS$LOGIN:NET$SERVER.LOG. Unlike the log file for a batch job, this log file is neither printed nor deleted. The log file is helpful for debugging your own network tasks. If NET$SERVER.LOG cannot be created for any reason, the network job continues running but does not produce any log file.
3. The login command procedure indicated in the UAF for the process is executed.
4. The process runs a command file to start the image that implements the DECnet Phase V application. The rules for locating this command file differ depending on whether the application has the number 0.

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 to run.

6.5 Deleting Network Entities

This section explains how to delete and disable network entities, and what you must do prior to recreating a previously deleted entity. In general, the procedures are the same for most 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 example disables and deletes routing for end systems using csma-cd links. Remember that the procedure applies to disabling and deleting most DECnet Phase V entities.

ncl> disable routing circuit csmacd-0 reachable address reachable-address (1)
ncl> delete routing circuit csmacd-0 reachable address reachable-address (2)

ncl> disable routing circuit csmacd-0 (3)
ncl> delete routing circuit csmacd-0 (4)

ncl> disable routing (5)
ncl> delete routing (6)

1. Disables the routing circuit reachable address child entity
2. Deletes the routing circuit reachable address child entity
3. Disables the routing circuit child entity
4. Deletes the routing circuit child entity
5. Disables the routing parent entity
6. Deletes the routing parent entity

DECnet-Plus regulates access to the network on various levels, including the following:

• Rights identifiers for access to the network
• Access control
• Routing initialization passwords for connecting local nodes to remote nodes

The following sections describe these levels of control for DECnet-Plus.

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.

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.

Examples

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 local node (for example, ncl show all or ncl show node 0 all), the rights of the executing process determine whether access is granted.

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:

1. If explicit access control is specified, the specified account is used.
2. If there is a default account for the application receiving the request, it is used.
3. If a proxy account is specified, or there is a default proxy account for the remote user, it is used.
4. If all the above fail, the session entity is checked for a default nonprivileged account to use.

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:

• Run the Authorize utility and grant an account the proper rights.
• Run the Authorize utility and create a proxy account. Grant the proxy account the proper rights.
• Determine the user name associated with the session control application CML. Run the Authorize utility to ensure that that account has NET$EXAMINE for read-only access.

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:

1. The network user on the local node can explicitly supply access control information. If this is the case, the remote node uses the access control information. See Section 7.3.1 for information about explicit access control.
2. If no explicit access control information has been provided, the local node checks to see if outgoing proxy access is enabled for a local node or an application. If the proxy is enabled, the local node initiates a connection and the session control entity on the remote node determines if the initiating user has proxy access. See Section 7.3.2 for information about proxy access control.
3. When the remote node sees that no explicit access control has been specified and that no proxy matches , it checks its application database. If the database contains an application user name, it uses that name. See Section 7.3.3 for information about default application accounts.
4. If there is no default application user name in its application database, the remote node checks its session control entity attributes for default nonprivileged DECnet user name information. If the information is there, the remote node uses the default nonprivileged DECnet user name.
   The default DECnet user name allows users to perform certain network operations, such as the exchange of electronic mail between users on different nodes, without having to supply a user name and password. The default DECnet user name is also used for file operations when access control information is not supplied. For example, it permits remote users to access local files on which the file protection has been set to allow world access. If you do not want remote users accessing your node, do not create a default DECnet user name. See Section 7.3.4 for information about default nonprivileged DECnet accounts.

Finally, if none of these sources supply valid access control information, the connection fails.

You can check if there is a default nonprivileged user name for session control by issuing the following command:

ncl> show session control non privileged user

You can check if there is a default nonprivileged account for applications by issuing the following command:

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 must establish access control information for applications in the application database.

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.

Note that network applications can also be assigned proxy login access.