HP OpenVMS Systems Documentation

If you are already using a namespace created with Version 1 of the VAX Distributed Name Service (DNS) running on DECnet-VAX Phase IV, you can continue to use this namespace when you upgrade your networking software to DECnet-Plus. However, because of differences in the way DNS Version 1 and DECdns Version 2 handle access control, you must follow several steps to prepare your DNS Version 1 namespace for use by DECnet-Plus. These differences affect the way in which DNS Version 1 and DECdns Version 2 interpret principal specifications in access control entries (ACEs).

In DNS Version 1, servers recognize principals only of the form nodename::username. In DECdns Version 2, servers recognize principals primarily of the form nodename.username. To make it possible for the DECdns Version 2 clerks and servers that you will create later to interpret and process the DNS Version 1-style ACEs already in use in the namespace, create a backtranslation directory (.DNA_BackTranslation) and node synonym directory (.DNA_Node_Synonym) in the namespace's root directory. Then, populate these directories by registering all the nodes participating in the Version 1 namespace. See your installation guides for complete information on how to prepare a DNS Version 1 namespace for use by DECnet-Plus.

You need to perform these operations only once to prepare a DNS Version 1 namespace for use with DECnet-Plus. Once the node synonym and backtranslation directories are populated, you can configure new DECdns clerks and servers, or convert existing DNS Version 1 servers to DECdns Version 2 format in the normal manner. See the DECnet-Plus DECdns Management guide for complete information on how to configure a DECdns server into an existing namespace and how to convert a DNS Version 1 clearinghouse to DECdns Version 2 format.

If you are using a namespace created with DNS Version 1, you are already familiar with many of the distributed naming and namespace planning concepts described in Chapter 6 through Chapter 10 of this guide. However, be sure to read all the DECdns-related sections in this guide to better understand the differences between DNS Version 1 and DECdns Version 2.

2.5 Step 5: Choose the First End System to Migrate

It is important to carefully identify the first node to migrate because, in a sense, it is from this point that you will move most of the network to DECnet Phase V. You will use this first system to manage other systems during migration and, probably, to set up the DECdns name service and initialize the namespace, if you are not using a Local namespace. The following are recommendations for choosing the first node to migrate:

• You will use this node to manage other nodes during transition, so ensure that it has access to other systems you want to manage and, possibly, migrate.
• If you want to use DECdns and it does not exist on the network, make the first node you migrate a DECdns server and create a distributed namespace. See Section 7.6 for guidelines on choosing a name server node.
• You can configure this node as a DECdns clerk and use an existing Version 1 name server with the following conditions:
  • The server node must be adjacent to this first DECnet-Plus system.
    On a LAN, adjacent means on the same LAN as the existing server; in a WAN environment, it means no other systems, except the router, are configured between the Phase IV name server and the DECnet-Plus system.
  • All DECnet-Plus systems must have DECnet-Plus paths to the Version 1 name server.

For details, see the appendix on DECdns version interoperability in the DECnet-Plus DECdns Management guide.

This chapter discusses your immediate transition tasks and the tools you need to complete these tasks.

You will perform some of these tasks during DECnet-Plus configuration, some while running the transition tools immediately after configuration, and some at other times. For information about how to perform these tasks, see your installation and network management guides.

3.1 Tools: Network Management, Node-Name Management, and Transition

DECnet-Plus software includes the following tools to help you during transition. After transition, some of these tools are used for ongoing network management support and node-name management.

• sys$system:net$mgmt.exe (for OpenVMS) or
  /usr/sbin/dna_mgmt (for DIGITAL UNIX)
  A graphical user interface provided to manage Phase V nodes. You can enable NCL logging if you wish to see any NCL commands performed on your behalf by this Motif-based application.
• decnet_register
  Use the decnet_register tool to manage the node names and addressing information contained in both Local namespaces and DECdns distributed namespaces. Use decnet_register to:
  • Register node names, node synonyms, and addresses in your namespaces.
  • Add addresses to a node registration.
  • Remove addresses from a node registration.
  • Modify a node registration's synonym or addresses.
  • Display a node registration and verify its internal consistency.
  • Export node registration information from a namespace to a text file.
  • Import node registration information from a text file into a namespace.
  • Update a remote node's registered address information with information obtained from the node itself.
  • Rename a registered node in a namespace.
  • Deregister a node from a namespace.
  
  You can also use decnet_register manage command to create and manage the directories associated with the DECdns namespace.

• decnet_migrate
  Use this tool to:
  • Check information on the network's current configuration
  • Set up routing between Phase IV and DECnet Phase V areas
  • Convert NCP command files to NCL command files and upgrade either DCL command files or UNIX scripts that contain NCP commands
    
    
  • Use the Language Sensitive Editor (LSE) to create and edit NCL command files <>
  • Learn NCL syntax and NCP/NCL equivalents
  
  For complete information about using decnet_migrate, see your network management guide.
  
  
