## TCPware V5.7 Installation & Configuration Guide

- Introduction
- Configure the TCP/IP Services
  - Basic Configuration Choice
  - Full Configuration Choice
  - Component Configuration Choice
- Configure the NFS-OpenVMS Client
  - Prepare
  - Add GROUP Users
  - Add GROUP Groups
- Configure the Dynamic Host Configuration Protocol Client (DHCP Client)
- Configure the Dynamic Host Configuration Protocol Server (DHCP)
  - CNFNET Steps
- Configure DECnet over IP Tunnels
  - Prepare
  - CNFNET Steps
- Configure the Domain Name Services (DNS)
- Configure the FTP-OpenVMS Server
  - CNFNET Steps
- Configure the Gateway Routing Daemon
  - CNFNET Steps
  - Create the GATED.CONF File
- Configure the Internet Message Protocol (IMAP) Server
  - CNFNET Steps
- Configure IPP with CNFNET
  - CNFNET Steps
- Configure the Kerberos Server
  - CNFNET Steps
- Configure the Kerberos Applications
  - CNFNET Steps
- Configure the Line Printer Services
  - CNFNET Steps
- Configure the Default Remote Printer for LPS
  - Prepare
  - CNFNET Steps
- Configure the LPS Client OpenVMS Print Queues
  - CNFNET Steps
- Configure LPS for Batch Startup
- Configure the LPD Server
- Build the LPD Server Access File
  - Prepare
  - CNFNET Steps
- Configure the Miscellaneous Services
  - CNFNET Steps
  - TFTPD File Access
- Configure the NFS-OpenVMS Server
  - Prepare to Set Up the Server
  - Set Up the Server
  - Add Users to the Server PROXY Database
  - Add Directories to the Server EXPORT Database
  - Create a Spool Directory
  - CNFNET Steps, Part 1
  - CNFNET Steps, Part 2
  - Start and Restart the NFS Server
  - Test the NFS Server
- Configure the Network Time Protocol
  - CNFNET Steps
  - Configuration File
- Configure the Post Office Protocol Version 3
  - CNFNET Steps
- Configure the PWIPDRIVER
  - CNFNET Steps
- Configure the Berkeley R Commands
  - Configure the R Services
  - Configure RLOGIN, RSH, and RMT
  - Host Equivalence File
- Configure SMTP-OpenVMS
  - CNFNET Steps
- Configure SNMP Services
  - CNFNET Steps
  - Configuration File
- Configure the SSH Utility
  - CNFNET Steps
- Configure the TALK Utility
  - CNFNET Steps
- Configure TELNET-OpenVMS
  - CNFNET Steps
- Configure TIMED
  - CNFNET Steps
- Configure X Display Manager
  - CNFNET Steps

Chapter 4

Configuring the TCP/IP Services

# Introduction

This chapter describes how to configure the TCP/IP Services of TCPware. It is for the OpenVMS system manager or operator responsible for product configuration.

Proceed with this chapter after you install TCPware (Chapter 2) and configure the TCP/IP core environment (Chapter 3).

This chapter focuses on using the CNFNET menu-driven method (see Chapter 3) and the text and prompts that appear for a full configuration. Your configuration might differ, especially if you are changing specific component configurations.

For a basic configuration, accept the default values for each component, which appear in brackets after a prompt. This also helps you step through the process more quickly.

Each component configuration is described in its own section and in the order it occurs during the full configuration process. You can return to a specific component after you complete the full configuration procedure. Instructions to access the specific component configuration are given in each section.

Note! If you did not configure the core environment, the following message appears:
Please configure the core environment before configuring a specific component
Return to Chapter 3, the Start CNFNET section.

Note! You do not need to reboot your system after the configuration.

A full configuration example appears in Appendix B.

# Configure the TCP/IP Services

How you start to configure the TCP/IP Services components depends on how you chose to configure the core environment.

## Basic Configuration Choice

If you invoked CNFNET in one of the following ways, you transition into the basic configuration after you complete the TCP/IP core configuration (in Chapter 3):

• @TCPWARE:CNFNET

• @TCPWARE:CNFNET TCPWARE

• @TCPWARE:CNFNET TCP

• @TCPWARE:CNFNET BASIC

After you complete the core environment configuration, you transition to the first prompt for the ACE/Client configuration, as in Example 4-1.

Example 4-1 Transition to a Basic Configuration

You can enter the host name and the corresponding internet address for the hosts on the network.

The host definition file, TCPWARE_COMMON:[TCPWARE]HOSTS., contains the host names and internet addresses for the hosts on the network. You may also edit this file manually.

localhost LOOPBACK (127.0.0.1) added to host definition file.

NUNKI.NENE.COM (192.168.1.56) added to host definition file.

Next host name (<return> to end): DAISY Return

Internet address for DAISY.NENE.COM: 192.168.1.57 Return

DAISY.NENE.COM (192.168.1.57) added to host definition file.

Next host name (<return> to end): Return

Do you want to use the TCPware ACE/Client to authenticate user login?[YES]

## Full Configuration Choice

Use the full configuration choice when you want to configure all the TCPware components. You perform a full configuration when you invoke CNFNET using

@TCPWARE:CNFNET MENU,

enter 1 (Configure TCPware Services) at the Enter configuration option: prompt, and enter 2 (Configure all TCP/IP components) after you perform the TCP/IP core configuration and return to the TCPware Services Configuration Menu (see Example 4-2).

You also perform a full configuration when you invoke CNFNET using

@TCPWARE:CNFNET FULL.

You usually perform a full configuration when you are familiar with each TCPware component and want to customize your settings.

Proceed directly to the Configure the TCPware ACE/Client section.

Example 4-2 Invoking a Full Configuration

TCPware Services Configuration Menu

Configuration Options:

1 - Core environment for TCP/IP services
2 - Configure all TCP/IP components
3 - Configure a specific TCP/IP component
4 - Startup/Restart TCP/IP services
5 - Shutdown TCP/IP services
6 - Startup/Restart a specific TCP/IP component
7 - Shutdown a specific TCP/IP component
E - Exit to previous menu

Enter configuration option: 2 Return

## Component Configuration Choice

The component configuration is most useful for fine tuning an individual component configuration. It is essentially a full configuration, but for a single component only. You start a component configuration when you invoke CNFNET using

@TCPWARE:CNFNET MENU

complete the core configuration, return to the TCPware Services Configuration Menu (as in Example 4-2), and enter 3 (Configure a specific TCP/IP component) at the prompt: Enter configuration option:.

You then access the Configuring a Specific TCP/IP Component menu (see Example 4-3). Enter the number next to the component listed at the prompt:

Enter menu option:

For example, to configure the NFS-OpenVMS Client, enter 2. (You can also enter the component name, such as CNFS.)

You can also perform a component configuration when you invoke CNFNET as follows:

$ @TCPWARE:CNFNET component

Substitute the component name abbreviation for component in the command. Use the abbreviations listed after the numbers in Example 4-3. For example, to configure the NFS-OpenVMS Client, enter

@TCPWARE:CNFNET CNFS.

Proceed directly to the Configure the TCPware ACE/Client section.

Example 4-3 Configuring a Specific TCP/IP Services Component

Configuring a Specific TCP/IP Component

Configuration options:
1 - ACCOUNTING Configure the TCP/IP Services accounting facility
2 - CNFS Configure the NFS-OpenVMS Client
3 - DHCP Configure the Dynamic Host Configuration Protocol Server
4 - DNIP Configure DECnet over IP tunnels
5 - DNS Configure the Domain Name Server
6 - FTP Configure the FTP-OpenVMS Server
7 - GATED Configure the Gate Daemon
8 - IMAP Configure the Internet Message Access Protocol Server

9 - IPP Configure the Internet Printer Protocol
10 - KERBEROS Configure the Kerberos Services
11 - LPS Configure the Line Printer Services
12 - MISC Configure the Miscellaneous Services
13 - NFS Configure the NFS-OpenVMS Server
14 - NTP Configure the Network Time Protocol Daemon
15 - POP3 Configure the Post Office Protocol V3 Server
16 - PWIP Configure the PWIPDRIVER
17 - RCMD Configure the Berkeley R Commands
18 - SMTP Configure the Simple Mail Transfer Protocol Services
19 - SNMP Configure the Simple Network Management Protocol Agents
20 - SSH Configure the SSH-OpenVMS Server
21 - TALK Configure the TALK server
22 - TELNET Configure the TELNET-OpenVMS Server
23 - TIMED Configure the TIMED Server
24 - XDM Configure the XDM Server
Enter menu option (E to exit):

# Configure the NFS-OpenVMS Client

Because you need to install, configure, and start TCPware for OpenVMS before you can set up the NFS-OpenVMS Client, you might want to enter N at the prompt:

Do you want the NFS Client [YES]

This lets you continue with CNFNET. You can always go back later to invoke the NFS-OpenVMS Client component configuration using

@TCPWARE:CNFNET CNFS.

You need to first use the Network Control Utility (NETCU) to define entries for the PROXY and GROUP databases to enforce file system protection across the network.

## Prepare

Before you add users to the PROXY and GROUP databases, you need to:

• Be sure the network is up and running.

• Identify which OpenVMS client users need to access NFS served files on the network.

• Match the OpenVMS users with valid accounts on the host running the NFS server software. In some cases, you might need to create new usernames to accommodate these accounts.

Example 4-4 Adding Users to the Client PROXY Database

$ NETCU
NETCU> SHOW PROXY
%TCPWARE_NETCU-I-NOENTRIES, no PROXY entries found

NETCU> ADD PROXY SMITH /UID=1127 /GID=15 /CLIENT/SERVER
NETCU> SHOW PROXY
NFS PROXY Database V5.7 Copyright (c) 2004 Process Software

Username UID GID Host(s)
-------- --- --- -------
SMITH 1127 15

NETCU> RELOAD PROXY SMITH

## Add GROUP Users

To add users to the client GROUP database (see Example 4-6):

1 Access the UNIX server and issue the cat /etc/group command at the UNIX system prompt. The format of each entry in the /etc/group file is:

unix-group:encrypted-password:GID:user-list

2 Select the file record with the unix-group that you want to associate with the OpenVMS user, and record the GID number. For example, select the following accounting group:

accounting:*:30:smith,jones

Then record the GID as the number 30.

3 Log out of the UNIX NFS server system.

4 Set the default to SYS$SYSTEM on the OpenVMS system and run AUTHORIZE.

5 Enter the SHOW/IDENT command and check the list of authorized rights identifiers.

6 Enter the ADD /IDENTIFIER command along with an OpenVMS rights identifier that corresponds to your chosen entry on the UNIX server.

7 Grant the ACCOUNTING identifier to all client users you want to have group access to the server file. These users should correspond to the user-list entries for the entry in the /etc/group file. Use the GRANT /IDENTIFIER command for each user.

8 Exit AUTHORIZE.

Example 4-5 Adding Users to the GROUP Database

> cat /etc/group
wheel:*:0:
nogroup:*:65534:
daemon:*:1:
kmem:*:2:
bin:*:3:
tty:*:4:
operator:*:5:
news:*:6:
uucp:*:8:
audit:*:9:
login:*:15:joe2
staff:*:10:peters,henry
other:*:20:
accounting:*:30:smith,jones|
> exit
logout
$ SET DEF SYS$SYSTEM
$ RUN AUTHORIZE
UAF> SHOW/IDENT *
Name Value Attributes
BART [001000,000127]
DECNET [000376,000376]
DIALUP %X80000002
FAL$SERVER [000376,000373]
INTERACTIVE %X80000003
LOCAL %X80000004
SYSTEM [000001,000004]
USER [000200,000200]
UAF> ADD/IDENTIFIER ACCOUNTING
%UAF-I-RDBADDMSG, identifier ACCOUNTING value: %X80010006 added to rights
data base
UAF> GRANT/ID ACCOUNTING SMITH
%UAF-I-GRANTMSG, identifier ACCOUNTING granted to SMITH
UAF> GRANT/ID ACCOUNTING SMITH
%UAF-I-GRANTMSG, identifier ACCOUNTING granted to SMITH
UAF> EXIT (continued on next page)

%UAF-I-NOMODS, no modifications made to system authorization file
%UAF-I-NAFNOMODS, no modifications made to network proxy data base
%UAF-I-RDBDONEMSG, rights data base modified

## Add GROUP Groups

To add a group to the GROUP database (see Example 4-7):

1 Run NETCU.

2 Enter an ADD GROUP command for the new group. Use the format:

ADD GROUP nfs-group identifier

nfs-group is the same number as the group in the /etc/group file on the server; for example, 30 in the accounting:*:30:smith,jones entry.

identifier is the rights identifier you previously defined with the ADD /IDENTIFIER command; for example, ACCOUNTING.

