Chapter 11
inetd: the Internet super server
|
|
|
|
| ![](gif/black.gif) |
In this chapter: |
|
| |
![*](gif/bullet.gif) ![](gif/clear.gif) |
Understanding inetd
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
Configuring inetd
|
|
|
|
![](gif/black.gif) |
|
We've spent a lot of time talking about networks, routing, interfaces,
subnets, and whatnot. None of this means very much if you've not first
asked yourself what you need a network for. If you use applications
and data only from your own machine, you don't need a network. So far,
we've shown you how to assure that one host can reach another, but we
haven't considered the reasons why you'd want to do this in the first
place. The answer is usually straightforward -- some other host
provides a desired service, or has data that the local host doesn't,
or needs a service or data that is present at the local host.
|
11.1 | 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.
|
11.2 | 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.
| |
![*](gif/bullet.gif) ![](gif/clear.gif) |
/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.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
/etc/rpc
Just like /etc/services, but with RPC (Remote Procedure
Call), services are mapped to names.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
/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:
| |
![*](gif/bullet.gif) ![](gif/clear.gif) |
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).
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
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.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
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.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
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.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
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.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
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.
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
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](gif/icon_xref.gif) |
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.
|
![XREF](gif/icon_xref.gif) |
The tcpd daemon and network security are discussed
more extensively in Chapter 26
.
|
|
|
![](gif/black.gif) |
Summary: |
|
The super daemon inetd is used to start other network
daemons on demand. It can be configured to listen in on a wide
range of network ports and activate the responsible daemon as soon
as a connection request for this specific daemon comes in.
|
![](gif/black.gif) |
|
| ![](gif/clear.gif) |