# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

DIGITAL recommends that you safeguard your system's normal file protection mechanisms from unauthorized TFTP access. In particular, ensure the security of system files.

A client's download request can use one of several formats for its file name specification:

- If the unprivileged TFTP server has read access to the requested file, the client uses a fully qualified file name --- including the device, directory, name, and extension --- to directly access the file.
- If the client specifies only the file name and extension, the TFTP server attempts to locate the file in the default TFTP directory tree.
  You can designate this directory tree with the system logical name UCX$TFTP_ROOT:. This is a concealed device name, usually pointing to the directory SYS$SYSDEVICE:[UCX$TFTP_ROOT.]. When looking for a directory, the TFTP server looks first in the UCX$TFTP_ROOT: area with the same name as the requesting client's host name.

For example, if a client named GULL.SHORE.COM sends a read request for the file SERVICE.DAT, the server's first attempt to find the file is in UCX$TFTP_ROOT:[GULL]. If that directory does not exist, the server next looks in the UCX$TFTP_ROOT: root directory, for example, in UCX$TFTP_ROOT:[000000]SERVICE.DAT.

If the TFTP client requests a file by specifying a name in UNIX-style format, for example, /etc/gull/myfile, TFTP tries to translate this file specification into OpenVMS-format.

The BOOTP and TFTP servers run as the non-privileged OpenVMS user accounts UCX$BOOTP and UCX$TFTP. When you set up BOOTP and TFTP, follow these security procedures:

- Ensure that neither server has automatic access to any files.
  To make files accessible to the BOOTP and TFTP servers, grant appropriate access to their accounts. Use the normal OpenVMS file protection procedures. For example, issue the DCL DIRECTORY /SECURITY command.
- Prevent unauthorized access to sensitive system or user data. Before you enable BOOTP and TFTP, and in particular TFTP, ensure that you have set up all the necessary file protections.
- Give the UCX$BOOTP and UCX$TFTP user accounts read access to the files in the UCX$TFTP_ROOT: directory tree that might be used for downloading.
- Some clients first send a BOOTP request for the name of the file that they need downloaded. Upon receipt, BOOTP opens the file for read access and retrieves its size. BOOTP needs access to confirm that the file exists and to provide the size of the file to the client in the BOOTP response.
  Ensure that BOOTP has access to this file.

# 6.6 Creating a BOOTP Database

If you select to configure BOOTP during the UCX configuration procedure, it creates an empty BOOTP database.

If you need to create it manually for any reason, use the CREATE BOOTP command. This command creates the file SYS$SYSTEM:UCX$BOOTP.DAT. The command uses the logical name UCX$BOOTP to point to the BOOTP database file. To create a separate database, perhaps in a different disk directory or with a different file name, modify this logical name.

To create a temporary, separate, empty BOOTP file, you can use a process-specific logical name. However, DIGITAL does not recommend creating separate or private BOOTP databases because the UCX$BOOTP user account requires read-access to it.

## 6.6.1 Populating the BOOTP Database

For each BOOTP client in the BOOTP database, use the SET BOOTP command to enter the following required information:

- Client's hardware address (mandatory).
- Either the client's name or IP address (mandatory).
- Network mask (mandatory).
- Client's system image file name (mandatory).
- Interim gateway (routing) systems.
- Either the name or IP address of other network servers. Some of the optional servers that you can specify are:
  - Cookie servers
  - IEN-116 name servers
  - IMPRESS network image servers
  - LPR print servers
  - MIT-LCS UDP logging servers
  - DNS (BIND) name servers
  - Resource location (RLP) servers
  - Network time servers

To populate the BOOTP database with client entries, use these commands:

- CONVERT /VMS BOOTP (adds UNIX client records)
- SET BOOTP (adds individual client records)

## 6.6.2 Converting UNIX Records

You can use the BOOTP client information in an existing UNIX boot file. The CONVERT /VMS BOOTP command populates the existing BOOTP database with entries from a BIND-formatted UNIX /etc/bootptab file.

