5. Configuring the TCP/IP Services
Introduction
This chapter describes how to configure the TCP/IP components 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 Components
How you start to configure the TCP/IP 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 shown below:
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.EXAMPLE.COM (192.168.1.56) added to host definition file.
Next host name (<return> to end): DAISY
Internet address for DAISY.EXAMPLE.COM: 192.168.1.57
DAISY.EXAMPLE.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 the example below).
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. An example of 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
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 Component Configuration Menu, 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. Enter the number next to the component listed at the prompt:
Enter menu option:
For example, to configure the NFS 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 the below output.
Configuring a Specific TCP/IP Component
Configuration
options:
1 - ACCOUNTING Configure the TCP/IP Services accounting facility
2 - ACECLIENT Configure the ACE/Client Service
3 - CNFS Configure the NFS-OpenVMS Client
4 - DHCP4 Configure the Dynamic Host Configuration Protocol V4 Server
5 - DHCP Configure the Dynamic Host Configuration Protocol Server
6 - DNIP Configure DECnet over IP tunnels
7 - DNS Configure the Domain Name Server
8 - FTP Configure the FTP-OpenVMS Server
9 - GATED Configure the Gate Daemon
10 - IMAP Configure the Internet Message Access Protocol Server
11 - IPP Configure the Internet Printer Protocol
12 - IPS Configure the IPS subsystem
13 - KERBEROS Configure the Kerberos Services
14 - LPS Configure the Line Printer Services
15 - MISC Configure the Miscellaneous Services
16 - NFS Configure the NFS-OpenVMS Server
17 - NTP Configure the Network Time Protocol Daemon
18 - POP3 Configure the Post Office Protocol V3 Server
19 - PWIP Configure the PWIPDRIVER
20 - RCMD Configure the Berkeley R Commands
21 - SMTP Configure the Simple Mail Transfer Protocol Services
22 - SNMP Configure the Simple Network Management Protocol Agents
23 - SSH Configure the SSH-OpenVMS Server
24 - TALK Configure the TALK server
25 - TELNET Configure the TELNET-OpenVMS Server
26 - TIMED Configure the TIMED Server
27 - XDM Configure the XDM Server
Enter menu option (E to exit):
For example, to configure the NFS client, enter
$ @TCPWARE:CNFNET CNFS
Configure the NFS Client
Because you need to install, configure, and start TCPware for OpenVMS before you can set up the NFS 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 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.
$ 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 V6.0 Copyright (c) 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:
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:x: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.
>cat /etc/group
wheel:x:0:
nogroup:x:65534:
daemon:x:1:
kmem:x:2:
bin:x:3:
tty:x:4:
operator:x:5:
news:x:6:
uucp:x:8:
audit:x:9:
login:x:15:joe2
staff:x:10:peters,henry
other:x:20:
accounting:x: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
%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:
1. Run NETCU.
2. Enter an ADD GROUP command for the new group. Use the format:
NETCU> 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:x: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 shown in the below example) 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 the below example (the staff:x:10:peters,henry entry in the /etc/group file on the server).
$ NETCU
NETCU>ADD GROUP 30 ACCOUNTING
NETCU>SHOW GROUP
NFS GROUP Database V6.0 Copyright (c) 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 TCPware Management Guide, Chapter 13, Managing the NFS Client.
Configure the DHCP Client
There are two DHCP Clients supplied by TCPware: the V3 client (DHCLIENT) and the V4 client (DHCLIENT4). Only one can be run at any given time. You must choose which one you want.
If this is your first time using a DHCP client on the host, you need to create a configuration file for it (TCPWARE:DHCLIENT.CONF). If you have been running the V3 DHCP client and want to change to running the V4 DHCP client, you can use the same configuration file.
If you need to create a configuration file, there are template configuration files available for both DHCLIENT and DHCLIENT4 in the TCPware common directory.
To create a configuration file from one of the templates, do the following. For DHCLIENT:
$ COPY TCPWARE:DHCLIENT_CONF.TEMPLATE TCPWARE:DHCLIENT.CONF
Or for DHCLIENT4:
$ COPY TCPWARE:DHCLIENT4_CONF.TEMPLATE TCPWARE:DHCLIENT.CONF
The DHCP client configuration file should now be edited to specify the name of your host. Talk to your network administrator: the administrator may want to assign you a host name.
To specify a host name, edit the configuration file to replace this line:
#send host-name “testing”;
with this line:
send host-name “any hostname you want”;
To configure your local host to use the DHCP client, run the TCPware configuration utility CNFNET. To use the V3 DHCP client, you run CNFNET as:
$ @TCPWARE:CNFNET DHCLIENT
To use the V4 DHCP client, you must configure it individually:
$ @TCPWARE:CNFNET DHCLIENT4
CNFNET can also be used to disable the DHCP client on the host. If you have been running the V3 DHCP client and want to change to the V4 DHCP client, run CNFNET to disable DHCLIENT then run CNFNET again to enable DHCLIENT4.
After you configure the local host to use a DHCP client, you can run STARTNET to start TCPware:
$ @TCPWARE:STARTNET
Here are two examples:
Using CNFNET:
$ @TCPWARE:CNFNET
TCPware (R) for OpenVMS Version 6.0-0 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]?
...
...
... ...
Using CNFNET DHCLIENT:
$ @TCPWARE:CNFNET DHCLIENT
TCPware(R) for OpenVMS Version 6.0-0 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 DHCP Server
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. There are two DHCP Servers supplied by TCPware: the V3 server (DHCP) and the V4 server (DHCP4). Only one can be run at any given time. You must choose which one you want.
CNFNET Steps
You can configure the DHCP server as part of the general CNFNET configuration or specifically using @TCPWARE:CNFNET DHCP (for V3, see the below example) or @TCPWARE:CNFNET DHCP4 (for V4):
1. At the prompt, enter Y if you want to run the server, or press Return or enter N if you do not want to run the server.
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 TCPware Management Guide, Chapter 2, DHCP/BOOTP Server.
Configuring the Dynamic Host Configuration Protocol (DHCP) Server:
Do you want to enable the Dynamic Host Configuration/Bootstrap Protocol Server (DHCPD) [YES]: Y
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
Debug file name (use _NL: for none) [TCPWARE:DHCPDEBUG.LOG]: Return
Include date on each log entry [NO]: Return
Log debug messages to OPCOM [NO]: Return
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 the below example).
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 IP 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.
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
Specify DECnet line name for the tunnel [DNIP-0-0]: Return
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
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
Specify port number for this tunnel on this host [64215]: Return
Do
you want to configure another tunnel [NO]: Y
Specify DECnet line name for the tunnel
[DNIP-0-1]: Return
Specify remote host internet address: 192.168.2.65
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
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
Configure 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 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 TCPware Management Guide.
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
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
Enter the cluster name(s) []: cluster.example.com
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
Enter the name(s) of the domains in search list []: example.com com
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
Enter the minimum number of dots to be resolved absolutely [1]: 2
This is how your DNS client is configured:
Domain
Name: example.com
Name Server(s): 192.168.1.1
Domain List: example.com com
Number of Dots: 2
Is this configuration correct [YES]: Return
Configure the FTP Server
CNFNET Steps
You can configure the FTP 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.
|
Configuring
FTP:
Do you want to enable the FTP server [YES]: Return
Do you want to enable the FTP client
[YES]: Return
Do you want to enable FTP accounting [NO]:
Y
Name of host that will run accounting
collection program [localhost]: Return
Port number that accounting collection program listens on []: Return
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 the below example).
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 below address a situation where the gateway announces a default route to the backbone and announces all the subnet routes to the outside world.
#
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 TCPware Management Guide, Chapter 8, Routing and GateD.
Configure the IMAP Server
The Internet Message Access Protocol (IMAP) server lets remote PC systems retrieve mail from 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 the below example):
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 TCPware Management Guide, Chapter 17, Managing Mail Services, in the IMAP Server section.
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
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
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
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
The IMAP server is configured as follows:
Username
: SYSTEM
Message caching enabled : YES
log level : NONE
Is this correct [YES]: Return
Do you want to restart the Internet Message Access Protocol Server [NO]: Y
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 the below example).
$ @TCPWARE:CNFNET IPP
TCPware(R) for OpenVMS Version 6.0-0 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 media types, 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 in nature, 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 and received is written to the log file in hexadecimal and in ASCII. The default 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 referred 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 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 OPCOM logging level [INFO]: RETURN
Configuring Opcom Terminal for the IPP symbiont.
There are several OPCOM "terminals" to which OPCOM messages can be directed. 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 values for 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 IPS with CNFNET
CNFNET Steps
You can configure IPP as part of the general CNFNET configuration, or specifically as
@TCPWARE: CNFNET IPP (see the below example).
$ @TCPWARE:CNFNET IPS
TCPware(R) for OpenVMS Version 6.0-0 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
TCPware IPS (Intrusion Prevention System) is a highly-configurable
subsystem for detecting attacks on components such as SSH, telnet
and ftp, and responding to these attacks by putting packet filters
on interfaces to block those attacks in real-time.
For detailed information on TCPware IPS, refer to the TCPware for
OpenVMS Management Guide.
Do you want to enable TCPware IPS [YES]? RETURN
TCPware IPS uses a mailbox to deliver event information from
instrumented components to the FILTER_SERVER process. The mailbox
must be sized to accommodate the anticipated number of simultaneous
event messages from all components. Failure to do this could
result in events being lost.
The number may range from 50 to a maximum of 1000, with a default
value of 400.
NOTE: If the size of the mailbox is changed, a system reboot must
be performed to recreate the mailbox with the desired size.
Enter the max # of simultaneous event messages in the mailbox [400]: RETURN
Some process quotas for the FILTER_SERVER process must be set up to
avoid issues with the FILTER_SERVER process hanging in MUTEX state.
The specific quotas, TQELM and ASTLM, should be determined based on
receiving events per source addresses per rule per component. A
good rule of thumb is to allocate TQELM's as follows:
1 for automated hourly reporting
1 for automated 24-hour maintenance
1 for each source address per rule per component for
which an event has been received. These timers
are used to clean up internal address structures
after 24 hours of inactivity from the address.
1 for each non-empty event queue per source address
per rule per component. These timers are used
to delete aged events from the event queue.
Form ASTLM, this tends to be used at a slightly higher rate
than TQELM, so plan accordingly.
For both TQELM and ASTLM, the default values are 500.
Enter the value for TQELM for the FILTER_SERVER process [500]: RETURN
Enter the value for ASTLM for the FILTER_SERVER process [500]: RETURN
Do you want to restart the IPS subsystem [NO]: Y
Shutting down the IPS subsystem ...
Starting the IPS subsystem ...
$
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 the below example).
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.
Configuring Kerberos (Version 4) Services:
Kerberos allows you to control user access to network services.
Do you want the Kerberos Services [NO]: Y
Do you want to configure Kerberos Services [NO]: Y
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
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 [example.com]: Return
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
Name of a Secondary Kerberos server []: BART
Name of a Secondary Kerberos server []: MARGE
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
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 the example below):
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.
|
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): RETURN
Do you want RLOGIN Kerberos authentication requests to be [ALLOWED]: Return
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
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
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 a 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:
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.
|
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
Do you want to configure LPS now [YES]: Return
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
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
If the print server is a UNIX or Linux system, get the host name by using the hostname command:
$ hostname
alpha.example.com
And locate the print queue name by using the lpstat command:
$ lpstat -p
If the print queue or hostname information needs editing, get your UNIX system manager to make changes.
CNFNET Steps
To configure the default remote printer (see the below example):
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):.
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
Enter
the host name for the remote printer []: ALPHA
Enter the remote printer on alpha []: SYS$PRINT
The current configuration for default remote printer is:
What would you like to do (CHANGE, DELETE, or END): END
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 the below example):
1. For a first time configuration, this message will appear:
Currently there is no print queue configured
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 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;
· 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.
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.
Would you like to configure print queues [NO]: Y
Specify
the OpenVMS print queue name for LPS: DOC$PRINT
Specify the remote host name: SIGMA
Specify the remote printer on sigma: DOC_PRINTER
May users override the remote printer specification [NO]: Return
Select formatting option (VMS/LPD) [LPD]: Return
Specify additional qualifier []: Return
Do you want to configure another queue [NO]: Return
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)
What would you like to do (ADD, CHANGE, DELETE, START or END):END
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 the below example):
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.
Do
you want to start LPS on a batch queue [NO]: Y
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 the below example):
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.
|
Configuring the LPD Server
Do you want this host to support the LPD server [NO]: Y
Do you want the LPD server to allow batch queues to be used [NO]:Return
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 the example below):
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.
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
Press return at the remote host prompt to stop entering information.
Enter the name of the remote host allowed access: alpha
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
Enter the local username for koenig at
alpha: luna
Enter the remote user on alpha allowed access: Return
Enter the name of the remote host allowed access: Return
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
|
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 the below example):
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 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.
Configuring the Miscellaneous Services:
Do you want the Trivial File Transfer Server (TFTPD) [NO]: Y
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
Do
you want the CHARGEN Server (CHARGEND) [NO]: Return
Do you want the DAYTIME Server (DAYTIMED) [NO]: Return
Do you want the DISCARD Server (DISCARDD) [NO]: Return
Do you want the ECHO Server (ECHOD) [NO]: Return
Do you want the QUOTE Server (QUOTED) [NO]: Return
Do you want the AUTH Server (Identification) [NO]: Return
Do you want the TIME Service [NO]: Return
Do you want to restart the miscellaneous servers [NO]: Return
Configure the NFS Server
Because you need to install, configure, and start TCPware before you can set up the NFS 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 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 (the below example). 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 if 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 the example below):
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:
NETCU> 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.
Obtain the uid and gid values from client's /etc/passwd file (see the below example). 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.
Obtaining UID and GID From UNIX /etc/passwd
> 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
Adding Users to the Server PROXY Database
(Iota)
$ RUN TCPWARE:STARTNET
(Iota) $ NETCU
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
NFS PROXY Database V6.0 Copyright (c) Process Software
Username
UID GID Host(s)
-------- --- --- -------
SYSTEM 0 1 SIGMA
GIMLI 1000 15
PIPPIN 1134 15
NETCU>RELOAD PROXY
NETCU>EXIT
Add Directories to the Server EXPORT Database
To add an entry to the NFS EXPORT database:
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 NFS 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:
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.
|
Adding an Entry to the Server EXPORT Database
NETCU>ADD EXPORT "/mnt/iota" DUA0:[000000]
%TCPWARE_NETCU-I-ADDPATH, added path /mnt/iota
NETCU>ADD EXPORT "/pcreports/spool"
DUA0:[PCREPORTS.SPOOL] -
_NETCU>/NOCONVERT /RFM=UNDEFINED
%TCPWARE_NETCU-I-ADDPATH, added path /pcreports/spool
NETCU>SHOW EXPORT
NFS EXPORT Database V6.0 Copyright (c) Process Software
Path
Directory Host(s)
---- --------- -------
/mnt/iota DUA0:[000000]
/pcreports/spool DUA0:[PCREPORTS.SPOOL]
NETCU>EXIT
Creating a Spool Directory and Spool Subdirectories
$ CREATE/DIRECTORY DUA0:[PCREPORTS.SPOOL]
$ CREATE/DIRECTORY DUA0:[PCREPORTS.SPOOL.DAISY]
$ CREATE/DIRECTORY DUA0:[PCREPORTS.SPOOL.ROSE]
CNFNET Steps, Part 1
To configure the NFS server in CNFNET:
1. Enter Y or Return at the prompt asking if you would like the NFS
v3 server on this machine.
To use the NFS 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 access 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)
Configuring NFS Server:
Do you want the NFS v3 Server (NFSDV3)[YES]: Return
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
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
CNFNET Steps, Part 2
During the second part of this NFS server configuration, you need to respond to the logging class, PCNFSD spool directory, and configuration prompts.
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.
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
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
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
Automatically create subdirectories for each client [NO]: Y
These are the NFS-OpenVMS Server configuration parameters you selected:
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
Start and Restart the NFS Server
To start the NFS server:
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.
$ @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
.
.
.
$
Test the NFS Server
To test the server:
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 below 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.
$ TYPE TCPWARE:NFSSERVER.LOG
If problems arise, see the Troubleshooting section in Chapter 14, Managing NFS 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).
|
$ TELNET SIGMA
.
.
.
sigma.example.com#
mount iota:/mnt/iota /iota
sigma.example.com# cd /iota
sigma.example.com# ls
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.example.com#
|
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
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 below in host 192.168.67.100's NTP.CONF file:
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 ...
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).
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
Configure POP3
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 the below example):
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.
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
Enter Maximum number of new mail messages to return per connect [32]: Return
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
Do you want to execute a MAIL PURGE/RECLAIM operation after use [YES]: Return
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
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:
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.
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.
Proceed directly to the next section to configure the R commands clients.
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:
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 a .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 N 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.
Do you want to activate login service [YES]: Return
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
Do you want to activate shell service [YES]: Return
Do you want to activate exec service [YES]: Return
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
Do you want to INSTALL the RSH image [YES]: Return
Do you want to INSTALL the RMTSETUP image [YES]: 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 SMTP
Follow these steps to configure SMTP. 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 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 operates.
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]: Return
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]: Return
Port number that accounting collection program listens on []: Return
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:
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 a 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
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
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
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
Enter the name of the shareable image without .EXE: SNMP_AGENT2_SHR
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 Management Guide for details on the configuration files.
CNFNET Steps
You can enable TCPware's SSH utility as shown below.
$ @TCPWARE:CNFNET SSH
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]: Return
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[]: Return
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[]: Return
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]: Return
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 []: Return
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]: Return
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]? Return
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]: Return
You may disable listening for server connections on an IPV4 socket or
on an IPV6 socket. The default is to listen on both IPV4 and IPV6
sockets.
NOTE: you must have either IPV4 or IPV6 (or both) listen sockets enabled.
Do you want to disable listening on an IPV4 socket [NO]? Return
Do you want to disable listening on an IPV6 socket [NO]? y
Do you want any messages logged by the SSH server at all [YES]? Return
Do you want verbose logging by the SSH server [NO]? Return
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]: Return
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] Return
Do you want to log rejected sessions [NO] Return
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]? Return
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]? Return
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.
$ @TCPWARE:CNFNET TALK
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
CNFNET Steps
You can configure TELNET as part of the general CNFNET configuration or specifically as @TCPWARE:CNFNET TELNET (see the below example).
Specify at the prompt how many 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).
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 the below example):
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.
Configuring the TIMED Daemon:
Do you want to use the TCPware for OpenVMS TIMED Daemon [YES]: Return
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
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
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 the below example).
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.
Configuring the X Display Manager (XDM) Server:
Do you want to use the TCPware for OpenVMS XDM Server [NO]: Return