3 Enter the SHOW GROUP command in NETCU to confirm that the GROUP database contains the correct information. The value can be either hexadecimal (as in Example 4-7) or in UIC format (such as [1000,1000]).

4 Enter the RELOAD GROUP command if you added a group to an existing GROUP database. This command ensures that new entries take effect by reloading the database on the client.

5 Exit NETCU.

6 Repeat the process for each new group definition; for example, group 10 in Example 4-6 (the staff:*:10:peters,henry entry in the /etc/group file on the server).

Example 4-6 Adding the Group to the GROUP Database

$ NETCU
NETCU> ADD GROUP 30 ACCOUNTING

NETCU> SHOW GROUP
NFS GROUP Database V5.7 Copyright (c) 2004 Process Software

Group Name Value Host(s)
----- ---- ------ -------
30 ACCOUNTING %X80010006

NETCU> RELOAD GROUP
NETCU> EXIT

$ RUN AUTHORIZE
UAF> ADD /ID STAFF
%UAF-I-RDBADDMSGU, identifier STAFF added
UAF> GRANT /ID STAFF PETERS
%UAF-I-GRANTMSG, identifier STAFF granted to PETERS
UAF> GRANT /ID STAFF HENRY
%UAF-I-GRANTMSG, identifier STAFF granted to HENRY
$ NETCU
NETCU> ADD GROUP 10 STAFF

See the Management Guide, Chapter 13, Managing NFS-OpenVMS Client.

# Configure the Dynamic Host Configuration Protocol Client (DHCP Client)

Before setting up a DHCP client, you should talk to your network administrator. The administrator may want to assign a host name to your DHCP client.

If this is your first time using the DHCP client on the host, you need to do the following:

$ COPY TCPWARE:DHCLIENT_CONF.TEMPLATE TCPWARE:DHCLIENT.CONF

Then, edit the file "TCPWARE:DHCLIENT.CONF" to replace this line:

#Send host-name "testing";

with this line:

Send host-name "any hostname you want";

You can configure your local host to use the DHCP client when you run the TCPware configuration utility CNFNET. There are two ways to do it:

$ @TCPWARE:CNFNET

$ @TCPWARE:CNFNET DHCLIENT

After you configure the local host to use DHCP client, you can run

@TCPWARE:STARTNET

to start TCPware. You can also use the same method above to disable the DHCP client on the host. Here are two examples:

Example 4-1 Using CNFNET

$ @TCPWARE:CNFNET
TCPware (R) for OpenVMS Version 5.7-1 Network Configuration procedure for:
TCP/IP Services: :
FTP-OpenVMS
NFS-OpenVMS Client
NFS-OpenVMS Server
SMTP-OpenVMS
TELNET-OpenVMS
Kerberos Services
SSH-OpenVMS Server
This procedure helps you define the parameters needed to get
TCPware (R) for OpenVMS running on this system.

This procedure creates the configuration data file,
TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your
system’s configuration.

Type Return to continue... Return

... ...
... ...
You need to supply the following information for each line:

- The internet address for the line
- The name for the line (same as the host name if single
line host, fully qualified domain name if using DNS)
- The subnet mask for the line
- The line specific information (depends on the line)
If there is a DHCP server running on the network and this is a single line host, you may get the information from DHCP server automatically. To do so, please select 2.
1. Configure Internet address and related items manually.
2. Configure Internet address and related items automatically
Continue with selection [1]:2 Return
Configure line SVA-0:
Set DHCP client Host Name
You can press Enter to let the system choose a host name. Or you can specify a name you would like to use for the host. However, the final name for the host will be up to the DHCP server to decide, it may not be the name you specify.
Host Name (Return to end) []:Return

You need to specify local time zone information. Time zone maybe specified as fixed value which must be manually set for the daylight savings time change, or you can use NTP (Network Time Protocol) Daemon to change the system clock and time offset automatically.

Do you want to have NTP set the time and time offset automatically [NO]?

... ...
... ...

Example 4-2 Using CNFNET DHCLIENT

$ @TCPWARE:CNFNET DHCLIENT

TCPware(R) for OpenVMS Version 5.7-1 Network Configuration procedure for: TCP/IP Services:
FTP-OpenVMS
NFS-OpenVMS Client
NFS-OpenVMS Server
SMTP-OpenVMS
TELNET-OpenVMS
Kerberos Services
SSH-OpenVMS Server

This procedure helps you define the parameters needed to get
TCPware(R) for OpenVMS running on this system.

This procedure creates the configuration data file, TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your system's configuration.

Type Return to continue... Return

Configuring the Dynamic Host Configuration Protocol (DHCP) Client:

Do you want to use the DHCP Client [YES]: Return

The DHCP Client can perform error logging and debug message logging to OPCOM.

You can choose whether to log debug messages to OPCOM (errors are always logged to OPCOM).

Log error/debug messages to OPCOM [NO]: Return

Set DHCP client Host Name :

You can press Enter to let the system choose a host name. Or you can specify a name you would like to use for the host. However, final name for the host will be up to the DHCP server to decide, it may not be the name you specify.

Host Name (Return to end) []:

Do you want to restart DHCLIENT [NO]:Return
$

# Configure the Dynamic Host Configuration Protocol Server (DHCP)

The Dynamic Host Configuration Protocol (DHCP) Server supports the DHCP protocol and the BOOTP (bootstrap) protocol. Both protocols allow you to supply IP addresses and network configuration data to remote client systems.

## CNFNET Steps

You can configure the DHCP server as part of the general CNFNET configuration or specifically using @TCPWARE:CNFNET DHCP (see Example 4-8):

1 At the prompt, enter Y if you want DHCPD, or press Return or enter N if you do not want DHCPD.

2 If you responded Y in step 1, you must also specify what kind of error logging and debug logging you want and where you want the logging to go.

a Specify the debug logging level you want, or press Return to accept the default, which is to log severe errors and warnings.

b Specify the name of the debug log file you want, or press Return to accept the default (TCPWARE:DHCPDEBUG.LOG). Enter _NL: to have no log file.

c At the prompt, enter Y if you want the date included in each log file entry (the time is always included), or press Return or enter N if you do not want the date included.

d At the prompt, enter Y if you want debug messages logged to OPCOM, or press Return or enter N if you do not.

For more information on DHCP, see the Management Guide, Chapter 2, DHCP/BOOTP Server.

Example 4-7 Configuring DHCP

Configuring the Dynamic Host Configuration Protocol (DHCP) Server:

Do you want to enable the Dynamic Host Configuration/Bootstrap Protocol Server (DHCPD) [YES]: Y Return [1]

The DHCP server can perform error logging and debug message logging to OPCOM or a file or both. You can set the error/debug logging level, the name of the file to log to (if any), whether to include the date on each entry in the log file, and whether to log debug messages to OPCOM (errors are always logged to OPCOM). The logging level value is a decimal integer that is a bitmask of levels of increasing severity. The levels are (in decimal):

1 Severe Errors
3 Warnings
7 Informationals
15 Debug Messages
31 Dump Packets (Formatted)
63 Dump Packets (Hex)
It is recommended that the value be set to log at least severe errors and warnings.

Error/Debug logging level [3]: Return [2a]

Debug file name (use _NL: for none) [TCPWARE:DHCPDEBUG.LOG]: Return [2b]

Include date on each log entry [NO]: Return [2c]

Log debug messages to OPCOM [NO]: Return [2d]

# Configure DECnet over IP Tunnels

The next step is to configure DECnet over IP tunnels. Tunneling DECnet over IP allows you to configure a DECnet line and circuit between two OpenVMS systems running TCPware.

## Prepare

To configure DECnet over IP tunneling, you need:

• The Internet address of the remote host that establishes the tunnel.

• The port number for this tunnel on the remote host (the default port number is 64215).

## CNFNET Steps

You can configure TCPware's DECnet over IP tunnels as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET DNIP (see Example 4-9).

1 Respond to the prompt Do you want to configure DECnet over IP tunnels [NO]: with Y.

2 Specify the DECnet line name for the first DECnet over IP tunnel. If this is the first DECnet over IP tunnel, enter DNIP-0-0.

3 Enter the Internet address of the remote host.

4 Enter the port number for this tunnel on the remote host. To accept the default port number [64215], press Return.

5 Enter the port number for this tunnel on the local host. If the one given is correct, press Return.

6 Enter Y if you want to configure another DECnet over IP tunnel. If you answer Y, return to step 2 and configure the next DECnet over IP tunnel.

7 To end configuring tunnels, enter N or press Return when the Do you want to configure another tunnel prompt reappears.

8 If the DNIP configuration is correct, enter END or E at the What would you like to do (ADD, CHANGE, DELETE, or END): prompt.

Example 4-8 Configuring DECnet over IP Tunnels

Configuring DECnet over IP tunnels:

DECnet over IP tunneling allows you to establish DECnet lines and circuits over a TCP/IP network.

Do you want to configure DECnet over IP tunnels [NO]: Y Return [1]

Specify DECnet line name for the tunnel [DNIP-0-0]: Return [2]

You need to specify the internet address of the remote host with which you want to establish the tunnel.

Specify remote host internet address: 192.168.2.10 Return [3]

You need to specify the TCP port number for the tunnel on both the local and remote hosts. Normally you should use the default port number (64215, an unassigned port that is unlikely to be used on your systems). If for any reason you need a different port number, specify it here.

The local port number and remote port number do not have to be the same.

You can use the same port number for more than one tunnel.
Specify port number for this tunnel on remote host 192.168.2.10 [64215]: Return [4]

Specify port number for this tunnel on this host [64215]: Return [5]

Do you want to configure another tunnel [NO]: Y Return [6]
Specify DECnet line name for the tunnel [DNIP-0-1]: Return
Specify remote host internet address: 192.168.2.65 Return
Specify port number for this tunnel on remote host 192.168.2.65 [64215]: Return
Specify port number for this tunnel on this host [64215]: Return

Do you want to configure another tunnel [NO]: Return [7]

The currently configured tunnels are:

DECnet Line Remote Host Local Port Remote Port
----------- ----------- ---------- -----------
DNIP-0-0 192.168.2.10 64215 64215
DNIP-0-1 192.168.2.65 64215 64215

You may enter:
ADD To add a new tunnel or tunnels
CHANGE To change an existing tunnel or tunnels
DELETE To delete an existing tunnel or tunnels
END To end configuring the DECnet over IP tunneling

What would you like to do (ADD, CHANGE, DELETE, or END): END Return [8]

# Configure the Domain Name Services (DNS)

If you entered a domain-style hostname when you defined your local hostname during the core configuration, CNFNET asks additional questions about the Domain Name Services.

You can configure the Domain Name Services as part of the general CNFNET configuration or specifically as

@TCPWARE:CNFNET DNS

If this is not a first time installation, CNFNET asks if you want to change the existing configuration. Press Return for YES, or enter N for NO.

Enabling the DNS server creates a default caching server if there was no previous configuration. If there was a previous configuration in the BIND version 4 format, the configuration is converted to a BIND version 8 format.

If you intend to run a server other than the default caching server, you must edit the DNS configuration. See the Editing Database Files section in Chapter 3 of the Management Guide.

Example 4-9 Configuring the Domain Name Services

Configuring the Domain Name Services (DNS):

Do you want to change the DNS configuration [YES]: Return

Do you want to enable the DNS Server [NO]: Y Return

Cluster Load balancing is used to order a list of IP addresses based on their perceived system load. This server must be authoritative for any cluster names that are to use cluster load balancing, and the server must know what those cluster names are. If you would like to use cluster load balancing, enter yes to be prompted to enter cluster names. Use spaces to separate cluster names

Do you want to configure a list of cluster names [NO]: Y Return
Enter the cluster name(s) []: cluster.nene.com Return

Do you want to enable DNS client support [YES]: Return

The client needs to obtain information from an DNS server.

Provide the internet address(es) of up to three DNS servers. Use spaces to separate multiple addresses.

Note: If the local host is configured as a server, you can enter the loopback internet address or the local host’s internet address to make use of that server.

Enter the internet address of the server(s) [192.168.1.1]: Return

By default, the client appends the local domain name to local queries, and queries that fail resolving as fully qualified names. If you would like other domains appended, provide the name(s) of up to six domains to append. If you do not want to append a domain other than your default domain, answer no to skip to the next section. Use spaces to separate multiple domains.

Do you want to configure a list of domains [NO]: Y Return

Enter the name(s) of the domains in search list []: nene.com com Return

By default, the client resolves host names with 1 or more dots absolutely before appending your domain name. If you would like host names with 1 or more dots to be resolved with your domain name first, or you would like host names with no dots to be resolved absolutely, you want to change the number of dots.

Do you want to configure number of dots [NO]: Y Return

Enter the minimum number of dots to be resolved absolutely [1]: 2 Return

This is how your DNS client is configured:

