HP OpenVMS Systems Documentation

1. The value that you enter for the local area creates a child directory under the OSI area prefix directory created previously.

For help answering the prompts, refer to the following:

Directory Name

Enter the name of the base backtranslation directory. This directory is commonly called .DNA_BackTranslation.

Enter YES to create the base backtranslation directory.

Master Replica Clearinghouse

Specify the name of the clearinghouse where the master directory replicas should be created. Include any required directory information; for example, if your clearinghouse is in the root directory, you might type .MAS_CH.

If you do not specify a clearinghouse name, the parent directory's clearinghouse is used (this is the DECdns default).

Access Control Groups

Enter the names of one or more DECdns access control groups that you want to include in the access control set for the directory (or directories) you create. Using access control groups allows you to control user access to the directories by listing those users who have read, write, delete, test, and control access to directories created using decnet_register_decdns. The specified access control groups are propagated to all backtranslation soft links.

To specify more than one group name, separate them by commas. You are responsible for creating and populating any access control groups that you specify.

OSI Area Prefix

Specify the IDP (initial domain part) and preDSP (domain-specific part) value for the network. Specify either the default value (49::) or a value explicitly allocated for this network.

The format is afi:idi:predsp, where:

The default of 49:: means that both the idi and predsp are null. When the AFI equals 49::, the network is not to be interconnected with other OSI networks.

If you specify an IDP with an AFI other than 49::, that value appears as the default the next time the prompt appears.

Enter YES to create the OSI area prefix directory.

Local Area Value

Specify the local area to use within the IDP. This is either of the following:

• A hexadecimal value from %X0040 to %XFFFF, for a DECnet Phase V extended area
• A decimal value from 1 to 63, for a Phase-IV-compatible area

This function adds new members to the DECdns .DNA_Registrar access control group. The .DNA_Registrar access control group lists those users who have read, write, delete, test, and control access to all directories, objects, and soft links created using decnet_register. This group is automatically placed in the appropriate access control list for every node registered using decnet_register.

If necessary, you can also use the DECdns Control Program to add additional users and groups to individual access control lists.

To add members to the access control group, select Option 8 at the decnet_register_decdns main menu. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:

Add members to the access control group. Press
Ctrl-Z when done.

Enter the name of the access control group to use.
The current default is "bb_ns:.biggroup".

* Group name: .biggroup

Enter the name of the group member to add.

* Member name: .mvg460.manager

For help answering the prompt for a member name, refer to the following:

Member

Enter the name of the member you want to add, using the format:

node_full_name.user_name

where:

You can also specify members using the format:

node_name::user_name

where:

The following example shows two members being added to the access control group, the first by specifying the node's full name, and the second by specifying the Phase IV node name. Press the appropriate control key sequence for your platform to exit.

* Member name: .Japan.Osaka.Sales.Yamamoto

Adding member ".Japan.Osaka.Sales.Yamamoto" to ".DNA_Registrar"

* Member name: GCsale::Obrien

Adding member ".DNS$IV.GCsale.Obrien" to ".DNA_Registrar"

* Member:

When you create a new namespace on an OpenVMS DECdns name server, a group called .WorldRead_Group is also created. This allows you to easily change from one namespace to another. This group allows READ and TEST access to node objects. Therefore, a node that is moving from one namespace to another can read old information from its previous namespace and move any of this information to the new namespace.

When the .WorldRead_Group is created, it contains members LOCAL:.*... and <ns>:.*..., where <ns> is the name of your namespace. The person managing the namespace determines which systems (or namespaces) will get READ and TEST access to the namespace. The namespace manager needs to explicitly remove the members from the .WorldRead_Group if the namespace manager does not want these members included.

5.3.12.6 Using the WorldRead_Group Access Control Group

When decnet_register_decdns is first used to set up the directories for a namespace, it checks for the existence of the .WorldRead_Group access control group. This group is generally used when multiple namespaces are in use in the network (for example, multiple DECdns namespaces, or one or more DECdns namespaces plus the local namespace). The members of this group are automatically granted read access to any created directories and objects, regardless of the namespace they are in.

Without the .WorldRead_Group access control group, users in other namespaces would need to be granted access to any appropriate directories and objects individually. Members in the .WorldRead_Group group are usually of the form namespace:.*..., where namespace is your namespace nickname (for example, ACME:.*...). Individuals can also be listed.

If decnet_register_decdns does not find the .WorldRead_Group access control group, it asks whether to create the group. If so, decnet_register_decdns does the following:

