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:
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:
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:
To populate the BOOTP database with client entries, use these commands:
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:
:hd=/usr/apple/orange/bootptab:
:hd="DISK_BIRD2$:[USR.APPLE.ORANGE]BOOTPTAB.DAT":
UCX> CONVERT /VMS BOOTP
CONVERT /VMS BOOTP has several options:
UCX> CONVERT /VMS BOOTP source_file /ADD_HOST /FILE=sys_image_file
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:
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
To enable and disable BOOTP and TFTP, use these commands:
To check if these services are enabled or disabled, issue these commands:
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
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:
Table 6-3 summarizes the 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. |
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.
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:
This chapter describes how to
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:
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
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
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.
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:
The new peer is accepted as a time source, when:
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:
peer 18.72.0.3
server 18.72.0.3
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.