HP-UX Internet Services Administrator's Guide HP-UX 11i v2, HP-UX 11i v3 HP Part Number: B2355-91060 Published: February 2007 Edition: 2
Legal Notices © Copyright 2004–2007 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents About This Document...................................................................................................................13 New and Changed Information in This Edition........................................................................13 Intended Audience................................................................................................................13 HP-UX Release Name and Release Identifier..................................................................
Choosing a Name Service............................................................................................27 Editing the /etc/hosts File.............................................................................................28 Configuring a Route....................................................................................................29 Changing a Host’s IP Address......................................................................................30 Configuring inetd...............
Setting up a Spectracom Netclock/2.........................................................................50 Location of Time Source....................................................................................................51 Example 1: Locating the Best Primary Server ................................................................52 Determining Synchronization Sources..........................................................................
Characterizing a Problem..................................................................................................77 Diagnostic Tools Summary................................................................................................78 Diagnosing Repeater and Gateway Problems.....................................................................79 Troubleshooting Tips.............................................................................................................80 Flowchart Format....
List of Figures 4-1 4-2 4-3 4-4 4-5 5-1 5-2 5-3 5-4 5-5 Survey of Best Time Servers........................................................................................51 Stratum-1 Time Servers...............................................................................................60 Example of Relationships Between Time Servers.......................................................61 Example Configurations............................................................................................
List of Tables 1-1 1-2 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 5-1 5-2 5-3 5-4 5-5 The Internet Services Products....................................................................................19 Software Versions........................................................................................................20 Available Time Servers................................................................................................52 Locating Synchronized Time Servers........................................
List of Examples 3-1 Sample Usage of the tcpdmatch Tool.................................................................................
About This Document This document provides an overview of the Internet Services software and describes how to install and configure it on your operating system. It is one of the documents available for the Internet Services suite of products. For a list of other Internet Services documents, see “Related Documentation” (page 14). These documents replace the document Installing and Administering Internet Services (B2355-90685), which was shipped with releases prior to the HP-UX 11i v2 operating system.
Publishing History The following table lists the publishing details of this document for various HP-UX releases.
• Using HP-UX Internet Services at: http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services • Request for Comments (RFC) at: http://www.ietf.org/rfc.html • Other Documents For detailed technical and conceptual information about BIND, as well as information about planning a BIND hierarchy and using Sendmail with BIND, HP recommends that you read Paul Albitz and Cricket Liu, 2001. DNS and BIND. O'Reilly and Associates, Inc., This book is available at: http://www.ora.
{} (Ctrl+A) Bold ... | The contents are required in formats and command description. If the contents are a list separated by |, you must choose one of the items. This symbol indicates that you hold down the first named key while pressing the key or mouse button that follows the plus. The defined use of an important word or phrase. The preceding element can be repeated an arbitrary number of times. Separates items in a list of choices.
1 Internet Services Overview The HP-UX Internet Services software, (formerly the ARPA Services suite of products) enables your HP system to carry out the following tasks: • Transfer files. • Log on to remote hosts. • Execute commands remotely. • Manage IP addresses and network clients. • Perform all routing protocols. • Exchange mail with remote hosts on the network. • Locate and configure networked services in enterprise networks.
ARPA services include the set of services developed by UCB for the Advanced Research Projects Agency (ARPA): ftp and telnet. ARPA services are used to communicate with HP-UX, UNIX®, and non-UNIX systems. Berkeley services include the set of services developed by UCB to implement UCB protocols: BIND, sendmail, finger, the rexec library, rcp, rlogin, remsh, ruptime, rwho, and rdist. Berkeley Services are used to communicate with HP-UX or other UNIX systems.
Table 1-1 The Internet Services Products Product Name Bundle Name Category Bundle description Restructured Products in the InternetSrvcs Product DHCPv4 HPUX-DHCPv4 Recommended This bundle contains the Dynamic Host Configuration Protocol (DHCP) daemon, the Bootstrap Protocol (BOOTP) server, clients, utilities, and sample configuration files. DHCPv6 HPUX-DHCPv6 Recommended This bundle contains the DHCP product for IPv6, the DHCPv6 server, clients, utilities, and sample configuration files.
Software Versions Table 1-2 lists the product versions that have been made available with this version of Internet Services on the HP-UX 11i v2 and HP-UX 11i v3 operating systems. The software versions listed in this table are public domain versions. Table 1-2 Software Versions Software Version FTP 2.6.1 Sendmail 8.13.3 BIND 9.3.2 gated 3.5.9 mrouted 3.8 TCP Wrappers 7.6.1 Software Descriptions This chapter provides an overview of Internet Services.
The tftp Service The tftp (Trivial File Transfer Protocol) service, used with bootp to enable some diskless systems (such as the HP 700/X terminal), transfers files containing bootstrap code, fonts, or other configuration information. You must invoke the tftpd server via inetd. Type man 1 tftp or man 1M tftpd at the HP-UX prompt for more information. The telnet Command The telnet command allows you to log on to a remote host that supports Internet Services.
See “Installing and Configuring Internet Services” (page 25) for information on installing and configuring the previous services. See HP-UX Remote Access Services Administrator’s Guide, at the URL http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, for complete information about these services. The elm Utility elm’s screen-oriented interface runs with Sendmail or with any other UNIX Mail Transport Agent and enables you to read and compose mail messages.
of addresses. See the HP-UX IP Address and Client Management Administrator’s Guide at the URL http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, or type man 1M dhcpv6d at the HP-UX prompt for more information. The gated Service The gated service determines routing over the Internet. See the HP-UX Routing Services Administrator’s Guide at the URL http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, or type man 1M gated at the HP-UX prompt for more information.
http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, or type man 1M ramD at the HP-UX prompt for more information. Secure Internet Services Secure Internet Services (SIS) is an optionally enabled mechanism that incorporates Kerberos V5 Release 1.0 authentication and authorization for the following services: ftp, rcp, remsh, rlogin, and telnet. See Using HP-UX Internet Services, at the URL http://www.docs.hp.com/hpux/netcom/index.html for more information.
2 Installing and Configuring Internet Services This chapter describes how to install and configure the Internet Services software on your system. It discusses the following topics: • “Installing the Internet Services Software” (page 25) • “Configuring the Internet Services Software” (page 25) Installing the Internet Services Software The Internet Services software is packaged along with the core HP-UX 11i v2 and HP-UX 11i v3 operating systems.
For host information, you can configure your system to use BIND (DNS), NIS, or the /etc/hosts file. The default name service switch configuration is adequate for most installations, so you probably do not have to change it. The default configuration is explained in the section “Default Configuration” (page 26).
publickey: nis [NOTFOUND=return] files netgroup: services nis [NOTFOUND=return] files nis [NOTFOUND=return] files automount: files nis aliases: files nis If your /etc/nsswitch.conf file contains a syntactically correct line for a particular type of information, that line is used instead of the default. Troubleshooting Using the nsquery Command You must use the nsquery command to troubleshoot the name service switch.
By configuring the name service switch, you can use these name services in any order you choose. See “Configuring the Name Service Switch” (page 25). If you have a large network, or if you need to connect to Internet hosts outside your local network, use BIND as your primary name service. When you use BIND, you administer a central database containing only the hosts on your local network, and you have access to the databases on all the other hosts on the Internet.
The first field is the IP address, the second is the official host name (as returned by the hostname command), and any remaining fields are aliases. Type man 4 hosts at the HP-UX prompt for more information. 4. 5. If your host has more than one network interface installed, add a line to /etc/hosts for each interface. The /etc/hosts entries for your host will have the same official host name but different aliases and different IP addresses. Add any other hosts to the /etc/hosts file that you need to reach.
Then, create a new set of routing variables in the /etc/rc.config.d/netconf file for each network interface. Whenever you create a new set of variables, increment the number in square brackets, as in the following example: 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.
http://www.docs.hp.com/hpux/netcom/index.html#Internet%20Services for more information. 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 4. If the host is moving to a different subnet, change the ROUTE_DESTINATION, ROUTE_GATEWAY, and BROADCAST_ADDRESS[n] variables in /etc/rc.config.d/netconf.
You must invoke inetd as part of the boot process, by running the following command at the HP-UX prompt: # /sbin/init.d/inetd start The /etc/inetd.conf file is the inetd configuration file, which lists the services that may be started by inetd. In addition to the configuration file, you can configure an optional security file called /var/adm/inetd.sec to restrict access to the services started by inetd. This section provides instructions for completing the following tasks: • • “Editing the /etc/inetd.
To edit the inetd.sec file using a text editor or HP SMH, complete the following steps: 1. 2. If the /var/adm/inetd.sec file does not exist on your host, copy /usr/newconfig/var/adm/inetd.sec to /var/adm/inetd.sec. Create one line in inetd.sec for each service to which you want to restrict access. Do not create more than one line for any service. Each line in the /var/adm/inetd.sec file has the following syntax: service_name {allow} host_specifier [host_specifier...
Each line in /etc/syslog.conf has a selector and an action. The selector specifies which part of the system generated the message and what priority the message has. The action specifies where the message should be sent. The part of the selector that specifies where a message comes from is called the facility. All Internet daemons and servers, except sendmail, log messages to the daemon facility. sendmail logs messages to the mail facility. syslogd logs messages to the syslog facility.
Configuring inetd Connection Logging The inetd daemon logs connection requests through syslogd. It logs successful connections at the information level and unsuccessful connection attempts at the notice level. By default, inetd starts up with connection logging turned off. If inetd is running with connection logging turned off, issue the following command to invoke it: /usr/sbin/inetd -l If inetd is running with connection logging turned on, the same command turns it off.
3 TCP Wrappers The Transmission Control Protocol (TCP) Wrappers product suite provides an enhanced security mechanism for services spawned by the Internet Services daemon, inetd.
Access Control TCP wrappers uses the files /etc/hosts.allow and /etc/hosts.deny as Access Control Lists (ACLs). These access control files are used to match the client and server entries with the service request. These files are based on pattern matching and can be extended via optional extensions such as allowing spawning of a shell command. Each access control file consists of a set of access control rules for different services that use tcpd.
3. To grant the telnet service to all the hosts in the domain xyz.com except the host abc.xyz.com, specify the following entry in the /etc.hosts.allow file: telnetd:.xyz.com EXCEPT abc.xyz.com For more information on the access control language and ACL options, type man 5 hosts_access or man 5 hosts_options at the HP-UX prompt. Host Name/Address Spoofing tcpd prevents an illegal host that behaves as a legal host from accessing services.
• • • • The tcpdchk Tool The tcpdmatch Tool The try-from Utility The safe_finger Program The tcpd Daemon The tcpd daemon monitors access to a service, logs the host name and the remote user name owning the connection, and performs some additional access control checks. After tcpd checks the connection, the wrapper invokes the desired server program and exits. Enabling tcpd You can use either of the following methods to enable tcpd: 1. Edit each entry in the /etc/inetd.
/etc/inetd.conf file. For example, you can enable the ftpd service with tcpd by executing the following commands at the command prompt: # mkdir /usr/lbin/wrapper # mv /usr/lbin/ftpd /usr/lbin/wrapper # cp tcpd /usr/lbin/ftpd When an ftp service is requested, inetd spawns the /usr/lbin/ftpd daemon which is actually the tcpd daemon. Then, tcpd performs access control checks before invoking the ftpd daemon in the /usr/lbin/wrapper directory.
contain valid data or STRING_UNKNOWN defined in the tcpd.h file. If the access is denied the hosts_ctl() API returns a value 0. The following are the methods to implement access control checks in a daemon program: 1. 2. Fill the variable elements in the structure request_info using the routines request_init() and request_set(), and call the hosts_access() routine to verify these elements with the ACLs. Call the function hosts_ctl() with appropriate input parameters to check with the ACLs.
You can execute the tcpdmatch tool on the command line using the following formats: 1. /usr/bin/tcpdmatch [-d] [-i inet_conf] daemon client 2. /usr/bin/tcpdmatch [-d] [-i inet_conf] daemon@[server] [user@]client daemon client server user Specifies a daemon name. Specifies the host name, network address, or the unknown or paranoid wildcard formats. Specifies a host name or network address or the unknown or paranoid wildcard formats.
The client information describes how the remote host recognizes the client in terms of an address, name, and user name, whereas, the server information describes the remote host. For more information on % expressions, type man 5 hosts_access at the HP-UX prompt. The safe_finger Program safe_finger, a wrapper program to the finger client, protects the data sent by the remote finger server. This program accepts all the options supported by the finger client.
With an extended parameter, tcpd logs the ACL information, such as, the entry with which the client request is matched and the entry’s related options. The default logging level parameter is normal which logs connection details, such as, acceptance or refusal of connections. TCP wrappers provides the tools tcpdchk and tcpdmatch for troubleshooting. tcpdchk validates the inetd.conf, hosts.allow and hosts.
4 Configuring NTP The Network Time Protocol (NTP) assures accurate synchronization of the computer’s clock time with reference to a number of primary reference sources, using an equipment such as a radio receiver. NTP runs as a continuous background client process on a system, and sends periodic time requests to primary servers to obtain the time stamps. It also checks for errors caused due to equipment or propagation failures.
be synchronized close to 1000 milliseconds, to ensure that make compiles the appropriate files. The following topics are discussed in this section: • • • • “NTP Equipment” (page 48) “Choosing the Source of Time” (page 48) “Backup Time Servers” (page 56) “Configuring Your Primary NTP Server” (page 58) NTP Equipment The following equipments are required to effectively use the NTP programs: • • • Internet or your own radio receiver, such as GPS (Global Positioning System), as a time source.
Available Time Sources The most common time distribution mechanisms from which you can draw time are: • • • Public time server (phone or modem) via the Internet Local clock impersonators Radio receiver – Terrestrial and satellite broadcast Public Time Server You can connect to public time servers via the Internet free of charge for a limited time. Public time servers also provide dial-up access through a modem. This is the cheapest and most popular method.
Radio Receiver The radio receiver is the most accurate and expensive time distribution mechanism. Radio receiver provides a stable time and is not affected by network delays, congestion, or outrages. Some of the popular radio receiver methods are: GPS (Global Positioning System), WWV (Terrestrial North America), and DCF77 (Terrestrial Europe). You must consider the cabling options when you select the radio receiver. Antenna cables are very expensive and RS232 cabling has a limited range.
server 3. 127.127.4.1 minpoll 3 maxpoll 4 # no fudge required # fudge 127.127.26.1 time1 -0.930 #s800 Create the following symbolic link: /usr/bin/ln -s /dev/tty0p0 /dev/wwvb1 Location of Time Source You must always select a time server that is physically close to your network; otherwise, it may lead to poor network connectivity and delays.
Example 1: Locating the Best Primary Server Table 4-1 shows the servers the time client can access. The primary time server is NAVOBS1.MIT.EDU. The other time servers within reasonable physical and network distance are cs.columbia.edu, 129.236.2.199, and clepsydra.dec.c . Table 4-1 Available Time Servers remote refid st t when poll reach delay offset disp ============================================================================== clepsydra.dec.c usno.pa-x.dec 2 u 927 1024 355 108.49 -18.215 3.
Following is the stratum-2 listing of the an HP machine which was provided in the Silicon Valley for public use in North America. ntp-cup.external.hp.com (192.6.38.127) Location: Cupertino CA (SF Bay area) 37:20N/122:00W Synchronization: NTPv3 primary (GPS), HP-UX Service Area: West Coast USA Access Policy: open access Contact: timer@cup.hp.
ntp.ctr.columbia.edu (128.59.64.60) Location: Columbia University Center for Telecommunications Research; NYC Synchronization: NTP secondary (stratum 2), Sun/Unix Service Area: Sprintlink/NYSERnet Access Policy: open access, authenticated NTP (DES/MD5) available Contact: Seth Robertson (timekeeper@ctr.columbia.edu) Note: IP addresses are subject to change; please use DNS /usr/sbin/ping ntp.ctr.columbia.edu 64 5 PING 128.59.64.60: 64 byte packets 64 bytes from 128.59.64.60: icmp_seq=0. time=83.
----huon.itd.adelaide.edu.AU PING Statistics---5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 496/497/500 Assume you are located in western United States and you ping this time server. The ping round-trip times are much larger; around 500 milliseconds. Do not use a time server at this distance unless you are really need it and understand what 500 milliseconds step changes mean to your users and applications.
Table 4-5 Output from ntpq for Configuring Silicon Valley Time Server remote refid st t when poll reach delay offset disp ========================================================================= *REFCLK(29,1) .GPS. 0 l 25 32 377 0.00 0.413 0.03 +bigben.cac.wash .USNO. 1 u 56 64 377 39.54 -0.466 1.68 clepsydra.dec.c usno.pa-x. 2 u 122 512 377 6.32 -0.250 0.92 -clock.isc.org .GOES. 1 u 149 512 357 5.98 -3.045 0.46 hpsdlo.sdd.hp.c wwvb.col.h 2 u 25 32 126 56.29 -8.078 8.50 +tick.ucla.edu .USNO.
RFC 1305 (Network Time Protocol Version 3 – Specification and Implementation). It is also compatible with the NTP servers Version 1 and 2 as defined in RFC 1059 (Network Time Protocol Version 1 – Specification and Implementation) and RFC 1119 (Network Time Protocol Version 2 – Specification and Implementation), respectively. xntpd operates in the following modes: symmetric active, symmetric passive, client/server, broadcast, and multicast mode, as specified in RFC 1305.
Configuring Your Primary NTP Server The following steps describe how to configure the primary NTP server: 1. 2. 3. Install the latest version of NTP on the system. Select a source of time: radio receivers, public time server or local NTP system. Add the server name to the file /etc/ntp.conf using the following command: server my_server.mydomain.my_org.com my_server.mydomain.my_org.comis the complete name of the server. 4. Specify the time source and add its information to the configuration file.
c. Start the daemon using the startup script: /sbin/init.d/xntpd start d. Verify whether the daemon process is running using the following command: ps -ef grep ntp The line /usr/sbin/xntpd appears in the list of running processes. Advanced NTP Topics This section includes advanced NTP topics and is ideal for experienced users.
Figure 4-2 Stratum-1 Time Servers Stratum-2 and -3 Time Servers Stratum-2 time servers use stratum-1 servers as their time source. Likewise, stratum-3 servers use stratum-2 servers as their time sources. The maximum stratum level a server can have is 15. Time Server Roles An NTP time server can take different roles in its relationships with other time servers in the synchronization subnet.
NOTE: Broadcasting is not recommended especially when used with local clock impersonators. Broadcasting is an old concept that is no longer used. Figure 4-3 illustrates the relationship between time servers in a synchronized subnet. Figure 4-3 Example of Relationships Between Time Servers Planning a Multiple-Server NTP Configuration You must consider the following guidelines when planning your configuration: • • • • Every NTP hierarchy must have atleast one stratum-1 server.
• • For enterprise networks that contain many file servers and workstations, the local time servers must obtain service from stratum-1 servers. While defining a relationship between a higher-numbered stratum server and lower-numbered stratum server, configure the relationship in the higher-numbered stratum server. For example, if a stratum-3 server is a client of a stratum-2 server, configure the relationship in the stratum-3 server.
of xntpd for this option. See “Configuring Authentication” (page 66) for more information. • version 1 You must specify this option if xntpd requests time from a host running ntpd, a daemon that is based on version 1 of the NTP protocol. You must specify version 2 if xntpd requests time from a host running an xntpd implementation that is based on version 2 of the NTP protocol. If you do not specify either of these options, xntpd daemon sends version 3 NTP packets when polling the host.
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 an External Clock Clocks are normally configured with server statements in the configuration file. You can configure xntpd to support an external clock. You can insert the clock address anywhere in the configuration file. Clocks are referenced by an address of the format 127.127.t.
Figure 4-4 Example Configurations You must configure the time server in the client system. For example, if Penelope is a client for Bonita, you must configure the name or IP address of Bonita on Penelope. You need not configure Penelope as a client on Bonita. Configuring a Driftfile The xntpd daemon computes the clock frequency error for a local host, and stores the frequency error in a driftfile. xntpd computes an accurate estimate of the frequency error after running for one or more days.
Configuring Authentication Authentication is a mechanism used to prevent 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. If you enable authentication on a host, the host synchronizes time only with those time servers that send messages encrypted with a configured key.
Figure 4-5 Authentication Example In Figure 4-5, authentication is enabled for both Penelope and Golden. An NTP time request from Penelope to Golden includes the authentication fields – key ID (10), and a checksum, tickle, encrypted with the key corresponding to the key ID 10. When Golden receives this request, it recomputes the checksum using the packet’s key ID field (10) to look up for the key ID 10 in its key file (tickle) and compares the checksum with the authentication field in the request.
IMPORTANT: 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. • -k keyfile This option specifies the file that contains the encryption keys used by xntpd. • -t key This option specifies the encryption key IDs that are trusted as synchronization sources. Restricting Incoming NTP Packets xntpd provides a mechanism for restricting access to the local daemon from certain sources.
Table 4-6 Restrict Option Flags (continued) Flag Effect 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. A source address of an incoming packet may match several entries in the restriction list. The entry that matches the source address most specifically is the entry that is applied.
NOTE: xntpd must be running continuously; if you wish to stop xntpd, it must be for a short duration. 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 for the configuration changes to be effective. To stop xntpd, issue the following command: /sbin/init.
Table 4-7 An ntpq Output Indicating Known NTP Hosts remote refid st t when poll reach delay offset disp ================================================================== *GPS_HP(1) GPS 0 l 48 64 377 0.00 0.516 4.19 hpps.cup.hp cupertino 3 u 467 1024 377 7.20 -12.430 15.67 +server2 WWVB 1 u 173 256 377 279.95 20.56 16.40 +node1 node3 2 u 131 256 373 9.89 16.28 23.
• • • • and 1024 seconds (approximately 8 mins. and 17 mins.). Systems with external clocks, like GPS, must poll every 64 seconds or less. The reach (reachability) column indicates how successful attempts to reach the server are. This is an 8-bit shift register with the most recent probe in the 2^0 position. The value 001 indicates the most recent probe was answered, while 357 indicates one probe was not answered. The value 377 indicates that all the recent probes have been answered.
NTP Associations Each NTP daemon must form an association with a time source: a higher-level (lower stratum) server for stratum-1 servers, or an external clock. NTP daemons can form additional associations with peer servers. Use the following command to list the NTP associations established by the local NTP daemon: /usr/sbin/ntpq -p In the output, an asterisk (*) must appear next to the node name to indicate that an association has been formed.
with the other system’s clock. For more information, type man 1M ntpdate at the HP-UX prompt. Error Messages This section describes the error messages that you may encounter while working with NTP. No server suitable for synchronization found. This message indicates that the NTP server is not responding. Packets were sent out, but a reply was not returned. The reason may be that the server is down, or the network link is broken or extremely congested.
/usr/sbin/ntpdate server The server is the name of a trusted server, such as a peer or high-level (lower stratum) server. If the local xntpd is unable to form any association, this command returns the message No suitable server for synchronization found. The possible causes for this error message is discussed in the following sections.
Startup Delay When xntpd is started, it takes five poll cycles (320 seconds using the default polling interval) to form an association with a higher-level server or peer. During this time window, xntpd does not respond to time requests from other NTP systems, because it does not have a suitable time source. This window exists even though xntpd is using an external clock, which can be either an attached radio clock (Netclock/2 WWVB Synchronized Clock) or the local system clock (server 127.127.n.n).
5 Troubleshooting Internet Services This chapter describes how to troubleshoot the Internet Services software. It discusses the following topics: • “Troubleshooting Overview” (page 77) • “Troubleshooting Tips” (page 80) • “Reporting Problems to Your Hewlett-Packard Support Contact” (page 91) Troubleshooting Overview Troubleshooting data communications problems may require you to investigate many hardware and software components. Some problems can be quickly identified and resolved.
— When using a nodal management utility? — When transmitting data? • Does the problem affect all users? The entire node? Has anything changed recently? The possibilities are as follows: — New software and hardware installation. — Same hardware but changes to the software. Has the configuration file been modified? Has the HP-UX configuration been changed? — Same software but changes to the hardware.
Table 5-1 Diagnostic Tools (continued) Tool Description nwmgr A diagnostic program that runs link-level loopback tests between HP systems. nwmgr uses IEEE 802.3 link-level test frames to check physical connectivity with the LAN. This diagnostic tool is different from the loopback capability of landiag because it tests only the link-level connectivity and not the transport-level connectivity.
Figure 5-1 Troubleshooting Networks that Use Repeaters The same concept holds for communication through a gateway. If you suspect a gateway problem, try the following procedures: • To determine if you are set up to communicate with the desired node, execute the following: netstat -r • To obtain routing statistics, execute the following: netstat -rs The statistics could indicate a bad route, suggesting a problem with a gateway node.
system? However, the terms local and remote are limited in their description of complex communications, such as when a local system logs on to a remote system and then the remote system logs back on to the local system. At that point, which is the local system and which is the remote system? A better solution is to use the terms client and server. The term client refers to a process that is requesting a service from another process.
Figure 5-2 Flowchart Symbols Error Messages The error messages generated by a service as seen on the client can be generated by the client or by the server. Error messages from the client occur before a connection is completely established. Error messages from the server occur after a connection is completely established. Whenever you receive an error message, follow the corrective action supplied in the manpage for that service. The error message is preceded by the name of the service.
Table 5-2 Manpages for Error Messages (continued) 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 system, see the appropriate user’s manual or system administration manual for that system. There is not a standard naming convention for servers or processes that activate the servers; however, you should be able to find the information in the system’s documentation.
Figure 5-3 Flowchart 1. Checking for a Server 1A. 1B. Assumptions. Before you begin Flowchart 1, you should have verified local node operations and verified connectivity with ping (see the troubleshooting section of Installing and Administering LAN/9000 Software). List current servers. List the servers currently running on your system by executing the following: netstat -a Table 5-3 lists the servers required for each service.
Table 5-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 UDP-based protocols are datagram driven, so they do not show a TCP LISTEN status. 1C. 1C1. 1D.
Check the permissions on the files in the /usr/lbin and /usr/sbin directories. The files ftpd, bootpd, telnetd, rlogind, remshd, rexecd, rwhod, and inetd must be owned and executable by root only. The file fingerd must be owned and executed by bin only. No other user should have permission to write them, although all users can read them. Table 5-5 lists the entries that are required in the /etc/services file.
1D4. 1E. 1F. Go to 1B. After inetd is running, repeat this flowchart beginning with 1B. Correct the 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. Reconfigure the Internet daemon. To reconfigure inetd, execute the following as superuser: /usr/sbin/inetd -c Continue with 1G. 1G. Go to 1B. Repeat flowchart from 1B to check if the server exists. Flowchart 2.
Figure 5-4 Flowchart 2. Security for telnet and ftp NOTE: The corrections suggested in 2B1, 2C1, and 2F1 must be done by the superuser. Also, except for the anonymous user ID, ftp requires non-null passwords on remote user accounts. 2A. 2B. 88 Determine the number of existing connections. If inetd was started with the -l option, the system log may list the number of connections. If these messages do not appear in the system log, continue with 2B, or enable the connection logging with inetd -l.
2B1. 2C. 2C1. 2C2. 2C3. 2C4. 2C5. 2C6. 2D. 2E. 2F. 2G. 2H. See the 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. Access to the server? The /var/adm/inetd.sec file also contains a list of systems that may not access the server. If inetd was started with the -l option, the system log may list the connections that are refused access to the server.
Flowchart 3. Security for Berkeley Services Flowchart 3 is for troubleshooting security for the Berkeley Services: sendmail, BIND, finger, the rexec library, and those services that begin with r. The following information assumes an account has a password. If it does not, the security checks are not performed. Figure 5-5 Flowchart 3. Security for Berkeley Services 3A.
3A1. 3A2. 3B. 3C. 3C1. 3D. 3E. 3E1. 3F. Accessing server system as yourself? If not, go to 3D. Are you superuser? If you are, go to 3D; otherwise, continue with 3C. Cannot access. Because your user name or the user name that you want to use to log on does not exist on the remote system, you cannot log on to the remote system unless the remote system’s node manager creates an account for you. Entry in server’s /etc/hosts.
Illustrate as clearly as possible the context of any messages. Prepare copies of information displayed at the system console and user terminal. • Obtain the version, update, and fix information for all software. To check your Internet Services version, execute the what service_name command, where service_name is a network service specific to the networking product, such as ftp for Internet Services. To check the version of your kernel, execute uname -r.
Index A authenticate statement, in ntp.conf, 67 authentication NTP, 66 B Berkeley Internet Name Domain, (see BIND) Berkeley services, 18 BIND, 27, 31 further reading, 18 BOOTP, 31 broadcast client, NTP, 60 broadcast statement, in ntp.conf, 62 broadcastclient statement, in ntp.
//www.docs.hp.com/hpux/netcom/index.html#Internet%20Services, 14 mode-6 control messages, 70 multi-homed host, 29 P peer statement, in ntp.conf, 62 peer, NTP, 60 ping, 79, 84 prefer statement, in ntp.conf, 63 N name service, 27 choosing, 27 name service switch default configuration, 26 troubleshooting, 27 netconf file, 31 netdaemons file, 69, 70 .
T TCP LISTEN status, 85 telnet, 21 troubleshooting, 87 tftp, 21 time server roles, 60 time sources location, 51 time synchronization, 59 timeserver hierarchy, 59 timeservers local impersonators, 49 public, 49 radio receiver, 50 tracing, 79 troubleshooting, 77 ftp, 88 name service switch, 27 networks using repeaters or gateways, 79 NTP, 72 rlogin, 90 security, 87 servers, 83 telnet, 87 tools, 78 U uname, 92 Universal Coordinated Time, see UTC, 59 UTC, 59 V /var/adm/inetd.sec file (see inetd.
