HP OpenVMS Systems Documentation

The PC-NFS server provides authentication and print services for personal computers running PC-NFS. Users on a PC client can associate the name of the PC printer with an OpenVMS print queue and print files to the associated queue. To access the PC-NFS server, PC users must have an entry in the proxy database and have corresponding OpenVMS accounts on the server.

This chapter describes:

• How to start up and shut down the PC-NFS server ( Section 26.1)
• How to provide PC-NFS printing services ( Section 26.2)
• How to manage PC-NFS print queues ( Section 26.3)
• PC-NFS authentication ( Section 26.4)

For information about setting up NFS proxy identities for PC-NFS client users, see Chapter 22.

26.1 PC-NFS Startup and Shutdown

The PC-NFS server can be shut down and started up independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$PCNFS_STARTUP.COM allows you to start up the PC-NFS server independently.
• SYS$STARTUP:TCPIP$PCNFS_SHUTDOWN.COM allows you to shut down the PC-NFS server independently.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$PCNFS_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the PC-NFS server is started.
• SYS$STARTUP:TCPIP$PCNFS_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the PC-NFS server is shut down.

To configure PC-NFS print services, you must create and export a spool directory and define two system logical names. Follow these steps when configuring your print server for printing by PC-NFS clients:

1. If one does not already exist, create a spool directory.
2. Map the OpenVMS device to the spool directory path name. For example:

   TCPIP> MAP "/PC_PRINT/WORK" DSA31:

3. Make the path available with the ADD EXPORT command as follows:

   TCPIP> ADD EXPORT "/PC_PRINT/WORK" /HOST=* /OPTIONS=TYPELESS_DIRECTORIES

4. Create or edit the SYS$STARTUP:TCPIP$PCNFS_SYSTARTUP.COM file to include the following logical name definitions:

   DEFINE /SYSTEM TCPIP$PCNFSD_SPOOLDEV DSA31: DEFINE /SYSTEM TCPIP$PCNFSD_SPOOLEXPORT "/PC_PRINT/WORK"

   
   The logical name TCPIP$PCNFSD_SPOOLDEV specifies the device name for the spool device; TCPIP$PCNFSD_SPOOLEXPORT specifies the exported spool directory.

PC users can associate the name of the DOS printer you are configuring with an OpenVMS print queue and print files to the associated queue. PC clients cannot, however, manage NFS print queues from their PC. To manage print queues, you must log in to either a privileged account or the PC's proxy account on the NFS server host, and enter DCL commands to:

• List jobs queued from the PC
• Cancel queued jobs
• Obtain a list of available print queues
• Obtain status of a particular print queue

When accessing files on an NFS server, a PC user obtains authentication once from any host running PC-NFS. The user can also access NFS files on that host or other hosts, even if the user's UID/GID has proxy mappings to a different OpenVMS account on each TCP/IP host.

However, with PC-NFS printing, if the PC user obtains authentication from one host, the user can only print successfully on other TCP/IP Services hosts that have a valid OpenVMS account for the same user name.

Part 7 contains the following appendixes:

• Appendix A, Gateway Routing Daemon (GATED) Configuration Reference, describes how to configure GATED protocols for use with the Gateway Routing Daemon (GATED).
• Appendix B, EBCDIC/DMCS Translation Tables, provides EBCDIC/DMCS translation tables.
• Appendix C, How NFS Converts File Names, describes how NFS converts UNIX file names to OpenVMS file names.
• Appendix D, Configuring and Managing BIND Version 8, describes how to configure and manage the BIND Version 8 server, which runs on both VAX and Alpha systems.

This appendix describes how to configure the Gateway Routing Daemon (GATED).

A.1 The GATED Configuration File

You must configure the GATED protocols before starting GATED routing by editing the configuration file TCPIP$GATED.CONF, located in SYS$SYSDEVICE:[TCPIP$GATED]. A template file TCPIP$GATED.TEMPLATE is also available in this directory.

The file TCPIP$GATED.CONF contains statements that select routing protocols, manage routing information, manage independent system routing and control tracing options.

After editing the configuration, enter the TCP/IP management command TCPIP START ROUTING/GATED to start the GATED process. If the configuration file is not formatted correctly, GATED will not be able to parse the file and GATED will terminate.

If you make changes to the GATED configuration file after the GATED process is already running, you must stop GATED by entering the command TCPIP STOP ROUTING/GATED. Then restart the GATED process to make the changes take affect.

See HP TCP/IP Services for OpenVMS Management Command Reference for detailed descriptions of the SET GATED and START ROUTING/GATED commands.

A.2 Configuration File Statement Syntax

Parameters shown in brackets ([]) show optional keywords and parameters. The vertical bar (|) indicates a choice of optional parameters. Parentheses (()) group keywords and parameters, when necessary. For example:

[backbone | (area area)]

In this example, the brackets indicate that either parameter is optional. The keywords are backbone and area . The vertical bar indicates that either backbone or area area can be specified. Because area is in italics, it is a parameter that you provide.

The following comment styles are valid in a GATED configuration file. (Comments may appear anywhere in the file.)