Domain Name: nene.com
Name Server(s): 192.168.1.1
Domain List: nene.com com
Number of Dots: 2

Is this configuration correct [YES]: Return

# Configure the FTP-OpenVMS Server

## CNFNET Steps

You can configure the FTP-OpenVMS Server as part of the general CNFNET configuration or specifically as

@TCPWARE:CNFNET FTP.

Note! It is advisable, if you want automatic startup of this component, to include the $ SET NOON line in your SYLOGIN.COM file to prevent the component from failing should there be an error in the file.

Example 4-10 Configuring FTP

Configuring FTP-OpenVMS:
Do you want to enable the FTP server [YES]: Return
Do you want to enable FTP accounting [NO]: Y Return
Name of host that will run accounting collection program [localhost]:
Port number that accounting collection program listens on []:

CNFNET then continues with the resolver configuration, as in the previous section.

# Configure the Gateway Routing Daemon

The Gateway Routing Daemon (GateD) manages multiple routing protocols, including the Routing Information Protocol (RIP), Local Network Protocol (HELLO), Open Shortest Path First (OSPF), Exterior Gateway Protocol (EGP), Border Gateway Protocol (BGP), and ICMP Router Discovery.

GateD allows you to control the flow of routing information by means of a configuration language. Once you start GateD, it makes routing decisions based on the data gathered by the routing protocols.

## CNFNET Steps

You can configure GateD as part of the general CNFNET configuration or specifically as

@TCPWARE:CNFNET GATED

Press Return for YES or enter N for NO at the prompt (see Example 4-12).

Example 4-11 Configuring GateD

Configuring the GateDaemon (GateD):

GateD is a routing process that automatically exchanges routing information with other hosts using a variety of protocols. The supported protocols are: RIP Version 1, RIP Version 2, DCN HELLO, OSPF Version 2, EGP Version 2, BGP Versions 2 through 4, and Router Discovery.

Please follow the procedure described in the TCPware for OpenVMS Installation & Configuration Guide to configure GateD.

Do you want to use the TCPware GateDaemon [YES]: Return

CAUTION! If using GateD, do not also have route settings in the ROUTING.COM file, since these ROUTES can conflict.

## Create the GATED.CONF File

Create the TCPWARE:GATED.CONF configuration file. For example, the statements in the GATED.CONF file shown in Example 4-13 address a situation where the gateway announces a default route to the backbone and announces all the subnet routes to the outside world.

Example 4-12 Default RIP Announcements

# enable RIP:
#
rip yes;

# using RIP, announce all local subnets via interface 192.168.12.3:
#
export proto rip interface 192.168.12.3 metric 3
{
proto rip interface 192.168.1.5
{
all;
};
};
#
# Using RIP, announce default via interface 192.168.1.5:
#
export proto rip interface 192.168.3.1
{
proto rip interface 192.168.1.5
{
default;
};
};

See the Management Guide, Chapter 8, Routing and GateD.

# Configure the Internet Message Protocol (IMAP) Server

The Internet Message Protocol (IMAP) Server lets remote PC systems receive mail in your system's mailboxes. TCPware's implementation is IMAP Version 4 revision1.

## CNFNET Steps

You can configure the IMAP Server as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET IMAP (see Example 4-14):

1 Enter Y or Return at the prompt asking if you want to enable the TCPware IMAP Server.

If you do not want IMAP, enter N.

2 If you entered Y, enter the user (account) the IMAPD (daemon) process should execute as. The default is SYSTEM. Whatever user you choose must have SYSNAM, TMPMBX, NETMBX, and SYSPRV or BYPASS privileges.

3 Determine if you want to enable message caching.

By default, the IMAP Server caches only the text of the last accessed message and the attributes of all messages in the currently selected folder. Enabling message caching causes the server to cache the text of all messages once seen and until the folder is closed. Message caching can increase server performance, but requires considerably more memory.

4 Determine the debug logging level for the connection. Select:

• NONE if you do not want debug logging (default)

• ERROR if you want to log errors only

• INFO if you want to log informational messages and errors

• DEBUG if you want complete debug logging

You can enter just the first letter of your choice at the prompt.

5 CNFNET displays the IMAP configuration parameters you set. Respond whether this is correct by pressing Return for YES, or entering N for NO. If NO, return to step 2 to reenter the parameters.

6 If you previously configured the IMAP server, a prompt comes up asking if you want to restart it based on the changes you made.

For more information on IMAP, see the Management Guide, Chapter 17, Managing Mail Services, in the IMAP Server section.

Example 4-13 Configuring IMAP

Configuring the Internet Message Access Protocol V4 (IMAP) Server:

For detailed information on the following parameters, refer to the TCPware for OpenVMS Management Guide.

Do you want to enable the IMAP server [YES]: Return [1]

Specify the username the IMAPD process should execute as. The account requires SYSNAM, TMPMBX, NETMBX, and SYSPRV or BYPASS privileges.

Enter the username [SYSTEM]: Return [2]

The server can be configured to cache all messages in a folder while it is in use. This may increase performance in some cases, but requires substantially more memory per process. By default, only the most recently accessed message is cached.

Do you want to enable full message caching [NO]: Y Return [3]

Determine the logging level, Options are:

NONE - No logging
ERROR - Errors only
INFO - Information messages and Errors
DEBUG - Complete Debug logging

You may enter the first character of your choice.

Enter your choice (None, Error, Info, Debug) [INFO]: NONE Return [4]

The IMAP server is configured as follows:

Username : SYSTEM
Message caching enabled : YES
log level : NONE

Is this correct [YES]: Return [5]

Do you want to restart the Internet Message Access Protocol Server [NO]: Y Return [6]

Shutting down the Internet Message Access Protocol Server ...
Starting the Internet Message Access Protocol Server ...

# Configure IPP with CNFNET

## CNFNET Steps

You can configure IPP as part of the general CNFNET configuration, or specifically as
@TCPWARE: CNFNET IPP (see Example 4-14).

Example 4-14 Configuring IPP with CNFNET

$ @TCPWARE:CNFNET IPP

TCPware(R) for OpenVMS Version 5.7-1 Network Configuration procedure for:

TCP/IP Services:
FTP-OpenVMS
NFS-OpenVMS Client
NFS-OpenVMS Server
SMTP-OpenVMS
TELNET-OpenVMS
Kerberos Services
SSH-OpenVMS Server

This procedure helps you define the parameters needed to get
TCPware(R) for OpenVMS running on this system.

This procedure creates the configuration data file,TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your

system's configuration.
Type <return> to continue... <RETURN>

Configuring IPP Symbiont (IPP):

IPP Symbiont is an Internet Printing Protocol Client that enables printing using IPP to IPP-capable printers and servers over a TCP/IP network. The supported version of the IPP protocol is 1.0.

Please follow the procedure described in the TCPware for OpenVMS Installation and Configuration Guide to configure IPP print queues.

Do you want to use the TCPware for OpenVMS IPP Symbiont [YES]: YES

Configuring the default document format for the IPP symbiont.

IPP allows the specification of the document format using MIME mediatypes, such as "text/plain", "application/postscript" or others. The default document format entered here will become the default used by all IPP queues that do not specify a different default in their own configurations. Individual jobs may specify other values as needed. To force the default to be whatever format the individual printers have set as a default, specify "***printer_default***".

What is the default document format [text/plain]: <RETURN>

Configuring Job retry Delay for the IPP symbiont.

When there is a problem with a job that appears to be temporary innature, the job will be requeued and tried again after a delay. The Job Retry Delay specifies the default value for how long a job will be requeued for. Individual queues may specify a different value. Specify this time as a standard OpenVMS delta time.

What is the job retry delay time [0 00:10:00.00]: <RETURN>

Configuring Max Log Bytes for the IPP symbiont.

When logging data in DETAILED_TRACE mode, the actual data being sent andreceived is written to the log file in hexidecimal and in ASCII. Thedefault behavior of the symbiont is to log all data. This setting will change that default for all IPP queues to the value entered. Individual queues may be configured to use different values than the default. The value is specified in bytes.

What is the MAX_LOG_BYTES value [-1]: <RETURN>

Configuring Max Stream Count for the IPP symbiont.

Each IPP symbiont process can handle data for up to 16 different IPP queues. Each queue handled by a given symbiont process is refered to as a "stream". This setting determines how many streams each queue will handle. When more than this number of IPP queues are started, additional symbiont processes will be created, each handling no more than MAX_STREAMS streams.

What is the maximum number of streams per symbiont process [16]: 15

Configuring Log Level for the IPP symbiont.

There are a number of different detail levels for logging symbiont progress and problem messages. The most detailed level,"DETAILED_TRACE", can generate significant amounts of data, and should be reserved for situations where a problem is being investigated. It is not recommended for normal use.
This value specifies the default level to be used by all queues that do not specify a different value explicitly in their configurations. See the IPP documentation for a list of legal values for this parameter.

What is the default logging level [JOB_TRACE]: FILE_TRACE

Configuring Opcom Log Level for the IPP symbiont.

There are a number of different detail levels for sending symbiont progress and problem messages to OPCOM. The most detailedlevel,"DETAILED_TRACE", can generate significant amounts of data, and should probably not be used for this setting.

This value specifies the default level to be used by all queues that donot specify a different value explicitly in their configurations. See the IPP documentation for a list of legal values for this parameter.

What is the default OPCOM logging level [INFO]: <RETURN>

Configuring Opcom Terminal for the IPP symbiont.

There are several OPCOM "terminals" to which OPCOM messages can bedirected. This value specifies the default OPCOM terminal to be used by all queues that do not specify a different value explicitly in their configurations. See the IPP documentation for a list of legal valuesfor this parameter.

Which OPCOM terminal should logging messages be sent to [PRINTER]: <RETURN>

Configuring Autostart for the IPP symbiont.

When TCPware is started, or CNFNET is used to start the IPP component in particular, it can automatically issue a START/QUEUE command for all of the queues on the system that use the IPP print symbiont.

Do you want to auto-start the IPP queues [NO]: YES

Configuring Autostop for the IPP symbiont.

When TCPware is shutdown, or CNFNET is used to shutdown the IPP component in particular, it can automatically issue a STOP/QUEUE/RESET command for each of the queues on the system that use the IPP print symbiont.

Do you want to auto-stop the IPP queues [NO]: YES

Do you want to restart the IPP client [NO]: YES

Shutting down the IPP client ...
All TCPWARE_IPP_SYMB queues stopped.
Starting the IPP client ...
Starting queue TW_IPP...
All TCPWARE_IPP_SYMB queues started.

# Configure the Kerberos Server

If you are configuring Kerberos for TCPware, you can configure your machine as a Primary Kerberos Server and have Kerberos applications, or have just Kerberos applications, such as RCP, RSH, RLOGIN, and TELNET.

## CNFNET Steps

You can configure the Kerberos Server as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET KERBEROS (see Example 4-16).

1 Enter Y at the prompt Do you want the Kerberos Services [NO]:.

2 Press Return at the prompt Do you want to configure Kerberos Services [YES]:.

3 Indicate the type of Kerberos service you want. You can set up your host as a Primary Kerberos Server with Kerberos applications, or can choose not to set it up as a server but have Kerberos applications. Enter PRIMARY for a Primary Server with Kerberos applications, or APPLICATIONS for Kerberos applications only.

4 Enter the name of the default Kerberos realm in which your host resides. The default Kerberos realm name is the DNS domain name. This information is in the TCPWARE:KRB.CONF file. Enter your realm name or accept the given default at the prompt Name of the default Kerberos realm [your-realm]:.

If the KRB.CONF file already exists from a previous configuration, the contents of the file appear. If you want to change this file, enter Y at the prompt Do you want to change TCPWARE:KRB.CONF [NO]:.

5 Enter the name of the Primary Kerberos Server at the prompt Name of the Primary Kerberos server []:. This name is required.

6 Enter the names of any secondary Kerberos server at the prompt Name of a Secondary Kerberos server []:. These names are optional.

The prompt reappears, allowing you to specify more secondary servers.

To delete an existing Kerberos secondary server name, enter an asterisk (*).

To stop entering names of secondary Kerberos servers, press Return.

To register other Kerberos servers after configuration, edit the TCPWARE:KRB.CONF file and add these servers to the end of the file.

7 If you entered PRIMARY in step 3, enter the maximum age of the Kerberos database. Kerberos servers use the maximum age setting at startup to determine if their databases are too old. Enter the value or accept the default of NONE at the prompt Maximum age of the Kerberos database (in seconds) [NONE]:.

The range is between one hour (3600 seconds) and three days (259200 seconds). If you enter NONE, TCPware does not check the maximum age of the database.

Example 4-15 Configuring the Kerberos Server

Configuring Kerberos (Version 4) Services:

Kerberos allows you to control user access to network services.

Do you want the Kerberos Services [NO]: Y Return [1]

