Administering your TCP/IP network

Configuring TCP and UDP services

A request for service from a client process is handled by a daemon process running on a server. The client process may be running on the same system as the server process or the processes may be running on different systems that are connected via a network.

A TCP service requires the establishment of a long-term connection between a client and a server for the exchange of information. Applications that use the TCP protocol as their transport protocol can automatically take advantage of built-in reliablity features such as flow control and retransmission.

A UDP service provides a simple one-time response by a server to a request from a client. The UDP protocol does not establish a connection and it does not check that a transmitted UDP datagram reaches its destination. Applications that use UDP for their transport protocol must implement reliability themselves if they require this.

The TCP and UDP services that your system knows about are defined in the /etc/inet/services file (see services(4tcp)).

Several TCP/IP service daemons are always configured to be running on your system because they are frequently used or because there is a large system performance overhead involved in starting them. An example is the network unicast routing daemon, routed(1Mtcp) which is configured to run via an entry in the /etc/inet/config configuration file (see config(4tcp)). Other daemons that are listed in this file, such as the Internet domain name server daemon, named(1Mtcp), and the Network Time Protocol (NTP) daemon, xntpd(1Mtcp), also require their own configuration file to be present in the appropriate location before they will run.

Other services may require several instances of a server daemon to be run to handle requests from different clients, or may be less frequently used so their continual presence on a system is not desirable for the sake of performance. Daemons for such services are usually started by the Internet services daemon, inetd(1Mtcp) which is itself started by the Service Access Facility (SAF). Examples are the File Transfer Protocol (FTP) daemon, ftpd(1Mtcp), and the remote login daemon, rlogind(1Mtcp). If inetd receives a request for a service on a TCP or UDP port on which it has been configured to listen, it responds by starting the appropriate service daemon or rejecting the request. The daemon processes that inetd can start are defined in the /etc/inet/inetd.conf file (see inetd.conf(4tcp)).

By default, inetd does not start Internet service daemons directly. Instead, it runs the TCP wrapper daemon, in.tcpd, which controls access to services by hosts. If the wrapper daemon decides that a host is permitted access, it invokes the service daemon. If it decides that a host is bogus, it can deny access and send a report of the incident to an administrator. See ``TCP Wrappers'' for more information.

The inetd.conf file contains two configuration lines for each Internet service daemon: one to start the daemon via in.tcpd, and the other to start the daemon directly. One or both entries for a service are commented out using a ``#'' character at the start of the line. If both entries are commented out, inetd will not start the service provided that it has been told to read the file since you last changed it.

To make inetd re-read inetd.conf, send it a SIGHUP signal using the following command:

kill -HUP `cat /etc/saf/inetd/_pid`

or stop and restart it:

sacadm -k -p inetd
sacadm -s -p inetd

If you want to enable a service, remove the comment character from the start of the appropriate line in the pair of lines for the service, ensure that the other line is commented out, and then stop and restart inetd.

Similarly, if you want to disable a service, comment out both lines for the service, and then stop and restart inetd.


NOTE: Service daemons which can present a security risk, such as fingerd(1Mtcp) and tftpd(1Mtcp), are normally configured not to be run by inetd.


© 1999 The Santa Cruz Operation, Inc. All rights reserved.
UnixWare 7 Release 7.1.1 - 5 November 1999