HP OpenVMS Systems Documentation

DECnet-PlusPlanning Guide

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.

Note

If you do intend to convert any of your existing DNS Version 1
clearinghouses to DECdns Version 2 format, DIGITAL strongly recommends
that you do not configure DECnet-Plus on any of your existing
DNS Version 1 server nodes until after you have prepared your DNS
Version 1 namespace for use by DECnet-Plus.

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.

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.

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.

For complete information about using decnet_migrate, see
your network management guide.

sys$update:net$convert_databaseUpgrades 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. <>

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:

Determine if the default IDP is appropriate for your network, and,
if not, obtain a unique IDP. See Section 3.2.1.

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.

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.

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

Install and configure your DECnet-Plus software.

When the configuration procedure prompts you for your node full
name, type local:.nodename. The reserved nickname for
the Local namespace is local.

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_registerexport and import commands to extract the node
information from the Phase IV database and to import it into the Local
namespace.<>

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.

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)

Replace any unsupported hardware.

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:

It automatically configures the system as a DECdts server if a time
synchronization service is not already running in your network.

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.

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.

Use the decnet_register manage command to modify default
access control for the node directories.

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.

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:

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)

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.)

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.

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.

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:

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.

1If a directory allows autoregistration, all
systems and users have read/write access to that directory, allowing
anyone to register nodes in it.
2If a directory disallows autoregistration, only
users who are explicitly granted read/write access to that directory
can register nodes in it.