![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
You have just completed the initial configuration of a DECnet-Plus for OpenVMS system. It should now be operational as an end system on the network.
See Figure 3-1 and Figure 3-2 to determine your next step. According to the flowcharts, you have just completed configuring the base components.
You can use the net$configure procedure to modify the current configuration. Depending on which menu option you select, net$configure either modifies the configuration automatically or produces modified NCL scripts that you can use to modify the system's configuration.
See Chapter 4 to determine whether you want to use the FAST, BASIC or ADVANCED configuration option to change your configuration. Refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration for instructions on how to run the ADVANCED configuration.
If this is the first time you are configuring the DECnet-Plus for OpenVMS software on your system, the information in this chapter further explains some of the topics that appear as you run the configuration procedure.
While configuring DECnet-Plus, the system administrator specifies one or more of the following directory name services to use on the node: the Local namespace, DECdns, or Domain Name System (for DNS/BIND). See Section 6.2 for more information.
For more information on name services, refer to the DECnet-Plus Planning Guide.
DECnet-Plus includes a Local namespace, independent of DECdns, that is designed to scale to at least 100,000 nodes.
The Local namespace is a discrete, nondistributed namespace that exists on a single node and provides that node with a local database of name and address information. The prefix LOCAL: (or local:) is reserved to indicate that the information for the node is stored in the Local namespace.
DECnet-Plus recognizes that when a node full name begins with LOCAL:, information for that node is stored in a Local namespace. The following are typical node full names properly formatted for the Local namespace: LOCAL:.xyz.abc and local:.maximum.
Unlike DECdns, the Local namespace does not employ backtranslation directories for address-to-node-name translation.
If you want to create a Local namespace, enter LOCAL:.DirectoryPath.NodeObject at the following prompt:
* Enter the full name for directory service LOCAL:
The directory path identifies the namespace subdirectory (if any). The node object is the system's node name.
The DECdns distributed namespace is not a requirement for DECnet-Plus and the Local namespace is not dependent on DECdns. However, the DECdns clerk software is still required on each node. You cannot use the DECdns Control Program (DNSCP) to manage information stored in the Local namespace. Instead, use decnet_register to manage the node name and address information stored in your namespace. The decnet_register tool is described in the DECnet-Plus for OpenVMS Network Management guide.
DECdns is a networkwide service that makes it possible to use network resources without knowing their physical location. Users and applications can assign DECnet-Plus names to resources such as nodes. The creator of a name also supplies other relevant information, such as the resource's network address, for DECdns to store. Users then need to remember only the name, and DECdns acts as a lookup service, providing the rest of the data when necessary.
You need to create a new DECdns namespace only if you are configuring the first DECdns server for the network or if you are creating an additional namespace. If you already have a DECdns namespace, you do not need to create a new namespace to be able to run DECnet-Plus. However, if this is the first system in a network where no namespace exists and you do not intend to use the Local namespace, you must create (and populate) a DECdns namespace.
If you are unsure whether you need to create a new namespace or configure your system as a server, see your network manager. For information about namespace planning, refer to the DECnet-Plus Planning Guide.
To create a new namespace while configuring a DECnet-Plus for OpenVMS system:
When you create a namespace, you need a namespace nickname and clearinghouse name. The namespace nickname is part of the full name of every subsequent system in the network and should be unique to your network. The namespace nickname that you specify becomes the actual name of the namespace. A clearinghouse is a collection of directory replicas that contains the names and addresses of objects (for example, servers, clerks, files).
Digital recommends that you create namespace directories before using the configuration procedure (net$configure.com) to create the namespace. Follow these steps to create namespace directories:
For more information on decnet_register, refer to DECnet-Plus for OpenVMS Network Management.
If you select DECdns as a directory service, net$configure prompts you for the full name you want to use:
* Enter the full name for directory service DECDNS: new_ns:.mrv042 [Return]
If this is a new namespace, net$configure prompts you for more information once the configuration procedure completes and you have started the network. The startup information will be similar to the following:
%NET$STARTUP-I-OPERSTATUS, DECnet-Plus for OpenVMS operational status is RUNNING-
MAJOR
The namespace you specified was NEW_NS.
%DNS-E-NOMATNS, The specified namespace is not being served on your LAN.
please choose from the following list
[1] BB_NS
[2] DOMAIN
[3] LOCAL
[4] X500
[0] - Reject this list -
Pick a number from the list: 0 [Return]
Because you are creating a new namespace, the namespace you specified at the prompt, "What is the full name of this node?" does not appear in the list. To continue, enter 0 and press Return to reject the list.
If you are installing DECnet-Plus for OpenVMS for the first time
and you want to create a namespace, type Y. If you want to
attempt a WAN connection to a remote DECdns server,
type N (default) at the following prompt:
Do you want to proceed with creating a new namespace [n]: y [Return]
At this point, the configuration procedure needs to determine whether you intend to configure your system as a clerk on a WAN (connect to an off-LAN server) or create a new namespace. Since you cannot create a new namespace unless you have installed DECdns server software on the system, the procedure first verifies that the server software has been installed.
If you want to create a new namespace, type YES at the prompt and press Return. The procedure continues prompting you for information necessary to create the namespace and the appropriate directories. The procedure displays information about the namespace, the directories, and other network parameters, then tells you when the configuration is complete.
Your next input will determine the name of the clearinghouse
in your namespace new_ns. Enter the clearinghouse name as
alphanumeric and/or underscore characters.
Enter a simple name for the clearinghouse: .mrv042_new_ns_ch [Return]
Node 0
at 1995-04-06-15:49:35.420-04:00Iinf
Creating DECdns Server process ...
%RUN-S-PROC_ID, identification of created process is 00000122
Your default namespace nickname is new_ns.
Node 0
at 1995-04-06-15:49:42.100-04:00Iinf
%NET$CONFIGURE-I-FLUSHCACHE, flushing selected cache entries
Node 0
at 1995-04-06-15:49:47.180-04:00Iinf
%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to new_ns:.mrv042
%NET$CONFIGURE-I-NEWNAMESPACE, a new namespace has been created
%NET$CONFIGURE-I-ADDGROUP, adding .WorldRead_Group to the new namespace
Create the initial namespace directories.
Press Ctrl/Z at any question to cancel the initialization.
* Phase IV prefix value [afi:idi:predsp, Def=47:0027:]: [Return]
* Maximum Phase IV area to use [1-63, Def=63]: 2 [Return]
The DECdns namespace groups and directories will now be created. This might
take up to 6 minutes or more, depending on the speed of the DECdns
server system and the amount of traffic on the network.
Creating the NEW_NS:.DNA_Registrar group.
Creating the NEW_NS:.DNA_BackTranslation directory.
Creating the NEW_NS:.DNA_BackTranslation.%X470027 directory.
Creating the NEW_NS:.DNA_BackTranslation.%X470027.%X0001 directory.
Creating the NEW_NS:.DNA_BackTranslation.%X470027.%X0002 directory.
Creating the NEW_NS:.DNA_NodeSynonym directory.
Creating the NEW_NS:.DTSS_GlobalTimeServers directory.
DECdns namespace initialization for DECnet use is complete.
If this is the first time you have initialized the namespace for DECnet
use, use SYS$SYSTEM:DECNET_REGISTER.EXE to:
- Create a command file to automatically register previously defined
Phase IV nodes. Execute this command file before you manually
register any other nodes using SYS$SYSTEM:DECNET_REGISTER.EXE.
- Create any directories you need for node names that should be registered
immediately, according to your namespace design. This includes the node
you are currently running on.
- Be sure to add backtranslation directories for any non PhaseIV areas/IPDs.
Failure to do so will lead to Backtranslation Failures. Once you've added
the necessary backtranslation directories, you may need to use the
ncl flush session control naming cache entry "*" command.
- Change the local node's registered name from its default name to its
final full name. The local node will be registered as a Phase IV node
with a default name when you execute the Phase IV node registration
command file above.
- Change the currently registered names of other nodes from their default
names to their final full names when appropriate (for example, when they
are upgraded to run DECnet-Plus software).
Continue to use SYS$SYSTEM:DECNET_REGISTER.EXE to:
- Create any additional directories you need for node names, as new nodes
are brought up on the network.
- Register new nodes as they are brought up on the network.
- Add members to the NEW_NS:.DNA_Registrar access control group.
Additionally, you can use the DECdns control utility to:
- Add specific access control to individual directories, objects, and
soft links.
- Create replicas of directories.
The following were created:
Group: NEW_NS:.DNA_Registrar
Directory: NEW_NS:.DNA_BackTranslation
Directory: NEW_NS:.DNA_BackTranslation.%X470027
Directories: NEW_NS:.DNA_BackTranslation.%X470027.*
Directory: NEW_NS:.DNA_NodeSynonym
Directory: NEW_NS:.DTSS_GlobalTimeServers
%NET$CONFIGURE-I-CREATEINITDIR, created initial namespace directories
Registering the node NEW_NS:.mrv042
Type is DECnet-Plus
Synonym is MRV042
%NET$CONFIGURE-I-REGSUCCESS, node has been successfully registered in the
!NEW_NS directory service
Node 0
at 1995-04-06-15:50:29.390-04:00Iinf
%NET$CONFIGURE-I-NODERENAMED, node successfully renamed to new_ns:.mrv042
. . .
. . .
. . .
. . .
. . .
%NET-I-LOADED, executive image NET$LOOP_APPLICATION.EXE loaded
%NET$STARTUP-I-OPERSTATUS, DECnet-Plus for OpenVMS operational status is RUNNING-
ALL
%NET$CONFIGURE-I-CONFIGCOMPLETED, DECnet-Plus for OpenVMS configuration completed
Refer to your BIND server documentation for specific installation and configuration instructions. For a list of supported vendors, see Section 1.4.1.1. Any properly constructed DNS/BIND node name is supported by DECnet-Plus.
DECnet-Plus includes a new in-memory naming cache to improve performance of name and address resolution for all supported name services. Refer to the DECnet-Plus for OpenVMS Network Management guide for more information.
DECnet-Plus includes several new features to ease namespace management including decnet_register (a new namespace management tool), several new Network Control Language (NCL) commands, and Common Trace Facility (CTF) support for monitoring node name and address resolution.
The decnet_register tool, an executable image located in SYS$SYSTEM:, centralizes and simplifies namespace management tasks by replacing functionality previously provided by both the decnet_dns_register and decnet_loc_register command procedures, which were located in SYS$MANAGER:. The decnet_register tool manages information in both the DECdns distributed name service and the Local namespace. The decnet_register manage command assists with setting up tasks for the DECdns name service. For example, it creates namespace directories and access groups, and enables autoregistration. Refer to the section on decnet_register in the DECnet-Plus for OpenVMS Network Management guide for more information.
The name service search path applies systemwide and allows DECnet-Plus to search a list of name services in a predetermined order when looking up names or addressing information. The search path includes naming templates that tell DECnet-Plus how to interpret any abbreviated node names entered by users.
The ordering of the name services is very important. The first name service listed is the primary name service to use on the system. The primary name service is the first choice used when looking up names and addressing information. The remaining name services listed are the secondary name services used on the system.
The search path contains a list of name service keywords, each followed by a naming template that specifies a "defaulting rule" so users can enter shorter node names.
During DECnet-Plus configuration, the system administrator uses net$configure.com to set up one, two, or three name services on each node.
From the information provided by the system administrator, net$configure creates NET$SEARCHPATH_STARTUP.NCL, the standard search path NCL startup script which contains the name service search path information for the node.
The system administrator supplies one or two properly formatted DECnet-Plus node full names (in the case of the Local namespace and the DECdns distributed name service) and one fully qualified host name for DNS/BIND (if DNS/BIND is to be used on the node).
The first full name is specified in the proper format for the name service to be searched first. The second and third node names are properly formatted for the name services to be searched second and last.
If more than one name service is to be used on the node, the name services are searched in the order specified by the system administrator. For example, if the system administrator specifies Local, DECdns and Domain for the name services to use on the system, the Local namespace is searched before the DECdns namespace and DNS/BIND.
The following configuration example illustrates how to upgrade to DECnet-Plus Version 7.1 and use the new name service access features. Invoke net$configure.com and select Option 2 ("Change node name/namespace name"). The following prompt is displayed:
* Enter the directory services to use on the system [LOCAL,DECDNS,DOMAIN]:
At the prompt, you can choose the following name services for the system: LOCAL, DECDNS, and DOMAIN. If you enter more than one name service, separate each name with commas.
For example, entering DECDNS,LOCAL,DOMAIN at the prompt, means the following:
Note
If your node is also a DECdns server, the primary name service must be DECdns.
All members in a cluster should have identical naming search paths configured. This will help to ensure that nodes are recognized in the various services you have identified.
For example, if you receive mail on one node in the cluster, the "from" node name would be LOCAL:.NODE::SMITH. If you attempt to reply to this node from a node in the cluster that does not have Local configured, the system would indicate that there is no such node.
The system maintains two separate search paths:
$ mcr ncl show session control naming search path
$ mcr ncl show session control backtranslation search path
Refer to DECnet-Plus OpenVMS Network Management for more information.
Digital recommends that you rerun net$configure.com to revise the standard search path NCL script (NET$SEARCHPATH_STARTUP.NCL) whenever it is necessary to reorder access to the name services on the node. To modify the standard search path startup script, run net$configure.com and use Option 2 ("Change node name/namespace name").
Note
Whenever you directly edit an existing NET$SEARCHPATH_STARTUP.NCL script, or when you use the NCL set command to change the script (rather than changing the script by rerunning net$configure.com), your edits are overwritten by any new NET$SEARCHPATH_STARTUP.NCL scripts you subsequently generate by rerunning net$configure.com.
Digital recommends that you allow net$configure.com (and in some cases net$startup.com) to create and use the standard NCL search path script (NET$SEARCHPATH_STARTUP.NCL).
However, if you need to make site-specific changes to your search path NCL script and you do not want net$configure to overwrite these changes, you can create a site-specific search path NCL script by renaming the standard search path script (NET$SEARCHPATH_STARTUP.NCL) to NET$SEARCHPATH_LOCAL.NCL and making your changes to the new file.
For example, you might want to use the NCL set command described in Section 7.2.6 to create site-specific naming templates in NET$SEARCHPATH_LOCAL.NCL.
The net$configure.com and net$startup.com procedures check for the presence of a site-specific search path script (NET$SEARCHPATH_LOCAL.NCL) on the node. If NET$SEARCHPATH_LOCAL.NCL is present on the node, it is invoked instead of the standard script. A message similar to the following is displayed:
************************************************************** A site-specific searchpath NCL script has been found on the system (SYS$SYSROOT:[SYSMGR]NET$SEARCHPATH_LOCAL.NCL;). The configuration procedure will use this script to set the searchpath instead of using the standard searchpath script that is created by NET$CONFIGURE (NET$SEARCHPATH_STARTUP.NCL). ************************************************************** %NET$CONFIGURE-I-SITESEARCHPATH, invoking site-specific searchpath NCL script found on system
The net$configure.com and net$startup.com procedures do not modify the site-specific search path NCL script; rather, they invoke the site-specific search path script as it currently exists. Therefore, when using a site-specific search path NCL script, you must modify it prior to invoking net$configure.com whenever you change any of the following name service information:
A search path can be used to simplify migration from one name service to another. The system administrator can create a search path designating the currently used name service as the primary name service (to be searched first) and the new name service as the secondary name service (to be searched second after the primary name service is searched).
As the secondary name service becomes populated with node and addressing information, the system administrator can rerun net$configure.com and select Option 2 to reverse the positions of the name services in the search path. This causes the current secondary service to become primary, to be searched first for node and addressing information.
In each template, the user-supplied portion of the name (usually the node's terminating name or rightmost simple name) is indicated with an asterisk (*). For example, if the DECdns template is: "ABCDE:.xyz.*" and a user supplies the name fin, then the following full name: ABCDE:.xyz.fin is looked up in namespace ABCDE in the DECdns name service.
You should specify only one asterisk per template. Only the first occurrence of an asterisk (*) in the template is substituted with the user-supplied name. Any additional asterisks are passed to the name service as part of the full name. When you specify a template without an asterisk, the template string is passed to the name service unchanged.
If the user-supplied name should be passed to the name service as entered by the user, the template should be specified as follows: "*".
DECnet-Plus provides an NCL set command for modifying the naming templates associated with the naming and backtranslation search paths. Do not use the NCL set command to modify aspects of the search path other than the naming templates.
The following NET$SEARCHPATH_LOCAL.NCL script creates typical naming and backtranslation search paths. In this script ABCDE represents the namespace nickname. Your namespace nickname will appear in your NCL script:
SET NODE 0 SESSION CONTROL NAMING SEARCH PATH -
([DIRECTORY SERVICE = LOCAL, TEMPLATE = "*"], -
[DIRECTORY SERVICE = LOCAL, TEMPLATE = "local:*"], -
[DIRECTORY SERVICE = LOCAL, TEMPLATE = "LOCAL:.*"], -
[DIRECTORY SERVICE = DECDNS, TEMPLATE = "*"], -
[DIRECTORY SERVICE = DECDNS, TEMPLATE = "ABCDE:*"], -
[DIRECTORY SERVICE = DECDNS, TEMPLATE = "ABCDE:.xyz.*"], -
[DIRECTORY SERVICE = DECDNS_SYNONYM, TEMPLATE = "ABCDE:.DNA_NodeSynonym.*"
], -
[DIRECTORY SERVICE = DOMAIN, TEMPLATE = "*"], -
[DIRECTORY SERVICE = DOMAIN, TEMPLATE = "*.xyz.ABCDE.com"])
SET NODE 0 SESSION CONTROL BACK SEARCH PATH -
([DIRECTORY SERVICE = LOCAL, TEMPLATE = ""], -
[DIRECTORY SERVICE = DECDNS, TEMPLATE = "ABCDE:.DNA_BackTranslation"], -
[DIRECTORY SERVICE = DOMAIN, TEMPLATE = ""])
Support for the Domain Name System (DNS/BIND) provides for the use of node synonyms. This allows for backward compatibility with older applications that cannot use long domain names.
There are two ways to configure node synonyms for use with DNS/BIND:
You can provide synonym support for entire domains by constructing an appropriate set of search path templates. Note that excessively long search paths (search paths with many entries) can increase the time it takes to look up node addresses. See Section 7.2 for general information on name service search paths.
Entering the following NCL command sets up a search path for a system using DNS/BIND:
$ mcr ncl set session control naming search path = -
{ [Directory Service = Domain, Template = "*"], -
[Directory Service = Domain, Template = "*.finbar.com"], -
[Directory Service = Domain, Template = "*.abc.finbar.com"], -
[Directory Service = Domain, Template = "*.xyz.finbar.com"]}
This NCL command results in the following DNS/BIND naming templates:
* *.finbar.com *.abc.finbar.com *.xyz.finbar.com
When DECnet-Plus receives a connection from node koi.abc.finbar.com, it determines that koi is a usable synonym for this node, and DECnet-Plus will return the name koi to applications that require Phase IV style node names.
Using search path naming templates for synonym support allows the user to enter any of the following node names: koi, koi.abc, or koi.abc.finbar.com for node koi.
Another way to define a node synonym for a particular node is by adding DNS/BIND alias names to the local host's database. The following is an example using Digital TCP/IP Services for OpenVMS:
$ ucx set host koi.abc.finbar.com/address=aa.bb.cc.dd/alias=koi
PROFILE_003.HTML OSSG Documentation 2-DEC-1996 13:01:41.17
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.