• Creates the .WorldRead_Group access control group
• Adds the group to the root directory
• Sets the group to be added by default to any subsequently created directories (and subsequently created objects within those directories)

If the access control group is not created, decnet_register_decdns does not ask this question again on subsequent invocations. To have the question repeated on a later invocation, edit the decnet_register_decdns.defaults file in the login directory, find the line that contains def_worrea or nrg_def_worrea, and remove the appropriate namespace from the value list.

It is important to note that this group affects only those directories and objects created after the group. Any directories and objects created before the group must have the access control set (ACS) explicitly set using the DECdns Control Program.

5.3.12.7 Removing Members from the Access Control Group

This function removes members from the DECdns .DNA_Registrar access control group. .DNA_Registrar lists those users who are allowed to manage node names in the namespace.

To perform this task, select Option 9 at the decnet_register_decdns main menu and the following messages appear. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:

Remove members from the access control group.
Press Ctrl-Z when finished.

* Member name:

For help answering the prompt, refer to the following:

Member Name

Enter the name of the member you want to remove. Specify the member's name exactly as it appears when you use Option 10 to list the members of the access control group.

If the member's name was added using the format node_name::user_name, you can use this same format to remove it.

To delete all members of the group, enter an asterisk (*) at the prompt. This command re-creates the .DNA_Registrar access control group.

The following example shows two members being removed from the access control group, the first using the name as shown by Option 10, and the second using the Phase IV format. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:

* Member: .Japan.Osaka.Sales.Yamamoto

Removing member ".Japan.Osaka.Sales.Yamamoto" from ".DNA_Registrar".

* Member: GCsale::Obrien

Removing member ".DNS$IV.GCsale.Obrien" from ".DNA_Registrar".

* Member:

This function shows the members of the DECdns .DNA_Registrar access control group. .DNA_Registrar lists those users who are allowed to manage node names in the namespace.

To perform this task, select Option 10 at the decnet_register_decdns main menu. The following messages appear:

Show members of the access control group.
Press Ctrl-Z when done.

Enter the name of the access control group to use.
the current default is "bb_ns:.biggroup".

Group name:
                  SHOW
                 GROUP  bb_ns:.biggroup
                    AT  05-NOV-1995:14:41:25
    DNS$Members  (set) = :
         (V) Principal = bb_ns:.mgv460.manager

Some tasks in this chapter manually register nodes in the namespace. DECnet Phase V nodes --- but not Phase IV nodes --- can automatically register themselves in the namespace when they are configured. This is called autoregistration. With this option you can enable or disable autoregistration of DECnet Phase V nodes. (Autoregistration of DECnet Phase V nodes is disabled by default.)

Although convenient, autoregistration of DECnet Phase V nodes presents a potential security risk because allowing autoregistration into a specific directory adds write access for the world (.*...) to the access control set (ACS) for that directory. Therefore, all users in the network can create child directories, objects, and soft links in that directory.

If you disallow autoregistration in a directory, the namespace is more secure because only authorized users can create entries in that directory. However, node names in that directory must be registered by an authorized namespace manager.

Allowing Autoregistration

To allow node autoregistration for a directory, select Option 11 at the decnet_register_decdns main menu. The following messages appear. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:

Allow DECnet-Plus node autoregistration in a directory.
Press Ctrl-Z when done.

* Directory name:

For help answering the prompt, refer to the following:

Directory Name

Specify the full name for the directory whose access is to be modified. This should not include a node name; for example, .Japan.Osaka.

In this example, autoregistration is enabled. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:

* Directory name: .Japan.Osaka

Modifying world write access to allow node autoregistration in this directory.

* Directory name:

Disallowing Autoregistration

To allow or disallow node autoregistration for a directory, select Option 12 at the decnet_register_decdns main menu. The following messages appear. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:

Allow or disallow DECnet-Plus node autoregistration in a directory.
Press Ctrl-Z when done.

* Directory name:

On OpenVMS systems, select Option 11 to create an interactive subprocess where you can enter NCL and other commands.

Enter the DCL logout command to terminate the subprocess and return to decnet_register.

This chapter provides information about four methods you can use to modify your network configuration:

• Configuration procedures
• Interactive Network Control Language (NCL) commands
• NCL scripts
• Logical names

This chapter also explains how you can create network server processes and how to delete and disable entities on all DECnet Phase V systems.

6.1 Using the Configuration Procedure

The DECnet-Plus software provides a configuration procedure, NET$CONFIGURE.COM, that you use to set up a basic, working node. The procedure produces a set of files called NCL scripts. To modify your network, rerun your configuration procedure, make the appropriate changes, and reboot the system. This modifies the configuration scripts and makes the changes permanent.