Before you issue CONVERT /VMS BOOTP, define the logical name UCX$BOOTP. The CONVERT /VMS BOOTP command uses it to specify the directory and file name for the database. Issue:

    $ DEFINE /SYSTEM UCX$BOOTP SYS$COMMON:[SYSEXE]UCX$BOOTP.DAT

If you do not define UCX$BOOTP, the database is created as [current_directory]UCX$BOOTP.DAT.

To populate the BOOTP database by using entries in a UNIX /etc/bootptab file, follow these steps:

1. Copy the /etc/bootptab file to your system.
2. Edit the output file. Examine the directory path for each client entry. Modify the UNIX path names to OpenVMS specifications, for example, change:

       :hd=/usr/apple/orange/bootptab:

   to

       :hd="DISK_BIRD2$:[USR.APPLE.ORANGE]BOOTPTAB.DAT":

   Note that this file is still UNIX style, not OpenVMS compatible.
3. Issue the convert command:

       UCX> CONVERT /VMS BOOTP

   The command reads the entries in your edited output file and adds them to the BOOTP database. If it finds an existing record for a client with a converted record, and if the information differs, the command updates the existing record with the newer data.

CONVERT /VMS BOOTP has several options:

    UCX> CONVERT /VMS BOOTP source_file /ADD_HOST /FILE=sys_image_file

- source_file
  This parameter specifies the name of the file you edited (the output from the copy command). The default is ETC.BOOTPTAB.
- /ADD_HOST
  This parameter adds client entries that are new to your system to the hosts database. The default is no adding.
- /FILE=sys_image_file
  This parameter specifies the download file. Use it if you are adding new clients to the BOOTP database. All these new clients have the same download file.

## 6.6.3 Creating Individual Entries

To add individual entries to the BOOTP database, issue:

    UCX> SET BOOTP host /FILE=download_file -
    _UCX> /HARDWARE=ADDRESS=hex_address

Example:
This command adds host PLOVER, with hardware address 08-00-2D-20-23-21, to the BOOTP database. BOOTP can respond to a remote boot request from client PLOVER by using TFTP to send its image file, PLOVER.SYS, to its hardware address.

    UCX>  SET BOOTP PLOVER -
    _UCX> /HARDWARE=ADDRESS=08-00-2D-20-23-21 -
    _UCX> /FILE=PLOVER.SYS

By default, upon receiving a request, BOOTP looks for the download file in UCX$TFTP_ROOT:[host], where host is the client's host name, excluding the domain. If this directory does not exist, BOOTP uses UCX$TFTP_ROOT:[000000].

## 6.6.4 Modifying and Deleting Entries

To modify a record in the BOOTP database, use the SET BOOTP command. For example, to stop using hosts seagull, tern, and sandpiper as gateways for downline loading to PLOVER, issue:

    UCX> SET BOOTP PLOVER /NOGATEWAYS=(seagull,tern,sandpiper)

To delete an entry from the BOOTP database, issue SET NOBOOTP.

# 6.7 Setting Up the BOOTP and TFTP Services

To set up the BOOTP and TFTP Server software, run the UCX configuration procedure (see the DIGITAL TCP/IP Services for OpenVMS Installation and Configuration manual).

The procedure creates:

- BOOTP user account
- TFTP user account
- Service records in the services database
- Default directories
- TFTP root directory to which the logical name UCX$TFTP_ROOT: will point

# 6.8 Monitoring BOOTP and TFTP Processes