Do you want to configure Kerberos Services [NO]: Y Return [2]

There are two Kerberos service types available:

PRIMARY = Primary server & Kerberos applications.
APPLICATIONS = Kerberos applications only.

Please choose one of (PRIMARY or APPLICATIONS).

What type of Kerberos service do you want [PRIMARY]: Return [3]

Enter the name of the default Kerberos realm that this machine resides in. The default for the Kerberos realm name is the DNS Domain Name. This information is stored in TCPWARE:KRB.CONF

Name of the default Kerberos realm [nene.com]: Return [4]

Enter the names of the primary and secondary Kerberos servers.

NOTE: The name of the primary server is REQUIRED.

To delete an existing Kerberos secondary server name, type "*" at the
prompt.

To stop entering names of secondary Kerberos servers, hit Return when
there is no default secondary server name present.

If you want to register other Kerberos servers after configuration,edit
the TCPWARE:KRB.CONF file and add them to the end of the file.

Name of the Primary Kerberos server []: PHI Return [5]

Name of a Secondary Kerberos server []: BART Return [6]

Name of a Secondary Kerberos server []: MARGE Return

Name of a Secondary Kerberos server []: Return

Enter the maximum age of the Kerberos database. Kerberos servers use
this at startup to determine if their databases are too old.

The range of this value is between one hour (3600 seconds) and three
days (259200).

If you enter "NONE", then the maximum age of the database is not
checked.

Maximum age of the Kerberos database (in seconds) [NONE]: Return [7]

# Configure the Kerberos Applications

You can configure Kerberos for incoming RCP, RLOGIN, RSH, and TELNET services.

## CNFNET Steps

Additional Kerberos configuration prompts ask whether you want to allow Kerberos authentication for incoming RCP, RLOGIN, RSH, and TELNET requests (see Example 4-17):

1 Determine if you want each application server to:

• REQUIRE that only Kerberos requests be handled.

• ALLOW both Kerberos and non-Kerberos requests to be handled.

• DISABLE Kerberos requests from being handled.

2 Respond to whether you want to require, allow, or disable handling of Kerberos authentication requests to the RLOGIN, RSH, and TELNET servers.

3 Determine the location of the user’s Kerberos ticket file and enter it at the prompt.

4 The configuration values appear. Determine if this configuration is correct and press Return or enter N at the prompt

Is this configuration correct [YES]:.

Note! Once completing the CNFNET procedure, you need to create the Kerberos database and stash the Kerberos master password, otherwise the Kerberos Server will not start. Use the NETCU commands described in Chapter 23 of the Management Guide, Managing Kerberos. Then restart Kerberos by entering @TCPWARE:STARTNET KERBEROS.

Example 4-16 Figuring Kerberos Applications

Kerberos authentication can be enabled for incoming requests to the RLOGIN, RSH (RCP), and TELNET servers. Available options are:

REQUIRED = Only Kerberos requests are handled.
ALLOWED = Both Kerberos and non-Kerberos requests are handled.
DISABLED = Only non-Kerberos requests are handled.

Please select one of (REQUIRED, ALLOWED, or DISABLED): [1]

Do you want RLOGIN Kerberos authentication requests to be [ALLOWED]: Return [2]

Do you want RSH (RCP) Kerberos authentication requests to be [ALLOWED]: Return

Do you want TELNET Kerberos authentication requests to be [ALLOWED]: Return

Enter the location of the user's ticket file [SYS$LOGIN:KERBV4.TICKET]: Return [3]

These are the values you have chosen:

Kerberos service type: PRIMARY
Kerberos database age limit: NONE
RLOGIN server Kerberos authentication is: ALLOWED
RSH (RCP) server Kerberos authentication is: ALLOWED
TELNET server Kerberos authentication is: ALLOWED
User's ticket file location: SYS$LOGIN:KERBV4.TICKET
Local Realm: nene.com
Primary Server: phi

Is this configuration correct [YES]: Return [4]

The Kerberos Primary Server database TCPWARE:PRINCIPAL.OK does not exist on this machine. The Kerberos server will not work properly unless this file exists.

After completing the TCPware configuration, create the Kerberos Database, and stash the Kerberos master password. Once this has been done, shutdown and restart the Kerberos Services.

Consult the TCPware documentation for more details.

# Configure the Line Printer Services

The Line Printer Services (LPS) include some of TCPware's remote printing features. LPS supports an LPS client and an Line Printer Daemon (LPD) server. LPS lets you use the LPR, LPQ, and LPRM commands to print local files on remote hosts, display status information for remote print queues, and remove jobs from remote print queues. LPS also lets you use the OpenVMS PRINT command to print files remotely. For LPS, you need to configure:

• The default remote printer for the LPS commands (LPR, LPQ, and LPRM)

• The OpenVMS print queue for the PRINT command

• Possible batch startup

• The LPD server

## CNFNET Steps

You can configure the Line Printer Services (LPS) as part of the general CNFNET configuration or specifically as

@TCPWARE:CNFNET LPS

Begin with the following steps (see Example 4-18):

1 Enter Y at the prompt asking if you want to enable the Line Printer Services.

2 Enter Y at the prompt asking if you want to configure LPS now.

3 Configure the spool directory for LPS. LPS uses a spool directory to temporarily store the files to be printed. You can use the default location or specify a different location as an OpenVMS directory specification. The default is TCPWARE_SPECIFIC:[TCPWARE.LPS_SPOOL].

Note! It might be necessary to configure the remote LPD server to accept print jobs from the client host. See your UNIX system administrator or documentation for information.

Example 4-17 Starting the Line Printer Services Configuration

Configuring the Line Printer Services (LPS):

Line Printer Services consists of the client and the server. The client lets users on this OpenVMS host print files on printers attached to remote hosts. The server accepts files from remote hosts to be printed on printers attached to this OpenVMS host. LPS configuration consists of configuring:

- Default remote printer for LPS Client commands (LPR,LPQ,LPRM)
- OpenVMS Print Queue
- LPD Server
Do you want to enable the Line Printer Services (LPS) [NO]: Y Return [1]

Do you want to configure LPS now [YES]: Return [2]

Configuring the spool directory for Line Printer Services.

LPS uses a spool directory to temporarily store the files to be printed. You may use the default location or specify a different location as an OpenVMS directory specification.

Enter the spool directory specification [TCPWARE_SPECIFIC:[TCPWARE.LPS_SPOOL] ]: Return [3]

# Configure the Default Remote Printer for LPS

You can configure the default remote printer to be able to use the UNIX-style LPR, LPQ, and LPRM commands in the Line Printer Services (LPS).

## Prepare

To configure LPS on the client so that users can use the UNIX-style LPR, LPRM, and LPQ commands, you need the name of the:

• Local spool directory (TCPWARE_SPECIFIC:[TCPWARE.LPS_SPOOL] by default)

• Remote host serving the print queue

• Print queue on the remote print server

Table 4-3 shows how to locate a print queue name and hostname by viewing the /etc/printcap file or printer status on different types of UNIX systems. If the print queue or hostname information needs editing, get your UNIX system manager to make changes.

Table 4-3 Examples of Locating Remote Print Queue and Host Names (Continued)

On SunOS V4 (BSD UNIX) | On HP-UX (UNIX System V)
% more /etc/printcapmarketing$printer :lp=\ :sd=/usr/spool/lpd:\...or % lpclpc> statusmarketing$printer queueing is enabled printing is enabled... | % lpstat -p
% hostnamealpha.daisy.com | % hostnamealpha.daisy.com

## CNFNET Steps

To configure the default remote printer (see Example 4-19):

1 Decide if you want to define the default remote printer at this time.

2 Enter the hostname for the remote printer. If you are not planning to use the LPR, LPRM, and LPQ commands, enter an asterisk (*).

3 Enter the default remote printer on the remote host; for example

ALPHA: SYS$PRINT.

4 If the default remote printer configuration is correct, enter END at the prompt

What would you like to do (CHANGE, DELETE, or END):.

Example 4-18 Configuring the Default Remote Printer for LPS Commands

Configuring the default remote printer for LPS client commands.

If you plan to use the LPR, LPQ and LPRM commands, you may define a default remote printer. LPS uses this printer if users do not specify a remote printer in the LPR, LPQ, or LPRM command.

Currently there is no default remote printer defined.

Do you want to define the default remote printer [YES]: Return [1]

Enter the host name for the remote printer []: ALPHA Return [2]
Enter the remote printer on alpha []: SYS$PRINT Return [3]

The current configuration for default remote printer is:

What would you like to do (CHANGE, DELETE, or END): END Return [4]

# Configure the LPS Client OpenVMS Print Queues

LPS lets you use the OpenVMS PRINT command to print on a remote printer. You can configure local LPS OpenVMS queues to send print jobs to remote printers attached to a remote host running LPD.

## CNFNET Steps

To configure LPS client print queues (see Example 4-20):

1 For a first time configuration, the message

Currently there is no print queue configured appears.

However, if CNFNET recognizes a PRINTCAP. file on the system, the message A printcap file has been found on this system appears. You have the option to use information in this file at the prompt

Do you want to base the symbiont configuration on printcap [YES]:.

See Chapter 15 in the Management Guide, Managing Print Services, for details on the PRINTCAP database.

2 If you are not using the PRINTCAP database, enter Y at the prompt asking if you want to configure print queues.

3 Enter the local LPS OpenVMS queue name; for example: DOC$PRINT.

4 Enter the remote hostname you want associated with the queue; for example: SIGMA.

5 Enter the remote printer name associated with the remote host; for example: DOC_PRINTER.

6 Enter Y or N at the prompt asking if users can override the remote printer specification.

7 Respond to the prompt asking you to select the formatting options; for example:

Select formatting options (VMS/LPD) [LPD]: VMS

• Enter LPD (the default) to enable the LPS OpenVMS print queue to send files to the remote LPD server for formatting.

• Enter VMS to enable the LPS OpenVMS queue to support the /FORM qualifier and formatting on the local print queue.

8 Responding to the additional qualifiers prompt is optional. Additional qualifiers refer only to qualifiers available with the OpenVMS INITIALIZE/QUEUE command.

For example, to implement OpenVMS device control, enter:

/LIBRARY=LN03DEVCTL

This qualifier specifies the device control modules within the device control library. Depending on your formatting configuration, this means the LPS OpenVMS queue either applies the device control information to the local device or to the remote device.

9 Enter Y or N at the prompt asking if you want to configure another print queue.

10 Respond to the prompt asking if you would like to ADD, CHANGE, DELETE, or START a queue, or END configuring the print queues; for example: END.

Use the START option only if LPS is already running. This is useful for restarting a single queue when changing its configuration or starting the newly created queue without stopping any existing ones.

Example 4-19 Configuring the LPS OpenVMS Print Queues

Configuring LPS OpenVMS Print Queue

You can configure an LPS OpenVMS print queue to print files on a printer attached to a remote host running LPD. Use the OpenVMS PRINT command to send print jobs to this queue.

You must name one or more local OpenVMS print queues for LPS to use. For each local OpenVMS print queue, you must also specify the:
- Associated remote host name
- Name of the printer attached to the remote host
You can also specify additional qualifiers used when LPS initializes the print queue. Please refer to the OpenVMS documentation on the
INITIALIZE/QUEUE command for the qualifiers you can use.

Currently there is no print queue configured. [1]

Would you like to configure print queues [NO]: Y Return [2]

Specify the OpenVMS print queue name for LPS: DOC$PRINT Return [3]
Specify the remote host name: SIGMA Return [4]
Specify the remote printer on sigma: DOC_PRINTER Return [5]
May users override the remote printer specification [NO]: Return [6]
Select formatting option (VMS/LPD) [LPD]: Return [7]
Specify additional qualifier []: Return [8]

Do you want to configure another queue [NO]: Return [9]

The currently configured queues are:

OpenVMS Print Queue Remote Host Remote Printer OvR Fmt
------------------- ----------- -------------- --- ---
DOC$PRINT sigma doc_printer NO LPD

You may enter:

ADD To add a new print queue(s)
CHANGE To change an existing print queue(s)
DELETE To delete an existing print queue(s)
START To (re)start print queue(s)
END To end configuring the print queue(s)
[10]
What would you like to do (ADD, CHANGE, DELETE, START or END):END Return

# Configure LPS for Batch Startup

You can select to start LPS on a batch queue, which greatly reduces the time of TCPware startup if there are many LPS print queues defined.

To start LPS as a batch job (see Example 4-21):

1 Enter Y at the prompt asking if you want to start LPS on a batch queue. The default is NO.

2 Enter the batch queue name. The default is SYS$BATCH.

STARTNET now submits the LPS portion of TCPware startup to the specified batch queue. The LPS startup log file, TCPWARE:LPSSTART.LOG, retains the LPS batch startup information.

Go to the next section to configure the LPD Server.

