INETD(1M)INETD(1M)NAMEinetd - Internet ``super-server''
SYNOPSIS
/usr/etc/inetd [ -R rate ] [ -d ] [ -l qlen ] [ -s ]
[ -X extended configuration file ]
[ -t {on|off|all}[:{accept|reject}] ]
[ -S {on|off|all|wrap} ]
[ configuration-file ]
DESCRIPTION
When inetd is started at boot time by /etc/init.d/network, it reads its
configuration information from the /etc/inetd.conf and listens for
connections on certain internet sockets. When a connection is found on
one of its sockets, it decides what service the socket corresponds to,
and invokes a program to service the request. After the program is
finished, it continues to listen on the socket (except in some cases
which will be described below). Essentially, inetd allows running one
daemon to invoke several others, reducing load on the system.
OPTIONS-R This option controls the maximum number of times a service can be
invoked in one minute; the default is 1000.
-d This option turns on debugging information. Note that this can
confuse some applications; use this cautiously.
-f This option is no longer supported and will simply cause a warning
message to be included in the syslog if used.
-l This option changes the listen queue length used for TCP sockets.
By default this value is 255.
-s Causes inetd to just parse the configuration file (default is
/etc/inetd.conf) and report any errors. Do not need superuser
privileges to run inetd using this option.
-X This option is used to specify an alternate extended configuration
file (default is /etc/inetd.conf.sec).
-t Controls when inetd uses tcp_wrappers(8) to accept or deny access to
services using hosts_access(5). This option may take the following
values:
off This is the default.
on Only services marked with the prefix '!' in the specified or
default inetd configuration file are controlled by
tcp_wrappers. You can control ``internal'' service using this
prefix, including the tcpmux service.
Page 1
INETD(1M)INETD(1M)
all All services (including ``internal'') are controlled by
tcp_wrappers. No special prefix is required.
NOTE: See TCP_WRAPPERS configuration section for details.
It is also possible to set the default accept/reject behavior when
an ERROR occurs when performing tcp_wrapper processing. These
errors can be related to configuration and system resource problems.
The default policy can be set by appending either
:accept(Default=accept) or :reject to the the -t command-line flag.
For example, -t on:reject would reject the connection when there's
an error. PLEASE NOTE This does not set or change the default
policy where a service is not defined in /etc/hosts.allow or
/etc/hosts.deny files.
-S Causes inetd to set a new session id ( setsid(2) ), when forking a
service, according to the following table below:
off This is the default. The forked service ( ftpd for example )
inherits the session id from inetd and, therefore, has the same
process group id of inetd. This may not be true if the service
calls setsid() itself.
on Services marked with the prefix '@' in inetd configuration file
( /etc/inetd.conf ) have a their own session id.
all All services ( including ``internal'' ) have a their own
session id.
wrap Enable ``setsid'' feature only for ``tcp_wrappe'd'' services
enabled via the ``-t'' switch.
NOTE: When the ``set session id'' feature is used, the forked
service does not have the same process group id of inetd and a
direct consequence is the command ``killall -g inetd'' will not
send the signals to the child of inetd where that feature has
been used.
To specify a different configuration file or use different options, put
configurations parameters in the file /etc/config/inetd.options. Any
empty lines or lines starting with a ``#'' are ignored.
CONFIGURATION FILE
Each line of the configuration file must be a valid service or a comment.
Comments are denoted by a ``#'' at the beginning of a line. Each field
in a line must be specified, with values for each field separated by a
tab or a space. The fields are as follows:
service name
socket type
protocol
wait/nowait
user
Page 2
INETD(1M)INETD(1M)
server program
server program arguments
There are three types of services that inetd can start: standard, RPC and
TCPMUX. A standard service has a well-known port assigned to it and is
listed in /etc/services or the NIS services map (see services(4)); it may
be a service that implements an official Internet standard or is a BSD
Unix-specific service. RPC services use the Sun RPC calls as the
transport; such services are listed in /etc/rpc or the NIS rpc map (see
rpc(4)). TCPMUX services are nonstandard services that do not have a
well-known port assigned to them. They are invoked from inetd when a
program connects to the ``tcpmux'' well-known port and specifies the
service name. This feature is useful for adding locally-developed
servers.
For standard Internet services, the service name field is the name of a
valid service in the services(4) database. For ``internal'' services
(discussed below), the service name must be the official name of the
service (that is, the first field in /etc/services). For RPC services,
the value of the service name field consists of the RPC service name,
followed by a slash and either a version number or a range of version
numbers (e.g., mountd/1). For TCPMUX services, the value of the service
name field consists of the string ``tcpmux'' followed by a slash and the
locally-chosen service name. If the service name begins with a ``+'', it
indicates inetd will handle the initial handshake with the requesting
program, otherwise the service is responsible for the handshake. (The
handshake is described in the inetd section in the IRIX Network
Programming Guide.) The service names listed in /etc/services and the
name ``help'' are reserved. The ``help'' name causes inetd to list
available TCPMUX services. Private protocols should use a service name
that has a high chance of being unique. A good practice is to prefix the
service name with the name of your organization. Multiple versions of a
protocol can suffix the service name with a protocol version number.
The socket type should be one of ``stream'', ``dgram'', or ``raw'',
depending on whether the socket is a stream, datagram, or raw socket.
TCPMUX services must use ``stream.''
The protocol must be a valid protocol. Examples are ``tcp'' and ``udp'',
both of which imply IPv4 for backward compatability. The protocols
``tcp4'' and ``udp4'' specify IPv4 only; ``tcp6'' and ``udp6'' imply IPv6
only. The protocols ``tcp46'' and ``udp46'' indicate that the service
should accept requests that arrive via IPv4 or IPv6. When ``tcp46'' or
``udp46'' is specified, IPv4 requests arrive via IPv4-mapped IPv6
addresses. For RPC services, the field consists of the string ``rpc''
followed by a slash and a specification of the transport protocol ,e.g.,
rpc/tcp, rpc/tcp4, rpc/tcp6, rpc/udp, rpc/udp4, etc. Note that ``tcp46''
and ``udp46'' should be avoided with RPC services, see the NOTES section
below. If 2 RPC services use the same server program with different
protocols, such as tcp and udp, the 2 services need to appear in protocol
lexicographic order. TCPMUX services must use ``tcp'', ``tcp4'', ``tcp6''
or ``tcp46''.
Page 3
INETD(1M)INETD(1M)
The wait/nowait entry specifies whether the server that is invoked by
inetd will take over the socket associated with the service access point,
and thus whether inetd should wait for the server to exit before
listening for new service requests. Datagram servers must use wait, as
they are always invoked with the original datagram socket bound to the
specified service address. These servers must read at least one datagram
from the socket before exiting. If a datagram server connects to its
peer, freeing the socket so inetd can received further messages on the
socket, it is said to be a ``multi-threaded'' server; it should read one
datagram from the socket and create a new socket connected to the peer.
It should fork, and the parent should then exit to allow inetd to check
for new service requests to spawn new servers. Datagram servers which
process all incoming datagrams on a socket and eventually time out are
said to be single-threaded. Talkd(8) is an example of the single-
threaded datagram server. Tftpd(8) is an example of a multi-threaded
datagram server.
Servers using stream sockets generally are multi-threaded and use the
nowait entry. Connection requests for these services are accepted by
inetd, and the server is given only the newly-accepted socket connected
to a client of the service. Most stream-based services operate in this
manner. Stream-based servers that use wait are started with the
listening service socket, and must accept at least one connection request
before exiting. Such a server would normally accept and process incoming
connection requests until a timeout. RPC services usually wait. TCPMUX
services must use nowait.
The user field 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.
The server program field should contain the pathname of the program which
is to be executed by inetd when a request is found on its socket. If
inetd provides this service internally, this field should be
``internal''. For non-internal services, the arguments to the server
program should be just as they normally are, starting with argv[0], which
is the name of the program. There is a limit of 11 arguments per program
(including argv[0]).
The following combination of prefixes, placed just before the server
program pathname, causes the following options to be turned on according
to the following table:
? Suppress error logging of a missing server. As shipped,
/etc/inetd.conf uses `?' to suppress error logging for servers
that are included in optional software packages.
! When tcp_wrappers options is enabled via `-t on', host access
to the service can be enable by prefixing the pathname with a
'!'.
Page 4
INETD(1M)INETD(1M)
@ When the ``set session id'' option is enabled via `-S on', a
new session id is created for the forked service.
Inetd provides several trivial services internally by use of routines
within itself. These services are ``echo'', ``discard'', ``chargen''
(character generator), ``daytime'' (human readable time), ``time''
(machine readable time, in the form of the number of seconds since
midnight, January 1, 1900), and ``tcpmux'' (service multiplexor). All of
these services are TCP-based. For details of these services, consult
RFCs 862, 863, 864, 867, 868, and 1078.
Inetd rereads its configuration file when it receives a hangup signal,
SIGHUP. Services may be added, deleted or modified when the
configuration file is reread. To disable a service, add the comment
character ``#'' at the beginning of the service's line in inetd.conf and
send SIGHUP to inetd with the command
/etc/killall -HUPinetd
Inetd supports an additional extended configuration file. Each entry of
this configuration file must be a valid service or a comment. Comments
are denoted by a ``#'' at the beginning of a line. The format of each
entry is a service name followed by any number of name-value pairs
separated by tabs or spaces. If the service name doesn't match an entry
in inetd.conf then the entry is ignored. Each name-value pair consists
of a feature name, followed by an '=' and the value of that feature.
Undefined feature names are ignored. The only feature name currently
supported is 'cap' which is used to specify the capability set to invoke
the service daemon with.
For RPC services inetd respects the mapping of RPC program numbers to UDP
or TCP ports defined in the /etc/rpcports file.
TCP_WRAPPERS configuration and implementation
All services ( including TCPMUX and internal ) services can be controlled
by the tcp_wrappers switch -t. To control them, use the following
``server'' entries for configuring the hosts_access(5) file:
o Use the ``service name'' itself. For connecting to the TCPMUX
service, use ``tcpmux''.
o To control a specific tcpmux service, use the name of the
service (i.e. what is listed after tcpmux/). For example,
``sgi_printer''.
o To control access to the TCPMUX ``help'' service, use the name
``tcpmux_help''.
Please note only stream/nowait and dgram services can be controlled via
the tcp_wrappers feature. See tcp_wrappers(8) manual pages for details.
Page 5
INETD(1M)INETD(1M)ERROR MESSAGES
Inetd logs error messages using syslog(3B). Important error messages and
their explanations are:
service/protocol server failing (looping), service terminated.
The number of requests for the specified service in the past minute
exceeded the limit. The limit exists to prevent a broken program or a
malicious user from swamping the system. This message may occur for
several reasons: 1) there are lots of hosts requesting the service
within a short time period, 2) a 'broken' client program is requesting
the service too frequently, 3) a malicious user is running a program to
invoke the service in a 'denial of service' attack, or 4) the invoked
service program has an error that causes clients to retry quickly. Use
the -R option, as described above, to change the rate limit. Once the
limit is reached, the service will be reenabled automatically in 10
minutes.
service/protocol: No such user 'user', service ignored
service/protocol: getpwnam: user: No such user
No entry for user exists in the passwd file. The first message occurs
when inetd (re)reads the configuration file. The second message occurs
when the service is invoked.
service: can't set uid number
service: can't set gid number
The user or group ID for the entry's user is invalid.
too many services: open-file limit reached.
The number of services in the configuration file exceeds the number of
file descriptors that inetd can keep open. Unnecessary services must be
removed or commented out or the kernel must be reconfigured to increase
the limit (the NOFILES parameter in /var/sysgen/master.d/kernel.)
service/protocol: all allowed ports in use.
Rules in the /etc/rpcports file specified a range of ports for the
service, but all the ports in that range were already bound to other
sockets. Inetd will fall back to using any non-reserved port for the
service.
EXAMPLES
Here are several example service entries for the various types of
services
Page 6
INETD(1M)INETD(1M)
ftp stream tcp6 nowait root /usr/etc/ftpd ftpd -l
ntalk dgram udp wait root /usr/etc/talkd talkd
rusersd/1 dgram rpc/udp wait root /usr/etc/rpc.rusersd rusersd
tcpmux/+date stream tcp nowait guest /bin/date date
Here another example where (1) tcpmux is controlled by hosts_access if
inetd command-line options ``-t'' is turned on (2) tcpmux and setsid() (
if command-line options ``-S'' is turned on ) are utilized for rshd.
Also, if /usr/etc/rshd is not present, inetd will not output an error
message in SYSLOG.
tcpmux stream tcp nowait root !internal
echo stream tcp nowait root internal
shell stream tcp6 nowait root !@?/usr/etc/rshd rshd -L
Here is an example entry for the extended configuration file
exec cap=CAP_SETUID,CAP_SETGID,CAP_SETPCAP+ip
NOTE
If NIS is enabled on your system, inetd uses the NIS equivalents of
/etc/services and /etc/rpc. Make sure your NIS server's services and rpc
databases contain the entries listed in these files.
NOTESinetd has a limit of 512 characters per line of the configuration file.
Exceeding this limit may cause inetd to terminate abnormally.
If both TCP and UDP services are listed for an RPC service, the TCP
service should be listed first.
Since IRIX 6.5.22, RPC services are bound after all non-RPC services.
This prevents occasional collision when RPC services grabs a port
reserved by a non-RPC service.
Using a protocol value of ``udp46'' or ``tcp46'' for RPC services can
lead to unexpected problems because a udp4 or tcp4 service can also be
bound to the same port and divert traffic from the udp46 or tcp46 socket.
Instead of using ``udp46'' RPC services should be listed in two separate
entries, one with a protocol of ``udp'' and another with a protocol of
``udp6''. Likewise, use two entries with ``tcp'' and ``tcp6'' instead of
one entry with ``tcp46''.
As of IRIX 6.5.26, inetd will attempt to use the rpcbind(1M) protocol to
register RPC services, and will fall back to portmap(1M) if rpcbind is
not running.
Page 7
INETD(1M)INETD(1M)SEE ALSOftpd(1M), rexecd(1M), rlogind(1M), rshd(1M), telnetd(1M), tftpd(1M),
rpcports(4), tcp_wrappers(8), hosts_access(5), setsid(2).
sockets programming chapter in the IRIX Network Programming Guide.
RFCs are available from the Network Information Center at SRI
International, Menlo Park, CA.
Page 8