• A pound sign (#)
• The C-style comments that start with /* and end with */

The configuration file consists of statements grouped in the following order:

1. Options statements
2. Interface statements
3. Definition statements
4. Protocol statements
5. Static statements
6. Control statements
7. Aggregate statements

The following statements do not fit in the above categories:

• %directive statements
• %trace statements

These statements provide instructions to the parser, and control tracing from the configuration file. They do not control the configuration of any protocol and may occur anywhere in the configuration file.

A.4 Configuration Statements

Table A-1 describes each TCPIP$GATED.CONF configuration statement.

To create a configuration file for your local host, edit a copy of the sample file TCPIP$GATED.TEMPLATE (located in the SYS$SYSDEVICE:[TCPIP$GATED] directory),then save the file to SYS$SYSDEVICE:TCPIP$GATED.CONF.

The following shows the template configuration file:

#
# File name:      TCPIP$GATED.CONF
# Product:        HP TCP/IP Services for OpenVMS
# Version:        V5.4
#
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P.
#

#
# GATED server configuration file
#

interfaces {
 interface all passive ;
 };

#
# Protocols:
#

rip on {
 broadcast;
 interface all ripin ripout version 1;
 };

redirect on;
routerdiscovery server off;
hello off;
ospf off;
egp off;
bgp off;
snmp off;

#
# Static routes:
#

#static {
# 10.1.2.0 mask 255.255.255.0 gateway 10.1.1.1;
# default gateway 10.1.2.3;
# };

#
# Policy:
#

#export proto rip {
# proto static { all metric 1; };
# proto direct { all; };
# proto rip { all; };
# };

The configuration file can define routes from one protocol or peer to another, assigning each route a value, called a preference.

The preference value determines the order of routes to the same destination in a single routing database. The active route is chosen by the lowest preference value. Some protocols implement a second preference ( preference2 ), sometimes referred to as a "tie breaker."

Preferences have the following characteristics:

• May appear in several different configuration statements in the configuration file. Be aware, however, that the last, or most specific value set for a route is the value GATED will use.
• May specify one network interface over another, one protocol over another, or one remote gateway over another.
• Cannot be used to control the selection of routes within an interior gateway protocol (IGP). That function is accomplished automatically by the protocol based on metric.
• May select routes from the same exterior gateway protocol (EGP) learned from different peers or autonomous systems.

The GATED daemon selects a route based on the following preference criteria:

• The route with the best (numerically smallest) preference is selected.
• If the two routes have the same preference, the route with the best (numerically smallest) preference2 is selected.
• A route from an IGP is selected over a route from an EGP. The least preferred is a route learned indirectly by an IGP from an EGP.
• If autonomous system (AS) path information is available, it is used to help determine the most preferred route as follows:
  • A route with an AS path is selected over one without an AS path.
  • If the AS paths and origins are identical, the route with the lower metric is selected.
  • A route with an AS path origin of IGP is preferred over a route with an AS path origin of EGP. The least preferred is an AS path with an unknown origin.
  • A route with a shorter AS path is preferred.
  • If both routes are from the same protocol and AS, the one with the lowest metric is selected.
  • The route with the lowest numeric next-hop address is used.

A default preference is assigned to each source from which GATED receives routes. Preference values range from 0 to 255, with the lowest number indicating the most preferred route.

Table A-2 lists each type of route, the statement (or clause within statements) that sets preference for the route, and the default preference for each type of route.

Note that a statement that is narrow in scope has a higher precedence given to its preference value, but affects a smaller set of routes.

In the following example, the preference applicable to routes learned through RIP from gateway 138.66.12.1 is 75. The last preference applicable to routes learned through RIP from gateway 138.66.12.1 is defined in the accept statement. The preference applicable to other RIP routes is found in the rip statement. The preference set on the interface statement applies only to the route to that interface.

       interfaces {
               interface 138.66.12.2 preference 10 ;
       } ;
       rip yes {
           preference 90 ;
       } ;
       import proto rip gateway 138.66.12.1 preference 75 ;

You can specify tracing options at the following levels: file specifications, control options, and global and protocol specific tracing options. Unless overridden, tracing options from the next higher level are inherited by lower levels. For example, Border Gateway Protocol (BGP) peer tracing options are inherited from BGP group tracing options, which are inherited from global BGP tracing options, which are inherited from global GATED tracing options. At each level, tracing specifications override the inherited options.

The syntax for trace options statements is as follows:

  traceoptions [trace_file [replace] [size size[k|m]

  files files]]

  [control_options] trace_options[except trace_options] ;

  traceoptions none ;

Table A-3 describes the valid trace options.

There are two types of global options: those with global significance (Table A-4) and those with protocol significance (Table A-5).

When protocols inherit their tracing options from the global tracing options, tracing levels that do not make sense (such as parse , adv , and packet tracing options) are masked out.

Global tracing statements have an immediate effect, especially parsing options that affect the parsing of the configuration file. Tracing values inherited by protocols specified in the configuration file are initially inherited from the global options in effect as they are parsed, unless they are overridden by more specific options.

After the configuration file is read, tracing options that were not explicitly specified are inherited from the global options in effect at the end of the configuration file.