|
|
United States-English | |
|
|
 |
|
Release Notes for HP-UX 10.20: HP 9000 Computers > Chapter 6 Networking
Internet Services (ARPA Services) |
|
|
For 10.20: The Internet Services product is essential for networking with the UNIX core software. These services, described in this section, are:
For 10.10:
For 10.0: Internet Services was the new 10.0 name for what has been called ARPA Services in pre-10.0 HP-UX releases. The Internet Services include not only the ARPA Services, but also services from Berkeley (BSD) and other sources. The following product areas are included:
The following sections summarize the major changes to this product. For 10.20: The rlogin/rlogind internet service has been enhanced to work with 4-byte EUC (Extended Universal Character set). To support this feature, the pseudo terminal in rlogind now uses a STREAMS-based pty driver. The STREAMS master pty driver is ptm and the device used is /dev/ptmx. The STREAMS slave pty driver is pts and the slave devices used are /dev/pts/number. This change to rlogin has an important effect on one of the tuning parameters of the kernel, namely NSTRPTY. Because rlogind now uses the STREAMS-based pseudo terminal, the kernel parameter to be tuned for rlogin pseudo terminals is NSTRPTY, rather than NPTY, which is used for pseudo terminals using the traditional pty driver. An additional effect of this change is that for rlogin-based pseudo terminals, an execution of the tty command will now display /dev/pts/number rather than /dev/ttynumber. For 10.20: In HP-UX 10.20 there is a new optionally installable product called InternetSvcSec. This product provides alternative versions of the following internet services: ftp, remsh, rcp, rlogin, and telnet. These alternative versions of the services incorporate Kerberos Version 5 Beta 4 authentication and authorization and are referred to as the "Secure Internet Services". The Secure Internet Services are meant as replacements for their non-secure counterparts. The main benefit of running the Secure Internet Services is that user authorization no longer requires transmitting a password in a readable form over the network. Additionally, when both systems are operating in a Kerberos V5-based secure environment, the Secure Internet Services ensure that a local and remote host are mutually identified to each other in a secure and trusted manner and that the user is authorized to access the remote account. For ftp/ftpd, rlogin/rlogind, and telnet/telnetd, the Kerberos V5 authentication involves sending encrypted tickets instead of a readable password over the network to verify and identify the user. Although rcp/remshd and remsh/remshd do not prompt for a password, the secure versions of these services ensure that you are authorized to access the remote account.
The Secure Internet Services use Kerberos-specific port entries in /etc/services and the entries for kshell and klogin in /etc/inetd.conf. These entries are automatically present in HP-UX 10.20.
The Secure Internet Services require a Kerberos network authentication services environment which includes a properly configured Key Distribution Center (KDC). Supported KDCs are the HP DCE security server or any third-party KDC based on Kerberos Version 5 beta 4. A properly configured KDC must be running for the Secure Internet Services to work. InternetSvcSec is optionally installable. This product should be selected only if you want Kerberos authentication for the ftp, remsh, rcp, rlogin and telnet services. To install the product, invoke swinstall. The default view of the software is in the form of bundles. Change the software view to products and select the InternetSvcSec product for installation. The product contains the runtime fileset (INETSVCS-SEC), as well as filesets containing the manpages. In addition to the client/daemon man pages there is a new manpage called sis(5) that contains information common to all the Secure Internet Services, including warning and error messages. Within INETSVCS-SEC, there is a required startup script called inetsvcs_sec. To enable the product, invoke the command
For disabling, either invoke
or disable and remove the product using the swremove command.
Before using the Secure Internet Services, you must first obtain credentials from the KDC server. Usually this is done by issuing a kinit command. Once these initial credentials are obtained, the Secure Internet Services can be used throughout the time period that the credentials are valid. This period is configurable and is typically eight hours. There are no visible differences between using the secure and non-secure versions of the internet services, except that you are not prompted for a password and there are some new Kerberos-related options available. When you are finished with the session, remove accumulated credentials using the kdestroy command. 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. If any of the Secure Internet Services are installed in an environment where some of the remote systems on the network are non-secure, you can use the -P command line option to bypass Kerberos authentication. However, if accessing the host requires a password, the password will be sent in a readable form over the network. To protect the integrity of passwords on servers, you can prevent remote users from gaining access in a non-secure manner. For ftpd and telnetd to prevent access from non-secure clients, these daemons should be invoked with the -A option. This option enforces Kerberos authentication. For remshd and rlogind to prevent access from non-secure clients, the entries for shell and login in the /etc/inetd.conf file should be commented out. For any service, if these steps are taken, the client cannot use the -P option to bypass authentication for that service. For 10.20: sendmail is the mail transport agent daemon that implements the SMTP mail protocol. For 10.20, the sendmail transport agent daemon is based on the public domain sendmail version 8.7. This is an upgrade from the previous HP-UX version of sendmail, which was based on version 5.65. The new version offers the same basic functionality as the previous version, but features significant new functionality and configuration flexibility, including a wide variety of new and extended options. The new features of sendmail version 8.7 are:
For 10.20: The basic sendmail functionality is not changed. There should be little impact on backward compatibility. You can still invoke sendmail as a mail user agent or mail transport agent with most of the same options. HP-UX 10.20 sendmail uses Version 6 sendmail configuration files; previously, sendmail used Version 1 sendmail configuration files. You cannot use an earlier version sendmail configuration file with HP-UX 10.20 sendmail. There are three options available for migrating your configuration file:
Frozen files were hashed versions of the configuration file sendmail.cf. Frozen files were often problematic and are no longer a part of sendmail. Thus, both /etc/freeze and the -bz option have been removed. The standard sendmail.cf file is used instead. HP no longer supports the /etc/mail/rev-aliases file that allowed a user to rewrite the "From:" line on outgoing mail based on a lookup to that rev-aliases database. Instead, the userdb.db file can be used. Prior to HP-UX 10.20, sendmail tried to connect to a host directly if there were no MX records for the destination. To revert to this behavior, you must uncomment the option TryNullMXList. There are no differences between the s700 and s800 versions of sendmail. The removal of sendmail.fc (the frozen version) should have only a nominal affect on sendmail's performance. The database support improvements to .db files should help to offset this performance difference. Also, the improvement of timeout controls mentioned earlier should permit better tuning. The remote mode of sendmail was enhanced at 10.0. Delivery of out-bound mail messages and receipt of in-bound mail messages have been modified to support 8-bit data for electronic mail messages using E-SMTP and to handle non-"DUX" environments and the 10.0 file system layout. The Remote-mode feature was added for users on sendmail clients. For more information on sendmail, refer to the sendmail(1M) manpage. For 10.0: Subnets of the same IP network number that have different sizes (that is, different masks) are called variable length subnets. The use of variable length subnetting techniques can help defer the onset of 32-bit IP address space exhaustion on the Internet by slowing down the need for allocating new IP network numbers. Packets within these subnets are routed to the best (longest or most specific) match. The following variable length subnet features have been added at 10.01:
For 10.0: If DNS is used on a 10.x host, there are a few small differences in behavior between 9.x and 10.x systems; these differences are especially noticeable if the domain keyword is used instead of the search keyword in resolv.conf, or if the local domain is generated from the system's hostname (when no resolv.conf is present). If the domain keyword is used in the resolv.conf file, a multi-level search list is no longer generated by default, and partially qualified hostnames may not work with most networking commands as they did with 9.x. For example, on 9.x, domain mkt.aone.com creates the search list mkt.aone.com aone.com. On 10.x, domain mkt.aone.com creates the search list mkt.aone.com. To generate 9.x behavior on 10.x, you need to replace the domain keyword in the resolv.conf file with the search keyword (in this example, use search mkt.aone.com instead of domain mkt.aone.com). If you are already using the search keyword instead of the domain keyword, the behavior will be the same as in 9.x. However, if you do convert from the domain keyword to a search keyword, read RFC 1535 (located in /usr/share/doc) to familiarize yourself with the security concerns. The second change is that hostnames with a dot (.) in them are tried first without appending any of the resolver search list items. This happens whether or not the hostname was provided in a partially or fully qualified form. The default is to do this when at least one dot is present in the name; however, this value is adjustable with the options keyword and the ndots option. If you use this option and the number of dots does not reach the threshold, the search list items are appended. If they then fail, the name is tried without appending any domains. Note that if you put a dot at the end of hostname, the resolver does not use the search list and the name is tried without appending any domains to it. Refer to the resolver(4) and hostname(5) manpages for more information on these changes. If the DNS resolver API is used, a small change is necessary for programs using the resolver structure including the declaring of the global library structure _res. The resolver structure type (defined in /usr/include/resolv.h) has been renamed from state to _res_state. This change does not affect binary compatibility. Refer to the resolver(3) manpage for more information. For 10.10: The mrouted daemon, a new feature in HP-UX 10.10, is a routing daemon that forwards IP multicast datagrams, within an autonomous network, through routers that support IP multicast addressing. The mrouted daemon implements DVMRP (the Distance-Vector Multicast Routing Protocol). DVMRP is an IGP (Interior Gateway Protocol) whose key purpose is to maintain the shortest return paths to the source of the multicast datagram. The mrouted daemon :
For detailed information on mrouted, refer to Chapter 8 "Configuring mrouted", of the Installing and Administering Internet Services Manual (B2355-90100) and to the mrouted(1M) manpage. For 10.10: The Name Service switch now allows the system administrator to configure the name service policy for additional network databases in addition to the host and IP address database. The new databases include: networks, protocols, services, rpc and netgroup. These new databases currently can use NIS or the local file as its data source. The administrator can make changes to the switch policy by directly editing the configuration file. See the switch (4) manpage, which describes the configuration file syntax and the various settings available. All code changes are contained within libc, thus any application that calls the routines to access services, protocols, networks, netgroup, and rpc databases can transparently gain this additional functionality. All applications built using shared libraries or the 10.10 archive libraries will indirectly use the new switch feature through these databases' access routines (for example, getnetbyname() and getservbyname()). The default configuration generates a behavior similar to that of previous HP-UX releases. Any application that accesses NIS or the local database files directly, or are built on older archived libraries, need to be modified to make use of the new switch feature. The netgroup database lookup routines setnetgrent(), getnetgrent(), endnetgrnt(), and innetgr() now support the Name Service Switch. The Name Service Switch now determines where your system will look for the information that is traditionally stored in the following files:
In previous releases, the Name Service Switch determined only where your system looked for /etc/hosts information. For all types of information except /etc/hosts information, you can configure your system to use NIS (one of the NFS Services), the local /etc file, or both, in any order. For /etc/hosts information, you can configure your system to use BIND (DNS), NIS, the /etc/hosts file, or any combination of the three, in any order. If you use the default Name Service Switch configuration, your system will behave the way it did before the Name Service Switch was available, so you do not have to configure the Name Service Switch. Enter man 4 switch for more information. For 10.0: The 10.0 Name Service Switch feature allows you to configure the name service policy for hostname and address lookups. This policy is used by the algorithms in the gethostbyname() and gethostbyaddr() library calls. You can choose any combination of the supported name services: DNS, NIS, and the local hosts file. Also, you can set the conditions under which an alternative name service is to be used. The conditions that can be controlled on a per-name service basis include name services that are unavailable, that do not contain an entry for the host, or that are non-responsive. You can make changes to the switch policy by directly editing the configuration file. The new switch(4) manpage describes the configuration file syntax and the various settings available. The name service switch is also described in the Installing and Administering Internet Services manual (B1031-90000). For 10.10: Talk is a new Internet service for 10.10 that allows users to communicate directly over the network. Two users connected through the talk service can send and receive text, typed simultaneously, on terminals at both ends. For more information, see the talk(1) and talkd(1M) manpages. For 10.10: The OSPF (Open Shortest Path First) protocol is one of the routing protocols handled by gated. In HP-UX 10.10, OSPF MIB (Management Information Base) support has been added to gated. The OSPF MIB objects are accessed through an SNMP (Simple Network Management Protocol) subagent called ospfagt.
The OSPF MIB can be accessed through the HP Network Management OpenView MIB browser. You can create OpenView applications using the information provided by the MIB browser. (HP does not provide any OpenView applications.) In general, OSPF MIB provides useful status and statistical information related to the OSPF protocol. For more information on OSPF MIB objects, refer to RFC1253 (OSPF Version 2 Management Information Base). The addition of OSPF MIB support does not create any compatibility issues with previous versions of gated, does not require any additional gated configuration to access this new feature, and has no affect on gated performance. For more information on using the OSPF MIB feature, refer to the section titled "Accessing the OSPF MIB", in Chapter 7, "Configuring gated", of the Installing and Administering Internet Services Manual (B2355-90100). For 10.0: gated is a routing daemon that handles multiple routing protocols. It uses RIP, HELLO, and OSPF to collect information from within an autonomous system, and it uses BGP and EGP to advertise routes to another autonomous system. The gated daemon can be configured to perform all of the supported protocols or any combination of them. For more information on gated, refer to the gated(1M) manpage. Also, note that although BGP is provided in gated, it is not officially supported by Hewlett-Packard on releases 9.x, 10.0, or 10.01. At HP-UX 10.0, support for the OSPF (Open Shortest Path First) protocol was added. OSPF uses a link state routing algorithm to determine routes. Each router on the network maintains an identical database describing the autonomous systems topology. Using the database information, each router constructs its own routing table of shortest paths from itself to each destination in the Autonomous System. OSPF overcomes the limitations of RIP and provides capabilities not found in RIP. With OSPF, a shorter convergence time can be achieved. Variable length subnet mask support has been added to gated at 10.01. Networks can be partitioned into different sizes of subnets. If the networks within an autonomous system or domain continue to have subnets of the same size, no configuration changes are required. Otherwise, minor modifications may be needed. There are few mask statements in the gated configuration, and they are all optional. Two mask statements are under the OSPF protocol specification, and both are used to aggregate subnet routes: The mask under the area networks statements is used only by the area border routers, and the mask under the backbone networks is used by the backbone routers. Note that you should avoid mixing networks that are partitioned into variable length subnets (with the support of the variable subnet masks) with networks that do not have this support in an autonomous system or domain. Nodes without this support do not contain the subnet mask information in the kernel routing table and therefore may fail to route packets to their proper destination. For more detailed information, refer to the Installing and Administering Internet Services manual (B1031-90000) and the gated.conf(4) manpage. For 10.0: The bootp relay agent, a new feature at 10.0, is provided as a part of the bootp daemon to enable booting across gateways. When a client resides on a different subnet/LAN from the server, a bootp relay agent is needed to run on a host on the same subnet as the client. When the client sends out a bootp broadcast request, the relay agent relays the bootp request to the bootp server and also relays the reply back to the client. The bootptab file is used as the default configuration file for configuring the bootp relay agent (that is, the server(s) to relay the bootp request to). Changes to the relay agent configuration need to be made manually in the bootptab configuration file. Additional information on the bootp relay agent function and configuration is in the bootpd(1M) manpage. For 10.0: The following two enhancements were added to the TFTP server at 10.0:
For more information, refer to the tftpd(1M) manpage. For 10.0: The rdist service was added at 10.0. rdist is designed to distribute files from a central server. It simplifies the task of maintaining identical copies of files on multiple systems. For example, you can modify files on the server, and then use rdist to propagate the files to the other systems in the network. For more information, see the rdist(1) manpage and the the section on rdist in the Installing and Administering Internet Services manual (B1031-90000). For 10.0: Network Time Protocol (NTP), which is a time synchronization service for the Internet architecture, was added at 10.0. NTP provides a mechanism to synchronize time and coordinate time distribution in a large, distributed internet. NTP operates in various modes to improve efficiency. A configuration file is used to configure NTP execution parameters such as communication mode with other NTP servers. The default configuration file is /etc/ntp.conf. Network Time Protocol Query (ntpq), a tool to query the status of NTP servers, has also been added. It can be run in command-line mode as well as in interactive mode. Network Time Protocol Date (ntpdate) is a tool to set the local host's date and time by polling the Network Time Protocol Servers. Descriptions of the NTP functions and configurations, ntpq, and ntpdate are in the following manpages: xntpd(1M), ntpq(1M), ntpdate(1M). For 10.0: Two new options to the File Transfer Protocol service (ftp/ftpd) were added at 10.0:
For more information, refer to the ftp(1) and ftpd(1M) manpages. For 10.0: nslookup, the diagnostic tool for name service resolution, was updated at 10.0 to recognize the name service switch (see the previous information on "Name Service Switch" in this section) and to provide some limited switch-related diagnostics. These changes include the addition of three new interactive-mode commands:
Two new options have also been added for tracing actions affected by the switch:
For more information on nslookup, refer to the nslookup(1) manpage. For 10.0: Two new headers in every mailx message to support 4-byte EUC and MIME were added at 10.0:
For more information on mailx, refer to the mailx(1) manpage. For 10.0: 10.x telnet supports SD (see “Software Distributor”), the 10.0 file system layout conventions (see “The HP-UX 10.0 File System Layout”), and port identification device files in a special directory (/dev/telnet). HP-UX 10.x includes a script (/usr/contrib/bin/ddfa_dev_mig) that will help you move device files to this special directory. In addition, telnet supports the following new options at 10.01:
For more information on telnet, refer to the telnet(1) and telnetd(1M) manpages. For 10.0: The whois command is new for 10.01. It is somewhat similar to a phone book lookup utility, and it is of interest primarily to military and government users. whois queries a database that is kept at the Network Information Center (NIC) and returns information about persons and organizations that are listed there. You must be able to make a direct socket connection to the NIC in order to get any response. The database at the NIC is often heavily loaded, so response can be slow. Also, vague or ambiguous requests (for example, "Smith") can take a long time to process and produce hundreds of pages of output. For more information, refer to the whois(1) manpage. For 10.0: 10.x DDFA supports SDU and the 10.0 file system layout conventions, as well as having pseudonym device files in a special directory (/dev/telnet). The /usr/contrib/bin/ddfa_dev_mig script facilitates moving device files to this special directory. DDFA also has more readable error messages and a way to filter the severity level of messages to be displayed. In addition, DDFA allows ARPA node names in place of IP addresses. DDFA now supports outgoing connections to devices on non-HP terminal servers, provided they use one of the supported options for defining the output device in the dp configuration file. These options include:
For additional information, refer to the dpp(1M) and ocd(1M) manpages. For 10.0: NetIPC, a Hewlett-Packard proprietary networking Application Programming Interface (API), is not supported on HP-UX 10.x. All of the NetIPC system calls, the sockreg daemon, rlb daemon, rlb diagnostic, nodename command, proxy command, and PROBE proxy services are not supported. HP-UX 10.x has no concept of the NS nodename space. As a result, HP-UX 10.x will not use PROBE to resolve name-to-address mapping and will not respond to PROBE name requests from other machines (HP 3000s, HP 1000s, PCs, and pre-10.0 HP 9000s). However, HP-UX 10.x will respond to PROBE Virtual Network Address (VNA) requests. All applications and services that use NetIPC need to be migrated to BSD Sockets (unless you do not want to update them to HP-UX 10.x). HP integration sockets, vt3k, X.400, and AllBase/Net are still supported, but dscopy is not. For more information on NetIPC, refer to the NetIPC to BSD Sockets Migration Guide (98194-90045). For additional ARPA transport information, refer to the Installing and Administering LAN/9000 Software manual (98194-90057). New features added to TCP/IP at 10.0 include the following:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
