inetd: the Internet super server

inetd: the Internet super server



==> Understanding inetd
==> Configuring inetd


What does inetd do?


To provide services over the network, you need an application that understands your requests and can provide that service. These applications usually work behind the scenes, without any user interface and interaction. This means that they are not visible in the normal work environment.

They are called daemons or network daemons. A daemon "listens" on a specific port for incoming requests. When a request arrives, the daemon "wakes up" and begins to perform a specific operation.

If you want to have many services available on your machine, you need to run a daemon for each service. These daemons need memory, take up space in the process table, and so on. For frequently used services, standalone daemons make sense. For services that receive few requests, they're a waste of resources.

To help you optimize your resources, there is a super server that can be configured to listen in on a list of ports and invoke the specific application the moment a request for the application arrives. This daemon is inetd. Most of the network daemons offer you the option to set them to run as stand-alone applications, or to be invoked by inetd on demand. Although the setup with inetd saves resources in the time the service is not used, it creates a delay for the client. The daemon for this service has to be loaded and probably has to initialize itself before it's ready to serve the request. You might think about which services you want to run as stand-alone applications and which ones you want to be called by inetd.

HTTP servers such as Apache are likely to be run as stand-alone services. Apache needs a relatively long load time, and you don't want your customers waiting too long while your Web site loads. Apache is highly optimized to run in stand-alone mode, so you probably don't want it to be spawned by inetd. A service such as in.telnetd, which enables logins from other machines, doesn't need much time to load. It makes a good candidate for being invoked by the super server.

You should be sure that you need inetd before you set it up. A client machine that primarily acts as a workstation has no need to run inetd, because the client machine is not meant to provide any services for the network. You probably don't need inetd for home machines. It's basically a question of security. Using inetd on machines on which you really don't need it may reveal possible entry points for crackers. Running inetd-enabled services such as telnet and rlogin can be used to exploit your machine. This doesn't mean that those services are generally insecure, but they may be a first source of information for potential crackers trying to enter your system.

During the installation, SuSE asks whether inetd should be started. The referring variable in /etc/rc.config is START_INETD. If it is set to yes, inetd will start at system boot time.

Configuring inetd


The inetd daemon reads several files in /etc when it's executed. The main configuration file is /etc/inetd.conf. It specifies which daemon should be started for which service.

The other files it reads are shared with other daemons and contain more general information about Internet services.


* /etc/services
This file maps port numbers to service names. Most of the port numbers below 1024 are assigned to special services (specified in RFC 1340). These assignments are reflected in this file. Every time you refer to a service by its name (as opposed to its port number), this name will be looked up in /etc/services and the referring port number will be used to process your request.
* /etc/rpc
Just like /etc/services, but with RPC (Remote Procedure Call), services are mapped to names.
* /etc/protocols
Another map. Here, protocols are specified and mapped to the numbers the kernel uses to distinguish between the different TCP/IP protocols.


Usually none of these files needs to be edited. The only candidate for changes is /etc/services. If you run some special daemon on your system (such as a database engine), you may want to add the port number of this service to this list.

The inetd daemon needs these files because in its own configuration file /etc/inetd.conf, these names are used to specify which daemon should be started to serve each service. Each line defines one service. Comment lines (starting with a hash sign -- #) and empty lines are ignored. The definition lines have seven fields, which must all contain legal values:


* service name
The name of a valid service in the file /etc/services. For internal services (discussed in the next chapter), the service name must be the official name of the service (that is, the first entry in /etc/services). When used to specify a Sun-RPC based service, this field is a valid RPC service name like listed in the file /etc/rpc. The part on the right of the slash (/) is the RPC version number. This can simply be a single numeric argument or a range of versions. A range is bounded by the lowest value to the highest value (for example, rusers/1-3).
* socket type
These should be one of the keywords stream, dgram, raw, rdm, or seqpacket, depending on whether the socket is a stream, datagram, raw, reliably delivered message, or sequenced packet socket.
* protocol
The protocol must be a valid protocol as listed in /etc/protocols. Examples might be tcp or udp. RPC-based services are specified with the rpc/tcp or rpc/udp service type.
* wait/nowait.max
The wait/nowait entry is applicable to datagram sockets only (other sockets should have a nowait entry in this space). If a datagram server connects to its peer, freeing the socket so that inetd can receive further messages on the socket, it is said to be a multithreaded server and should use the nowait entry. For datagram servers that process all incoming datagrams on a socket and eventually time out, the server is said to be single-threaded and should use a wait entry. Comsat(8) and talkd(8) are both examples of the latter type of datagram server. The optional max suffix (separated from wait or nowait by a period) specifies the maximum number of server instances that may be spawned from inetd within an interval of 60 seconds. When omitted, it defaults to 40.
* user.group
This entry should contain the user name of the user as whom the server should run. This allows for servers to be given less permission than root. An optional group name can be specified by appending a dot to the user name followed by the group name. This allows for servers to run with a different (primary) group id than specified in the password file. If a group is specified and user is not root, the supplementary groups associated with that user will still be set.
* server program
The server-program entry should contain the pathname of the program that is to be executed by inetd when a request is found on its socket. If inetd provides this service internally, this entry should be internal.
* server program arguments
This is the place to give arguments to the daemon. Note that they are starting with argv[0], which is the name of the program. If the service is provided internally, the keyword internal should take the place of this entry.


The inetd daemon provides several trivial services internally by use of routines within itself. These services are echo, discard, chargen (character generator), daytime (human readable time), and time (machine readable time, in the form of the number of seconds since midnight, January 1, 1900).

XREF These services are discussed more extensively in Chapter 12 .


Some examples can show you how it works. To enable telnet into the machine, you will need a line like this in /etc/inetd.conf:



telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd



Telnet is the name of the service, it uses a stream socket and TCP protocol, and because it's a TCP service, you can specify it as nowait. The user ID the daemon should run with is root. The last two arguments give the path and name of the actual server application and its arguments.

You always have to give the program name here, because most daemons require it to get a argv[0].

An example for a datagram-based service is talk:



talk dgram udp wait root /usr/sbin/in.talkd in.talkd



You see the differences. Rather than stream you use dgram to specify a datagram type of service. The socket type is set to udp and inetd has to wait until the daemon exits before waiting for new connections.

Now if you look into the preinstalled /etc/inetd.conf file, you will notice that almost all services are using /usr/sbin/tcpd as a daemon for the service, and give the actual service daemon on the command line for tcpd. This is done to increase network security. The tcpd daemon acts as a wrapper and provides lists of hosts who are allowed to use this service. For the moment, think about tcpd as an in-between step that starts the daemon after checking whether the person requesting the service is actually allowed to do this. The SuSE default configuration allows everybody to connect to any port.