Example 4-20 Configuring LPS for Batch Startup

Do you want to start LPS on a batch queue [NO]: Y Return
Enter the batch queue name for the LPS startup [SYS$BATCH]: Return

When this selection is made, STARTNET will submit LPS portion of startup to the specified batch queue. Log of the startup will remain in TCPWARE:LPSSTART.LOG.

# Configure the LPD Server

If you configure the Line Printer Services (LPS), you may also want to configure the LPS server (LPD). LPD allows remote users to send files to print queues on your OpenVMS host. To configure the LPD server (see Example 4-22):

1 Enter Y at the prompt asking if you want this host to support the LPD server.

If you accept the default NO, go to the next section.

2 Enter Return or N at the prompt if you do not want the LPD server to use batch queues. If you want to use batch queues, enter Y.

Note that:

• LPD places the jobs it receives into ordinary OpenVMS print queues. You must define these queues on your local host before anyone can use LPD. TCPware does not set up these queues and you cannot define them in CNFNET. Instead, see your OpenVMS documentation for instructions.

• The local LPD works properly only if the system manager on the remote client with which it communicates properly configured it to send print jobs.

Users at remote clients need to specify names of OpenVMS print queues as printers. On many UNIX systems, the /etc/printcap file defines this information. See your client documentation for details.

Note! STARTNET does not define the TCPWARE_LPD_qname_PARAMETER, TCPWARE_LPD_qname_FORM, and TCPWARE_LPD_qname_QUEUE logicals. You should define these system logicals in the system startup file.

Example 4-21 Configuring the LPD Server

Configuring the LPD Server

Do you want this host to support the LPD server [NO]: Y Return [1]

Do you want the LPD server to allow batch queues to be used [NO]:Return [2]

# Build the LPD Server Access File

The LPD Access File determines which remote hosts can use the LPD server and maps remote users to OpenVMS usernames.

## Prepare

To build the LPD access file, you need the name of the:

• Remote host allowed access to the print server.

• Remote user on the remote host that you want to be allowed access.

• Local user for the remote user on the print server.

• Default local user for the remote users whose hosts are defined in the LPD Access File but whose remote usernames are not mapped to a specific OpenVMS username.

## CNFNET Steps

The LPD server requires an LPD Access File. You can build this file now or later
(see Example 4-23):

1 Enter Y at the prompt asking you if you want to build the LPD Access File now.
If you enter N or press Return, continue with the next section.

2 Enter the name of the remote host allowed access; for example: ALPHA.

3 Enter the remote user on the remote host allowed access. For example, the remote user on ALPHA: KOENIG.

Use upper- or lowercase letters according to how the remote host defines the name.

4 Enter the local username for the remote user at the remote host. For example, KOENIG at ALPHA: LUNA.

The system converts this username to uppercase, regardless of how you enter it.

5 Repeat steps 3 and 4 for each remote user permitted to print files on printers attached to your OpenVMS host. After you enter all usernames for a remote host, press Return.

6 Press Return at the remote host prompt to stop entering information.

7 Enter a default OpenVMS username; for example, LPD_USER.

Remote users whose hosts are defined in the LPD Access File but whose remote usernames are not mapped to a specific OpenVMS username use this default.

Example 4-22 Building the LPD Access File

The LPD Server requires an LPD Access File, specifying:
- Which remote hosts are permitted to print files on this system.
- Remote-to-local OpenVMS username mappings.

Do you want to build the LPD Access File now [YES]: Return [1]

Press return at the remote host prompt to stop entering information.

Enter the name of the remote host allowed access: alpha Return [2]

When you have entered all users from alpha to be allowed local access,
press return to specify the next remote host.
NOTE: Enter * to map all remote users to a local username.

Enter the remote user on alpha allowed access: koenig Return [3]
Enter the local username for koenig at alpha: luna Return [4]

Enter the remote user on alpha allowed access: Return [5]

Enter the name of the remote host allowed access: Return [6]

You need to define a default OpenVMS username for remote users whose hosts are defined in the LPD Access File, but whose remote usernames are not mapped to a local OpenVMS username.

Enter the default OpenVMS username: lpd_user Return [7]

Note! Be careful when defining the default OpenVMS username. Remote users can submit batch jobs to your local OpenVMS host by printing to a batch queue (if enabled). To prevent unauthorized users from submitting batch jobs, avoid defining a username belonging to a privileged account (such as SYSTEM). Instead, create a special user account and use the AUTHORIZE utility to restrict access.

# Configure the Miscellaneous Services

The miscellaneous services include the following:

TFTPD | Trivial File Transfer Protocol Server
CHARGEND | Character Generator Protocol Server
DAYTIMED | Daytime Protocol Server
DISCARDD | Discard Protocol Server
ECHOD | Echo Protocol Server
QUOTED | Quote-of-the-Day Server
IDENT | Identification Server (formerly Authentication Server)
TIME | Time Protocol

All these services can be enabled or disabled. They also have some options that can be configured.

## CNFNET Steps

You can configure the Miscellaneous Services as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET MISC (see Example 4-24):

1 At the prompt, enter Y if you want TFTPD, or press Return or enter N if you do not want TFTPD.

2 If you entered Y in step 1, you must also enter the TFTPD root working directory. Enter a directory name or press Return to accept the default (TCPWARE_ROOT:[TCPWARE.TFTP_WORK]). (See the following subsection.)

3 For all other services, at the prompt, enter Y if you want to enable, or press Return or enter N if you want to disable service. (See Example 4-24).

See the Management Guide for more information on the TFTP and other miscellaneous servers.

## TFTPD File Access

The TFTP protocol does not provide user authentication. Therefore, TFTPD allows access only to files in the TCPWARE_TFTP_ROOT directory and its subdirectories. You usually define this system logical as TCPWARE_ROOT:[TCPWARE.TFTP_WORK], but you can define it otherwise.

TFTPD allows you to read, create, and write files in this directory. It creates files transferred in "netascii" mode as STREAM_LF formatted files, and files transferred in "binary" mode as fixed-length 512-byte record files.

Example 4-23 Configuring the Miscellaneous Services

Configuring the Miscellaneous Services:

Do you want the Trivial File Transfer Server (TFTPD) [NO]: Y Return [1]

You must specify the root working directory for TFTPD.

Remote TFTP users have access only to the files within this directory (and its subdirectories).

NOTE: The TFTP protocol does not provide user authorization. Any remote users can access the files in this directory and its subdirectories. You may want to write protect this directory, if remote users will not need to create new files.

Enter the root working directory for
TFTPD [TCPWARE_ROOT:[TCPWARE.TFTP-WORK]]: Return [2]

Do you want the CHARGEN Server (CHARGEND) [NO]:
Do you want the DAYTIME Server (DAYTIMED) [NO]:
Do you want the DISCARD Server (DISCARDD) [NO]:
Do you want the ECHO Server (ECHOD) [NO]:
Do you want the QUOTE Server (QUOTED) [NO]:
Do you want the AUTH Server (Identification) [NO]:
Do you want the TIME Service [NO]:
Do you want to restart the miscellaneous servers [NO]:

# Configure the NFS-OpenVMS Server

Because you need to install, configure, and start TCPware for OpenVMS before you can set up the NFS-OpenVMS Server, you might want to enter N at the Do you want the NFS Server [YES] prompt. This lets you continue with CNFNET. You can always go back later to invoke the NFS-OpenVMS Server component configuration using

@TCPWARE:CNFNET NFS

## Prepare to Set Up the Server

Before you set up the Server:

1 Identify the NFS users on the network that should have access to the OpenVMS server.

Obtain the User ID (UID) and Group ID (GID) numbers for each NFS user. For UNIX system users, obtain the UIDs and GIDs from the /etc/passwd file (see Example 4-25). For PC users, assign any UIDs and GIDs that do not conflict with existing users.

For an OpenVMS user, assign a UID and GID that does not conflict with UNIX users. You can take the UIDs and GIDs from the user UIC [gid, uic]. Any method is acceptable as long as it generates unique UID/GID pairs for each user.

2 Identify which OpenVMS directories and files the NFS users need to access. You should export only the necessary directories and files.

3 Match the NFS users with the valid usernames of OpenVMS accounts that can use the required directories and files.

In some cases, you need to create new OpenVMS accounts to accommodate the NFS users. You must update your SYSUAF.DAT file. (See your OpenVMS documentation.)

## Set Up the Server

Setting up the NFS Server consists of the following:

1 Add users to the PROXY database.

2 Add directories to the EXPORT database.

3 If necessary, create a spool directory.

4 Restart and test the Server.

## Add Users to the Server PROXY Database

To add users to the server PROXY database (see Example 4-26):

1 Be sure the network is running.

2 Start TCPware.

3 Invoke NETCU by entering at the DCL prompt:

$ NETCU

Enter an ADD PROXY command for each NFS user and superuser. Use the format:

ADD PROXY vms-username /UID=uid /GID=gid [/HOST=host]

The vms-username is the OpenVMS account to which you want to register an NFS user. Enter this name exactly as it is entered in the OpenVMS user authorization file (UAF).

If the username is not in the UAF, use the AUTHORIZE utility and add the user to the UAF. Do this before you add the username to the PROXY database.

Example 4-24

Locating UIDs and GIDs

> cat /etc/passwd

gimli:fmE3CZNyjKZt2:1000:15:Frodo Gimli:/usr/users/user:/bin/csh

pippin:TZ7u8CuAJRs5g:1134:15:Merry Pippin:/usr/users/pippin:/bin/csh

UID GID

Obtain the uid and gid values from client's etc/passwd file (see Example 4-25). Enter UID=0 AND GID=1 for a superuser.

For PC users, assign any UIDs and give the same GIDs to users that need to have group access to files. Do not use wildcards.

Using the added /HOST qualifier with a host name value means that only the specified user on the specified host can use the server account.

4 Enter the SHOW PROXY command to confirm that you entered the information correctly.

5 Enter the RELOAD PROXY command if you added users to an existing PROXY database. This command ensures that new entries take effect by reloading the database on the server.

Example 4-25 Adding Users to the Server PROXY Database

(Iota) $ RUN TCPWARE:STARTNET [1]
(Iota) $ NETCU [2]
NETCU> ADD PROXY SYSTEM /UID=0 /GID=1/HOST=SIGMA
NETCU> ADD PROXY GIMLI/UID=1000 /GID=15
NETCU> ADD PROXY PIPPIN /UID=1134 /GID=15
NETCU> SHOW PROXY [3]
NFS PROXY Database V5.7 Copyright (c) 2004 Process Software

Username UID GID Host(s)
-------- --- --- -------
SYSTEM 0 1 SIGMA
GIMLI 1000 15
PIPPIN 1134 15

NETCU> RELOAD PROXY [4]
NETCU> EXIT

## Add Directories to the Server EXPORT Database

To add an entry to the NFS EXPORT database (see Example 4-27):

1 Be sure the network is up and running.

2 Enter an ADD EXPORT command at the NETCU prompt for each OpenVMS directory you want exported. Use the format:

ADD EXPORT "pathname" vms-directory

The pathname is the name the NFS client uses for the exported directory. Enclose the pathname in quotation marks (" "). The pathname is generally a UNIX-style name similar to an OpenVMS directory name.

Note! The case of the pathname is preserved so you must use the same case when using the NFS MOUNT command.

The vms-directory is the device and directory on the local OpenVMS system that you want to export.

When adding an EXPORT entry for the TCPware NFS-OpenVMS Client, export that entry using the /NOCONVERT qualifier to the NFSMOUNT command.

3 Enter an ADD EXPORT command for the spool directory if you use PCNFSD for printing.

If the spool directory is a subdirectory of a directory already listed in the EXPORT database, you do not need to create a separate entry.

Do not append the PC client host name to the end of the directory specification.

It is recommended that you enter the PC spool directory entry in the EXPORT database as follows:

ADD EXPORT "/spool" device:[directory] /NOCONVERT /RFM=UNDEFINED

4 Enter the SHOW EXPORT command to confirm your entries.

Note! You can also set additional export parameters, including specifying particular hosts, using ADD EXPORT qualifiers. See the ADD EXPORT command description in Chapter 2 of the NETCU Command Reference, NETCU Commands, for details on these parameters.

## Create a Spool Directory

Complete this step only if you have PCs and plan to use the PC NFS protocol (PCNFS) for printing. Otherwise, proceed to the next section.

To create a spool directory (see Example 4-28):

1 Enter the CREATE/DIRECTORY command and create a spool directory on the server that the PCNFS server program (PCNFSD) can use for printing.

2 Create a subdirectory within the spool directory for each client allowed to use PCNFS for printing. The subdirectory name is the client's host name. You can skip this step if you choose to create subdirectories automatically (see CNFNET Steps, Part 2).

Note! You need to export the spool directory only. When you create the EXPORT database, be sure to include the spool directory. Do not include any subdirectories within the spool directory.