• sys$update:net$convert_database
  Upgrades the object database for DECnet-Plus for OpenVMS and converts the Phase IV MOP database to the DECnet-Plus MOP client database. During net$configure you are asked if you want to convert Phase IV databases. Answering yes runs sys$update:net$convert_database.

  Note DECnet-Plus for OpenVMS uses the proxy file created with DECnet for OpenVMS Phase IV; therefore, no update is needed. <>

  
  
  
• /usr/field/objtoncl (for UNIX)
  Converts the Phase IV object database to an NCL script (see Section 3.3.1).
• /usr/field/proxytoncl (for UNIX)
  Converts the Phase IV proxy file to an NCL script (see Section 3.3.2).
• /usr/field/update_mopdb (for UNIX)
  Converts the Phase IV MOP database to the DECnet-Plus MOP client database (see Section 3.3.3). <>

Migrating a network ultimately means migrating individual systems. Follow your transition plan to decide which procedures you will use, and in what order. No one way to migrate is correct for all networks. However, the following steps always apply:

1. Determine if the default IDP is appropriate for your network, and, if not, obtain a unique IDP. See Section 3.2.1.
2. Decide if you will use a Local namespace, a DECdns distributed namespace, or both.
   • If you use a DECdns namespace, see Section 3.2.3 for information about migrating the first end node. See Section 3.2.4 for information about migrating subsequent end systems.
   • If you use a Local namespace, see Section 3.2.2 for instructions on how to create a Local namespace for each node you configure.
   • If you use both, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration for detailed information.
3. For DECnet-Plus for OpenVMS, migrate OpenVMS cluster nodes. See Section 3.2.5.
4. Migrate local area networks. See Section 3.2.6.
5. Configure DECnet-Plus end systems in a multivendor OSI network, if your network is multivendor. See Section 3.2.7.

To configure the first DECnet-Plus system, you must know its new OSI address, including your network's IDP and, in some cases, the preDSP as well.

Determine if you can use the default IDP. If you cannot, before you start the transition to DECnet-Plus, apply for a unique IDP. For information about the format of DECnet Phase V addresses, see Chapter 4; for details about IDPs, see Section 4.1, and for instructions on how to get a unique IDP for your network, see Section 4.7.

3.2.2 Using a Local Namespace: Migrating the Network

With a Local namespace, migrating consists of installing and configuring DECnet-Plus. To create a Local namespace, take the following steps:

1. Install and configure your DECnet-Plus software.
   1. When the configuration procedure prompts you for your node full name, type local:.nodename. The reserved nickname for the Local namespace is local.
   2. The configuration procedure automatically creates the local name file.
      If neither data file exists or is readable, the procedure creates the local name file with information for the node in it.

      
      
      
      For OpenVMS, if the DECnet Phase IV node data file sys$system:netnode_remote.dat exists and is readable, then answer YES to the question, Do you want to convert a Phase IV database? and the procedure converts it to the local name file.
      The procedure will also use the decnet_register export and import commands to extract the node information from the Phase IV database and to import it into the Local namespace.<>

2. You are ready to use Go to Section 3.2.6.

Migrating the first end node includes several tasks that affect the management and migration of the entire network. These tasks include creating the namespace, configuring the first name server, and setting up access control. Therefore, it is important that the network manager carry out or oversee the migration of the first end node.

To help you plan, this section outlines the steps required to install and configure the first DECnet-Plus system in the network. Section 3.2 is meant to serve as a "road map" to familiarize you with the transition steps you need to take. The goal is to prepare you for installation, configuration, and transition as documented in the installation guides.

DECdns server software is not available for OpenVMS Alpha systems, therefore, all references to DECdns servers apply to those servers running on DIGITAL UNIX or OpenVMS VAX systems.

Choose the scenario that applies to your transition:

• If the network does not have a DECdns namespace, create a new DECdns namespace when you migrate the first system (see Section 3.2.3.1).
• If the network has a DNS Version 1 namespace (OpenVMS only), you join this existing namespace when you migrate the first system (see Section 3.2.3.2).
• If your network already has a DECdns Version 2 namespace, follow the instructions in Section 3.2.4. Each node you install and configure is a subsequent node. If you are considering multiple namespaces, see Section 2.4.2 and Section 7.1 for restrictions and guidelines.

If you choose to install and configure the first DECnet-Plus node in a network with no existing namespace, follow the steps in this section. All references to DECdns servers apply to those servers running on DIGITAL UNIX or OpenVMS VAX systems.

1. On the system to undergo the transition, ensure that the permanent node database is up to date. Back it up. This database file is:
   sys$system:netnode_remote.dat (OpenVMS only)
   /usr/lib/dnet/nodes_p (DIGITAL UNIX only)