To customize your system beyond what the configuration procedure provides, you must edit the NCL scripts produced by the configuration procedure (see Section 6.2.2).

6.2 Network Control Language

NCL is a command-based tool that lets you set up, modify, and display information about any DECnet-Plus entity. You may, at times, want to manage an attribute of an entity, such as a buffer size. To perform this task, you need to use NCL to make the change interactively or you need to edit the NCL scripts produced by the configuration procedure.

You should manage your DECnet-Plus system this way only if:

• You cannot use the configuration program to carry out the task you want. For instance, you might need to make a temporary change to the running network (see Section 6.2.1).
• The feature you want to use is not available through the configuration procedure.

NCL supports an optional initialization file and an optional key definition file:

• The initialization file contains NCL commands that are executed when you start NCL; that is, before you receive the NCL prompt (ncl>). Alternatively, the NCL commands are executed prior to executing an NCL script file that is specified as part of a DCL command line.
• The key definition file associates commonly used NCL commands with keys on the keypad.

For more information, refer to the DECnet-Plus Network Control Language Reference guide.

6.2.1 Using Interactive NCL

Interactive NCL is useful only for temporary changes to a configuration. When you make changes to the running node using NCL interactively, the changes become effective immediately, but last only until the system is rebooted. For example, you might want to monitor a set of counters for a particular entity or you might want to temporarily disable a link.

The following steps briefly explain how to use interactive NCL:

1. Run the NCL utility on your local system. Refer to the DECnet-Plus Network Control Language Reference for information about starting NCL.
   If you want to issue several commands to a remote node, you can set the default to the node with the following command:

   ncl> set ncl default entity node node-id

   
   Where node-id is the name of the remote node. You can now enter NCL commands as if you were using them on a local node.
2. Enter the appropriate NCL commands to accomplish your task. Refer to the DECnet-Plus Network Control Language Reference for an explanation of all the commands and the entities and attributes that support them.
3. Update the NCL script if necessary. If you have made changes to the configuration of the system, and you want these changes to be permanent, use the configuration program (if possible) to update the system. If the configuration program cannot make the changes, modify the system's NCL script (see Section 6.2.2).

An NCL script is an ASCII file of NCL commands that sets up the network management entities. These commands reflect the configuration you specified in the configuration procedure. You can edit the script files with a text editor to make permanent changes to your configuration. You can also edit the NCL script to add features that are not covered by the configuration procedure.

The following example shows a typical example (Routing module) of a script file produced by a configuration procedure.

create node 0 routing type endnode
set node 0 routing phaseiv address = 19.5
enable node 0 routing

create node 0 routing circuit csmacd-0 type = csma-cd
set node 0 routing circuit csmacd-0 data link entity = -
  csma-cd station csmacd-0
enable node 0 routing circuit csmacd-0

The configuration procedure produces a script file for each module that it can configure. However, the configuration procedure creates more than one script file for some tasks. Therefore, manually making some changes to your configuration might require you to edit more than one NCL script. Script files have names that indicate what modules they implement.

Some common NCL scripts are:

• SYS$MANAGER:NET$CSMACD_STARTUP.NCL (CSMA-CD module)
• SYS$MANAGER:NET$SESSION_STARTUP.NCL (Session Control module)

The installation and configuration guides for your system provide full information about the configuration procedure and NCL scripts generated.

The following steps briefly explain how to edit NCL scripts:

1. Log in to a suitably privileged account on the system. Usually, this is the system account or one with equivalent privileges.
2. Edit the NCL scripts with any text editor. Enter the new commands in sections of their own, or in the appropriate sections that are already in the NCL script. Refer to the DECnet-Plus Network Control Language Reference for an explanation of all the commands and the entities and attributes that support them. If possible, test the changes before you make them by interactively entering the appropriate NCL commands.
3. After you have completed updating your NCL scripts, disable the entity and, if possible, re-execute the script or reboot the system to have the new values take effect.
   To execute an NCL script, use the following format:

   ncl> do ncl_script_file

   
   On an OpenVMS system, you can execute the following script:

   ncl> do sys$manager:net$nsp_transport_startup.ncl

   
   If you cannot re-execute or reboot at that time, enter the NCL commands interactively so they take effect immediately (see Section 6.2.1). Then, when you reboot the system, the changes in the NCL script take effect.

You may also need to alter DECdns or DECdts modules and entities. Refer to DECnet-Plus DECdns Management, DECnet-Plus DECdts Management, and the installation and configuration guides for your system for this information.