To display information about the BOOTP and TFTP server processes, issue SHOW SERVICE, for example:

    UCX> SHOW SERVICE BOOTP

    Service         Port  Proto   Process       Address    State
    BOOTP             67  UDP     UCX$BOOTP     0.0.0.0    Enabled

    UCX> SHOW SERVICE BOOTP /FULL

    Service: BOOTP
                      State:     Enabled
    Port:        67   Protocol:  UDP             Address:  0.0.0.0
    Inactivity:   5   User_name: UCX$BOOTP       Process:  UCX$BOOTP
    Limit:        1   Active:      1             Peak:       1

    File:  SYS$SYSDEVICE:[UCX$BOOTP]UCX$BOOTP_STARTUP.COM
    Flags: Listen

    Socket Opts:  Rcheck Scheck
     Receive:            0     Send:               0

    Log Opts:     Acpt Actv Conn Error Exit Logi Logo Mdfy Rjct Addr
     File:        SYS$SYSDEVICE:[UCX$BOOTP]UCX$BOOTP_STARTUP.LOG

    Security
     Reject msg:  not defined
     Accept host: 0.0.0.0
     Accept netw: 0.0.0.0

# 6.9 Enabling and Disabling BOOTP and TFTP

To enable and disable BOOTP and TFTP, use these commands:

- On the running system:
  - ENABLE SERVICE BOOTP
  - ENABLE SERVICE TFTP
- In the Configuration Database:
  - SET CONFIGURATION ENABLE SERVICE BOOTP
  - SET CONFIGURATION ENABLE SERVICE TFTP

To check if these services are enabled or disabled, issue these commands:

- SHOW SERVICE BOOTP
- SHOW SERVICE TFTP
- SHOW CONFIGURATION ENABLE SERVICE BOOTP
- SHOW CONFIGURATION ENABLE SERVICE TFTP

Example 1:
This command shows basic information about the TFTP service on the running system.

    UCX> SHOW SERVICE TFTP
    Service     Port   Proto    Process      Address       State

    TFTP          69   UDP      UCX$TFTP     0.0.0.0       Enabled

Example 2:
This command shows complete information about TFTP parameters and statistics.

    UCX> SHOW SERVICE TFTP /FULL
    Service: TFTP
                               State:     Enabled
    Port:            69     Protocol:  UDP            Address:  0.0.0.0
    Inactivity:       5     User_name: UCX$TFTP       Process:  UCX$TFTP
    Limit:            1     Active:    1              Peak:     1

    File:         SYS$SYSDEVICE:[UCX$TFTP]UCX$TFTP_STARTUP.COM
    Flags:        Listen

    Socket Opts:  Rcheck Scheck
     Receive:            0     Send:               0

    Log Opts:     Acpt Actv Dactv Conn Exit Logi Mdfy Rjct TimO
     File:        SYS$SYSDEVICE:[UCX$TFTP]UCX$TFTPD_STARTUP.LOG

    Security
     Reject msg:  not defined
     Accept host: 0.0.0.0
     Accept netw: 0.0.0.0

# 6.10 TFTP

The Trivial File Transfer Protocol (TFTP) transfers files from a BOOTP server to diskless clients or other remote systems. The client initiates the file transfer.

When the client receives the configuration information in the BOOTP response, it sends a request to the TFTP server host named in the response. This request is necessary only if the client must retrieve the load file.

If the client sends a read request (RRQ) to the TFTP server, the server attempts to locate this file.

TFTP has the following characteristics:

- TFTP clients are not registered in a database.
- TFTP, which runs as an unprivileged user in the UCX$TFTP account, is restricted to only those files that the normal unprivileged user can access.
- TFTP clients are not regulated by the usual OpenVMS user security methods.
- No user name or password is required to use the TFTP service.

# 6.11 TFTP Management Commands

Table 6-3 summarizes the TFTP management commands.

Table 6-3 TFTP Management Commands
Command | Function
--- | ---
ENABLE SERVICE TFTP | Enables the service.
DISABLE SERVICE TFTP | Disables the service.
SET SERVICE TFTP | Configures TFTP in the service database.
SHOW SERVICE TFTP | Displays information about TFTP from the service database.

## 6.11.1 TFTP Directory Structure

The post-installation configuration procedure (UCX$CONFIG.COM) creates the TFTP directory structure and defines the system logical name UCX$TFTP_ROOT as a concealed device that points to the TFTP directory tree.