Example 4-26

Adding an Entry to the Server EXPORT Database

NETCU> ADD EXPORT "/mnt/iota" DUA0:[000000] [1]

%TCPWARE_NETCU-I-ADDPATH, added path /mnt/iota

NETCU> ADD EXPORT "/pcreports/spool" DUA0:[PCREPORTS.SPOOL] -
_NETCU> /NOCONVERT /RFM=UNDEFINED [2]

%TCPWARE_NETCU-I-ADDPATH, added path /pcreports/spool

NETCU> SHOW EXPORT [3]
NFS EXPORT Database V5.7 Copyright (c) 2004 Process Software

Path Directory Host(s)
---- --------- -------
/mnt/iota DUA0:[000000]
/pcreports/spool DUA0:[PCREPORTS.SPOOL]

NETCU> EXIT

Example 4-27 Creating a Spool Directory and Spool Subdirectories

$ CREATE/DIRECTORY DUA0:[PCREPORTS.SPOOL] [1]
$
$ CREATE/DIRECTORY DUA0:[PCREPORTS.SPOOL.DAISY] [2]
$
$ CREATE/DIRECTORY DUA0:[PCREPORTS.SPOOL.ROSE]
$

## CNFNET Steps, Part 1

To configure the NFS Server in CNFNET (see Example 4-29):

1 Enter Y or Return at the prompt asking if you would like the NFS v3 Server on this machine.
To use the v2 server, enter N to get to the NFS v2 prompt.

2 Press Return to accept the default access identifier.

Accepting the default of [ ] (null) means that you do not want to add any further access restrictions to the server than already exist. Entering a value further restricts access to the server.

3 Press Return to accept the default security mask value, or enter a new value.

Accepting the default of [ ] means that you do not want to add any security mask values. You should normally specify these options on a filesystem basis using appropriate NETCU ADD EXPORT command qualifiers. However, if you want these options on a system-wide basis, add their individual bit mask values and enter the result at the prompt. The options and their matching ADD EXPORT qualifiers are:

• Superuser mount — Only the superuser can mount filesystems
(/SUPERUSER_MOUNT)

• Explicit — Only filesystems explicitly exported can be mounted (/EXPLICIT_MOUNT)

• Mount proxy check — The UID/GID used in mount requests must exist in the PROXY database (/PROXY_CHECK)

• Privileged port checks — All incoming NFS requests must originate from privileged ports
(/PRIVILEGED_PORT).

Report all acceess allowed for files to the client (the server does all access checks)
(/SERVER_ACCESS)

Allow PCNFS batch queue printing (no corresponding qualifier)

Disable PCNFSD use of the intrusion database (no corresponding qualifier)

Disable PCNFSD deletion of printed files (no corresponding qualifier)

Example 4-28 Configuring the NFS-OpenVMS Server

Configuring NFS-OpenVMS Server:

Do you want the NFS v3 Server (NFSDV3)[YES]: Return [1]

For detailed information on NFS-OpenVMS Server parameters, refer to the TCPware for OpenVMS(R) Installation & Configuration Guide.

The access identifier parameter, NFS_ACCESS_IDENTIFIER, specifies the name of the rights identifier to be granted to all NFS users. This parameter is optional.

To remove a previously entered identifier, enter *.

Enter the access identifier []: Return [2]

The security mask parameter, NFS_SECURITY, controls access to the OpenVMS system. Note that these options should normally be specified on a file system basis (rather than a global basis) using the appropriate NETCU ADD EXPORT command qualifiers (as indicated below) if applicable.

Bit Mask Meaning when set
-------- ----------------
1 Superuser mount. Only the superuser is allowed to mount
file systems (/SUPERUSER_MOUNT).
2 Explicit mount. Only file systems explicitly exported
can be mounted (/EXPLICIT_MOUNT).
4 Mount proxy check. The UID/GID used in mount requests
must exist in the PROXY database (/PROXY_CHECK).
8 Privileged port check. All incoming NFS requests must
originate from privileged ports (/PRIVILEGED_PORT).
16 Report all access allowed for files to client (server
does all access checks) (/SERVER_ACCESS).
32 Allow PCNFS batch queue printing.
64 Disable PCNFSD use of the intrusion database.
128 Disable PCNFSD deletion of printed files.

To specify the security mask, add up all the bit mask values for the types of security you want provided.

Enter the security mask []: 68 Return [3]

## CNFNET Steps, Part 2

During the second part of this NFS-OpenVMS Server configuration, you need to respond to the logging class, PCNFSD spool directory, and configuration prompts (see Example 4-30).

If you are configuring the NFS Server for the first time, use the default values to get the Server up and running quickly. You can change the parameter values later.

1 Enter Y or Return to accept the default logging class mask value or enter a new value.

2 Enter Y or Return when asked if you want to enable PCNFSD if you have PCs and plan to use the PC-NFS protocol (PCNFS) for printing.

You can also specify PRINTING-ONLY if you want to enable print spooling of files on the server without enabling PCNFSD authentication.

See the Management Guide, Chapter 14, NFS-OpenVMS Server Management, the PCNFSD Services section, for details on PCNFSD authentication.

3 If you enable PCNFSD, the Server prompts you to enter the spool directory. Enter the pathname already assigned to the spool directory in the EXPORT database. Do not use quotation marks around the spool directory name. Enter the PC-NFS Client spool directory; for example:

/pcreports/spool

4 You can automatically create subdirectories in the spool directory specified in step 3 for each PCNFSD client. This option simplifies the subdirectory creation process for when many clients are involved. If you decide to enable autocreation, enter Y at the prompt. When the configuration parameters appear, the words (autocreate subdirectories) appear after the Spool directory: specification.

The default is N since, in many cases, the subdirectories have already been created so that only the specific client has access to the spool directory. With the option set to YES, the automatically created subdirectories inherit the permissions from the directory created in step 3, which might not be desired.

5 After CNFNET displays the current value of each parameter, enter Y or Return if the configuration is correct.

If you enter N, CNFNET repeats the prompts for each parameter.

Example 4-29 Setting NFS Server Parameters

The logging class mask parameter, NFS_LOG_CLASS, controls the types of information written to the log file.

Bit Mask Meaning when set Comments
-------- ---------------- --------
1 Warnings Error recovery messages
2 Mount Requests Mount call messages
4 General General operation messages
8 Security Security violation messages
16 NFS Errors NFSERR_IO messages

To specify the logging class mask, add up all the bit mask values for the types of information you want logged. The value -1 logs all classes.

Enter the logging class mask [-1]: Return [1]

The PCNFSD enable parameter, NFS_PCNFSD_ENABLE, enables or disables the PCNFSD protocol.

You may enter YES (to enable PCNFSD), NO (to disable PCNFSD), or PRINTING-ONLY (to enable PCNFSD for printing only - authentication requests are ignored).

Do you want PCNFSD enabled [YES]: Return [2]

The spool directory parameter, NFS_PCNFSD_SPOOL, defines the spool directory used for printing files with PCNFSD. If this parameter is undefined, the printing capability of PCNFSD is disabled. The spool directory name is case sensitive.

To remove a previously entered spool directory, enter *

Enter the PC-NFS Client spool directory []: /pcreports/spool Return [3]

Automatically create subdirectories for each client [NO]: Y Return [4]

These are the NFS-OpenVMS Server configuration parameters you selected:

NFS Server: Type: Network File System Server

Access Identifier: (none)
Security Mask: 68 = Proxy, Disable Intrusion
Logging Class Mask: -1 = Warnings, Mounts, General, Security, Errors
PCNFSD enable: 1 (YES)
Spool directory: /pcreports/spool(autocreate subdirectories)

Is this configuration correct [YES]: Return [5]

## Start and Restart the NFS Server

To start the NFS server (see Example 4-31):

1 Enter @TCPWARE:STARTNET NFS at the DCL prompt.

2 Enter @TCPWARE:SHUTNET NFS at the DCL prompt, if the server is running.

3 Enter @TCPWARE:STARTNET NFS at the DCL prompt.

## Test the NFS Server

To test the server (see Example 4-32):

1 Access an NFS client authorized to use this server.

2 On the NFS client, enter a mount command for one of the exported directories. Refer to the directory by the pathname assigned in the EXPORT database.

3 For a UNIX client, enter the cd command and change the directory to the one you specified in the mount command, for example: cd /iota.

4 For a UNIX client, issue the ls command to show the contents of this directory. The NFS-Server is installed and configured properly if this command does not cause the system to display an error message.

See the text below and Example 12-3 in the Management Guide for sample output of the ls command.

5 Check the log file to make sure the NFS server is running and that status messages do not indicate problems. See Example 4-33.

If problems arise, see the Troubleshooting section in Chapter 14, Managing NFS-OpenVMS Server, of the Management Guide for possible solutions.

If you need to modify the PROXY or EXPORT database, use the commands available through NETCU.

Note! The Server updates the PROXY database dynamically only if you use the /SERVER qualifier with the ADD PROXY command or use the RELOAD PROXY command in NETCU. Also use the RELOAD PROXY command in to reload the database every time you modify the system authorization file (SYSUAF).

Example 4-30 Starting the Server

$ @TCPWARE:STARTNET NFS

Starting NFS -OpenVMS Server...
%RUN-S-PROC_ID, identification of created process is 00000060
%RUN-S-PROC_ID, identification of created process is 00000061
.
.
.
$

Example 4-31 Testing the NFS Server

$ TELNET SIGMA [1]

.
.
.

sigma.daisy.com# mount iota:/mnt/iota /iota [2]
sigma.daisy.com# cd /iota [3]
sigma.daisy.com# ls [4]
backup.sys contin.sys lpsCLIENT sqlsrvSERVER syslost
badblk.sys corimg.sys notesSERVER sys0 sysmaint
badlog.sys engineering nsc sys293 user
bitmap.sys indexf.sys rdmRUJ syscommon vmsCOMMON
clipart lci root sysexe volset.sys
sigma.daisy.com#

Example 4-32 Checking the NFS Server Log File

$ TYPE TCPWARE:NFSSERVER.LOG [5]

Note! NFS V3 Server - Testing the asynchronous write functionality has revealed a problem with some v3 clients not recognizing failed asynchronous write requests. The writes may fail due to a full UDP buffer on the server. Process Software recommends increasing the UDP buffer size on the server if you are using a v3 client. We have tested successfully with a buffer size of 25:

NETCU> START/UDP/UNSOLICITED_RECEIVE_LIMIT=25

# Configure the Network Time Protocol

The Network Time Protocol (NTP) synchronizes timekeeping among a set of distributed time servers and clients.

## CNFNET Steps

You can configure NTP as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET NTP (see Example 4-34):

Enter Y or Return at the prompt asking you if you want to use the TCPware NTP daemon. This creates the NTP server. (If you do not want NTP, enter N.)

Note! If you installed Kerberos on your system, a message appears that you should use NTP. NTP synchronizes your clock with that of other Kerberos users so that authentication will work correctly.

## Configuration File

To use NTP, you must create the NTP configuration file, TCPWARE:NTP.CONF. To create the most basic version of this file:

1 Determine one, or preferably two or more, NTP time servers on your network.

2 Identify NTP-supporting hosts with which you regularly exchange data where accurate time coordination is an issue.

3 Configure each NTP time server as a server and each participating client host as a peer in the NTP.CONF file.

If your time servers were 192.168.67.1, 192.168.67.2, and 192.168.67.3, you could include the entries shown in Example 4-34 in host 192.168.67.100's NTP.CONF file.

You can also designate master clocks and local masters for more advanced configuration.

For details, see the Management Guide, Chapter 10, Network Time Protocol (NTP).

Example 4-33 Enabling NTP

Configuring the Network Time Protocol (NTP) Daemon:

Kerberos is installed on this system. For Kerberos to work correctly, use the Network Time Protocol (NTP) Daemon to synchronize the clock on this system with the other systems that are also using Kerberos.

Do you want to use the TCPware for OpenVMS NTP Daemon [YES]: Return
You may set the parameter WAYTOOBIG, which defines the number of seconds difference between the system clock and the reference clock past which no clock adjustment will be performed by the NTP daemon.

While you may set this to any numeric value you wish, you should realize that setting it to lower than 4000 may interfere with NTP attempting to automatically adjust your system clock for Daylight Savings Time (if your timezone rule calls for that).

Enter value for WAYTOOBIG [289985]: 4000

Do you want to restart the Network Time Protocol Daemon [NO]: Y Return

Example 4-34 Configuring the NTP.CONF File on Host 192.168.67.100

server 192.168.67.1
server 192.168.67.2
server 192.168.67.3
peer 192.168.67.101
peer 192.168.67.102 ...

# Configure the Post Office Protocol Version 3

The Post Office Protocol Version 3 (POP3) Server lets remote PC systems retrieve mail in your system's inbound mailbox.

