Installing and Administering Internet Services HP 9000 Networking Edition 7 B2355-90147 E1097 Printed in: United States © Copyright 1997 Hewlett-Packard Company
Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty.
This software is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University of California. ©copyright 1980, 1984, 1986 Novell, Inc. ©copyright 1986-1992 Sun Microsystems, Inc. ©copyright 1985-86, 1988 Massachusetts Institute of Technology. ©copyright 1989-93 The Open Software Foundation, Inc. ©copyright 1986 Digital Equipment Corporation. ©copyright 1990 Motorola, Inc.
Contents 1. Product Overview The Internet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Military Standards and Request for Comment Documents . . . . . . . . . .25 2. Installing and Configuring Internet Services Updating Your Network Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Installing the Internet Services Software . . . . . . . . . . . . . . . . . . . . . . . .30 Configuring the Name Service Switch . . . . . . . . . . . . . . . .
Contents Restricting ftp Access with /etc/ftpusers . . . . . . . . . . . . . . . . . . . . . . . . . 52 Specifying rlogin Pseudo-Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Specifying telnet Pseudo-Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuring Files to Bypass Security . . . . . . . . . . . . . . . . . . . . . . . . . . . To Configure the /etc/hosts.equiv File . . . . . . . . . . . . . . . . . . . . . . . . . To Configure the $HOME/.rhosts File . .
Contents To Add a Host to the Domain Data Files . . . . . . . . . . . . . . . . . . . . . . .84 To Delete a Host from the Domain Data Files . . . . . . . . . . . . . . . . . . .85 Configuring a Secondary Master Name Server . . . . . . . . . . . . . . . . . . . .86 Creating Secondary Server Data Files via hosts_to_named . . . . . . . .86 To Create the Secondary Master Server’s Data Files Manually . . . . .87 To Set the Default Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Example 2: Retransmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Name Server Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4. Installing and Administering sendmail Deciding Whether to Install sendmail . . . . . . . . . . . . . . . . . . . . . . . . . 120 Installing sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing sendmail on a Standalone System . . . . . . . . . . . . . . . . . .
Contents How sendmail Handles Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144 How sendmail Handles “Permanent” Failures . . . . . . . . . . . . . . . .144 How sendmail Handles “Temporary” Failures . . . . . . . . . . . . . . . .145 Modifying the Default sendmail Configuration File . . . . . . . . . . . . . . .147 The sendmail Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 Restarting sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Booting RMP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Configuring the TFTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Procedure for Configuring tftpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Verify Your tftpd Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Configuring the BOOTP Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Devices Booting From Remote Servers . . . . . . . . . . . . . . . . . . . . . . . .201 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Problem 1: No suitable server for synchronization found. . . . . . . 232 Problem 2: Version 1 and 2 NTP Servers Do Not Respond . . . . . . 233 Reporting Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 8. Configuring gated Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Use gated . . . . . .
Contents Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269 Defining Backbones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 AS External Routes (AS Boundary Routers Only) . . . . . . . . . . . . . . .
Contents gated Routing Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ripquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ospf_monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem 1: gated does not act as you expected it to. . . . . . . . . . . .
Contents Setting Up remsh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Creating the Distfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Variable Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 File Distribution Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325 Changed Files List Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents File Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before HP-UX 11.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beginning with HP-UX 11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KDC Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 12. Troubleshooting Internet Services Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375 Characterizing the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Diagnostic Tools Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Diagnosing Repeater and Gateway Problems . . . . . . . . . . . . . . . . . . . .380 Flowchart Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 18
1 Product Overview The HP 9000 Internet Services enable your HP 9000 computer to transfer files, log into remote hosts, execute commands remotely, and exchange mail with remote hosts on the network. The Internet Services product was previously called the ARPA Services.
Product Overview A link product, such as LAN/9000 or X.25/9000, must be installed for the Internet Services to function. The link product provides the hardware and software needed for communication by an HP 9000 computer over an IEEE 802.3, Ethernet Local Area Network, or X.25 packet switch network. NS and NFS Services also require link software and can run concurrently on the same node with the Internet Services.
Product Overview The Internet Services The Internet Services The HP 9000 Internet Services product combines services developed by the University of California at Berkeley (UCB), Cornell University, Merit Network, Inc., Carnegie-Mellon University (CMU), Hewlett-Packard, Massachusetts Institute of Technology (MIT), Internet Software Consortium, and other public domain sources. ARPA Services include the set of services developed by UCB for the Advanced Research Projects Agency (ARPA): ftp and telnet.
Product Overview The Internet Services Table 1-1 The Internet Services ftp Copies files among hosts on the network that support Internet Services. For more information, see “Installing and Configuring Internet Services” on page 27 or type man 1 ftp or man 1M ftpd. telnet Allows you to log onto a remote host that supports Internet Services. For more information, see “Installing and Configuring Internet Services” on page 27 or type man 1 telnet or man 1M telenetd.
Product Overview The Internet Services NTP Maintains the local clock on an HP-UX workstation in agreement with Internet-standard time servers. For more information, see “Configuring NTP” on page 207, or type man 1M xntpd. rexec A library routine used to execute commands on a remote UNIX host on the network. For more information, see “Installing and Configuring Internet Services” on page 27 or type man 3N rexec or man 1M rexecd. rcp Allows you to transfer files between UNIX hosts on the network.
Product Overview The Internet Services whois Lists information about specified people and organizations listed in the Network Information Center (NIC) database. A direct socket connection to the NIC is required. For more information, type man 1 whois. DDFA Allows access from HP-UX systems and user-written applications to HP DTCs. For more information, see the DTC Device File Access Utilities Manual. Secure Internet Services An optionally enabled mechanism that incorporates Kerberos V5 Release 1.
Product Overview Military Standards and Request for Comment Documents Military Standards and Request for Comment Documents To obtain information about available MIL-STD specifications, contact the following: Department of the Navy Naval Publications and Forms Center 5801 Tabor Avenue Philadelphia, PA 19120-5099 To obtain information about available RFCs, contact the following: Government Systems, Inc.
Product Overview Military Standards and Request for Comment Documents 26 Chapter 1
2 Installing and Configuring Internet Services This chapter describes how to install the Internet Services and configure them for your system.
Installing and Configuring Internet Services • “Updating Your Network Map” on page 29 • “Installing the Internet Services Software” on page 30 • “Configuring the Name Service Switch” on page 31 • “Configuring Internet Addresses” on page 35 • “Configuring the Internet Daemon, inetd” on page 40 • “Configuring rwhod, the Server for rwho and ruptime” on page 43 • “Configuring Logging for the Internet Services” on page 44 • “Configuring Anonymous ftp Access” on page 48 • “Restricting ftp Access with /etc/ftpuse
Installing and Configuring Internet Services Updating Your Network Map Updating Your Network Map Before you install the Internet Services, take the time to update your network map to indicate that the Internet Services are installed on your node. A network map provides information about the configuration of the computers on the network. As node manager, it is your responsibility to keep the network map up to date when you add or delete computers or make cable changes.
Installing and Configuring Internet Services Installing the Internet Services Software Installing the Internet Services Software Before you begin to install the software, make sure you have the correct operating system on your computer. The HP-UX operating system, the required link software, and the Internet Services software must all be the same version. You can check your HP-UX operating system version with the uname -r command.
Installing and Configuring Internet Services Configuring the Name Service Switch Configuring the Name Service Switch The Name Service Switch determines where your system will look for the information that is traditionally stored in the following files: /etc/mail/aliases AutoFS maps (like /etc/auto_master and /etc/auto_home) /etc/group /etc/hosts /etc/netgroup /etc/networks /etc/passwd /etc/protocols /etc/publickey /etc/rpc /etc/services For all types of information except host information, you can configur
Installing and Configuring Internet Services Configuring the Name Service Switch Also, for more information about the Name Service Switch configuration files supplied in the /etc directory, see Installing and Administering NFS Services. The ability to consult more than one name service for host information is often called hostname fallback.
Installing and Configuring Internet Services Configuring the Name Service Switch passwd: group: hosts: networks: protocols: rpc: publickey: netgroup: automount: aliases: services: files nis files nis dns [NOTFOUND=return] nis [NOTFOUND=return] nis [NOTFOUND=return] nis [NOTFOUND=return] nis [NOTFOUND=return] nis [NOTFOUND=return] files nis files nis nis [NOTFOUND=return] nis [NOTFOUND=return] files files files files files files files If your /etc/nsswitch.
Installing and Configuring Internet Services Configuring the Name Service Switch User name: www User ID: 30 Group ID: 1 Gecos: Home Directory: / Shell: Switch configuration: Terminates Search For more information, type man 1 nsquery at the HP-UX prompt.
Installing and Configuring Internet Services Configuring Internet Addresses Configuring Internet Addresses This section tells you how to configure your host to find other hosts on the network, by host name or IP address.
Installing and Configuring Internet Services Configuring Internet Addresses If you have a large network and little need for Internet connectivity, you can use NIS as your primary name service. The NIS hosts database is administered centrally on one of your hosts, but it must contain the names and IP addresses of all the other hosts in your network. For information on NIS, see Installing and Administering NFS Services.
Installing and Configuring Internet Services Configuring Internet Addresses 5. Add any other hosts to the /etc/hosts file that you need to reach. If you will use a BIND, NIS, or NIS+ server on a different host, add that host to your /etc/hosts file. If you have no default gateway configured, and you add a host that is not on your subnet, SAM will prompt you for the gateway. To stop the prompting, configure a default gateway. 6.
Installing and Configuring Internet Services Configuring Internet Addresses ROUTE_DESTINATION[1]="15.13.131.0" ROUTE_GATEWAY[1]="15.13.131.213" ROUTE_COUNT[1]="0" 3. If you will not be using gated, configure routes to all the networks you need to reach. Type the following command for each network you need to reach from your host: /usr/sbin/route add net network_address gateway_address Then, create a new set of routing variables in the /etc/rc.config.d/netconf file for each new route.
Installing and Configuring Internet Services Configuring Internet Addresses If the host is on a network that uses NIS, change its IP address in the /etc/hosts file on the NIS master server, and issue the following commands to regenerate the hosts database and push it out to the NIS slave servers: cd var/yp /usr/ccs/bin/make hosts If the host is on a network that uses NIS+, use the nistbladm (1) command to change the host’s IP address in the NIS+ hosts table. 4.
Installing and Configuring Internet Services Configuring the Internet Daemon, inetd Configuring the Internet Daemon, inetd The internet daemon, /usr/sbin/inetd, is the master server for many of the Internet Services. The inetd daemon listens for connection requests for the services listed in its configuration file and starts up the appropriate server when it receives a request. The inetd daemon is always started as part of the boot process, by the startup script /sbin/init.d/inetd. The /etc/inetd.
Installing and Configuring Internet Services Configuring the Internet Daemon, inetd 3. Make sure /etc/inetd.conf is owned by user root and group other, and make sure its permissions are set to 0444 (-r--r--r--). For more information, type man 4 inetd.conf or man 1M inetd. To Edit the /var/adm/inetd.sec File The /var/adm/inetd.sec file is a security file that inetd reads to determine which remote hosts are allowed access to the services on your host. The inetd.
Installing and Configuring Internet Services Configuring the Internet Daemon, inetd Only the services configured in /etc/inetd.conf can be configured in /var/adm/inetd.sec. For more information, type man 4 inetd.sec or man 1M inetd.
Installing and Configuring Internet Services Configuring rwhod, the Server for rwho and ruptime Configuring rwhod, the Server for rwho and ruptime The rwhod daemon checks the state of your host and generates status messages, which it broadcasts on the network every 180 seconds. It also listens for status messages broadcast by rwhod daemons on remote hosts, and it records these messages in a database of files in /var/spool/rwho. The files are named whod.
Installing and Configuring Internet Services Configuring Logging for the Internet Services Configuring Logging for the Internet Services This section tells you how to complete the following tasks: • “To Configure syslogd” on page 44 • “To Maintain System Log Files” on page 45 • “To Configure inetd Connection Logging” on page 45 • “To Configure ftpd Logging” on page 46 To Configure syslogd The Internet daemons and servers log informational and error messages through syslog.
Installing and Configuring Internet Services Configuring Logging for the Internet Services mail.debug *.info,mail.none *.alert *.alert *.emerg /var/adm/syslog/mail.log /var/adm/syslog/syslog.log /det/console root * With this configuration, all mail log messages at the debug level or higher are sent to /var/adm/syslog/mail.log. Log messages from any facility at the information level or higher (but no mail messages) are sent to /var/adm/syslog/syslog.log.
Installing and Configuring Internet Services Configuring Logging for the Internet Services If inetd is running with connection logging turned on, the same command turns it off. For more information, type man 1M inetd. To Configure ftpd Logging To configure ftpd to log messages about logins, login failures, and anonymous ftp activity, follow these steps: 1. Add the -l or -v (verbose) option to the ftp line in the /etc/inetd.
Installing and Configuring Internet Services Configuring ftp Configuring ftp Beginning with HP-UX 11.0, ftp provides support for Pluggable Authentication Module (PAM). PAM is an Open Group standard (RFC 71.0) for user authentication, password modification, and validation of accounts. The PAM configuration file (/etc/pam.conf) has been updated to include ftp. The default authentication mechanism is UNIX, and its entry in pam.conf is as follows: ftp ftp auth required /usr/lib/security/libpam_unix.
Installing and Configuring Internet Services Configuring Anonymous ftp Access Configuring Anonymous ftp Access Anonymous ftp allows a user without a login on your host to transfer files to and from a public directory. A user types the ftp command to connect to your host and types anonymous or ftp as a login name. The user can type any string of characters as a password. (By convention, the password is the host name of the user’s host).
Installing and Configuring Internet Services Configuring Anonymous ftp Access 2. Create the subdirectory /usr/bin under the ftp home directory: cd /home/ftp mkdir usr cd usr mkdir bin 3. Copy the ls and pwd commands from /sbin to ˜ftp/usr/bin, and set the permissions on the commands to 0111 (executable only): cp /sbin/ls /home/ftp/usr/bin cp /sbin/pwd /home/ftp/usr/bin chmod 0111 /home/ftp/usr/bin/ls chmod 0111 /home/ftp/usr/bin/pwd 4.
Installing and Configuring Internet Services Configuring Anonymous ftp Access chown root /home/ftp/etc chmod 0555 /home/ftp/etc 11. Create a directory called pub under ˜ftp. Set its owner to user ftp and its permissions to 0777 (writeable by all). Anonymous ftp users can put files in this directory to make them available to other anonymous ftp users. mkdir /home/ftp/pub chown ftp /home/ftp/pub chmod 0777 /home/ftp/pub 12. Create a directory called dist under ˜ftp.
Installing and Configuring Internet Services Configuring Anonymous ftp Access Figure 2-1 Directory Structure for Anonymous ftp Account / usr home etc bin usr ... passwd file ftp ftp etc pub dist passwd group ls ... pwd Chapter 2 ...
Installing and Configuring Internet Services Restricting ftp Access with /etc/ftpusers Restricting ftp Access with /etc/ftpusers When a user attempts to log into your system using ftp, the ftpd daemon checks the /etc/ftpusers file. If the file exists, and the user’s login name is listed in it, ftpd denies access to the user. User accounts that specify a restricted login shell in /etc/passwd should be listed in /etc/ftpusers, because ftpd accesses local accounts without using their login shells.
Installing and Configuring Internet Services Specifying rlogin Pseudo-Terminals Specifying rlogin Pseudo-Terminals Beginning with the earlier 10.20 version of HP-UX, the rlogin/rlogind internet service works with the 4-byte EUC (Extended Universal Character set). To support this feature, the pseudo-terminal in rlogind uses a STREAMS-based pseudo-terminal driver. The STREAMS master pseudo-terminal driver is ptm and the device used is /dev/ptmx.
Installing and Configuring Internet Services Specifying telnet Pseudo-Terminals Specifying telnet Pseudo-Terminals Beginning with the earlier 10.30 version of HP-UX, the pseudo-terminal in the telnet/telnetd internet service uses two STREAMS-based pseudo-terminal drivers (telm and tels). Because of this, you must tune a new kernel parameter for telnet pseudo-terminals: NSTRTEL. NSTRTEL specifies the number of telnet slave devices to be created.
Installing and Configuring Internet Services Configuring Files to Bypass Security Configuring Files to Bypass Security The following files may be used to allow users access to your host without supplying a password: • /etc/hosts.equiv, a file owned by user root. This file allows certain users to connect to your host with rcp, remsh, or rlogin without supplying a password. • $HOME/.rhosts, a file that may be created by any user in his or her home directory.
Installing and Configuring Internet Services Configuring Files to Bypass Security CAUTION Hewlett-Packard recommends that you leave user names out of the /etc/hosts.equiv file, unless you intend to give a user the privilege of logging into all the accounts on the system without having to provide a password. When a non-root user attempts to log into your host, the /etc/hosts.equiv file is checked before $HOME/.rhosts. If an entry is found in /etc/hosts.equiv, $HOME/.rhosts is not checked.
Installing and Configuring Internet Services Configuring Files to Bypass Security The remshd and rlogind servers can be configured to ignore $HOME/.rhosts files. See “To Disable Use of $HOME/.rhosts” on page 57. When a non-root user attempts to connect to your host, the /etc/hosts.equiv file is checked before $HOME/.rhosts. If an entry is found in /etc/hosts.equiv, $HOME/.rhosts is not checked. When a user attempts to connect to your host as root, the /etc/hosts.equiv file is not checked. Only the /.
Installing and Configuring Internet Services Configuring Files to Bypass Security machine broccoli login bill password try2Bhave If user andrea has this entry in her .netrc file on host cabbage, she can use ftp or rexec to connect to user bill’s account on host broccoli without being prompted for a password. Each $HOME/.netrc file should be owned by the user of the home directory, with permissions set to 0600 (-rw-------).
3 Configuring and Administering the BIND Name Service 59
Configuring and Administering the BIND Name Service The Berkeley Internet Name Domain (BIND) is a distributed network information lookup service. It allows you to retrieve host names and internet addresses for any node on the network. It also provides mail routing capability by supplying a list of hosts that will accept mail for other hosts.
Configuring and Administering the BIND Name Service Overview of the BIND Name Service Overview of the BIND Name Service The Berkeley Internet Name Domain (BIND) is the Berkeley implementation of DNS (Domain Name System). It is a database, distributed across the Internet, which maps host names to internet addresses, maps internet addresses to host names, and facilitates internet mail routing. This section describes the components of BIND and how they work.
Configuring and Administering the BIND Name Service Overview of the BIND Name Service • You can contact almost any host on the Internet. Because BIND spans network boundaries, you can locate almost any host on the network by starting at the root server and working down. An NIS server can serve only the hosts on its local LAN. NIS clients send out broadcasts to locate and bind to NIS servers, and broadcasts do not cross network boundaries.
Configuring and Administering the BIND Name Service Overview of the BIND Name Service Figure 3-1 Structure of the DNS Name Space . (root) = domain com = host inc div indigo edu purdue nmt venus cs econ arthur How BIND Works When a user who is logged into host venus in the nmt.edu domain types the following command, telnet indigo.div.inc.com the following events occur: 1. The telnet process calls gethostbyname to get the internet address of indigo.div.inc.com. 2.
Configuring and Administering the BIND Name Service Overview of the BIND Name Service 5. The local name server queries a root name server to find the address of indigo.div.inc.com. A root name server serves the root domain. It typically stores information about hosts and name servers one and two levels below the root. 6. If the root name server cannot resolve the host name, it returns the address of a name server for the inc.com domain. 7. The local name server queries the server for the inc.
Configuring and Administering the BIND Name Service Overview of the BIND Name Service round-robin address rotation, the name server rotates the order of the addresses returned, so connections to rainbow will be balanced among red, blue, and green. Round-robin address cycling can also affect multi-homed hosts (hosts with multiple IP addresses).
Configuring and Administering the BIND Name Service Overview of the BIND Name Service • If the input host name contains at least the number of dots specified by the ndots option in the /etc/resolv.conf file, BIND looks it up as is, before appending any domains to it. (The default value of ndots is 1, so if the input host name contains at least one dot, it will be looked up as is before any domains are appended to it.
Configuring and Administering the BIND Name Service Overview of the BIND Name Service The search option specifies a list of domains to search. Following is an example of a search option in /etc/resolv.conf: search div.inc.com inc.com You can set the search option to any list of domains, but the first domain in the list must be the domain of the local host. BIND looks up host names in each domain, in the order they are listed. BIND uses the search option only if the LOCALDOMAIN variable is not set.
Configuring and Administering the BIND Name Service Creating and Registering a New Domain Creating and Registering a New Domain Follow the steps in this section if you need to set up a new domain. Skip this section if you are interested only in adding hosts to an existing domain. 1. Ask the appropriate person or organization for a range of internet addresses to be assigned to the hosts in your domain.
Configuring and Administering the BIND Name Service Creating and Registering a New Domain • Do not use nic or other well known acronyms as leftmost (most specific) labels in a name. Contact Government Systems, Inc., for a list of top-level and second-level domain names already in use. 3. After you have registered your domain, you can create subdomains without registering them with the public network.
Configuring and Administering the BIND Name Service Configuring the Name Service Switch Configuring the Name Service Switch The Name Service Switch determines where your system will look for host information when it needs to resolve a host name to an IP address. For all types of information except host information, you can configure your system to use NIS (one of the NFS Services), NIS+ (the next generation of NIS), or the local /etc file, in any order.
Configuring and Administering the BIND Name Service Choosing Name Servers for Your Domain Choosing Name Servers for Your Domain You can configure your host as any of three types of BIND name servers: Primary Master Server A primary master server is the authority for its domain and contains all data corresponding to its domain. It reads its information from a master file on disk.
Configuring and Administering the BIND Name Service Choosing Name Servers for Your Domain • If your network is isolated from the Internet, and your host will be the only BIND name server in your organization, you need to configure a root name server. See “Configuring a Root Name Server” on page 97.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server Configuring a Primary Master Name Server This section explains how to configure a primary master server in your domain. It also describes the name server data files in the primary master server configuration.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server mv /etc/named.data/named.boot /etc/named.boot 5. Copy the file /usr/examples/bind/db.cache.arpa to the /etc/named.data directory. This file is a list of root name servers. You can also use anonymous ftp to get the current list of root name servers from rs.internic.net. Instructions are included in the /usr/examples/bind/db.cache.arpa file. 6. Use the list of root name servers from the /usr/examples/bind/db.cache.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server To Set the Default Domain Name If you will be using an /etc/resolv.conf file on your host, configure the default domain name with the search or domain keyword. See “Configuring the Resolver to Query a Remote Name Server” on page 91. If you will not be using an /etc/resolv.conf file, follow these steps: 1.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server Every name server must have data for the 0.0.127.IN-ADDR.ARPA domain. Hosts running Berkeley networking use 127.0.0.1 as the address of the loopback interface. Since the network number 127.0.0 is not assigned to any one site but is used by all hosts running Berkeley networking, each name server must be authoritative for network 127.0.0. ; Lines beginning with a semicolon (;) are comments.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server . NS.NIC.DDN.MIL. . AOS.ARL.ARMY.MIL. . NIC.NORDU.NET. 99999999 99999999 99999999 99999999 99999999 99999999 99999999 99999999 A NS A NS A A NS A 192.52.195.10 NS.NIC.DDN.MIL. 192.112.36.4 AOS.ARL.ARMY.MIL. 128.63.4.82 192.5.25.82 NIC.NORDU.NET. 192.36.148.17 ; Lines beginning with a semicolon (;) are comments. name In NS records, the name of the domain served by the name server listed in the data column.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server db.127.0.0 contains the resource record that maps 127.0.0.1 to the name of the loopback address, usually localhost. The hosts_to_named program creates this file. ;name class type data @ SOA rabbit.div.inc.com. root.moon.div.inc.com. ( IN 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Retry every hour 604800 ; Expires after a week 86400 ) ; Minimum ttl of 1 day @ IN NS rabbit.div.inc.com.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server 1.0.0.127.in-addr.arpa. (The current origin is appended to the 1 in the name field, because it does not end with a dot.) data The SOA data includes the name of the host this data file was created on, the mailing address of the person responsible for the name server, and the following values: Serial The version number of this file, incremented whenever the data is changed.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server SOA Start of Address record. The SOA record designates the start of a domain, and indicates that this server is authoritative for the data in the domain. In data files, @ represents the current origin. The current origin is the domain configured in this file, according to the boot file. The boot file says that the div.inc.com domain is configured in the db.div file. Therefore, every instance of @ in the db.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server The current origin is appended to names that do not end with a dot. For example, localhost in the first A record is interpreted as localhost.div.inc.com. HINFO Host Information records. The HINFO records indicate the hardware and operating system of the host. CNAME Canonical Name record. The CNAME record specifies an alias for a canonical name (the host’s official name).
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server 604800 86400 ; Expires after a week ) ; Minimum ttl of 1 day IN NB rabbit.div.inc.com IN NS indigo.div.inc.com. localhost IN A 127.0.0.1 indigo IN A 15.19.8.197 IN A 15.19.13.197 IN HINFO HP9000/840 HPUX incindigo IN CNAME indigo cheetah IN A 15.19.8.64 IN HINFO HP9000/850 HPUX IN WKS 15.19.8.64 UDP syslog domain route IN WKS 15.19.8.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server @ IN SOA rabbit.div.inc.com. root.moon.div.inc.com.( 1 ; Serial 10800 ; Refresh every 3 hours 3600 ; Retry every hour 604800 ; Expire after a week 86400 ) ; Minimum ttl of 1 day IN NS rabbit.div.inc.com. IN NS indigo.div.inc.com. 119 IN PTR rabbit.div.inc.com. 64 IN PTR cheetah.div.inc.com. 197 IN PTR indigo.div.inc.com. This example file, db.15.19.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server Expire Indicates (in seconds) how long the secondary name server can use the data before it expires for lack of a refresh. Minimum ttl The minimum number of seconds for the time to live field on other resource records for this domain. NS Name Server records. The NS records give the names of the name servers and the domains for which they have authority.
Configuring and Administering the BIND Name Service Configuring a Primary Master Name Server Examples of these records are shown in “The Primary Master Server’s db.domain Files” on page 79 and “The Primary Master Server’s db.net Files” on page 82. 2. After modifying the domain data files, issue the following command to restart the name server and force it to reload its databases: /usr/sbin/sig_named restart To Delete a Host from the Domain Data Files 1.
Configuring and Administering the BIND Name Service Configuring a Secondary Master Name Server Configuring a Secondary Master Name Server A secondary master server can operate in either of two ways: • It can store the authoritative data in backup files on its disk. When this type of secondary server reboots, it reads its data from the backup files and does not have to rely on loading data from a primary server.
Configuring and Administering the BIND Name Service Configuring a Secondary Master Name Server If you ran hosts_to_named with the -Z option, copy the file boot.sec from the current directory on the primary server to the /etc directory on the secondary server. 3. On the secondary server, rename /etc/boot.sec.save or /etc/boot.sec to /etc/named.boot. 4. Copy the files /etc/named.data/db.cache and /etc/named.data/db.127.0.0 from the primary server to the secondary server.
Configuring and Administering the BIND Name Service Configuring a Secondary Master Name Server ; ; type ; directory domain server address backup file /etc/named.data ;running directory for named secondary div.inc.com 15.19.8.119 db.div primary 0.0.127.IN-ADDR.ARPA secondary 8.19.15.IN-ADDR.ARPA 15.19.8.119 db.15.19.8 secondary 13.19.15.IN-ADDR-ARPA 15.19.8.119 db.15.19.13 db.127.0.0 cache db.cache This file specifies a file name in the fourth field for each domain.
Configuring and Administering the BIND Name Service Configuring a Caching-Only Name Server Configuring a Caching-Only Name Server The boot file of a caching-only name server has no primary or secondary lines, except the primary line for the 0.0.127.in-addr.arpa domain (the loopback interface). Hosts running Berkeley networking use 127.0.0.1 as the address of the loopback interface. Since the network number 127.0.
Configuring and Administering the BIND Name Service Configuring a Caching-Only Name Server /usr/bin/hostname indigo.div.inc.com and set the HOSTNAME variable in the /etc/rc.config.d/netconf file to the same value, as in the following example: HOSTNAME=indigo.div.inc.com Do not put a trailing dot at the end of the domain name.
Configuring and Administering the BIND Name Service Configuring the Resolver to Query a Remote Name Server Configuring the Resolver to Query a Remote Name Server Follow these steps if you want your host to query a name server on a remote host: 1. Create a file on your host called /etc/resolv.conf. The /etc/resolv.conf file has three configuration options: • domain followed by the default domain name.
Configuring and Administering the BIND Name Service Configuring the Resolver to Query a Remote Name Server Do not put a trailing dot at the end of the domain name. NOTE If you want to run both BIND and HP VUE, you must have an /etc/resolv.conf file on your system, or HP VUE will not start. If a user sets the LOCALDOMAIN environment variable, any BIND requests made within the context of the user’s shell environment will use the search list specified in the LOCALDOMAIN variable.
Configuring and Administering the BIND Name Service Starting the Name Server Daemon Starting the Name Server Daemon The name server daemon, /usr/sbin/named, must be running on every primary, secondary, and caching-only name server. If you have configured your system to query a remote name server (that is, if you have created an /etc/resolv.conf file that directs BIND queries to a name server on another host), you do not have to run the named daemon on your host.
Configuring and Administering the BIND Name Service Starting the Name Server Daemon 4. At the > prompt, type the name of a host for the name server to look up, as in the following example > charlie You should see output similar to the following: Name Server: indigo.div.inc.com Addresses: 15.19.14.100, 15.19.15.100 Name: charlie.div.inc.com Address: 15.19.9.100 5. Look up several host names and IP addresses of hosts in the name server’s domain. 6.
Configuring and Administering the BIND Name Service Updating Network-Related Files Updating Network-Related Files After you configure your system to use BIND, the following network-related configuration files require fully-qualified domain names for all hosts outside your local domain: /etc/hosts.equiv $HOME/.rhosts /var/adm/inetd.sec $HOME/.netrc To Update /etc/hosts.equiv and $HOME/.
Configuring and Administering the BIND Name Service Delegating a Subdomain Delegating a Subdomain Within your own domain, you may delegate any number and level of subdomains to distribute control and management responsibility. These subdomains need not be registered with the parent network. The organization that owns a zone or subdomain is responsible for maintaining the data and ensuring that up-to-date data is available from multiple, redundant servers. Follow these steps to add a subdomain: 1.
Configuring and Administering the BIND Name Service Configuring a Root Name Server Configuring a Root Name Server If you are connected to the Internet, use the root servers already available. (For a list of root servers, use anonymous ftp to get the file /domain/named.ca from nic.ddn.mil.) However, if you are on an isolated network, you must set up your own root servers. A root server does not have a cache line in its boot file.
Configuring and Administering the BIND Name Service Configuring a Root Name Server denny.dept.inc.com. 86400 IN A 15.19.15.33 sally.doc.inc.com. 86400 IN A 15.19.9.17 259200 IN NS eduardo.inc.com. 25920 IN NS labs.inc.com. 259200 IN NS eduardo.inc.com. 259200 IN NS labs.inc.com. eduardo.inc.com. 259200 IN A 15.19.11.2 labs.inc.com. 259200 IN A 15.19.13.7 ; ; set ttl to 3 days ; inc.com. 15.in-addr.arpa.
Configuring and Administering the BIND Name Service Configuring BIND in SAM Configuring BIND in SAM On the local system, you can configure a primary server, a secondary server, a caching-only server, and resolver; start, restart, or stop the server; specify a parent domain; update the DNS database files; and configure NS resource records. More information on configuring BIND in sam can be found by running sam and referring to the help screens.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server Troubleshooting the BIND Name Server This section tells you how to identify and correct problems with the BIND name server.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server If host name lookups are failing, use ping with an IP address to test network connectivity. $ /usr/sbin/ping IP_address The nsquery command Issue the nsquery command to perform a hosts, passwd, or group lookup, as follows: /usr/contrib/bin/nsqurey lookup_typelookup_query The nsquery command displays the Name Service Switch configuration that is currently in use. Then, it displays the results of the query.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server servers were found for a remote domain, and how many addresses were found for each server. When a secondary server checks with the primary to see if the secondary’s data is up to date, an SOA query is made. The SOA responses are displayed at this level. 4 This level displays the initial query packet and the response packets from other remote servers.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server • Problem 8, Local Domain Not Set • After configuring the primary server for the first time, names in the local domain can be found, but names in remote domains fail.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server • Problem 7, Incorrect Delegation of Subdomain Name Server Problems This section explains the problems that may cause the symptoms listed above, and suggests ways to solve the problems. 1. Incorrect parameters supplied to hosts_to_named. Check the domain data files to be sure they contain records for the hosts in your domain.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server May fail to look up the local host’s name on startup and give a servfail message. To check root server information, execute the following: $ nslookup > set type=NS > . This asks for the NS records for the root. If no records for root servers are present, it returns Can't find "." : Server failed. • ping hostname Names in the local domain are found, while names in remote domains are not found.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server • Name server debugging output Turn on debug level 1. ping the host name. Check the name server debugging output in /var/tmp/named.run for lines like this: req: found 'cucard.med.columbia.edu' as 'columbia.edu' resend(addr=1 n=0) -> 128.59.32.1 6 (53) nsid=18 id=1 0ms resend(addr=2 n=0) -> 128.59.40.130 6 (53) nsid=18 id=1 0ms resend(addr=3 n=0) -> 128.103.1.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server • nslookup Use nslookup and set the name server to the master the secondary is trying to load from. $ nslookup > server server_name or IP_address > ls domain The ls command initiates a zone transfer. If the error message is No response from server, then no server is running on the remote host. If the ls command succeeds, the secondary should be able to load the data from this server. 7.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server Name server records for div.inc.com, the delegated subdomain. Authoritative answers can be found from: walleye.div.inc.com inet address = 15.19.13.197 friday.div.inc.com inet address = 15.19.10.74 Address records for the name servers for div.inc.com. • Dumping the name server database Because the name server caches information, a database dump can be searched for the NS and A records for the subdomain.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server 10. The /etc/hosts file, NIS, or NIS+ contains incorrect data. The name service switch (/etc/nsswitch.conf) allows host name lookups in /etc/hosts, NIS, or NIS+ and one of those databases contains incorrect data. For information on configuring the /etc/hosts file, see “To Edit the /etc/hosts File” on page 36. For information on NIS and NIS+, see Installing and Administering NFS Services.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server • In the third group of four lines, the inc.com server responded with NS records for dept.inc.com. • In the fourth group of four lines, the dept.inc.com server responded with the address of john. The local server responds with the answer to 15.19.10.14. Following are detailed explanations of certain lines from the above example. Debug turned ON, Level 1 The name server was already running.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server After the response from the root server, the database is searched again. inc.com is found once again. The next query goes to an inc.com server, so this time there were NS records. datagram from 15.19.11.2 port 53, fd 6, len 119 This datagram is from another name server since it is from port 53. Since our server sent a query to 15.19.11.2, we assume this is the response. send_msg -> 15.19.10.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server This message was logged from the routine that handles requests. Shown are the name looked up, the packet ID (used to determine duplicate requests), and the type (as defined in /usr/include/arpa/nameser.h). Type 1 is an address query. resend(addr=1 n=0) -> 128.59.32.1 6 (53) nsid=18 id=1 0ms Since no response came from 128.59.16.1, the query with nsid 18 was resent to other servers. datagram from 15.19.10.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server 0 47921 2054 8216 35906 10569 424 179263 Unknown query types A querys CNAME querys SOA querys PTR querys MX querys AXFR querys ANY querys The first two lines print out the number of seconds that the name server has been running and the number of seconds since the last restart caused by a SIGHUP signal. To convert these values to days, divide by 86,400 (the number of seconds in a day).
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server OK answers is the number of responses to queries that contain some information. FAIL answers is the number of responses indicating either that the name does not exist or that there is no data of the requested type for this name. FORMERR answers is the number of malformed response packets from other name servers. A message is sent to the syslog daemon listing the sender of the malformed response packet.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server SOA queries are queries for the start of authority records. These queries are most often made by secondary servers over a stream connection to check if their domain data is current. PTR queries are queries for the domain name for a host address. The gethostbyaddr library routine generates these queries. MX queries are mail exchanger queries made by sendmail during the delivery of electronic mail.
Configuring and Administering the BIND Name Service Troubleshooting the BIND Name Server 116 Chapter 3
4 Installing and Administering sendmail 117
Installing and Administering sendmail This chapter describes sendmail, the Internet Services mail routing facility. sendmail relays incoming and outgoing mail to the appropriate programs for delivery and further routing. sendmail allows you to send mail to and receive mail from other hosts on a local area network or through a gateway.
Installing and Administering sendmail NOTE sendmail for HP-UX 11.0 is an HP implementation of version 8.7 of publicly-available sendmail software. HP provides support for the features documented in this chapter and in the sendmail man page.
Installing and Administering sendmail Deciding Whether to Install sendmail Deciding Whether to Install sendmail You must install sendmail in order to do the following things: • Deliver mail to other machines using the SMTP protocol over a LAN or WAN. • Route X.400 mail using the X.400/9000 delivery agent. • Route OpenMail or X.400 mail using the OpenMail product. If you do not install sendmail, only local and UUCP mail will work.
Installing and Administering sendmail Installing sendmail Installing sendmail When you install sendmail, the installation script creates and modifies files on the system that are needed for sendmail operation. The sendmail configuration file supplied with HP-UX 11.0 will work without modifications for most installations. Therefore, the only steps you must do are: set up sendmail servers to run with NFS, configure and start sendmail clients, and verify that sendmail is running properly.
Installing and Administering sendmail Installing sendmail • Creates /etc/mail/sendmail.cf and /etc/mail/aliases files with default configurations. These files are created with root as the owner, other as the group, and permissions set to 0444. NOTE If an /etc/mail/sendmail.cf file already exists, the existing file is saved to /etc/mail/#sendmail. If an /etc/mail/aliases file already exists, then the sendmail installation script does not create it. • Creates the file /etc/mail/sendmail.
Installing and Administering sendmail Installing sendmail The sendmail installation script performs the configuration changes that are described in “Installing sendmail on a Standalone System” on page 121. To set the system up as an NFS server and allow the sendmail clients to read and write to the /var/mail directory, do the following: 1. Make sure all mail users have accounts on the mail server and that their user IDs and group IDs on the mail server are the same as on the client machines.
Installing and Administering sendmail Installing sendmail 1. In the /etc/rc.config.d/mailservs file, use a text editor to set the SENDMAIL_SERVER variable to 0. This ensures that the sendmail daemon will not be started when you reboot your system or run the sendmail startup script. 2. In the /etc/rc.config.d/mailservs file, use a text editor to set the SENDMAIL_SERVER_NAME variable to the host name or IP address of the mail server you will use (the machine that will run the sendmail daemon). 3.
Installing and Administering sendmail Installing sendmail The NFS startup script NFS-mounts the /var/mail directory from the mail server to your system. For more information on NFS, see Installing and Administering NFS Services.
Installing and Administering sendmail Installing sendmail To verify both inbound and outbound UUCP connections, mail the message in a loop, using the syntax remote_host!my_host!user. For example, if you try date | mailx -s "UUCP Test" node1!node2!joe and node2 is your local host, you should receive a message similar to this: From node1!node2!joe Wed Aug 6 09:48 MDT 1986 Received: by node2; Wed, 6 Aug 86 09:48:09 mdt Return-Path: Received: from node1.
Installing and Administering sendmail Installing sendmail From joe@node2 Wed Aug 6 14:22 MDT 1986 Received: from node1 by node2; Wed, 6 Aug 86 14:22:56 Return-Path: Received: from node2 by node1; Wed, 6 Aug 86 14:25:04 Received: by node2; Wed, 6 Aug 86 14:22:31 mdt Date: Wed, 6 Aug 86 14:22:31 mdt From: Joe User To: joe%node2@node1 Subject: Round Robin SMTP Wed Aug mdt mdt 6 14:22:28 MDT 1986 An entry in your /var/adm/syslog/mail.
Installing and Administering sendmail Creating sendmail Aliases Creating sendmail Aliases The sendmail aliases database stores mailing lists and mail aliases. You create the aliases database by adding aliases to the file /etc/mail/aliases and then running the newaliases script to generate the database from the file. The generated database is stored in the file /etc/mail/aliases.db. The sendmail startup script also generates the aliases database when you reboot your system.
Installing and Administering sendmail Creating sendmail Aliases /usr/sbin/newaliases This command creates the aliases database, which is located in the file /etc/mail/aliases. Table 4-1 user_name Things That May Be Included in a Mailing List A local user name will be looked up in the aliases database unless you put a backslash (\) before it. To prevent sendmail from performing unnecessary alias lookups, put backslashes before local user names.
Installing and Administering sendmail Creating sendmail Aliases "| command" sendmail pipes the message as standard input to the specified command. The double quotes are required to protect the command line from being interpreted by sendmail. Commands must be listed as full pathnames. If stdout and stderr are not redirected, they are not printed to the terminal, and they disappear. However, if a command returns a non-zero exit status, its output to stderr becomes part of the sendmail error transcript.
Installing and Administering sendmail Creating sendmail Aliases Configuring Owners for Mailing Lists Because the sender of a message often does not control the mailing list to which the message is addressed, sendmail allows you to configure an owner for a mailing list. If sendmail encounters an error while attempting to deliver a message to the members of a mailing list, it looks for an alias of the form owner-mailing_list and sends the error message to the owner.
Installing and Administering sendmail Creating sendmail Aliases Creating a Postmaster Alias RFC 822 requires that a “postmaster” alias be defined on every host. The postmaster is the person in charge of handling problems with the mail system on that host. The default aliases file supplied with HP-UX defines the postmaster to be root. You can change this alias to the appropriate user for your system.
Installing and Administering sendmail Creating sendmail Aliases Modifying Your NIS Aliases Database For information about the NIS or NIS+ aliases database, see Installing and Administering NFS Services. Rewriting the “From” Line on Outgoing Mail HP provides a method that allows the “From” line on mail to be rewritten. This can be useful where a user’s login name does not clearly identify the user to intended mail recipients.
Installing and Administering sendmail Creating sendmail Aliases Forwarding Your Own Mail with a .forward File You can redirect your own mail by creating a .forward file in your home directory. If a .forward file exists in your home directory and is owned by you, sendmail will redirect mail addressed to you to the addresses in the .forward file. A .forward file can contain anything that can appear on the right side of an alias definition, including programs and files. (See Table 4-1 earlier in this chapter.
Installing and Administering sendmail How sendmail Works How sendmail Works sendmail acts as a post office to which all messages can be submitted for routing. sendmail can interpret both Internet-style addressing (that is, user@domain) and UUCP-style addressing (that is, host!user). How addresses are interpreted is controlled by the sendmail configuration file. sendmail can rewrite message addresses to conform to standards on many common target networks.
Installing and Administering sendmail How sendmail Works How sendmail Collects Messages sendmail can receive messages from any of the following: • A user agent that calls sendmail to route a piece of mail. User agents that are supported by HP for use with HP-UX 11.0 sendmail include elm, mail, mailx, and rmail. • A sendmail daemon or other mail program that calls sendmail to route a piece of mail received from the network or the mail queue. • A user that calls sendmail directly from the command line.
Installing and Administering sendmail How sendmail Works Figure 4-1 Flow of Mail Through sendmail User mailx rmail elm ... User Agents Local Host sendmail OpenMail Delivery Agent X.400 Delivery Agent SMTP Delivery Agent OpenMail or X.25 Network X.400 Network Local Area Network OpenMail Receiving Agent X.
Installing and Administering sendmail How sendmail Works The aliasing facility or a user’s .forward file may be used to route mail to programs and to files. (sendmail does not mail directly to programs or files.) Mail to programs is normally piped to the prog mailer (/usr/bin/sh -c), which executes the command specified in the alias or .forward file definition. (You can restrict the programs that can be run through the aliases or .forward files. See “Security” on page 151 for more information.
Installing and Administering sendmail How sendmail Works If your host has a direct UUCP connection to the next host in the path, the mail is delivered to that host through UUCP. If not, the message is returned with an error. The supplied configuration file provides detailed instructions for arranging to relay such mail through hosts to which you can connect. SMTP Addresses.
Installing and Administering sendmail How sendmail Works temporarily down or otherwise inaccessible. For information on creating MX records, see “Configuring and Administering the BIND Name Service” on page 59. MX records are used only if a message address resolves to an IPC mailer (that is, one that uses SMTP over sockets to perform delivery.) Instead of attempting to connect directly to the recipient host, sendmail first queries the name server, if it is running, for MX records for that host.
Installing and Administering sendmail How sendmail Works ;name ttl bling class MX preference mail exchanger IN IN IN MX MX MX 0 20 30 bling.paf.edu. wheo.paf.edu. munch.pag.edu. Ordinarily, mail for bling will go directly to bling. However, if bling is down, or if the sending host cannot connect to bling, sendmail will route mail for it to wheo. If wheo is also down or unreachable, sendmail will route the mail to munch.
Installing and Administering sendmail How sendmail Works temporary failures, but the attempt to connect to munch fails permanently, the message will be returned as an error. If the attempts to connect to bling and wheo result in permanent failures, but the attempt to connect to munch fails temporarily, the message will be queued. • A host cannot deliver a message to another host for which it is a mail exchanger.
Installing and Administering sendmail How sendmail Works Figure 4-2 sendmail Client-Server Operation company.com Domain mailserv Incoming remote mail to user1@mailserv.company.com Incoming remote mail for user1@mailclient Local mail to/from mailclient users mailclient Internet Outgoing remote mail from user1@mailserv.company.com user1 Outgoing mail from user1 can be “local” mail that is intended for any user on mailclient.
Installing and Administering sendmail How sendmail Works also modify the /etc/mail/sendmail.cf file so that the clients relay all outbound mail to the server; this is described in “Modifying the Default sendmail Configuration File” on page 147. How sendmail Handles Errors By default sendmail immediately reports to standard output any errors that occur during the routing or delivery of a message. sendmail distinguishes between “temporary failures” and “permanent failures.
Installing and Administering sendmail How sendmail Works If sendmail tries all MX hosts in its preference list and fails to deliver a message, the message is returned to the sender with an error message. For more information, see “MX Records” on page 139. If delivery failed on an alias, and an owner is configured for that alias in the aliases database, sendmail returns the message and transcript to the alias owner.
Installing and Administering sendmail How sendmail Works When processing the queue, sendmail first creates and sorts a list of the messages in the queue. sendmail reads the queue control file for each message to collect the pre-processed envelope information, the header lines, and the name of the data file containing the message body. sendmail then processes the message just as it did when it was originally collected.
Installing and Administering sendmail Modifying the Default sendmail Configuration File Modifying the Default sendmail Configuration File The sendmail configuration file that is supplied with HP-UX will work correctly for most sendmail configurations, so you probably do not need to modify it. However, certain modifications to the file are supported. This section describes examples of modifications that you may want to make.
Installing and Administering sendmail Modifying the Default sendmail Configuration File • Defines the delivery agents (mailers) to be used for delivering the mail. • Specifies how sendmail should rewrite addresses in the header, if necessary, so that the message address can be understood by the receiving host. The address rewriting process is controlled by sets of address rewriting rules called “rulesets.
Installing and Administering sendmail Migrating the sendmail Configuration File Migrating the sendmail Configuration File Beginning with the earlier HP-UX 10.20 release, the format of the sendmail configuration file /etc/mail/sendmail.cf changed from the version 1 format to the version 6 format. You cannot use a pre-10.20 version (that is, version 1) of the sendmail configuration file with the sendmail included with HP-UX 10.20 and later.
Installing and Administering sendmail Migrating the sendmail Configuration File reason, you should use convert_awk only if your old (pre-version 6) sendmail configuration file contains many site-specific rulesets that are not easily redefined in the version 6 sendmail.cf format.
Installing and Administering sendmail Security Security sendmail on HP-UX 10.30 and later allows the aliases file or a user’s .forward file to specify programs to be run. These programs are by default invoked through /usr/bin/sh -c. The sendmail restricted shell (smrsh) program allows you to restrict the programs that can be run through the aliases file or through a .forward file; only programs that are linked to the /var/adm/sm.bin directory can be invoked. To use the smrsh program: 1.
Installing and Administering sendmail Troubleshooting sendmail Troubleshooting sendmail This section describes the following techniques for troubleshooting sendmail: • “Keeping the Aliases Database Up to Date” on page 152 • “Verifying Address Resolution and Aliasing” on page 153 • “Verifying Message Delivery” on page 153 • “Contacting the sendmail Daemon to Verify Connectivity” on page 154 • “Setting Your Domain Name” on page 155 • “Attempting to Start Multiple sendmail Daemons” on page 155 • “Configuring
Installing and Administering sendmail Troubleshooting sendmail Verifying Address Resolution and Aliasing In order to deliver a message, sendmail must first resolve the recipient addresses appropriately. To determine how sendmail would route mail to a particular address, issue the following command: /usr/sbin/sendmail -bv -v -oL10 address [address...] The -bv (verify mode) option causes sendmail to verify addresses without collecting or sending a message.
Installing and Administering sendmail Troubleshooting sendmail This is only a test. . sendmail responds with the following information: myname@cup.hp.com... Connecting to local host (local)... myname@cup.hp.com... Executing "/bin/rmail -d myname" myname@cup.hp.com... Sent sendmail has interfaces to three types of delivery agents.
Installing and Administering sendmail Troubleshooting sendmail telnet furschlugginer 25 220 furschlugginer.bftxp.edu SMTP server ready vrfy aen 250 Alfred E. Newman vrfy blemph@morb.poot 554 blemph@morb.poot: unable to route to domain morb.poot quit 221 furschlugginer.bftxp.edu SMTP server shutting down Not all SMTP servers support the VRFY and EXPN commands.
Installing and Administering sendmail Troubleshooting sendmail Configuring and Reading the sendmail Log sendmail logs its mail messages through the syslogd logging facility. The syslogd configuration should write mail logging to the file /var/adm/syslog/mail.log. You can do this by adding the following line in /etc/syslog.conf: mail.debug /var/adm/syslog/mail.
Installing and Administering sendmail Troubleshooting sendmail 6 Unusual but benign incidents, such as trying to process a locked queue file. 9 Log internal queue ID to external message ID mappings. This can be useful for tracing a message as it travels between several hosts. 10 The name of the mailer used, the host (if non-local), and the user name passed to the mailer are logged. If the log level is 10 or higher, sendmail also reports this information in -bv (verify) mode.
Installing and Administering sendmail Troubleshooting sendmail to= The recipient of the message. One message may have multiple recipients. sendmail logs a separate entry for each separate delivery attempt it makes, so multiple recipients on the same host may appear on the same line, but multiple recipients on different hosts will appear on different lines. The delivery status of the message (whether message succeeded, failed, or was queued), the mailer, and the host used are logged.
Installing and Administering sendmail Troubleshooting sendmail Mail Queue (3 requests) ---QID--- --Size-- ----Q-Time---- ----Sender/Recipient----- AA15841 86 Wed Feb 9 07:08 janet (Deferred: Connection refused by med.hub.com) ees@vetmed.umd.edu ebs@surv.ob.com AA15794 1482 Wed Feb 9 07:57 carole bja@edp.cloq.potlatch.com vls@ee.cmu.edu AA15792 10169 Wed Feb 9 07:57 chuck hrm@per.stmarys.com sys6!sysloc!njm vls@ce.umd.
Installing and Administering sendmail Troubleshooting sendmail the same process ID. sendmail starts with TAA and loops through TAB, TAC, and so on, until it is able to form a unique ID. The five-digit number (nnnnn) is the process ID of the process creating the queue entry. A file whose name begins with df is a data file. The message body, excluding the header, is kept in this file. A file whose name begins with qf is a queue-control file, which contains the information necessary to process the job.
Installing and Administering sendmail Troubleshooting sendmail Initial Letter Content of Line M A message. This line is printed by the mailq command and is generally used to store status information (that is, the reason the message was queued). It can contain any text. R A recipient address. Normally this has already been completely aliased, but it is actually re-aliased when the queue is processed. There is one line for each recipient. S The sender address.
Installing and Administering sendmail Troubleshooting sendmail 162 Chapter 4
5 Configuring TFTP and BOOTP Servers The Trivial File Transfer Protocol (TFTP) is a simple protocol used to read and write files to or from a remote system.
Configuring TFTP and BOOTP Servers The Bootstrap Protocol (BOOTP) allows certain systems to discover network configuration information (such as an IP address and a subnet mask) and boot information automatically. Together, TFTP and BOOTP allow a system to provide boot information for client systems that support BOOTP, such as HP’s 700/X terminal. These protocols are implemented on top of the Internet User Datagram Protocol (UDP), so they can be used across networks that support UDP.
Configuring TFTP and BOOTP Servers Chapter Overview Chapter Overview The topics covered in this chapter include the following: • “How BOOTP Works” on page 166 • “Booting RMP Clients” on page 169 • “Configuring the TFTP Server” on page 171 • “Configuring the BOOTP Server” on page 174 • “Adding Client or Relay Information” on page 176 • “Command Options for Using TFTP” on page 184 • “Troubleshooting BOOTP and TFTP Servers” on page 185 Chapter 5 165
Configuring TFTP and BOOTP Servers How BOOTP Works How BOOTP Works The Bootstrap Protocol (BOOTP) allows a client system to discover its own IP address, the address of a BOOTP server, and the name of a file to be loaded into memory and executed. The bootstrap operation happens in two phases. In the first phase, address determination and bootfile selection occur. This phase uses the BOOTP server, bootpd.
Configuring TFTP and BOOTP Servers How BOOTP Works 2. The client broadcasts the bootrequest packet on its first LAN interface (lan0). The bootrequest also contains the client’s hardware address, and, if known, its IP address. 3. The BOOTP server checks to see if boot information for the client is in its database. If boot information for the client is available in the server’s database, the server answers the bootrequest with a bootreply packet. 4.
Configuring TFTP and BOOTP Servers How BOOTP Works Figure 5-1 shows an example of a bootrequest that is relayed from server A to server B to server C. Server C finds the client’s boot information in its database, and sends the bootreply back to server A. Server A then sends the bootreply to the client.
Configuring TFTP and BOOTP Servers Booting RMP Clients Booting RMP Clients Remote Maintenance Protocol (RMP) is an HP-proprietary boot and file transfer protocol used in early Series 700 workstations and in the Datacommunications and Terminal Controllers (DTC/9000). The rbootd daemon allows BOOTP servers to serve clients that use RMP. rbootd must be run on a BOOTP server on the same subnet as the RMP client. That is, both rbootd and bootpd must run on the same system.
Configuring TFTP and BOOTP Servers Booting RMP Clients its local system. rbootd uses either NFS or TFTP to transfer boot files from the remote server to its local system. (TFTP is the default file transfer method.) rbootd then transfers bootable images to the client in the form of RMP packets. If TFTP is used to transfer boot files from a remote server, the boot files must be accessible via TFTP. For more information, see “Configuring the TFTP Server” on page 171.
Configuring TFTP and BOOTP Servers Configuring the TFTP Server Configuring the TFTP Server To manually configure the TFTP server, tftpd, you need to modify the tftpd entry in the /etc/inetd.conf file or create an entry for the user tftp in the /etc/passwd file. If you use SAM to configure your system as a BOOTP server, your system is automatically configured as a TFTP server. The following sections explain the manual method for configuring and verifying tftpd.
Configuring TFTP and BOOTP Servers Configuring the TFTP Server $ $ $ $ mkdir chown chgrp chmod /home/tftpdir$ tftp /home/tftpdir guest /home/tftpdir 700 /home/tftpdir • Specify the files available to clients in the tftpd command line in /etc/inetd.conf: tftpd dgram udp wait root /usr/lbin/tftpd tftpd [path...] [path...] is a list of the files or directories that you want to make available to TFTP clients. File or directory names are separated by spaces.
Configuring TFTP and BOOTP Servers Configuring the TFTP Server 3. Compare the ASCII files to verify data transfer: $ diff testfile /export/testfile $ 4. Remove the test file once you have verified the installation.
Configuring TFTP and BOOTP Servers Configuring the BOOTP Server Configuring the BOOTP Server To manually configure the BOOTP server daemon, bootpd, you need to add entries to the files /etc/services and /etc/inetd.conf. When you use SAM to do the configuration, entries are made to the appropriate files automatically. The following sections explain the manual method for configuring and verifying bootpd. NOTE You must be superuser to configure the BOOTP server.
Configuring TFTP and BOOTP Servers Configuring the BOOTP Server 1. On the host where you configured bootpd, use bootpquery to send a boot request to the server. (Type man 1M bootpquery for more information.) For example, if you configured bootpd on a system named myhost, enter: /usr/sbin/bootpquery 001122334455 -s myhost A bootrequest is sent to the server, requesting a bootreply for the client with hardware address 001122334455.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information Adding Client or Relay Information To allow a client to boot from your local system or to allow a bootrequest to be relayed to the appropriate boot server, you must add information about the client in your /etc/bootptab file. bootpd uses the /etc/bootptab file as the database for two types of entries: • Client entries that contain information that allows the clients to boot from your system.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information • Subnet mask—the mask that is used to identify the network address where the client resides. • Gateway address—the address of the gateway that connects the client’s local subnet to the BOOTP server’s subnet. • Boot server(s) for client—the boot servers to which the local system will relay the client’s bootrequest. • Threshold value—the number of seconds since the client sent its first request.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information • The ht (hardware type) tag, if specified, must precede the ha (hardware address) and hm (hardware mask) tags. • If the gw (gateway IP address) tag is specified, the sm (subnet mask) tag must also be specified. Other points to know when adding an entry in /etc/bootptab include the following: • IP addresses listed for a single tag must be separated by a space.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information ht Client’s hardware type. May be assigned the value ieee or ether. If used, this tag must precede the ha tag. ip BOOTP client’s IP address. This tag takes only one IP address. This tag distinguishes a boot entry from a relay entry. sm The subnet mask for the client’s network. tc Specifies previously-listed entry that contains tag values that are shared by several client entries.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information A relay entry can contain relay parameters for an individual system or for a group of systems. If a BOOTP client does not have an individual entry in the BOOTP server’s /etc/bootptab file, the group relay entries are searched. The first group relay entry that matches the BOOTP client is used. Examples of Adding BOOTP Clients This section shows examples of adding entries to the /etc/bootptab file.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information xterm01: hn: ht=ether: ha=080009030165: \ ip=15.19.8.37: sm=255.255.248.0: \ gw=15.19.8.1: ds=15.19.8.119: bf=/xterminal: ba 2. Run the bootpquery tool to see how bootpd on your local system responds to a request from xterm01. For the example configuration, the following would be entered (as superuser): /usr/sbin/bootpquery 080009030165 -s hpserver The following output is displayed: Received BOOTREPLY from hpserver.hp.com (15.19.8.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information Figure 5-4 Example Configuration: Relay Entry BOOTP Server B (HP Only) BOOTP Server C (Others) IP address: 15.4.3.142 IP address: 15.4.3.136 IP address: 15.4.3.138 BOOTP Server A IP address: 15.4.8.1 Client Host name: xterm02 IP address: 15.19.8.
Configuring TFTP and BOOTP Servers Adding Client or Relay Information The gateway address (gw=15.19.8.1) is passed back to the client in the bootreply and allows the client to send a TFTP request to the BOOTP server to get its boot file. To verify the new /etc/bootptab entry, do the following: 1. Add the ba (broadcast address) tag to the xterm02 entry on the BOOTP server that contains the client’s boot entry (server B) so that the bootreply is not sent directly to xterm02.
Configuring TFTP and BOOTP Servers Command Options for Using TFTP Command Options for Using TFTP Internet Services includes a TFTP client implementation, /usr/bin/tftp. You can use this client to verify that your TFTP server is working correctly. For example, to retrieve the file bootf from the TFTP server duncan, enter the following: /usr/bin/tftp duncan At the tftp prompt, enter: get bootf Table 5-3 describes the most common tftp commands you can use when transferring files.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers Troubleshooting BOOTP and TFTP Servers This section outlines techniques that can help you diagnose and correct common problems with the BOOTP and TFTP servers. Helpful Configuration Changes To make troubleshooting easier, configure your system as follows: • Ensure syslogd is configured to log daemon information messages to the file /var/adm/syslog/syslog.log. To check this configuration, make sure /etc/syslog.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers To view the information that bootpd places in the bootreply, enable a broadcast bootreply by adding the ba tap to the client’s /etc/bootptab entry. Use the bootpquery command to emulate the client’s bootrequest: bootpquery client_link_address -s servername bootpquery prints the reply it receives from the server, which allows you to examine the information supplied to the client.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers Action: ❏ Check the system log for any indication of syntax errors for the client’s configuration entry. Correct the entry in /etc/bootptab and reboot the BOOTP client. ❏ Ensure that the hardware address you specified for the ha tag matches the hardware address that /usr/lbin/bootpd said it could not find. Correct the tag and reboot the BOOTP client. ❏ Ensure the hardware type tag ht has the correct value for the client.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers ❏ Ensure the IP address you have chosen for the client is a valid IP address for the server’s network.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers to = time_offset Tnnn = generic_information Cause: Too many RFC-1048 options have been specified for the client’s configuration entry in /etc/bootptab. The BOOTP protocol allows only 64 bytes of “vendor extension” information.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers If the server still fails to start when the client attempts the file transfer, then you probably have a connectivity problem. Refer to Installing and Administering LAN/9000 Software or the BOOTP client manual (for example, HP 700/X documentation). Symptom: File transfer “timed out.” The system log contains one of the following messages: User tftp unknown system_call: error Cause: The TFTP server, tftpd, exited prematurely.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers Symptom: File transfer fails with Access Violation, Permission Denied, or TFTP Error Code 2 message. Cause: tftpd does not have permission to read the file. Action: If the transfer is a get operation where the client is attempting to read the file from the server, then the server does not have read permissions on the file that it is trying to send. Ensure that the file the client is reading has read permissions for the user tftp.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers If bootpd hasn’t received a bootrequest within time minutes (the timeout set with the -t option), it issues this message and exits. • reading configuration_file reading new configuration_file bootpd is reading or rereading configuration information from the indicated configuration_file.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers Notice Log Level There may be cases where bootpd receives a bootrequest but does not send a bootreply. The reason is given in one of the following messages and logged at the notice log level: • hardware address not found: hardware_address bootpd could not find a configuration entry for the client with the indicated hardware_address.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers The value for the hardware address mask tag hm was incorrectly formatted in the configuration file entry for hostname. Correct the configuration entry and try to reboot the BOOTP client. The subnet mask must be specified in hex. • bad hardware type for host hostname The value specified for the ht tag is an unsupported hardware type. See the bootpd man page for a list of supported hardware types.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers • bad vendor magic cookie for host hostname The vendor magic cookie, specified with the vm tag, was incorrectly formatted. Correct the configuration entry and try to reboot the BOOTP client. The vm tag can be one of the following values: auto, rfc1048, or cmu. • can't find tc=label bootpd could not find a table continuation configuration entry with the host field label.
Configuring TFTP and BOOTP Servers Troubleshooting BOOTP and TFTP Servers 196 Chapter 5
6 DHCP 197
DHCP DHCP (Dynamic Host Configuration Protocol) provides advanced IP address allocation and management for TCP/IP LAN computing environments. By automating IP address allocation, the server provides a level of automation not provided with the BOOTP client-server bootstrap protocol. DHCP also supports more configuration options than BOOTP. DHCP clients can include TCP/IP network printers, X terminals, and Microsoft Windows machines.
DHCP Configuration Overview Configuration Overview The DHCP server is configured and administered through SAM (or by editing the files /etc/bootptab and /etc/dhcptab, described later).
DHCP Configuration Overview DHCP allows you to exclude certain addresses within a group if you wish to make them unavailable for assignment. You also have the capability to define many values for the devices of a group including address lease times, DNS servers, NIS servers, and many other optional parameters. For detailed configuration information, refer to the on-line help that is provided with the DHCP graphical user interface.
DHCP Configuration Overview Devices Booting From Remote Servers The third method of DHCP clients receiving IP addresses is through the use of what is called a BOOTP Relay Agent. A BOOTP Relay Agent is a machine on the local network which forwards boot requests from a DHCP or BOOTP client to a configured DHCP or BOOTP server. Figure 6-3 Relay Agent Scenario Server Client 1 Gateway Client 2 Relay Agent In the drawing, suppose that Client2 broadcasts a boot request.
DHCP Configuration Overview For more detailed configuration information, refer to the on-line help that is provided with the DHCP graphical user interface.
DHCP Configuration Files Configuration Files Two configuration files, bootptab and dhcptab, are used for your DHCP configuration. These files are written to when you perform configuration through SAM. You can also manually edit these files if desired, although most of your work will probably be performed using SAM. The bootptab file contains configuration information for old BOOTP clients as well as DHCP clients with fixed IP addresses. The bootptab file also contains configuration for relay agents.
DHCP Configuration Files DHCP is backwards compatible with BOOTP, so no changes are required of existing users of BOOTP.
DHCP Tools Tools The command-line tool known as dhcptools(1M) is available to provide access to DHCP-related options for the bootpd server. The options provide control for dumping internal data structures, generating a host’s file, previewing client address assignment, reclaiming unused addresses, tracing packets, and validating configuration files. Refer to the dhcptools(1M) man page for detailed information about the various options.
DHCP Getting Started Information Getting Started Information Before startup, you must set the broadcast address for the lan0 interface name to 255.255.255.255. You can do this either manually or through SAM. To manually adjust the address, do the following: 1. Issue the command ifconfig lan0 broadcast 255.255.255.255. 2. Issue the command /etc/rc.config.d/netconf. 3. Edit the BROADCAST_ADDRESS variable for lan0 to 255.255.255.255. To change the address through SAM, do the following: 1.
7 Configuring NTP 207
Configuring NTP This chapter contains information about how to configure and use xntpd. xntpd is a daemon that maintains the local clock on an HP-UX workstation in agreement with Internet-standard time servers. xntpd is an implementation of the Network Time Protocol (NTP) version 3 standard, as defined in RFC 1305.
Configuring NTP Overview Overview Many internetwork services and applications depend upon the system clocks of the networked systems being synchronized with each other. For example, network management systems need to be able to determine the order in which events in an internetwork occur. Without clock synchronization, the timestamps of networked or distributed file systems (such as NFS, AFS, or DFS) may not reflect the actual time at which a file was created.
Configuring NTP Overview change due to server or network path availability, the stratum level of your server can also change. The maximum stratum level that a server can assume is 15. Figure 7-1 depicts the organization of time servers into strata. The arrows show the direction of time synchronization.
Configuring NTP Overview Time Server Roles An NTP time server can assume different roles in its relationships with other time servers in the synchronization subnet. A time server can assume one or more of the following roles: • Server—The local host provides time to clients when requested. This role can be assumed by time servers at various strata. The server role is illustrated in Figure 7-2.
Configuring NTP Overview • Broadcaster—The local host provides time to the specified remote host, or more typically, the broadcast address on a LAN. This role is most appropriate for an NTP time server that provides time to workstation clients on a LAN. The broadcaster role is illustrated in Figure 7-5. Figure 7-5 Local Host as Broadcaster Time Local Host Remote Host • Broadcast Client—The local host listens for and synchronizes to broadcast time.
Configuring NTP Overview Figure 7-7 Example of Relationships Between Time Servers Stratum 1 Gordo Bonita (server) (server) (client) (client) Stratum 2 (peer) (peer) Penelope (broadcaster) Stratum 3 Golden (broadcaster) Hugo (broadcast client) In Figure 7-7, Gordo and Bonita are stratum-1 servers. Because they are stratum-1 servers, they receive time from external clocks or use their local system clocks as time sources for NTP.
Configuring NTP Configuration Configuration This section covers the following topics: • Overview of the xntpd configuration file and the steps needed to configure xntpd. • Guidelines for configuring a synchronization subnet. • Descriptions of how to configure various characteristics of xntpd in the /etc/ntp.conf file. Configuration Overview When xntpd starts, it reads a configuration file to find out its operating characteristics. The configuration file is called /etc/ntp.conf.
Configuring NTP Configuration Guidelines for Configuration The following are guidelines that you should consider when planning your configuration: • Every NTP hierarchy must have at least one stratum-1 server. You may configure your administrative domain to have outside sources of synchronization which ultimately link to stratum-1 server(s), or you may implement your own hierarchy of NTP time servers with one or more stratum-1 servers.
Configuring NTP Configuration • The outside sources of synchronization should each be in different administrative domains, and should be accessed from different gateways and access paths. Avoid loops and common points of failure. Do not synchronize multiple time servers in an administrative domain to the same outside source, if possible. See Figure 7-8.
Configuring NTP Configuration • Use NTP broadcasting where possible and practical in order to reduce NTP traffic on subnets. Configuration File This section describes the statements that can be defined in the /etc/ntp.conf configuration file.
Configuring NTP Configuration key number specifies that the NTP packets sent to the named host are encrypted using the key that is associated with number. The authentication feature of xntpd must be enabled. See “Configuring Authentication” on page 221. version 1 must be specified if xntpd will be requesting time from a host that is running ntpd, a daemon that is based on version 1 of the NTP protocol.
Configuring NTP Configuration but if the remote server does not meet the criteria for an authenticated synchronization source, it will never be used as a time source by the local host. See “Configuring Authentication” on page 221. NOTE xntpd is an HP implementation of version 3.2 of a publicly-available NTP daemon. HP does not guarantee that xntpd is fully compatible with version 1 or version 2 implementations of the daemon. Configuring External Clocks You can configure xntpd to support an external clock.
Configuring NTP Configuration configured on its client systems. For example, if Penelope is to be a client of Bonita, you configure the name or address of Bonita on Penelope. You do not need to configure Penelope as a client on Bonita. Figure 7-9 Example Configurations Bonita external clock Gordo server 127.127.4.1 external clock server 127.127.4.1 Penelope Golden server bonita peer golden broadcast 193.100.255.255 server gordo peer penelope broadcast 193.100.255.
Configuring NTP Configuration Configuring Authentication Authentication is a mechanism that helps protect against unauthorized access to time servers. Authentication is enabled on a system-by-system basis. Once enabled on a system, authentication applies to all NTP relationships configured on the system. When authentication is enabled on a host, only those time servers that send messages encrypted with a configured key are considered as candidates to which the host would be synchronized.
Configuring NTP Configuration servers that use a specified trusted key for encryption, and whose authenticity is verified by successful decryption, are considered synchronization candidates. Figure 7-10 illustrates how authentication works. Figure 7-10 Authentication Example NTP Packet Golden + Key Num. (10) + authenticate yes authenticate yes Encrypted keys /etc/ntp.keys server golden key 10 Checksum server 127.127.1.1 keys /etc/ntp.keys Penelope trustedkey 10 /etc/ntp.
Configuring NTP Configuration authdelay seconds indicates the amount of time (in seconds) needed to encrypt an NTP authentication field on the local host. The seconds value is used to correct transmit timestamps for authenticated outgoing packets. The value depends upon the CPU speed of the local host. CAUTION The startup script automatically calculates the proper value for authdelay for the local system and writes it into the configuration file /etc/ntp.conf. Do not modify this value.
Configuring NTP Configuration Table 7-1 Restrict Option Flags Flag Effect ignore Ignore all packets. noquery Ignore ntpq queries. nomodify Ignore ntpq packets that attempt to modify the state of the server. noserve Ignore requests for time, but permit ntpq queries. nopeer Provide time service, but do not form peer association. notrust Do not use the host as a synchronization source. A restriction list entry with no flags set leaves matching hosts unrestricted.
Configuring NTP Configuration #local host address is unrestricted restrict 193.100.100.
Configuring NTP Starting xntpd Starting xntpd To start xntpd, do one of the following: • Set the environment variable XNTPD to 1 in the file /etc/rc.config.d/netdaemons. This causes xntpd to start automatically whenever the system is booted. • Issue the following command to run the xntpd startup script: /sbin/init.d/xntpd start Command line arguments for starting xntpd may be specified with the XNTPD_ARGS environment variable in the file /etc/rc.config.d/netdaemons.
Configuring NTP Stopping xntpd Stopping xntpd NOTE xntpd should be operated on a continuous basis. If it is necessary to stop xntpd, the interval when it is not running should be kept to a minimum. If you modify the configuration file or the XNTPD_ARGS environment variable in the file /etc/rc.config.d/netdaemons while xntpd is running, you have to stop and restart the daemon in order for the configuration changes to take effect. To stop xntpd, issue the following command: /sbin/init.
Configuring NTP Querying xntpd Querying xntpd ntpq is a program used to query systems that are running xntpd about the current state of the server. It can also be used to obtain a list of a server’s peers. ntpq sends requests to and receives responses from NTP time servers using a special form of NTP messages called mode-6 control messages. The program can be run either interactively or from a command line. See the ntpq man page for details about using this program.
Configuring NTP Querying xntpd synchronization source. A ‘-’ indicates a host that was not considered for synchronization, while a ‘+’ indicates a host that was considered for synchronization. The refid column shows the current source of synchronization for the remote host. ‘.WWVB.’ indicates that the host uses a radio clock that receives time signals from the U.S. government radio station WWVB. The st column shows the stratum level of the remote host.
Configuring NTP Troubleshooting ntp Troubleshooting ntp If ntp is not operating properly, use this section to identify and correct the problem. To Find Out if xntpd is Running Issue the following command to find out if xntpd is running: /usr/bin/ps -ef | /usr/bin/grep xntpd This command reports the process identification (PID), current time, and the command invoked (xntpd).
Configuring NTP Troubleshooting ntp Figure 7-12 ntpg Output Showing NTP Associations remote refid st when poll reach delay offset disp ======================================================================= *good.cup.hp LOCAL(1) 2 29 64 377 5.43 -0.16 16.40 bad 0.0.0.
Configuring NTP Troubleshooting ntp Problem 1: No suitable server for synchronization found. Every NTP time hierarchy must have at least one stratum-1 server, with an external time source configured, either an attached radio clock (Netclock/2 WWVB Synchronized Clock) or the local system clock. If there is no stratum-1 server in the hierarchy, no associations will be formed.
Configuring NTP Troubleshooting ntp For external clocks, xntpd will not form a complete association until it has sent five successful polls to itself using the local loopback address. Problem 2: Version 1 and 2 NTP Servers Do Not Respond NTP version 3 packets (HP-UX 10.0 NTP is version 3) are ignored by NTP version 1 and version 2 systems. The solution is to indicate the version 1 and 2 systems in the configuration entries on the version 3 systems.
Configuring NTP Troubleshooting ntp 234 Chapter 7
8 Configuring gated gated (pronounced “gate D”) is a routing daemon that handles multiple routing protocols. The gated daemon can be configured to perform all or any combination of the supported protocols.
Configuring gated Beginning with HP-UX 10.30, gated 3.0 was replaced by gated 3.5. This chapter contains information about how to configure and use version 3.5 of gated.
Configuring gated Overview Overview A router is a device that has multiple network interfaces and transfers Internet Protocol (IP) packets from one network or subnet to another within an internetwork. (In many IP-related documents, this device is also referred to as a “gateway.” The term “router” is used in this chapter.) The gated daemon updates routing tables in internetwork routers.
Configuring gated Overview • gated translates among several protocols, passing information within or between IP routing domains or autonomous systems. “Autonomous system” is used here to refer to a group of connected nodes and routers in the same administrative domain that are exchanging routing information via a common routing protocol. • gated gives the system administrator flexibility in setting up and controlling network routing.
Configuring gated Overview organizations that wish to connect to the Internet and form an AS must obtain a unique AS number from the Internet Assigned Numbers Authority. An interior gateway protocol is used to distribute routing information within the autonomous system. An exterior gateway protocol is used to distribute general routing information about an autonomous system to other autonomous systems.
Configuring gated Overview NOTE Do not mix RIP and OSPF protocols within a single network, because the routing information might conflict. Table 8-1 compares the advantages and disadvantages of the RIP and OSPF protocols. Table 8-1 Comparison of RIP and OSPF Protocols RIP OSPF Advantage: RIP is easy to configure. Disadvantage: OSPF is complicated to configure and requires network design and planning.
Configuring gated Overview • EGP (External Gateway Protocol) is known as a “reachability” protocol primarily because it permits a node on the NSFNET backbone to exchange information with other backbone nodes about whether a destination can be reached. Use EGP to communicate routing information between autonomous systems. • BGP (Border Gateway Protocol) is intended as a replacement for EGP. BGP uses path attributes to select routes.
Configuring gated Configuration Overview Configuration Overview When gated starts, it reads a configuration file to find out how each protocol should be used to manage routing. By default, it uses the configuration file called /etc/gated.conf. Creating the configuration file is usually the responsibility of the system administrator. The configuration file may include up to eight sections (called classes) of configuration statements. Statements can be further defined with optional clauses.
Configuring gated Configuration Overview NOTE If you do not want to use any of the gated 3.5 features added at HP-UX 10.30, and do not have any tracing configured in your gated 3.0 /etc/gated.conf configuration file, you can continue to use your 3.0 configuration file with gated 3.5. If you do have tracing configured in your gated 3.0 file, you must run the conv_config conversion tool on the file so that it follows the 3.5 syntax (see “Converting the Configuration File from 3.0 to 3.5” on page 245).
Configuring gated Configuration Overview 3. Add statements as needed for any additional configuration information. See “Customizing Routes” on page 285, “Specifying Tracing Options” on page 287, and “Specifying Route Preference” on page 289 for other configuration options. In particular, you may want to prevent gated from deleting interfaces from the routing table if gated receives no routing protocol information from that interface.
Configuring gated Configuration Overview 7. To start gated, reboot your system or run the gated startup script with the following command: /sbin/init.d/gated start Examples of gated configuration files are included in the sections “Configuring the OSPF Protocol” on page 256 and “Configuring the RIP Protocol” on page 247. They are also included in the /usr/newconfig/gated/conf directory. NOTE It is best to use IP addresses in dot notation (for example, a.b.c.
Configuring gated Configuration Overview conv_config < /etc/gated.conf.30 > /etc/gated.conf When the conversion tool has finished running, you might want to check the new file for compatibility, by using the gated -c command (see the Note under “Configuration Overview” on page 242).
Configuring gated Configuring the RIP Protocol Configuring the RIP Protocol RIP uses hopcount to determine the shortest path to a destination. Hopcount is the number of routers a packet must pass through to reach its destination. If a path is directly connected, it has the lowest hopcount of 1. If the path passes through a single router, the hopcount increases to 2. Hopcount can increase to a maximum value of 16, which is RIP’s “infinity metric,” an indication that a network or node cannot be reached.
Configuring gated Configuring the RIP Protocol Figure 8-1 Example of Simple RIP Configuration ... A End systems 121.1.0.10 B ... RIP Routers A: End System on a LAN with RIP Routers Set up /etc/gated.conf as follows: rip yes { interface 121.1.0.10 version 2 multicast; }; static { default interface 121.1.0.10 preference 255 ; }; With one interface, A can listen to RIP traffic on the network but does not forward routing information.
Configuring gated Configuring the RIP Protocol RIP Protocol Statement The syntax for the RIP protocol statement is: rip yes|no | on|off [ { broadcast|nobroadcast ; nocheckzero ; preference preference ; defaultmetric metric ; query authentication [none|[[simple|md5] password]] ; interface interface_list [noripin]|[ripin] [noripout]|[ripout] [metricin metric] [metricout metric] [version 1]|[version 2 [multicast|broadcast]] [[secondary] authentication [none|[simple|md5] password]] ; [interface ...
Configuring gated Configuring the RIP Protocol preference determines the order of routes from other protocols to the same destination in the routing table. gated allows one route to a destination per protocol for each autonomous system. In the case of multiple routes, the route used is determined by the value of preference. Default: 100 Range: 0 (most preferred) - 255 (least preferred) defaultmetric is the default metric used when propagating routes learned from other protocols.
Configuring gated Configuring the RIP Protocol version 1 specifies that RIP version 1 (as defined in RFC 1058) packets are sent; RIP version 2 packets (defined in RFC 1388) are sent only in response to a version 2 poll packet. version 2 specifies that RIP version 2 packets are sent to the RIP multicast address or to the broadcast addresses. You can specify how the packets are sent with the multicast or broadcast clauses.
Configuring gated Configuring the RIP Protocol • The sourcegateways clause tells gated to send RIP information directly to the specified routers. See “RIP Protocol Statement” on page 249 for more information about these clauses. Two options for limiting RIP routing information imported by gated are in the RIP protocol definition in the /etc/gated.conf file: • The noripin clause in the interface definition tells gated not to process RIP information received through the listed interfaces.
Configuring gated Configuring the RIP Protocol Figure 8-2 Example of Large RIP Network (D) Major Router (A) Cluster Node or Isolated Node 134.5.0.1 A 121.1.0.2 130.15.0.5 133.4.0.1 D 130.15.0.0 (network number) B 130.15.0.6 132.5.0.1 121.1.0.92 (B) Root Server 121.1.0.0 (network number) (F) Single Node 121.1.0.10 (C) Single Node (E) Major Router 121.1.0.15 136.5.0.1 C F 136.5.0.0 (network number) 132.6.0.1 E 131.5.0.
Configuring gated Configuring the RIP Protocol B: Cluster (or Root) Server Node Run gated to get routing information about the 121.0.0.0 network. Set up /etc/gated.conf as follows: interfaces { interface 130.15.0.6 121.1.0.92 passive ; }; rip yes { interface 130.15.0.6 noripout ; interface 121.1.0.92 version 2 multicast; }; static { default gateway 121.1.0.2 preference 255 ; }; In this case, setting rip to yes is like setting rip to broadcast.
Configuring gated Configuring the RIP Protocol static { default interface 121.1.0.10 preference 255 ; }; With one interface, C can listen to RIP traffic on the network but does not forward routing information. Routers must be multicasting RIP packets on this network for C to learn about them and update its routing table. D: Major Router Set up /etc/gated.conf as follows: rip yes { interface all version 2 multicast ; }; This runs RIP on all attached networks. E: Major Router Set up /etc/gated.
Configuring gated Configuring the OSPF Protocol Configuring the OSPF Protocol OSPF is a link-state routing protocol designed to distribute routing information between routers in a single autonomous system (AS). Each OSPF router transmits a packet with a description of its local links to all other OSPF routers. The distributed database is built from the collected descriptions.
Configuring gated Configuring the OSPF Protocol Routers that have all their directly-connected networks in the same area are called internal routers. In Figure 8-3, routers A, B, and H are internal routers. Routers that are connected to multiple areas are called area border routers. In Figure 8-3, routers F and G are area border routers. Routers that connect one AS to another are called AS boundary routers. In Figure 8-3, router D is an AS boundary router.
Configuring gated Configuring the OSPF Protocol Table 8-2 Types of Link State Advertisements Type Content Originated By Flooded Throughout Router Link Router’s links to area Internal and area border routers Area Network Link List of routers attached to network Designated Router Area Summary link Routes to destination outside area but within AS Area border router Area AS external link Routes to destinations outside AS AS boundary router AS AS boundary routers exchange routing informatio
Configuring gated Configuring the OSPF Protocol 1. If your AS will be exchanging routing information with other autonomous systems, you need to obtain a unique AS number from the Internet Assigned Numbers Authority. 2. Partition the AS into areas. Any inter-connected networks can be partitioned into lists of address ranges, with each address range represented as an address-mask pair. The area border routers will summarize the area contents for each address range and distribute the summaries to the backbone.
Configuring gated Configuring the OSPF Protocol Enabling OSPF The default router identifier used by OSPF is the address of the first interface on the router encountered by gated. To set the router identifier to a specific address, specify the routerid interface statement in the Definition class of the /etc/gated.conf file. NOTE The OSPF protocol should be enabled only for routers. Once the OSPF protocol is enabled for a system, the system is treated as a router by other routers, and not a host.
Configuring gated Configuring the OSPF Protocol Figure 8-4 Area Border Router Configuration Example Area 0.0.0.1 Area 0.0.0.2 to Network A Area 193.2.1.33 Border Router 193.2.1.17 to Network B The following is an example of the area definitions in the router’s /etc/gated.conf file: ospf yes { area 0.0.0.1 { interface 193.2.1.33 { ... } ; } ; area 0.0.0.2 { interface 193.2.1.17 { ... } ; } ; } ; There are various other characteristics that you can define for the area and for the interface(s).
Configuring gated Configuring the OSPF Protocol Figure 8-5 shows an example of a router that is connected to area 0.0.0.1 through interface 193.2.1.33. The attached network consists of addresses 193.2.1.33 through 193.2.1.47. The other network in the area consists of addresses 193.2.1.17 through 193.2.1.31. Figure 8-5 Network Configuration Example Area 0.0.0.1 193.2.1.33 Router A 193.2.1.17 193.2.1.34 193.2.1.18 193.2.1.35 193.2.1.19 ... 193.2.1.31 Router B 193.2.1.47 193.2.1.36 ...
Configuring gated Configuring the OSPF Protocol address, name, wildcard name, all.) Multiple interface statements may be specified with different clauses. If a clause is specified more than once, the instance with the most specific interface reference is used. The cost clause can optionally be specified to define a cost of sending a packet on the interface. This cost is advertised as the link cost for this interface. See “Cost” on page 274 for more information about setting interface costs.
Configuring gated Configuring the OSPF Protocol transitdelay is the number of seconds it takes to transmit a Link State Update Packet over this interface. This value must take into account the transmission and propagation delays for the interface. It must be greater than 0. A sample value for a LAN is 1 second. Default: None (you must specify a value) Range: Integer between 1 - 65535 priority should be configured only for interfaces to multi-access networks.
Configuring gated Configuring the OSPF Protocol authkey is the password used to validate protocol packets received on the router interface. The value is one of the following: 1 to 8 decimal digits separated by periods, a 1-byte to 8-byte hexadecimal string preceded by 0x, or a string of 1 to 8 characters in double quotes. Default: None Range: Up to 8 bytes NOTE To set an authkey value, the authtype clause must be set to 1 or simple for the area.
Configuring gated Configuring the OSPF Protocol definition applies to both X.25 network interfaces as well as for systems that do not support IP multicast. An NBMA type interface is defined with the same statements as for a multicast type interface, with the following additions: • The clause nonbroadcast must be specified in the interface statement. • pollinterval specifies a rate at which hellos are sent when a neighboring router becomes inactive.
Configuring gated Configuring the OSPF Protocol Figure 8-7 Non-Broadcast Router Interface Example Router A 193.2.1.35 Router B 193.2.1.33 193.2.1.46 Router C The following is an example of the non-broadcast interface definition in router A’s /etc/gated.conf file: interface 193.2.1.35 nonbroadcast cost 5 { routers { 193.2.1.33 eligible ; 193.2.1.46 eligible ; } ; priority 15 ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; pollinterval 20 ; } ; Point-to-Point Interfaces.
Configuring gated Configuring the OSPF Protocol Default: None (you must specify a value) Range: 0 - 65535 hellointerval specifies the number of seconds between transmission of OSPF Hello packets. Smaller intervals ensure that changes in network topology are detected faster; however, routing traffic can increase. A sample value for an X.25 network is 30 seconds. A sample value for a LAN is 10 seconds.
Configuring gated Configuring the OSPF Protocol packet to the host must also be specified. (In most cases, the host has only a single connection to the network so the cost configured has no effect on routing.) Figure 8-8 shows an example of a router (A) that is connected to a non-broadcast, point-to-point network through interface 193.2.1.1. Figure 8-8 Point-to-Point Router Interface Example Router A 193.2.1.1 193.2.1.
Configuring gated Configuring the OSPF Protocol Figure 8-9 shows an example of an area border router that is connected to area 0.0.0.2 through interface 193.2.1.20. Since all traffic in and out of area 0.0.0.2 must pass through router A, it is not necessary for the area’s internal routers, such as router B, to receive inter-area routing information. Figure 8-9 Area Border Router Configuration Example Area 0.0.0.1 Area 0.0.0.2 193.2.1.16 mask 0xfffffff0 193.2.1.17 Router A Router B 193.2.1.20 193.2.
Configuring gated Configuring the OSPF Protocol Defining Backbones The OSPF backbone distributes routing information between areas. Backbones are defined with the same statements and clauses as areas. The stub statement may not be defined for a backbone. The backbone statement is used to define a router as a backbone router. If an OSPF internal or area boarder router is also a backbone router, the backbone statement must follow the area statement(s) in the /etc/gated.conf file.
Configuring gated Configuring the OSPF Protocol transitdelay 20 ; priority 20 ; hellointerval 30 ; routerdeadinterval 120 ; retransmitinterval 60 ; } ; } ; If the router is directly attached via a point-to-point interface to a host that is not running OSPF, you can prevent OSPF Hello packets from being sent to the host. This is done by specifying the subhost statement with the host’s address. A cost can optionally be defined. NOTE Backbones must be directly-connected or “contiguous”.
Configuring gated Configuring the OSPF Protocol Figure 8-11 Simple Password Authentication A LAN 1 authkey "travis" B LAN 2 authkey "pepe" C The following example shows an authtype statement that enables a simple password authentication for the routers in the area and an authkey statement in the interface definition that defines a password (“travis”) to validate protocol packets received by the router: area 0.0.0.1 { authtype simple ; networks { 193.2.1.16 mask 0xfffffff0 ; 193.2.1.
Configuring gated Configuring the OSPF Protocol Cost The outbound side of each router interface is associated with a configurable cost. Lower cost interfaces are more likely to be used in forwarding data traffic. Cost values are assigned at the discretion of the network or system administrator. While the value is arbitrary, it should be a function of throughput or capacity of the interface: the higher the value, the lower the throughput or capacity.
Configuring gated Configuring the OSPF Protocol The lowest cost OSPF path between nodes A and D is therefore through node B. However, if there were a link failure between node B and LAN 2, packets would be rerouted through node C. There are other places in the /etc/gated.conf file where cost can optionally be defined: • In a defaults statement in the OSPF protocol configuration, which applies only to AS boundary routers. This cost definition applies to routes to destinations outside the AS.
Configuring gated Configuring the OSPF Protocol Externally-defined routing information is kept separately from the OSPF routing information. In addition, the externally-defined routing information can be tagged, where the source of the information is identified and stored along with the route information. Statements in the Control class of the /etc/gated.conf file control the importing of routes from routing protocols to a gated forwarding table and the exporting of routes from the gated forwarding table.
Configuring gated Configuring the OSPF Protocol 2 routes should be routes from external gateway protocols with metrics that are not comparable to OSPF metrics. When OSPF is selecting a route, OSPF will ignore a type 2 route’s metric and use only the OSPF internal cost to the AS border router. Default: 1 • exportlimit specifies the rate that ASE routes are imported into the gated routing table for each exportinterval (see below).
Configuring gated Configuring the OSPF Protocol Figure 8-13 OSPF Sample Configuration Area 1 (Non-Stub) A 193.2.1.35 LAN 1 193.2.1.32 193.2.1.33 B 15.13.115.156 193.2.1.17 LAN 2 193.2.1.16 193.2.1.20 C Area 2 (Stub) A: Internal Router (Non-Stub Area) Set up /etc/gated.conf as follows: # Router A Configuration OSPF yes { area 0.0.0.1 { interface 193.2.1.
Configuring gated Configuring the OSPF Protocol } ; } ; } ; Note that the configuration shown above is for a multicast interface. For an NBMA interface, the configuration in /etc/gated.conf would be set up as follows: # Router A Configuration (non-stub area) OSPF yes { area 0.0.0.1 { interface 193.2.1.35 nonbroadcast cost 5 { routers { 193.2.1.
Configuring gated Configuring the OSPF Protocol backbone { interface 15.13.115.156 cost 5 { enable ; priority 10 ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ; } ; C: Internal Router (Stub Area) Set up /etc/gated.conf as follows: OSPF yes { area 0.0.0.2 { stub cost 5 ; interface 193.2.1.20 cost 5 { priority 5 ; enable ; hellointerval 5 ; routerdeadinterval 20 ; retransmitinterval 10 ; } ; } ; } ; The routing table on node A contains routes to 193.2.1.32 and 193.2.1.16.
Configuring gated Configuring the OSPF Protocol To load the OSPF MIB, select “Load/Unload SNMP:MIBS ...” from the Options Menu of OpenView.
Configuring gated Configuring the Router Discovery Protocol (RDP) Configuring the Router Discovery Protocol (RDP) The Router Discovery Protocol (RDP) is a standard protocol that is used to inform hosts of the presence of routers they can send packets to. RDP is intended to be used in place of hosts wiretapping routing protocols (for example, RIP). It is used instead of, or in addition to, having statically configured default routes in hosts.
Configuring gated Configuring the Router Discovery Protocol (RDP) 255.255.255.255, the advertisements contain all IP addresses configured on the physical interface. If advertisements are being sent to a net or subnet broadcast, only that net’s or subnet’s address is included in the advertisement. An example of the routerdiscovery server statement is shown below. In the example, the server is being enabled on physical interfaces lan0 and lan2, and the IP addresses 193.2.1.17, 193.2.1.33, and 193.2.1.
Configuring gated Configuring the Router Discovery Protocol (RDP) redirects pointing to the invalid addresses. Also, if a Router Advertisement is not received before the addresses it lists become invalid (that is, before its lifetime expires), the routes learned from that router are deleted by the host. An example of the routerdiscovery client statement is shown below. In the example, the client is being enabled on physical interface lan0, and the default routes are to be given a preference of 50.
Configuring gated Customizing Routes Customizing Routes gated maintains a complete routing table in the user space, and keeps the kernel routing table synchronized with that table. This section describes statements for setting up customized routes in the Static class of the gated configuration file, /etc/gated.conf. These statements can be used to specify default routers, static routes, passive interfaces, and routing metrics for interfaces.
Configuring gated Customizing Routes Setting Interface States gated times out routes that pass through interfaces that are not receiving any RIP, HELLO, OSPF, BGP, or EGP packets. The passive clause in the interface statement in the Static class prevents gated from changing the preference of a route to the interface if routing information is not received for the interface. We recommend that you use the passive clause for all interfaces in HP-UX machines.
Configuring gated Specifying Tracing Options Specifying Tracing Options Trace options specify the desired level of tracing output from gated. Tracing output provides useful system information for setting up a node on the network. Use trace options if you are setting up a node and want a certain type of tracing sent to a log file. You can specify tracing in the following ways: • In a Protocol statement in the /etc/gated.conf configuration file. • In the Trace class of the /etc/gated.conf configuration file.
Configuring gated Specifying Tracing Options Option Effect route Traces all routing table changes for routes installed by this protocol or peer. general A combination of normal and route. all Enables all of the above tracing options. Note that some of the above options do not apply to all of the protocols. To see which options are applicable for each protocol and which other trace options are available within the configuration file, type man 4 gated.conf at the HP-UX prompt.
Configuring gated Specifying Route Preference Specifying Route Preference gated maintains a routing table that consists of route information learned from OSPF and from other active routing protocols, such as RIP or EGP. You can also configure static routes in the /etc/gated.conf file with one or more static clauses. (See “Installing Static Routes” on page 285.) The gated routing pool can therefore contain multiple routes to a single destination.
Configuring gated Specifying Route Preference Route Type Preference /etc/gated.config Configuration Static Routes 60 Can be changed in static statement in Static class. HELLO 90 Can be changed with import statement in Control class. RIP 100 Can be changed with import statement in Control class. Point-to-point interface 110 Can be changed with interface statement in Interface class. “Down” interface 120 Can be changed with interface statement in Interface class.
Configuring gated Specifying Route Preference • In a defaults statement in the OSPF protocol configuration. This preference definition specifies the preference value of ASE routes that are imported into OSPF. See “AS External Routes (AS Boundary Routers Only)” on page 275. ASE routes are imported into OSPF with a default preference of 150. • In an import statement in the Control class of the /etc/gated.conf file.
Configuring gated Importing and Exporting Routes Importing and Exporting Routes The import and export control statements allow you to propagate routes from one routing protocol to another. Routes are imported into a gated forwarding table and exported out to the routing protocols. Type man 4 gated.conf for more information on import and export statements. import Statements import statements restrict or control how routes are imported to the gated forwarding table.
Configuring gated Importing and Exporting Routes Examples of import and export Statements The following import statement imports an EGP route for network 195.1.1 to the gated forwarding table with a preference of 15: import proto egp as 1 { 195.1.1 mask 0xffffff00 preference 15 ; } ; The following export statement exports to OSPF the ASE route that was imported to the gated forwarding table in the example above. The route was originally built by EGP and the destination of the route is network 195.1.1.
Configuring gated Starting gated Starting gated 1. Set the environment variable GATED to 1 in the file /etc/rc.config.d/netconf. This causes gated to start automatically whenever the system is booted. 2. Reboot your system, or issue the following command to run the gated startup script: /sbin/init.d/gated start Command line arguments for starting gated may be specified with the GATED_ARGS environment variable in the file /etc/rc.config.d/netconf.
Configuring gated Starting gated /usr/bin/ps -ef | /usr/bin/grep gated This command reports the process identification (PID), current time, and the command invoked (gated).
Configuring gated Troubleshooting gated Troubleshooting gated If gated is not operating properly, use this section to identify and correct the problem. Troubleshooting Tools and Techniques This section describes the available tools for general troubleshooting of gated. Checking for Syntax Errors in the Configuration File After creating or modifying a gated configuration file, you should start gated from the command line with the -C option.
Configuring gated Troubleshooting gated Once tracing is started to a file, the trace file can be rotated. Receipt of a SIGUSR1 signal causes gated to stop tracing and closes the trace file. The trace file can then be moved out of the way. To send a SIGUSR1 signal to gated, issue one of the following commands: /usr/bin/kill -SIGUSR1 pid or /usr/bin/kill -USR1 pid where pid is gated’s process ID, determined by invoking the command ps -ef | grep gated.
Configuring gated Troubleshooting gated ospf_monitor /usr/sbin/ospf_monitor is a support tool that can be used to query OSPF routers for information on OSPF routing tables, interfaces, and neighbors, as well as data on AS external databases, link-state databases, error logs, and input/output statistics. Running the ospf_monitor command displays a prompt that allows you to enter interactive commands. See the ospf_monitor man page for details on using this tool.
Configuring gated Troubleshooting gated trace_on: Tracing to "/tt" started Tracing flags enabled: general parse: conf.tt:4 Interface not found at ’lan3’ parse_parse: 2 parse errors Exit gated[15941] version @(#)Revision: 1.0 based on Cornell GateD R3_5Beta_3 Interface Configuration without strictintfs Option Specified. The following configuration references a non-existent interface, but does not include the strictintfs option.
Configuring gated Troubleshooting gated Broadcast Address: 15.13.119.255 Subnet Number: 15.13.112 lan2 Index 3 Address 802.2 8:0:9:3d:2c:b1 Refcount: 2 Up-down transitions: 0 Subnet Mask: 255.255.248 Change: <> State: <> 198.1.1.17 Metric: 0 MTU: 1436 Refcount: 4 Preference: 0 Down: 120 Change: <> State: Broadcast Address: 198.1.1.255 Subnet Number: 198.1.1 Subnet Mask: 255.255.255 lan1 Index 4 Address 802.
Configuring gated Troubleshooting gated Another common scenario occurs in networks where not all gateways implement the gated routing protocols. In this situation, routes that do not use gated gateways will not be confirmed by gated, and gated will delete them unless a static statement is included in /etc/gated.conf: static { 13.0.0.0 mask 0xff000000 gateway 15.14.14.14 ; }; The static entry in the above example ensures that the local system will include a route to network 13.0.0.
Configuring gated Troubleshooting gated 302 Chapter 8
9 Configuring mrouted mrouted (pronounced “M route D”) is a routing daemon that forwards IP multicast datagrams, within an autonomous network, through routers that support IP multicast addressing.
Configuring mrouted by mrouted is the Distance-Vector Multicast Routing Protocol (DVMRP). The ultimate destination of multicast datagrams are host systems that are members of one or more multicast groups. Multicasting enables one-to-many and many-to-many communication among hosts and is used extensively in networking applications such as audio and video teleconferencing where multiple hosts need to communicate simultaneously. This chapter contains information about how to configure and use version 3.
Configuring mrouted Overview of Multicasting Overview of Multicasting DVMRP mrouted implements the Distance-Vector Multicast Routing Protocol (DVMRP). DVMRP is an Interior Gateway Protocol (IGP) used for routing multicast datagrams within an autonomous network. The primary purpose of DVMRP is to maintain the shortest return paths to the source of the multicast datagrams.
Configuring mrouted Overview of Multicasting packet, is sent through the intervening, non-multicast network to R2. R2 receives the packet and removes the outer IP header, thereby restoring the original multicast packet. R2 then forwards the multicast packet through its network interface to node N.
Configuring mrouted Overview of Multicasting network, all hosts that participate in IP multicast. The addresses of other well-known permanent multicast groups are published in the “Assigned Numbers” RFC (RFC-1060, March 1990). IP multicast addresses can be used only as destination addresses and should never appear in the source address field of a datagram. It should also be noted that ICMP (Internet Control Message Protocol) error messages are not generated for multicast datagrams.
Configuring mrouted Overview of Multicasting IGMP to pass multicast routing information to other mrouted routers as well as to poll the hosts to determine whether the host is still an active group member. IGMP uses IP datagrams to carry information and is a TCP/IP standard that must be present on all systems that participate in IP multicast. While IGMP defines a standard for communicating information, it does not define a standard for how the multicast information is propagated among multicast routers.
Configuring mrouted Configuring mrouted Configuring mrouted When the mrouted daemon is started, it automatically reads the default ASCII text configuration file /etc/mrouted.conf. You can override the default configuration file by specifying an alternate file when invoking mrouted; refer to “Starting mrouted” on page 313. If mrouted.conf is changed while mrouted is running, you can issue the HP-UX command kill -HUP to signal mrouted to reread the configuration file.
Configuring mrouted Configuring mrouted The tunnel command can be used to establish a tunnel link between local IP address local-addr and remote IP address remote-addr (see figure below). It can also be used to associate a non-default metric or threshold value with that tunnel. The local IP address local-addr can be replaced by the interface name, such as lan0. The remote IP address remote-addr can be replaced by a host name, but only if the host name has a single IP address associated with it.
Configuring mrouted Configuring mrouted you are specifically attempting to force traffic to take another route. In this case, the metric of the alternate path should be the sum of the metrics on the primary path + 1. The default value is 1. The threshold is the minimum IP time-to-live (TTL) required for a multicast datagram to be forwarded to the given interface or tunnel. It controls the scope of multicast datagrams.
Configuring mrouted Configuring mrouted The cache_lifetime value determines the amount of time that a cached multicast route remains in the kernel before timing out. This value is specified in seconds and should be between 300 (5 minutes) and 86400 (24 hours). The default value is 300. The pruning off command explicitly configures mrouted to act as a “non-pruning” router.
Configuring mrouted Starting mrouted Starting mrouted mrouted is started from the HP-UX prompt or from within a shell script by issuing the following command: /etc/mrouted [-p] [-c config_file] [-d debug_level] The -p option disables pruning by overriding a pruning on statement within the /etc/mrouted.conf configuration file. This option should be used only for testing. The -c option overrides the default configuration file /etc/mrouted.conf. Use config_file to specify the alternate configuration file.
Configuring mrouted Verifying mrouted Operation Verifying mrouted Operation You can use one or more of the following methods to verify that mrouted is operating: • Retrieve the Virtual Interface Table and the Multicast Routing Table to see if the correct virtual interfaces (vifs) are configured. Refer to “Displaying mrouted Routing Tables” on page 315 for information on retrieving these tables.
Configuring mrouted Displaying mrouted Routing Tables Displaying mrouted Routing Tables There are three routing tables associated with mrouted. They are the Virtual Interface Table, the Multicast Routing Table, and the Multicast Routing Cache Table.
Configuring mrouted Displaying mrouted Routing Tables where pid is the process ID of the mrouted daemon. Refer to the “Example” section of the mrouted (1m) man pages for an explanation of the contents of the mrouted routing tables. Refer to the “Signals” section of the mrouted (1m) man pages for additional information about other signals to which mrouted responds.
Configuring mrouted Multicast Routing Support Tools Multicast Routing Support Tools mrinfo mrinfo is a multicast routing tool that requests configuration information from mrouted and prints the information to standard out. By default, configuration information for the local instance of mrouted is returned. You can override the default request to the local instance of mrouted by specifying an alternate router IP address or system name. Type man 1m mrinfo for additional information on using mrinfo.
Configuring mrouted Sources for Additional Information Sources for Additional Information RFC documents Additional information pertaining to mrouted and IP multicast routing can be obtained from the following RFC (Request for Comment) documents. Refer to the section “Military Standards and Request for Comment Documents” within chapter 1 of this manual for information on accessing these documents: • RFC 1075: “Distance-Vector Multicast Routing Protocol” This RFC has been obsoleted and has no successor.
10 Using rdist 319
Using rdist This chapter contains information about how to use rdist, a program that distributes and maintains identical copies of files across multiple network hosts. System administrators can use rdist to install new or updated software on all machines in a network.
Using rdist Overview Overview To use rdist, one system in the network is designated as the master host. The master host contains the master copy of source files that are distributed to remote hosts. rdist software is installed as part of the operating system. It must reside in the /usr/bin directory on the master host and on the remote hosts that are to be updated. It must be owned by root and must have its access permissions set to rwsr-xr-x.
Using rdist Overview Figure 10-1 Distributing Files with rdist Standard Output: updating host B installing: filea1 installing: filea2 installing: filea3 updating host C ... System A (Master Host) rdist Source Files: filea1 filea2 filea3 System B System C rdist rdist Note that the rdist process does not prompt for passwords. The user on the master host who starts rdist (usually a system or network administrator) must have an account on the remote host and must be allowed remote command execution.
Using rdist Setting Up remsh Setting Up remsh rdist uses remsh as the mechanism for distributing files over the network. In order to use rdist, you must set up remsh on each of the remote hosts. Follow these steps: 1. On each of the remote hosts, create an entry for the master host in the $HOME/.rhosts file of the user who will run rdist. For example, if rdist will always be run by user root, create an entry for the master host in root’s .rhosts file (/.rhosts) on each of the remote hosts. 2.
Using rdist Creating the Distfile Creating the Distfile The distfile used by the master host contains a sequence of entries that specify the files to be copied, the destination hosts, and the operations to be performed to do the updating. Since a distfile is an ASCII file, you can create it with any text editor. If you are familiar with the make program, the structure of a distfile is somewhat similar to a makefile.
Using rdist Creating the Distfile Spaces or tabs immediately to the left and right of the “=” are ignored. Subsequent appearances of ${variable_name} in the distfile (except in comments) are replaced by name_list. (Braces can be omitted if variable_name consists of just one character.) Variable definitions can also be specified in the command line when invoking rdist; variable definitions in the command line override definitions in the distfile. (See “Starting rdist” on page 330.
Using rdist Creating the Distfile label: is optional and is used to group command entries. You can use labels to perform a partial update. Normally, rdist updates all the files and directories listed in a distfile. You can invoke rdist with a specific label; in this case, rdist executes only the entries under the specified label. source_list specifies the directories or files on the master host that are to be used as the master copy for distributing to the remote hosts.
Using rdist Creating the Distfile Table 10-1 Distfile Commands Copies source files/directories to each host in the destination list. Any of the following options can be specified: install -b performs a binary comparison and updates files if they differ. Without this option, rdist updates files only if the size or modification time differs. -h follows symbolic links on the master host and copies the file(s) that the link points to. Without this option, rdist copies the name of a symbolic link.
Using rdist Creating the Distfile except file_list Updates all files in the source list except for the file(s) specified in file_list. except_pat pattern Updates all files in the source list except for those files whose names contain the pattern pattern. The characters “\” and “$” must be escaped with a backslash (\). special [file] ”command” Specifies command(s) that are to be executed on the remote host after each specified file is updated or installed.
Using rdist Creating the Distfile The second example (labeled srcs) distributes the directory /usr/src/bin to the host arpa; object files or files that are under SCCS control are not copied. Changed Files List Commands The third type of distfile entry is used to make a list of files that have been changed on the master host since a specified date.
Using rdist Starting rdist Starting rdist After creating the distfile on the master host, you can start rdist from the command line or from a cron file. rdist must be run as root on the master host. There are two forms of the rdist command syntax. One form is the following: /usr/bin/rdist [-b] [-h] [-i] [-n] [-q] [-R] [-v] [-w] [-y] [-d var=value] [-f distfile] [-m host] ... [label] -d var=value sets the value of the variable var to value.
Using rdist Starting rdist Table 10-2 rdist Command Line Options -b Performs a binary comparison and updates files if they differ. Without this option, rdist updates files only if the size or modification time differs. -h Follows symbolic links on the master host and copies the file(s) that the link points to. Without this option, rdist copies the name of a symbolic link. -i Ignores unresolved links.
Using rdist Starting rdist % /usr/bin/rdist updating host lassie installing: myprog.c special "cc" notify @lassie (bentley@tbear) updating host benji installing: myprog.
Using rdist Troubleshooting rdist Troubleshooting rdist Errors, warnings, and other messages are sent to standard output on the master host. Use the notify command to mail a list of files updated and errors that may have occurred to the specified users on the remote host being updated. To mail the list to a user that is not on the remote host, make sure that you specify the mail recipient as user@host.
Using rdist Troubleshooting rdist 334 Chapter 10
11 Secure Internet Services 335
Secure Internet Services Before HP-UX 11.0, alternative versions of the Internet Services ftp, rcp, remsh, rlogin, and telnet were provided by the optionally installable Secure Internet Services product (InternetSvcSec). That product incorporated Kerberos Version 5 Beta 4 authentication and authorization. Beginning with HP-UX 11.0, the Secure Internet Services product is replaced by the Secure Internet Services mechanism, which incorporates Kerberos V5 Release 1.
Secure Internet Services Overview of the Secure Internet Services Overview of the Secure Internet Services Network security concerns are becoming increasingly important to the computer system user. The purpose of the Secure Internet Services is to allow the user greater security when running these services. When an Internet Services client connects to the server daemon, the server daemon requests authentication.
Secure Internet Services Overview of the Secure Internet Services If any of the Secure Internet Services are installed in an environment where some of the remote systems on the network are running without the Secure Internet Services mechanism enabled, you can use a special command line option to bypass Kerberos authentication to access those remote systems. However, if a password is required to access the system, the password is sent in a readable form over the network.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol Overview of the Secure Environment and the Kerberos V5 Protocol This section gives an overview of the secure environment in which the Secure Internet Services operate, including a simplified overview of the Kerberos V5 authentication protocol and related Kerberos concepts. Kerberos, originally developed by MIT, refers to an authentication protocol for open network computing environments.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol Figure 11-1 The Secure Environment and the Kerberos V5 Protocol (A) Security Server KDC TGS AS 3 1 4 2 Security Client Runtime (e.g., kinit, klist) Application Client (e.g., ftp, telnet) Security Client (B) Security Client (C) 5 6 Application Server (e.g.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol • Application server (D in Figure 11-1): A Secure Internet Services daemon (ftpd, remshd, rlogind, or telnetd). • Security client runtime (B in Figure 11-1): A Kerberos command (kinit, klist, or kdestroy). Security clients communicate with the security server for authentication. Note that none of the components of the Kerberos environment are restricted to run on a specific type of system.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol When users invoke one of the Secure Internet Services, they enter the usual command along with any desired command options. From a user’s perspective, using the Internet Services with the Secure Internet Services mechanism enabled is virtually identical to using them without the mechanism enabled. The only difference is that the user is not prompted for a password.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol To summarize, • The user obtains a TGT from the AS portion of the KDC when it first issues the kinit, dce_login, or dess_login command to the KDC. • When the user invokes a Secure Internet Service, the client requests a service ticket from the TGS portion of the KDC. It obtains this service ticket by presenting the TGT and other credentials to the TGS portion of the KDC.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol When using the HP DCE Security Service as a KDC, the term cell is used. A cell is roughly equivalent to a realm. An HP DCE cell name must be lowercase. It appears as a prefix and has a leading “/.../” in a principal name (/.../my_kdc_cell.com/david). Domains A P/SS domain defines an administrative structure and is equivalent to a Kerberos realm and an HP DCE cell. Like an HP DCE cell, its name must be lowercase.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol • Kerberos: susan@MYREALM.COM • HP DCE: /.../my_kdc_cell/susan • HP P/SS: /.../my_domain/susan Service Principal Names. A service principal name is a principal name that authorizes an application server to use a particular service. For ftp, the service principal name is ftp (as a first choice) or host (as an acceptable second choice. Note that the actual name is host; it is not meant to be replaced by a host name.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol $ ftp hostA $ Connected to hostA $ Name:(hostA:david): susan In this example, susan is the login user. Both of the following requirements must be met for authorization to succeed: • The login user must have an entry in the /etc/passwd file on the host where the application server is running. • One of the following three conditions must be met: • A $HOME/.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol First, the KDC’s forwardable ticket option must be enabled. For Kerberos V5 KDCs, use the kadmin command. For the HP DCE Security Service and the HP P/SS, use the dcecp command to set the forwardabletkt account attribute. Second, kinit must be invoked with the forwardable flag set (-f). If the -f option is specified when kinit is run, the TGT for the local system can be forwarded to the remote system.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol For more information on GSS-API Version 1, refer to RFCs 1508, 1509, and 1964. Secure Environment Configurations Configurations consist of KDCs and client nodes. The figures below illustrate possible KDC/client configurations. The paragraphs following the figures describe the nodes in more detail and also discuss interoperability among the nodes.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol Figure 11-3 Client Interoperability with Non-HP Kerberos V5 KDCs (G) Non-HP Kerberos V5 KDC & HP Secure Internet Services Non-HP Kerberos Clients* & Non-HP Secure Internet Services (D) (E) HP Kerberos Clients* * "Clients" are security clients. They can be application clients or application servers. Figure 11-3 illustrates which security clients can interoperate in configurations using non-HP Kerberos V5 KDCs.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol • The HP P/SS can be configured to run with security clients using the Secure Internet Services and fulfill the role of the KDC. An HP P/SS security server node runs the HP P/SS security daemon secd. This node can be configured as the only member of a single-node P/SS domain, or as a member of a multi-node domain with HP P/SS clients.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol The Kerberos utilities kinit, klist, and kdestroy are supplied by HP on this client. However, this client generally obtains credentials using the dess_login command, instead of the Kerberos kinit command. This client can use dcecp and other administrative tools for Kerberos-related management tasks.
Secure Internet Services Overview of the Secure Environment and the Kerberos V5 Protocol Generally, configurations that contain non-HP security clients will interoperate securely with configurations that include the HP Secure Internet Services, provided all of the following things are true: • The Kerberos utilities kinit, klist, and kdestroy are based on Kerberos V5. • Secure versions of rcp/remshd, remsh/remshd, rlogin/rlogind, and telnet/telnetd either are implemented with Kerberos V5 Release 1.
Secure Internet Services Configuration and Kerberos Version Interoperability Requirements Configuration and Kerberos Version Interoperability Requirements The main purpose of this chapter is to provide information required specifically for the Secure Internet Services. However, since the successful usage of the Secure Internet Services requires a correctly configured secure environment, this section discusses some general requirements of the secure environment.
Secure Internet Services Configuration and Kerberos Version Interoperability Requirements This file is automatically created when the client is configured into the HP DCE cell (for HP DCE clients) or the HP P/SS domain (for HP P/SS clients). Additional entries can be added manually. • A realms file named /krb5/krb.realms. This file is used to associate host names to realm or cell names. Suggested ownership and permissions for this file are root, sys, -r--r--r--. • A keytab file named /krb5/v5srvtab.
Secure Internet Services Configuration and Kerberos Version Interoperability Requirements • The configuration file and realms file are combined into one configuration file with a new format. The new configuration file is named /etc/krb5.conf. The /etc/krb5.conf file specifies (1) defaults for the realm and for Kerberos applications, (2) mappings of host names onto Kerberos realms, and (3) the location of KDCs for the Kerberos realms. For HP DCE clients, the /etc/krb5.
Secure Internet Services Configuration and Kerberos Version Interoperability Requirements If the above entries need to be added to or changed in the configuration file, you must make the additions or changes manually (use the text editor of your choice). • The keytab file is named /etc/krb5.keytab. Note that, when an HP DCE or HP P/SS cell is configured, the keytab file is created automatically, but it is given the V5 Beta 4 name (/krb5/v5srvtab).
Secure Internet Services Configuration and Kerberos Version Interoperability Requirements • The V5 Beta 4 configuration file, realms file, and keytab file must exist, and the V5-1.0 configuration file and keytab file must exist, as explained in “Beginning with HP-UX 11.0” on page 354. • A $HOME/.k5login file must exist in each login user’s home directory. This file must be owned by the login user, and only the login user can have write permission.
Secure Internet Services System Requirements for the Secure Internet Services System Requirements for the Secure Internet Services The system requirements for the Secure Internet Services mechanism are shown in Table 11-1 below. Table 11-1 Secure Internet Services System Requirements Hardware Requirements HP 9000 system Software Requirements HP-UX 11.0 Disk Space No additional disk space is required. Memory No additional memory is required.
Secure Internet Services Configuring the Secure Internet Services Configuring the Secure Internet Services Provided that the general secure environment configuration requirements have been met (see “Configuration and Kerberos Version Interoperability Requirements” on page 353), the tasks required specifically for configuring the Secure Internet Services are described below. The KDC A properly configured KDC must be running for the Secure Internet Services to work.
Secure Internet Services Configuring the Secure Internet Services CAUTION If the shell line is commented out, the rdist command will no longer work. 4. If you modified the /etc/inetd.conf file, run the inetd -c command to force inetd to reread its configuration file. 5. Repeat steps 1-4 for all systems where security clients are running.
Secure Internet Services Migrating Version 5 Beta 4 Files to Version 5 Release 1.0 Migrating Version 5 Beta 4 Files to Version 5 Release 1.0 To convert and combine the Version 5 Beta 4 /krb5/krb.conf configuration file and the /krb5/krb.realms realms file into the Version 5 Release 1.0 /etc/krb5.conf configuration file, run the convert_krb_config_files migration tool. The steps to follow are listed below. NOTE You must run the migration tool on each client (HP DCE, HP P/SS, and HP Kerberos). 1.
Secure Internet Services Enabling the Secure Internet Services Mechanism Enabling the Secure Internet Services Mechanism To use Kerberos authentication instead of the default UNIX (user/password) authentication, follow these steps to enable the Secure Internet Services mechanism: 1. Log in as root on the system where you want to enable the mechanism. 2. Type this command: /usr/sbin/inetsvcs_sec enable The system file /etc/inetsvcs.conf is updated with the entry kerberos true.
Secure Internet Services Disabling the Secure Internet Services Mechanism Disabling the Secure Internet Services Mechanism To disable the Secure Internet Services mechanism (and return to using the default UNIX authentication), follow these steps: 1. Log in as root on the system where you want to disable the mechanism. 2. Type this command: /usr/sbin/inetsvcs_sec disable The system file /etc/inetsvcs.conf is updated with the entry kerberos false.
Secure Internet Services Checking the Current Authentication Mechanism Checking the Current Authentication Mechanism To determine which authentication mechanism is currently in use, follow these steps: 1. Log in as root on the system where you want to check the mechanism. 2. Type this command: /usr/sbin/inetsvcs_sec status The name of the authentication mechanism currently in effect is displayed.
Secure Internet Services Verifying the Secure Internet Services Verifying the Secure Internet Services The tasks you should do if you want to verify that the Secure Internet Services have been configured correctly are described in the paragraphs below. Secure Environment Checklist The following is a quick checklist to verify that the secure environment is properly configured. 1. On the KDC, issue a ps -ef command and verify that the necessary security server executables are running.
Secure Internet Services Verifying the Secure Internet Services realm’s KDC. It can also check the keys in the keytab file for agreement with the KDC. By acting as a client/daemon service itself, it can further assist in verifying the correctness of the configuration. For more information refer to the krbval(1M) man page.
Secure Internet Services Using the Secure Internet Services Using the Secure Internet Services Some things you, as network or system administrator, should be aware of, regarding how end users might use the Secure Internet Services, are described in the paragraphs below. Overview of the User’s Session • Users must issue a kinit (for HP DCE clients, a dce_login, or for HP P/SS clients, a dess_login) command so that they get a TGT from the KDC (for example, kinit amy@realm1.com).
Secure Internet Services Using the Secure Internet Services Bypassing and Enforcing Kerberos Authentication Depending on how certain options are used with these services, the Secure Internet Services clients will still be able to access non-secure remote hosts, and the daemons will still be able to accept requests from non-secure clients. To access a non-secure remote system on the network, users can use the -P option when issuing the client command to bypass Kerberos authentication.
Secure Internet Services Using the Secure Internet Services • rlogin accesses rlogind through the new port specified by the /etc/services entry klogin when operating as a secure client. If you invoke rlogin with the -P option, or if you run rlogin without the Secure Internet Services mechanism enabled, then rlogin will behave as a non-secure client and access rlogind through the login port.
Secure Internet Services Troubleshooting the Secure Internet Services Troubleshooting the Secure Internet Services Some guidelines for you to follow when you troubleshoot the Secure Internet Services are described below. The Verification Checklist Go through the checklist described in the section “Verifying the Secure Internet Services” on page 365: • Verify that the secure environment is correct. • Verify that the Secure Internet Services mechanism was successfully enabled.
Secure Internet Services Troubleshooting the Secure Internet Services Other common problems will most likely relate to an incorrect configuration.
Secure Internet Services Sources for Additional Information Sources for Additional Information Listed below are some other resources where you can find more information about Secure Internet Services. Additional HP Documentation Other Hewlett-Packard documentation that provides Secure Internet Services information is as follows: • Using HP DCE 9000 Security with Kerberos Applications Available in postscript and ASCII form in the directory /opt/dce/newconfig/RelNotes/ in the files krbWhitePaper.
12 Troubleshooting Internet Services 373
Troubleshooting Internet Services Troubleshooting data communications problems may require you to investigate many hardware and software components. Some problems can be quickly identified and resolved. These include invalid software installation, version incompatibilities, insufficient HP-UX resources, corrupt configuration shell scripts, and programming or command errors. Other problems require more investigation.
Troubleshooting Internet Services Chapter Overview Chapter Overview The strategy and tools to use while investigating the software and hardware components are provided in this chapter.
Troubleshooting Internet Services Characterizing the Problem Characterizing the Problem It is important to ask questions when you are trying to characterize a problem. Start with global questions and gradually get more specific. Depending on the response, ask another series of questions until you have enough information to understand exactly what happened.
Troubleshooting Internet Services Characterizing the Problem These are symptoms that would lead you to suspect the software: • Network services errors returned to users or programs. • Data corruption. • Logging messages at the console. Knowing what has recently changed on your network may also indicate whether the problem is software-related or hardware-related.
Troubleshooting Internet Services Diagnostic Tools Summary Diagnostic Tools Summary The most frequently used diagnostic tools are listed below. These tools are documented in the link installation manuals. Table 12-1 Diagnostic Tools netstat A nodal management command that returns statistical information regarding your network. landiag A diagnostic program that tests LAN connections between HP 9000 computers. linkloop A diagnostic program that runs link-level loopback tests between HP 9000 systems.
Troubleshooting Internet Services Diagnostic Tools Summary x25upload This is used to upload the firmware in case of problems with the firmware on the board. Event Logging A utility that sends informational messages regarding network activity to the system console or to a file. Network Tracing A utility that traces link-level traffic to and from a node. HP recommends that you enable tracing only when troubleshooting a problem unsolved by other means.
Troubleshooting Internet Services Diagnosing Repeater and Gateway Problems Diagnosing Repeater and Gateway Problems If you are using a repeater and hosts on either side of the repeater are having difficulty communicating with each other, a repeater subsystem failure may have occurred. In the illustration below, all of the systems on side A are able to communicate with one another. All the systems on side B are able to communicate with each other.
Troubleshooting Internet Services Diagnosing Repeater and Gateway Problems x25stat -f -d /devicefile For more information on troubleshooting gateways, refer to the appropriate link manual. For information on repeaters, refer to the HP-PB LAN Interface Controller (LANIC) Installation Manual.
Troubleshooting Internet Services Flowchart Format Flowchart Format The flowcharts in this chapter each have a corresponding set of labeled explanations. You can follow the flowcharts alone or follow the flowcharts and read the explanations for more detail. The explanations are on the pages that follow each flowchart.
Troubleshooting Internet Services Troubleshooting the Internet Services Troubleshooting the Internet Services When troubleshooting problems with the Internet Services, you need a reference point to work from. For example, does the problem exist on the remote system or on the local system? However, the terms “local” and “remote” are limited in their description of complex communications, such as when a local system logs onto a remote system and then the remote system logs back onto the local system.
Troubleshooting Internet Services Troubleshooting the Internet Services Table 12-2 Reference Pages for Error Messages Service Client Server telnet telnet(1) telnetd(1M) ftp ftp(1) ftpd(1M) rlogin rlogin(1) rlogind(1M) remsh remsh(1) remshd(1M) rcp rcp(1) remshd(1M) ruptime ruptime(1) rwhod(1M) rwho rwho(1) rwhod(1M) ddfa user application ocd(1M) If the server or the client is not an HP 9000 computer, refer to the appropriate user’s manual or system administration manual for that
Troubleshooting Internet Services Troubleshooting the Internet Services Figure 12-3 Flowchart 1. Checking for a Server 1 1A Assumptions 1B List current servers 1C1 1C Server exists for service ? Yes 2 No 1D Are files correct ? 1E 1D1 Issue ps Yes command to check for internet daemon No 1D2 ps lists only grep ? No 1F reconfigure the internet daemon Correct files 1D3 Start the Yes internet daemon 1D4 1 1G 1 1A. Assumptions.
Troubleshooting Internet Services Troubleshooting the Internet Services Table 12-3 Servers Required for Each Service Local Address Client/Request TCP State *.ftp ftp LISTEN *.telnet telnet LISTEN *.login rlogin LISTEN *.shell remsh, rcp LISTEN *.exec rexec library LISTEN *.who rwho, ruptime *.smtp sendmail SMTP LISTEN *.tftp tftp LISTEN *.bootps bootpd LISTEN *.finger fingerd LISTEN Note that UDP-based protocols are datagram driven so they do not show a TCP LISTEN status.
Troubleshooting Internet Services Troubleshooting the Internet Services Service Requested inetd.
Troubleshooting Internet Services Troubleshooting the Internet Services Entries Required in /etc/services Service Requested /etc/services Entry ftp ftp 21/tcp telnet telnet 23/tcp sendmail/SMTP smtp 25/tcp rexec library exec 512/tcp rlogin login 513/tcp remsh and rcp shell 514/tcp rwho and ruptime who 513/tcp tftp tftp 69/udp bootpd bootps 67/udp and bootpc fingerd finger 79/tcp 68/udp If the file entries or permissions are not correct, continue with 1E. 1D1.
Troubleshooting Internet Services Troubleshooting the Internet Services 1D4. Go to 1B. Once inetd is running, repeat this flowchart beginning with 1B. 1E. Correct files. If there was an incorrect entry or no entry in the /etc/inetd.conf or /etc/services files, enter the correct information and continue with 1D1. 1F. Reconfigure the internet daemon. To reconfigure inetd, execute the following as superuser: /usr/sbin/inetd -c and continue with 1G. 1G. Go to 1B.
Troubleshooting Internet Services Troubleshooting the Internet Services Figure 12-4 Flowchart 2. Security for telnet and ftp 2 2A Determine number of existing connections 2B Maximum number of connections ? No 2C Access to the server ? 2D Yes Yes No See node manager 2B1 See node manager 2C2 2C1 Yes Using Using telnet or ftp ftp ? ? No No 2E 2F 3 Yes telnet should work 2C4 2C3 Yes $HOME/.
Troubleshooting Internet Services Troubleshooting the Internet Services configured, it checks this file to determine the number of allowable incoming connections. Look at this file to determine how many connections are allowed. The default is 1000. 2B1. See node manager. If the maximum number of connections has been reached, the node manager can change this value in the /var/adm/inetd.sec file. 2C. Access to the server? The /var/adm/inetd.
Troubleshooting Internet Services Troubleshooting the Internet Services 2E. Go to Flowchart 3. If you are using the Berkeley Services (sendmail, BIND, finger, the rexec library, or any of the “r” services), go to Flowchart 3 to begin troubleshooting the security for those services. 2F. telnet should work. If you have reached this point in the flowchart, the telnet server exists and you have access to the system.
Troubleshooting Internet Services Troubleshooting the Internet Services Figure 12-5 Flowchart 3. Security for Berkeley Services 3 3A User name exists on server host ? No 3B 3A1 Accessing Yes server system as yourself ? No Yes 3A2 Are you superuser ? Yes 3D No 3C Entry Yes in server's /etc/hosts.equiv file 3C1 ? OK No 3D Cannot access $HOME/.rhosts exists and has entry for you ? No 3E Using rlogin ? Yes 3E1 Yes Password prompt No 3F Permission denied 3A.
Troubleshooting Internet Services Troubleshooting the Internet Services NOTE 3A2. Are you superuser? If you are, go to 3D; otherwise continue with 3C. 3B. Cannot access. Since your user name or the user name that you want to use to log in does not exist on the remote system, you cannot log in to the remote system unless the remote system’s node manager creates an account for you. 3C. Entry in server’s /etc/hosts.
Troubleshooting Internet Services Reporting Problems to Your Hewlett-Packard Support Contact Reporting Problems to Your Hewlett-Packard Support Contact If you do not have a service contract with HP, you may follow the procedure described below but you will be billed accordingly for time and materials. If you have a service contract with HP, document the problem as a Service Request (SR) and forward it to your Hewlett-Packard support contact.
Troubleshooting Internet Services Reporting Problems to Your Hewlett-Packard Support Contact • Try to determine the general area within the software where you think the problem exists. Refer to the appropriate reference manual and follow the guidelines on gathering information for problems. • Document your interim or “workaround” solution. The cause of the problem can sometimes be found by comparing the circumstances in which it occurs with the circumstances in which it does not occur.
Index Symbols $HOME/.netrc file, 57, 391 with BIND, 95 $HOME/.rhosts file, 56, 394 disabling, 57 with BIND, 95 .forward file, 128, 134 .netrc file, with BIND, 95 .
Index boot.sec.
Index accessing options for bootpd server, 205 administering, 199 BOOTP relay agent, 201 bootptab file, 203 configuration files, 203 configuring, 199 device groups, 199 dhcptab file, 203 fixed-address devices, 200 dhcptab file, 203 dhcptools, 205 diskless booting, 163 clients that use RMP, 169 Distance-Vector Multicast Routing Protocol, 305 distfile, rdist, 322 command entries, 325 creating, 324 except command, 328 except_pat command, 328 install command, 327 list of changed files, 329 notify command, 327
Index anonymous, 48 bypassing security, 55 configuring, 47 Secure Internet Services mechanism for, 336 troubleshooting, 390 ftpd logging, 46 restricting access, 52 Secure Internet Services mechanism for, 336 ftpusers file, 52, 391, 392 G gated, 22, 39, 235 advantages, 237 checking 3.0 compatibility with 3.5, 243 common problems, 298 configuring, 242 converting configuration file to 3.
Index hardware type, in bootptab, 177, 179 hd tag, in bootptab, 178 header, sendmail, 135 HELLO routing protocol, 239 hellointerval statement, in gated.conf, 264, 268 HINFO records, 81, 84 hm tag, in bootptab, 179 hn tag, in bootptab, 178 holddown mode, gated, 247 $HOME/.netrc file, 57, 391 $HOME/.
Index version interoperability requirements, 353 kernel routing table, 237, 294 Key Distribution Center (KDC), 340, 348, 349, 350, 351, 352 DCE Security Server, 348, 349 Praesidium/Security Server, 350 key, for NTP authentication, 221 keys statement, in ntp.
Index on caching-only server, 89 on primary master, 75 on secondary master, 86, 87 named.ca file, 74, 76, 97 named.data directory, 73 named.run file, 101 named.stats file, 112 named_dump.db file, 102 nameserver option, in resolv.conf, 91 namesvrs file, 93 NBMA network interface, 263, 266 ndots option, in resolv.conf, 65 neighbor routers, 257 netconf file, 39, 244, 294 netdaemons file, 170, 214, 226, 227 netdb.h, 141 netgroups, NFS, 56, 57 netid field, in IP address, 306 .
Index cost, 263, 274 designated router, 257, 259, 264, 266 enabling, 260 equal cost multipath, 239 importing routes, 275 interfaces, 263 internal routers, 257 link state advertisements, 257 neighbor routers, 257 networks, 261 router interfaces, 259 sample configuration, 277 stub area, 269 types of interfaces, 263 ospf statement, in gated.conf, 260 ospf_monitor, 298 P passive clause, in gated.
Index retransmitinterval statement, in gated.conf, 263, 268 Retry, in SOA record, 79 rexec, 23 bypassing security, 55 RFC 1048 vendor information, 188 RFCs, 25 for BIND, 60, 92, 102 .rhosts file, 56, 394 RIP routing protocol, 239, 247 exporting routes, 251 sample configuration, 252 rip statement, in gated.conf, 249 ripin clause, in gated.conf, 250 ripout clause, in gated.
Index default routing configuration, 138 DH macro, 124 DM macro, 124 error handling, 144 expand_alias utility, 132 forwarding mail, 134 forwarding non-domain mail, 148 further reading, 21, 118 installation, 125 installing on mail client, 123 installing on mail server, 122 installing on standalone system, 121 local mailing, 125 logging, 44, 125, 126, 127 mail queue, 145 mailing lists, 129 mailing to programs or files, 138 mailing to remote systems, 126 masquerading, 124 message header, 135 message structure
Index common problems, 189 configuring, 171 example, 184 file transfer options, 184 home directory, 171, 172, 187 logging, 185 retransmission timeout, 190 testing, 172 troubleshooting, 185 unsupported products, 164 tftp, 22 TFTP Error Code 1 message, 190 TFTP Error Code 2 message, 191 tftpd, 166 threshold value, in bootrequest, 166 time synchronization, 209 time-to-live, in BIND data file, 77 TIMEZONE file, 214 TOS (type of service) routing, 239 traceoptions statement, in gated.
Index x25check, 378 x25server, 378 x25stat, 378, 380 x25upload, 379 xntpd, 208 configuration file, 217 logging, 230 querying, 228 starting, 226 startup script, 214, 226 stopping, 227 XNTPD variable, 214, 226 XNTPD_ARGS variable, 226, 227 Y Yellow Pages, 35 ypinit script, 132 Z zone, definition of, 72 408 Index