## 6.11.2 Upline Dumping

The TFTP server provides upline dumping services to clients requesting a transfer of data or program image to the TFTP server host.

The same rules apply to upline dumping as downline loading. In addition, before a data transfer, you must create the file on the TFTP server host to which data is transferred. This sequence lets you manage the creation of new files on the TFTP server host, and helps to prevent the creation of unwanted files on the server host.

Each incoming transfer of data to a file creates a new generation of the target file. As a result, you need to manage the consumption of disk space on the server system. Carefully set up file version limits for the target files and directories.

# Chapter 7
Configuring the Portmapper

The Portmapper service eliminates the need to preconfigure all client and server remote procedure call (RPC) applications with the port numbers they use. The Portmapper "listens" at port 111 and maintains a database of registered server programs, their unique program numbers, and assigned port numbers.

If you intend to use the following applications, you must run the Portmapper:

- NFS
- PC-NFS
- MOUNT
- Any customer-developed programs that use RPC

This chapter describes how to

- Configure the services that use RPC with information that the Portmapper needs (Section 7.1)
- Display Portmapper settings (Section 7.2)
- Start and stop the Portmapper (Section 7.3)

For information about programming with the DIGITAL TCP/IP Services for OpenVMS RPC application programming interface (API), see the DIGITAL TCP/IP Services for OpenVMS ONC RPC Programming manual.

# 7.1 Configuring Services to Use the Portmapper

The SET SERVICE command configures the applications so they are known to the Portmapper. To set RPC-related parameters, use the /RPC qualifier. Issue:

    UCX> SET SERVICE service -
    _UCX> /RPC=(PROGRAM_NUMBER=n, VERSION_NUMBER=(LOWEST=n, HIGHEST=n))

The UCX services that use the Portmapper have the following default values for the /RPC qualifier:

- MOUNT
  - PROGRAM_NUMBER=100005
  - VERSION_NUMBER=(LOWEST=1, HIGHEST=1)
- NFS Server
  - PROGRAM_NUMBER=100003
  - VERSION_NUMBER=(LOWEST=2, HIGHEST=2)
- PCNFSD
  - PROGRAM_NUMBER=150001
  - VERSION_NUMBER=(LOWEST=1, HIGHEST=2)
- PORTMAPPER
  - PROGRAM_NUMBER=100000
  - VERSION_NUMBER=(LOWEST=1, HIGHEST=1)

# 7.2 Displaying Portmapper Information

The SHOW SERVICE command with the /RPC and /PERMANENT qualifiers displays the current RPC options.

Example 1:
The following example displays the RPC options for these running services: MOUNT, NFS, PC-NFS, and the Portmapper.

    UCX> SHOW SERVICE /RPC /PERMANENT
                             RPC              Protocol Versions
    Service             Program Number         Lowest / Highest

    MOUNT                     100005                 1        1
    NFS                       100003                 2        2
    PCNFS                     150001                 1        2
    PORTMAPPER                100000                 2        2
    UCX>

Example 2:
In this example, the /FULL and /PERMANENT qualifiers display the RPC options for the NFS server, whose program number is 100003, lowest version is 2, and highest version is 2.

    UCX> SHOW SERVICE NFS /FULL /PERMANENT
    Service: NFS

    Port:             2049     Protocol:  UDP             Address:  0.0.0.0
    Inactivity:          0     User_name: UCX$NFS         Process:  UCX$NFS
    Limit:               1

    File:         SYS$SYSDEVICE:[UCX$NFS]UCX$NFS_STARTUP.COM
    Flags:        UCX

    Socket Opts:  Rcheck Scheck
     Receive:        64000     Send:           64000

    Log Opts:     Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
     File:        SYS$SYSDEVICE:[UCX$NFS]UCX$NFS_STARTUP.LOG

    RPC Opts
     Program number:      100003  Low version:      2   High version:      2

    Security
     Reject msg:  not defined
     Accept host: 0.0.0.0
     Accept netw: 0.0.0.0
    UCX>