## CNFNET Steps

You can configure the POP3 Server as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET POP3 (see Example 4-36):

1 Enter Y or Return at the prompt asking if you want to enable the TCPware POP3 Server.

If you do not want POP3, enter N.

2 If you enter Y, enter the maximum number of new mail messages to return per connection to the remote PC. The default is 32. Either accept the default by pressing Return or enter another number.

3 Determine the debug logging level for the connection:

• Select ERROR if you want to log errors only

• Select INFO if you want to log informational messages and errors

• Select THREAD if you want detailed thread logging, informational messages, and errors

• Select DEBUG if you want complete debug logging

You can enter just the first letter of your choice at the prompt. The default is I.

4 If you want to execute a MAIL PURGE /RECLAIM operation, enter Y.

5 CNFNET displays the POP3 configuration parameters you set. Respond whether this is correct by pressing Return for YES, or entering N for NO. If NO, return to step 2 to reenter the parameters.

For more information on POP3, see the Management Guide, Chapter 17, Managing Mail Services, the POP3 Server section.

Example 4-35 Configuring POP3

Configuring The Post Office Protocol V3 (POP3) Server:

For detailed information on the following parameters, refer to the TCPware for OpenVMS Management Guide.

Do you want to enable the POP3 server [YES]: Return [1]

Enter Maximum number of new mail messages to return per connect [32]: Return [2]

Determine the logging level, Options are:

ERROR - Errors only
INFO - Information messages and Errors
THREAD - Detailed Thread logging, information messages and Errors
DEBUG - Complete Debug logging

You may enter the first character of your choice.

Enter your choice (Error, Info, Thread, Debug) [INFO]: Return [3]

Do you want to execute a MAIL PURGE/RECLAIM operation after use [YES]: Return [4]

The POP3 server is configured as follows:

Maximum number of new mail messages to return : 32
Logging Level : INFO
Do a MAIL PURGE/RECLAIM : YES
Is this correct [YES]: Return [5]

# Configure the PWIPDRIVER

## CNFNET Steps

You can enable the PWIPDRIVER for PATHWORKS and DECnet/OSI as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET PWIP (see Example 4-37):

Press Return or enter N at the prompt asking if you want to enable the PWIPDRIVER. The default is YES.

If you do not want the PWIPDRIVER, enter N.

Example 4-36 Configuring the PWIPDRIVER

Configuring the PWIPDRIVER:

The PWIPDRIVER is *required* by Pathworks and DECnet/OSI over TCP/IP.

Do you want to enable the PWIPDRIVER [YES]: Return

# Configure the Berkeley R Commands

The Berkeley R Commands consist of:

• Three R Services (login, shell, and exec)

• Three clients (RLOGIN, RSH, and RMT)

CAUTION! Make sure that you are familiar with the R Commands and authorization methods before starting the R Services. Failure to do so may inadvertently expose you to a security risk. (See the Management Guide, Chapter 16, Managing R Commands.)

## Configure the R Services

You can enable the Berkeley R Commands as part of the general CNFNET configuration or specifically as

@TCPWARE:CNFNET RCMD.

First, determine the type of R Service you want to enable:

login, shell, or exec

Read the explanations for each on the CNFNET screen (see Example 4-38).

Proceed directly to the next section to configure the R Commands clients.

Example 4-37 Configuring the R Services

Configuring the Berkeley R Commands:

The Berkeley R Commands have 2 parts: services and clients.

login service allows remote users to log in to this system using the BSD RLOGIN protocol. Authorization is done using equivalence files alone, or with both equivalence files and the user having to enter a password.

shell and exec services both allow remote users to execute a single command on this system. The difference is in the authorization method used. shell uses equivalence files while exec uses explicit username/password strings.

All services can, optionally, use Service Access Lists to further restrict remote access.

There are 3 clients: RLOGIN, RSH, and RMT.

You have the option of making the services available. You should be familiar with the R Commands and the authorization methods before starting the services to insure that you do not inadvertently expose your system to a security risk.

## Configure RLOGIN, RSH, and RMT

The R Commands include an RLOGIN Client, RSH Client, and RMT Client. To continue configuring the R Commands (see Example 4-39):

1 Press Return if you want to activate the login service, or enter N if you do not.

2 Specify the type of login authorization you want. The selections are NORMAL or SECURE. Press Return if you want to accept NORMAL, the default value. Enter SECURE if you want SECURE login authorization. SECURE login authorization requires an .RHOSTS file entry on the system.

See the Host Equivalence Files section of Chapter 16, Managing R Commands, in the Management Guide for details.

The login service allows remote users to log in using the BSD RLOGIN protocol.

3 Press Return if you want to activate the shell service, or enter N if you do not. (The Remote Copy Program (RCP) requires this service.)

4 Press Return if you want to activate the exec service, or enter N if you do not. (The RCP command also requires this service.)

5 Press Return if you want to install the RLOGIN image, or enter N if you do not.

6 Press Return if you want to install the RSH image, or enter if you do not.

7 Press Return if you want to install the RMTSETUP image for RMT, or enter N if you do not.

Note! The klogin service starts only if you start the login service and allow Kerberos authentication requests for the RLOGIN server. The kshell service starts only if you start the shell service and allow Kerberos authentication requests for the RSH server. See the Configure IPP with CNFNET section for details.

## Host Equivalence File

Determine the method you want to use for host equivalence. Once you start TCPware, remote users cannot access the R Services until you set up the "host equivalence" data in the HOSTS.EQUIV or .RHOSTS file:

• The HOSTS.EQUIV file defines which remote hosts or users can access the server host. The HOSTS.EQUIV file is in the TCPWARE directory and is analogous to the
/etc/hosts.equiv file in UNIX.

Place the HOSTS.EQUIV file in either the TCPWARE_COMMON:[TCPWARE] or TCPWARE_SPECIFIC:[TCPWARE] directory, depending on your needs.

• The .RHOSTS file lets users have remote access to accounts beyond what the HOSTS.EQUIV file specifies. The .RHOSTS file is in the user's login directory and is analogous to the UNIX
~/.rhosts file.

To create a .RHOSTS file, use a text editor on the TCPware host to create a SYS$LOGIN:.RHOSTS file in your login directory.

Example 4-38 Configuring RLOGIN, RSH, and RMTSETUP

Do you want to activate login service [YES]: Return [1]

There are 2 methods of authorization available for login service.

NORMAL: Uses equivalence files to authorize remote users, and allows
remote user to try a username/password if there isn't an
equivalence file match.
SECURE: Uses equivalence files, and if there is a match, requires the
remote user to enter the account's password correctly. If there is
no equivalence file match, access is denied.

Which type of login authorization (NORMAL, SECURE) [NORMAL]: Return [2]

Do you want to activate shell service [YES]: Return [3]

Do you want to activate exec service [YES]: Return [4]

The RLOGIN, RSH, and RMTSETUP (without the /PASSWORD qualifier) commands require SYSPRV privilege to bind to reserved TCP ports which are needed for them to work correctly. In a BASIC configuration, the executable images are INSTALLed with SYSPRV privilege to allow all users on your system to make use of them. In this FULL configuration, you have the option of restricting the use of these 3 commands.

Answering "NO" to the following questions restricts use of the indicated command to users with either SYSPRV or BYPASS privilege only.

Answering "YES" allows general use of the command.

Do you want to INSTALL the RLOGIN image [YES]: Return [5]

Do you want to INSTALL the RSH image [YES]: Return [6]

Do you want to INSTALL the RMTSETUP image [YES]: Return [7]

Note! It is advisable, if you want automatic startup of this component, to include the $ SET NOON line in your SYLOGIN.COM file to prevent the component from failing should there be an error in the file.

# Configure SMTP-OpenVMS

Follow these steps to configure SMTP-OpenVMS. Refer to the TCPware Management Guide, Chapter 17, and the TCPware Network Control Utility (NETCU) Command Reference, Chapter 1, for information on the TCPWARE CONFIGURE /MAIL command.

## CNFNET Steps

You can configure SMTP-OpenVMS as part of the general CNFNET configuration or specifically as

@TCPWARE:CNFNET SMTP

1 Enter whether you want to use the SMTP Mail Transfer Agent. The default is NO.

2 Enter the username of the local postmaster. Press Return to accept the default ([SYSTEM]).

One user on this system must act as the local postmaster. This person receives mail sent to the postmaster. The person's username must always be valid while SMTP-OpenVMS operates.

Example 4-39 Configuring SMTP-OpenVMS

Configuring SMTP-OpenVMS:

For detailed information on the following parameters, refer to the TCPware for OpenVMS Management Guide.

Do you want to use the SMTP Mail Transfer Agent? [YES]: Return

One user on this system must act as the local postmaster. This person will receive mail sent to the postmaster. The person's username must always be valid while SMTP-OpenVMS is operating.

Enter the username of the local postmaster [SYSTEM]:

Do you want to enable the SMTP RFC2789 MIB [Yes]? Return

Do you want to enable SMTP accounting [Yes]? Return

Name of the host that will run the accounting collection program [localhost]:

Port number that accounting collection program listens on []:

For further configuration options, please see the procedure described in
the TCPware for OpenVMS Installation & Configuration Guide to configure SMTP-OpenVMS

# Configure SNMP Services

SNMP is the Simple Network Management Protocol. Activate the SNMP agent only if your network has an SNMP client (network management station).

## CNFNET Steps

You can configure the SNMP Services as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET SNMP (see Example 4-41):

1 Enter Y if you want to activate the SNMP agent on your host.

2 You might want to configure the SNMP Multiplexing (SMUX) Service. If so, activate it on the host by typing Y at the prompt. Also, include the relevant peer names in the SNMPD.CONF file (see Configuration File) using the given syntax.

Note! Enabling SMUX when there are no SMUX subagents to use it can interfere with walking of the SNMP management base due to the SMUX MIB returning NoSuchName when no subagents exist. SMUX is an historical protocol, and should not be enabled unless there are subagents that will be using it. Specific items in the SNMP management base that appear after the SMUX MIB can still be queried when they are accessed from the start of their management base.

3 You might want to configure the SNMP Agent X Service. If so, activate it on the host by typing Y at the prompt. Also, include the relevant peer names in the SNMPD.CONF file (see Configuration File) using the given syntax. You need Agent X for SMTP and FTP Statistics as well as for using HP’s Insight Manager’s subagents.

4 You might want to configure an SNMP subagent on your host. A subagent serves private Management Information Bases (MIBs) available through an application programming interface (API).

External users wanting to have their private MIBs served by TCPware's SNMP agent should develop a shareable image that exports the APIs in the private MIBs in addition to the routines needed to access the MIB variables.

Enter Y if you want to configure SNMP subagents on your host.
The subagent must be an installed shareable image and export the routines SnmpExtensionInit, SnmpExtensionQuery, and SnmpExtensionTrap as universal symbols. If you have more than one subagent, enter each name when prompted.

While entering the name, do not enter the .EXE extension. For example, if you built and installed a shareable image called PRIVATE_MIB.EXE for a subagent, enter PRIVATE_MIB as the name of the shareable image when prompted.

Enter Return by itself to end the subagent configuration.

See the Programmer's Guide, Chapter 10, SNMP Extendible Agent API Routines.

## Configuration File

TCPware normally uses default values for SNMP Services. To customize the configuration (such as by adding SMUX or AgentX peers), edit the TCPWARE_COMMON:SNMPD.CONF configuration file.

See the Management Guide, Chapter 7, Managing SNMP Services, for information on the SNMPD.CONF file.

After editing the SNMP configuration file, you need to stop and restart the agent so the changes can take effect. Follow these steps:

1 Log in as the system manager.

2 Stop the SNMP agent process by entering:

@TCPWARE:SHUTNET SNMP

3 Start the SNMP agent process by entering:

@TCPWARE:STARTNET SNMP

Example 4-40 Configuring an SNMP Agent

Configuring the SNMP Agent:

SNMP is the Simple Network Management Protocol. If you activate the SNMP agent on this host, the agent will start up when you start up the network and will respond to queries. Answer YES to the next prompt only if your network has an SNMP client (network management station).
Do you want to activate the SNMP agent on this host [NO]: Y Return

Configuring the SNMP SMUX Service:

You have the option of enabling the SNMP server's SMUX Service. SMUX (RFC 1227) is an SNMP subagent protocol.

Warning: If you enable SMUX support, the SNMP server will only accept SMUX connections from hosts explicitly listed in the SNMPD.CONF file. Make sure to configure this file appropriately. Refer to the TCPware Management Guide, the Managing SNMP Services chapter.

Do you want to activate the SNMP SMUX service on this host [NO]: Return

Configuring the SNMP AgentX Service:

You have the option of enabling the SNMP server's AgentX Service. AgentX (RFC 2741) is an SNMP subagent protocol.
Warning: If you enable AgentX support, the SNMP server will only accept AgentX connections from hosts explicitly listed in the SNMPD.CONF file. Make sure to configure this file appropriately. Refer to the TCPware Management Guide, the Managing SNMP Services chapter.
Do you want to activate the SNMP AgentX service on this host [NO]:Return

Configuring an SNMP subagent(s):

An SNMP subagent is a shareable image that serves a private MIB. If the master SNMP agent receives a query for a variable in the private MIB, it will hand that query to the subagent for resolution.

Each subagent must be a shareable image, and conform to the SNMP Extendible Agent API Routines interface defined in the TCPware Programmer's Guide.

Answer YES to the next prompt only if this installation has SNMP subagents.

Do you want to configure subagent(s) on this host [NO]: Y Return

Please enter the name of one subagent per prompt, until finished. When finished press <Return> at the prompt to signify the end. Please do not enter the ".EXE" extension.

Enter the name of the shareable image without .EXE: SNMP_AGENT1_SHR Return
Enter the name of the shareable image without .EXE: SNMP_AGENT2_SHR Return

Enter the name of the shareable image without .EXE: Return

# Configure the SSH Utility

SSH is the Secure Shell protocol. TCPware provides support for both SSH Version 1 protocol and SSH Version 2 protocol.

Please note that in addition to the configuration performed via CNFNET as described below, there are configuration files for both the SSH1/SSH2 servers and SSH client which must be modified as appropriate to meet the security requirements of your organization. Refer to chapters 25 and 26 of the TCPware TCP/IP for OpenVMS Management Guide for details on the configuration files.

## CNFNET Steps

You can enable TCPware's SSH utility as shown in Example 4-41.

Example 4-41 Configuring the SSH Utility

$ @TCPWARE:CNFNET SSH

TCPware(R) for OpenVMS Version 5.7-1 Network Configuration procedure for:

TCP/IP Services:

FTP-OpenVMS

NFS-OpenVMS Client

SMTP-OpenVMS

TELNET-OpenVMS

Kerberos Services

SSH-OpenVMS Server

This procedure helps you define the parameters needed to get TCPware(R) for OpenVMS running on this system.

THis procedure creates the configuration data file, TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your system’s configuration.

Type <return> to continue...

Configuring SSH-OpenVMS

For detailed information on the following parameters, refer to the TCPware for OpenVMS Management Guide.

TCPware supports both SSH1 and SSH2 servers. You may configure TCPware to support either SSH1 servers or SSH2 servers, or both. Note that the choice of TCPware servers has no impact on the TCPware SSH client, which supports both SSH1 and SSH2 remote servers.

Do you want to enable the SSH1 server[NO]? YES

Do you want to enable the SSH2 server[NO]? YES

For SSH1, you must specify the number of bits in the RSA key. The range is 512 to 32768 bits, but keys longer than 1024 are generally not much safer, and they significantly increase the amount of CPU time consumed by key generation when the SSHD_MASTER process is starting.

Enter the number of bits in the RSA key[768]:

You may specify an alternate configuration file for the SSH1 server. If you have already specified an alternate config file, enter a single space and hit RETURN at the prompt to reset it to the default file name.

Enter an alternate SSH1 configuration filename[]:

You may specify an alternate configuration file for the SSH2 server. If you have already specified an alternate config file, enter a single space and hit RETURN at the prompt to reset it to the default file name.

Enter an alternate SSH2 configuration filename[]:

Specify the level of debug for the SSH1 and SSH2 servers.

For SSH1, any non-zero value will turn on debug, but there is no "degree of debug."

For SSH2, this is a value from 0 to 50, where zero is no debug and 50 is the maximum level of debug. Note that at levels exceeding debug level 8, there may be a substantial impact on SSH2 server (and possibly, the system, too) performance due to the amount of information logged.

Enter the debug level[0 50, 0]:

For SSH1, you may enter the name of an alternate RSA host key file. If you have already specified an alternate host key file, enter a single space and hit RETURN at the prompt to reset it to the default file name.

Enter an alternate SSH1 public server host key file []:

Specify the time in seconds after which the server private key is generated. This is only done for SSH1 sessions.

Enter the key regeneration time [3600]:

You may specify the number of seconds a user has to enter a password during user authentication (default = "dval" = 600). In addition, you may allow this to default to the value used by OpenVMS when a user is logging into a non-SSH session. To specify an infinite wait time, enter 0 for the timeout value.

Do you want to change the default login grace time [NO]?

Specify the port for the SSH server to listen on, if you wish to use a port other than the default port of 22.

Enter port to use[22]:

Do you want any messages logged by the SSH server at all [YES]?

Do you want verbose logging by the SSH server [NO]?

You may specify the maximum number of concurrent SSH sessions to be allowed on the server. This is the total of both SSH1 and SSH2 sessions. The default is 1000 sessions.

Enter maximum number of concurrent SSH sessions [1-1000, 100]:

You may permit the server to log a brief informational message when a user is allowed or denied access to a system.

- For SSH1 connections, an ACCEPT or REJECT event will be simply dependent upon if a user could connect based on the ALLOWGROUP/DENYGROUP settings in the configuration file SSH_DIR:SSHD_CONFIG. The message will be of the form:

<date><time> SSH1 (accepted) from [192.168.0.1,111] (my.server.com)

- For SSH2 sessions, an ACCEPT or REJECT event will be logged when the user is either successfully authenticated or fails authentication. The message will be of the form:

<date><time> SSH2 (accepted) from user "foo" at [192.168.0.1,111] (my.server.com)

You may specify the name and location of the log file to record accepted and/or rejected connections. If you simply hit RETURN, this information will be logged to OPCOM as opposed to a disk file.

By default, this file will be in the SSH_DIR: directory. You may override this by specifying a complete filename, including the directory specification; or by specifying a logical name that translates to a full filename specification.

Do you want to log accepted sessions [NO] Do you want to log rejected sessions [NO]

In OpenVMS, users with passwords that have expired because the SYSUAF PWDLIFETIME value has been exceeded are allowed to log into the system, and are then forced to changed their password. The SSH1 protocol does not allow for that condition. Answer "YES" to the following question if you wish to allows users with expired passwords to still log into the system. They WILL NOT be forced to change their password.

Note that the SSH2 protocol is not restricted as the SSH1 protocol is; changing of expired passwords, save for pre-generated passwords, is performed by many SSH2 clients (including the TCPware client).

Do you want to allow users with preexpired passwords to log in [YES]?

The SSH1 protocol does not permit the display of the contents of SYS$ANNOUNCE logical or file prior to a user logging in. Answering "Y" to the next question will cause the TCPware SSH1 client to display the contents of SYS$ANNOUNCE after user authentication is completed but before the contents of SYS$WELCOME are displayed.

Do you want to display SYS$ANNOUNCE [YES]?

When generating user keys, a passphrase may be used to further protect the key. No limit is normally enforced for the length of the passphrase. However, you may specify a minimum length the passphrase may be.

What you want the minimum passphrase length to be for SS1 [0-1024, 0]? 10

What you want the minimum passphrase length to be for SSH2 [0-1024, 0]? 10

Do you want to restart the SSH-OpenVMS Server [NO]: YES

Shutting down the SSH-OpenVMS Server ...

Starting the SSH-OpenVMS Server ...

%RUN-S-PROC_ID, identification of created process is 20800104

$

# Configure the TALK Utility

The TALK utility allows you to exchange messages you type at your terminal window with another local or remote user.

## CNFNET Steps

You can enable TCPware's TALK as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET TALK (see Example 4-43):

Determine if you want to enable the TALK server to use TALK at the following prompt (the default is YES):

Do you want to enable the TALKD server [Y]:

Example 4-42 Configuring the TALK Utility

Configuring TALK Utility:

The TALK client/server operates with other "NTALK" clients and servers. The "NTALK" protocol was introduced in BSD V4.3; the version of TALK shipped with TCPware is not compatible with TALK utilities based on earlier versions of BSD.

In order for users to use TALK, the TALKD server must also be enabled.

Do you want to enable the TALKD server [Y]: Return

# Configure TELNET-OpenVMS

## CNFNET Steps

You can configure TELNET-OpenVMS as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET TELNET (see Example 4-44):

Specify at the prompt how many Server-TELNET listeners you want on this system. Set this number to 1 unless you expect a lot of incoming TELNET activity. This number does not limit the number of incoming TELNET sessions. The number of sessions is limited only by the available system resources (such as the maximum number of processes).

Example 4-43 Configuring TELNET-OpenVMS

Configuring TELNET-OpenVMS:

Determine how many Server-TELNET listeners you want on this system. Set this number to 1 unless you expect a lot of incoming TELNET activity.

This number does not limit the number of incoming TELNET sessions. The number of sessions is limited only by the available system resources (such as the maximum number of processes).

Enter the number of Server-TELNET listeners [1]: Return

Note! It is advisable, if you want automatic startup of this component, to include the $ SET NOON line in your SYLOGIN.COM file to prevent the component from failing should there be an error in the file.

# Configure TIMED

The Time Synchronization Protocol (TIMED) synchronizes the clocks of the various hosts in a LAN.

## CNFNET Steps

You can configure TCPware's TIMED as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET TIMED (see Example 4-45):

1 Specify if you want to use the TIMED daemon at the prompt

Do you want to use the TCPware TIMED Daemon [YES]:.

2 TIMED operates in one of three modes:

SLAVE — The secondary daemon adjusts time in response to a master daemon. A slave daemon can never become a master.

MASTER — The master candidate daemon operates as a master if there are no other masters already running in the network, runs as a secondary if there is already a master, and may be promoted to a master in case the master terminates (there can be multiple masters).

FIXED_MASTER — Operates as a master in fixed mode and adjusts the secondary daemon to its own node instead of calculating the network average time, and adjusts the clocks on all the nodes, including its own (only one fixed master can be in the network and there should be no other master or secondary candidate in the network).

If you do not want to accept the default (MASTER), reply with Y at the prompt:

Do you want to change the TIMED mode [NO]:

and indicate a different mode at the Select TIMED mode (SLAVE/MASTER/FIXED_MASTER) [MASTER]: prompt.

3 Decide which networks you want included or excluded in TIMED synchronization. By default, TIMED tries to communicate to other servers through all the available networks on each host:

• INCLUDE specifies the list of networks to include in the time synchronization

• EXCLUDE specifies the list of networks to exclude from the time synchronization

Your current configuration (DEFAULT) appears. You are then prompted whether you want to change it at the prompt

Do you want to change the TIMED network configuration.

NO is the default response.

To change the configuration, enter Y and then enter INCLUDE or EXCLUDE at the prompt

Select TIMED network configuration (DEFAULT/INCLUDE/EXCLUDE) [DEFAULT]:.

Then, at the next prompt, enter the network or list of networks (separated by commas) to include or exclude.

Your current configuration appears.

Decide if you want to restart TIMED. The default is NO.

Example 4-44 Configuring TIMED

Configuring the TIMED Daemon:

Do you want to use the TCPware for OpenVMS TIMED Daemon [YES]: Return [1]

Each TIMED daemon in this network can operate in the following 3 different modes:

SLAVE Slave daemon which adjust time in response to a master
daemon. Never promoted to a master.
MASTER Master candidate daemon which operates as a master if there
are no other masters already running in the network. It
will run as slave if there is already a master, and may
promote to master in case the master terminates. There can
be multiple daemons run in this mode.
FIXED_MASTER This daemon will operate as a master in fixed mode. In
fixed mode, the master adjusts the slave daemon to its
own node instead of calculating the network average
time, and adjusts the clocks on all the nodes, including
its own. Only one fixed master is allowed in the
network and there should be no other master or master
candidate in the network.

Current configuration is: MASTER

Do you want to change the TIMED mode [NO]: Return [2]

By default, TIMED will try to communicate to other daemons through all the available networks on this host. If the host is connected to more than one network, you can optionally limit the networks to which TIMED will synchronize the time. You can either:

- INCLUDE to specify the list of networks to include in the time
synchronization

or

- EXCLUDE to specify the list of networks to exclude from time
synchronization

Current configuration is:

DEFAULT

Do you want to change the TIMED network configuration [NO]: Return [3]

# Configure X Display Manager

## CNFNET Steps

You can configure the X Display Manager as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET XDM (see Example 4-46).

Determine if you want to use the XDM Server. The default is NO.

If you enable XDM, you can manage remote X displays (X terminals). When started, remote X displays communicate with XDM through the UDP-based X Display Manager Control Protocol (XDMCP). The XDM Server creates a DECwindows login process that prompts users on the remote X display to log in and create a DECwindows session.

Example 4-45 Configuring the XDM Server

Configuring the X Display Manager (XDM) Server:

Do you want to use the TCPware for OpenVMS XDM Server [NO]: Return