2. Replace any unsupported hardware.
3. Install your DECnet-Plus software. As part of the installation and configuration, install and configure the DECdns server software.
   On an OpenVMS VAX system, perform the advanced configuration @sys$manager:net$configure advanced.
   On a DIGITAL UNIX system, perform the advanced configuration, decnetsetup advanced.
   During the configuration procedure:
   1. It automatically configures the system as a DECdts server if a time synchronization service is not already running in your network.
   2. You create a namespace in one of the following ways:
      • If you specified local during network configuration, a local namespace is created automatically.
      • If you specified decdns during network configuration, DNS$CONFIGURE is called to create a new DECdns namespace.
      • If you choose DECdns, you also need to do the following after the configuration procedure exits:
        • Use the decnet_register manage command to create the namespace directories, create and enable a clearinghouse, and create the root directory of the namespace in that clearinghouse.
        • Use the decnet_register manage command to initialize the namespace for use by DECnet-Plus. This initialization creates the node synonym directory (.DNA_NodeSynonym by default), the backtranslation directory (.DNA_BackTranslation by default), and the global time servers directory (.DTSS_GlobalTimeServers by default).
        • Use the decnet_register manage command to create the .DNA_Registrar access control group. The group is initially empty; use decnet_register later to add members.
        • Rerun the configuration procedure for the system to configure it as a DECdns server and a DECdns clerk.
4. Implement the namespacewide access control policy you have decided to use. DIGITAL highly recommends this practice, especially in large networks. Section 7.4 describes how to plan an access control policy.
   To implement this policy, use the decnet_register manage command to add members to .DNS_Admin, the namespace administrator group, and add access to the root directory.
5. Use the decnet_register manage command to modify default access control for the node directories.
6. While you are using decnet_register, make sure that the account under which you will run your startup procedure has at least write access to the newly created clearinghouse and root directory.
7. Your DECnet-Plus node cannot communicate with a Phase IV node until the namespace has an object and soft links for that Phase IV node. Therefore, if your network is to include Phase IV nodes, register those nodes in the namespace now. Follow these steps:
   1. Make sure that on the newly installed DECnet-Plus node, you have the up-to-date copy of:
      sys$system:netnode_remote.dat (OpenVMS only)
      /usr/lib/dnet/nodes_p (DIGITAL UNIX only)
   2. Use decnet_register to populate the namespace with Phase IV node objects and soft links. See your network management guide.
      Do this before populating the namespace with any other node names.
      Use the decnet_register manage command to create the .DNA_Node directory at this time. The node information files are initially set up to register the Phase IV nodes in this directory. (If you want, you can edit those files to change the name of the directory into which the nodes are to be registered.)
   3. Use decnet_register to:
      • Fill .DNA_Node with objects for Phase IV node names.
      • Fill the .DNA_NodeSynonym directory with soft links pointing from each node's Phase IV-style synonym to its full object name.
      • Fill the .DNA_BackTranslation area subdirectories with soft links pointing from each node address to its full object name. Each area subdirectory is populated with the node IDs of systems in that area.

After you install and configure the first DECnet-Plus system, install subsequent systems according to the transition schedule you have planned. See Section 3.3 for additional transition tasks.

3.2.3.2 If the Network Has a DNS Version 1 Namespace

If you are already using a namespace created with Version 1 of the VAX Distributed Name Service (DNS) running on DECnet-VAX Phase IV, you can continue to use this namespace when you upgrade your networking software to DECnet-Plus. However, because of differences in the way that DNS Version 1 and DECdns Version 2 handle access control, you must perform several steps to prepare your DNS Version 1 namespace for use by DECnet-Plus. These differences affect the way in which DNS Version 1 and DECdns Version 2 interpret principal specifications in access control entries (ACEs). For more information, refer to Section 2.4.3.

3.2.4 Using a Distributed Namespace: Migrating Subsequent End Nodes

The transition of any end node other than the first end node consists of installing and configuring the DECnet-Plus software. System managers can therefore migrate subsequent end nodes, as long as the network manager is available to supply the information required to answer the prompts during installation and configuration.

Installers might need help registering nodes in the namespace. Near the end of the configuration, the procedure attempts to automatically register the node in the namespace. Registration could fail, depending on the type of installation being performed and the protection level of the namespace. If it does fail, you get a message stating that you will have to manually register this node in the namespace.

To simplify node registration, you can implement one of the following strategies before installing subsequent nodes:

• Manually register each subsequent system in the namespace before it is installed and configured. Use decnet_register. See your network management guide.
• Enable node autoregistration for all directories into which users will register systems so that, during node configuration, each system can be registered automatically. Table 3-1 and Table 3-2 summarize how automatic registration and manual registration apply to:
  • New systems
  • Systems making the transition from Phase IV to DECnet-Plus
  • Systems downgraded from DECnet-Plus to Phase IV

Table 3-1 describes how you use decnet_register to register a new system in the namespace after installing DECnet-Plus or Phase IV software on the system, assuming that the system is not currently registered in the namespace.