Use the SHOW PORTMAPPER command to list information about all the registered applications. For example:

    UCX> SHOW PORTMAPPER
        Program Number     Version  Protocol  Port-number  Process   Service-name
    ---------------------  -------  --------  -----------  --------  ------------
    000186A0 (    100000)        2  TCP         111        24800126  PORTMAPPER
    000186A0 (    100000)        2  UDP         111        24800126  PORTMAPPER
    000186A3 (    100003)        2  UDP        2049        24800125  NFS
    2C30B587 ( 741389703)        1  UDP        2049        24800125
    000186A5 (    100005)        1  UDP          10        24800125  MOUNT

To monitor the server, issue the SHOW SERVICE PORTMAPPER command, for example:

    UCX> SHOW SERVICE PORTMAPPER
    Service     Port      Protocol        Process     Address     State

    PORTMAPPER   111       TCP,UDP      UCX$PORTM     0.0.0.0     Enabled

# 7.3 Starting and Stopping the Portmapper

To start the Portmapper service manually, issue:

    $ @SYS$COMMON:[SYSMGR]UCX$PORTM_STARTUP.COM
    $ UCX ENABLE SERVICE PORTMAPPER
    $ UCX SET CONFIGURATION ENABLE SERVICE PORTMAPPER

To stop and shut down the Portmapper service manually, issue:

    $ UCX DISABLE SERVICE PORTMAPPER
    $ @SYS$COMMON:[SYSMGR]UCX$PORTM_SHUTDOWN.COM

To disable the service permanently, also issue:

    $ UCX SET CONFIGURATION DISABLE SERVICE PORTMAPPER

# Chapter 8
Configuring and Managing NTP

The Network Time Protocol (NTP) provides accurate, dependable, and synchronized time for hosts on TCP/IP networks. NTP provides synchronization traceable to clocks of high absolute accuracy and avoids synchronization to clocks keeping incorrect time.

Time synchronization is important in client/server computing. For example, systems that share common databases require coordinated transaction processing and timestamping of instrumental data.

This chapter reviews key NTP concepts and provides guidelines for configuring and administering NTP software on your OpenVMS system.

# 8.1 Reviewing Key Concepts

NTP is used to synchronize the time of a computer client or server to another server or reference time source such as a radio, satellite receiver, or modem.

Synchronized timekeeping means that hosts with accurate system timestamps send time quotes to each other. Hosts running NTP may be either time servers or clients although they are often both servers and clients.

## 8.1.1 Time Distributed Through a Hierarchy of Servers

In the NTP environment, time is distributed through a hierarchy of NTP time servers. Each server adopts a stratum that indicates how far away it is operating from an external source of Universal Coordinated Time (UTC).¹ Stratum 1 servers have access to an external time source, usually a radio clock. A stratum 2 server is one that is currently obtaining time from a stratum 1 server; a stratum 3 server gets its time from a stratum 2 server, and so on.

Stratum 2 servers might be company or campus servers that obtain time from some number of primary servers and provide time to many local clients. Stratum 2 servers may be configured to peer with each other, comparing clocks and coming to consensus on synchronized time.

- Lower strata peers act as time servers.
- Higher strata peers are clients who adjust their time clocks according to the servers.

Internet time servers are stratum 1 servers. Other hosts connected to an internet time server have higher stratum numbers (2 or higher) and act as time servers for other hosts on the network. Clients choose one of the available servers to which to synchronize. Usually this is the lowest stratum server to which it has access.

## 8.1.2 How Hosts Negotiate Synchronization

Each host has its identifying stratum number encoded within UDP datagrams. Peers communicate by exchanging these UDP datagrams and examining the stratum number to determine which peer is the server and which is the client. The datagrams are time-stamped. Each host adjusts its clock as needed.

When a new peer is found, NTP evaluates the new peer to determine if it qualifies as a new (more suitable) synchronization source. The new peer is rejected under the following conditions:

- If the peer is not synchronized
- If the stratum is higher than the current source's stratum
- If the peer is synchronized to the local node

The new peer is accepted as a time source, when:

- There is no current time source.
- The current source is unreachable.
- The current source is not synchronized
- The new source's stratum is lower than the current source.
- The new source's stratum is the same as the current source but its distance is closer to the synchronization source by more than 50%.

## 8.1.3 How the OpenVMS System Maintains the System Clock

The OpenVMS system clock is maintained as a software timer with a resolution of 100 nanoseconds, updated at 10 millisecond intervals. A clock update is triggered when a register, loaded with a predefined value, has decremented to zero. Upon reaching zero, an interrupt is triggered that reloads the register, thus repeating the process.

The smaller the value loaded into this register, the more quickly it reaches zero and triggers an update. The clock will run more quickly in such an instance. A larger value means more time between updates --- the clock runs more slowly.

## 8.1.4 How NTP Makes Adjustments to System Time

Once NTP has selected a suitable synchronization source, NTP compares the source's time with that of the local clock. If NTP determines that the local clock is running ahead of or behind the synchronization source, NTP uses a general drift mechanism to slow down or speed up the clock as needed. NTP accomplishes this by issuing a series of new ticks. For example, if NTP detects that the local clock is drifting ahead by +0.1884338 second, it issues a series of new ticks in an effort to reduce the difference between the synchronization source and the local clock.

If the difference between the local clock and the synchronization source is too great for NTP to resolve with a series of new ticks, NTP sets the local clock by jumping the local time to match the synchronization source. NTP accomplishes this with a clock reset.

At times, NTP detects a very small difference between the synchronization source and the local clock. This difference may be so small it does not warrant a sustained number of ticks as used by the drift mechanism (described above). In such an instance, NTP will (for one loop in the software clock) either add or subtract one tick. (If the local clock is slow, this is known as a "frobbed systick.")

NTP maintains a record of any adjustments it makes along with informational messages in the NTP log file, UCX$NTP_LOGFILE.LOG. See Section 8.5 for more details about event logging and help in interpretting an NTP log file.

## 8.1.5 Configuring the Local Host

The system manager of a local host determines which network hosts will be used for synchronization and populates an NTP configuration file with a list of these participating hosts.

Hosts may be configured as follows:

- Client/server mode
  This mode indicates that the local host wishes to obtain time from the remote server and is willing to supply time to the remote server if need be. This mode is appropriate in configurations involving a number of redundant time servers interconnected via diverse network paths.
  You indicate this mode with a peer declaration in the configuration file. For example:

      peer 18.72.0.3

- Client mode
  This mode indicates that the local host wishes to obtain time from the remote server but it is not willing to provide time to the remote server. Client mode is appropriate for file server and workstation clients that do not provide synchronization to other local clients.
  You indicate client mode with the server declaration in the configuration file. For example:

      server 18.72.0.3

## 8.1.6 Configuring Master Servers and Local Masters

In addition to identifying peer and server hosts, you may specify a stratum 1 server, called a master server, and a local master server in the NTP configuration file.

The master server is a host with special hardware used to synchronize its system clock to a particular reference time source such as a WWVB (radio station) clock. You define a host as a master server by adding the master-clock declaration in the configuration file and specifying a stratum lower than 10. For example:

    master-clock 1

The local master is used to identify a backup server. This system is not connected to synchronization hardware but is still considered to be a dependable time source. If the connection to a lower stratum host is lost, the local master runs at the stratum you specify (specify a value between 10 and 32) in the NTP configuration file. For example:

    local-master 10

Configure the local-master host to become the highest stratum available in the network. When the preferred NTP server is again available, the hosts on the network, including the local-master, resynchronize with the lowest-stratum NTP server.

See Section 8.2.2 for a sample configuration that uses a master clock server, Internet servers, and a local master server.

### Note

#### ¹ NTP times are an offset of UTC, formerly Greenwich Mean Time (GMT).

Previous | Next | Contents