Index: inetd.8
===================================================================
--- inetd.8 (nonexistent)
+++ inetd.8 (revision 5)
@@ -0,0 +1,403 @@
+.\" Copyright (c) 1985, 1991 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\" must display the following acknowledgement:
+.\" This product includes software developed by the University of
+.\" California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\" may be used to endorse or promote products derived from this software
+.\" without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" from: @(#)inetd.8 6.7 (Berkeley) 3/16/91
+.\" $Id: inetd.8,v 1.18 2001/01/29 11:38:32 deraadt Exp $
+.\"
+.Dd March 16, 1991
+.Dt INETD 8
+.Os
+.Sh NAME
+.Nm inetd
+.Nd internet
+.Dq super-server
+.Sh SYNOPSIS
+.Nm inetd
+.Op Fl d
+.Op Fl R Ar rate
+.Op Ar configuration file
+.Sh DESCRIPTION
+.Nm inetd
+should be run at boot time by
+.Pa /etc/rc
+(see
+.Xr rc 8 ) .
+It then 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,
+.Nm inetd
+allows running one daemon to invoke several others,
+reducing load on the system.
+.Pp
+The options are as follows:
+.Bl -tag -width Ds
+.It Fl d
+Turns on debugging.
+.It Fl R Ar rate
+Specify the maximum number of times a service can be invoked
+in one minute; the default is unlimited. A rate of 0 allows an
+unlimited number of invocations.
+.El
+.Pp
+Upon execution,
+.Nm inetd
+reads its configuration information from a configuration
+file which, by default, is
+.Pa /etc/inetd.conf .
+There must be an entry for each field of the configuration
+file, with entries for each field separated by a tab or
+a space.
+Comments are denoted by a
+.Dq #
+at the beginning
+of a line.
+There must be an entry for each field.
+The fields of the configuration file are as follows:
+.Pp
+.Bd -unfilled -offset indent -compact
+service name
+socket type
+protocol
+wait/nowait[.max]
+user[.group] or user[:group]
+server program
+server program arguments
+.Ed
+.Pp
+To specify a Sun-RPC
+based service, the entry would contain these fields.
+.Pp
+.Bd -unfilled -offset indent -compact
+service name/version
+socket type
+rpc/protocol
+wait/nowait[.max]
+user[.group] or user[:group]
+server program
+server program arguments
+.Ed
+.Pp
+For internet services, the first field of the line may also have a host
+address specifier prefixed to it, separated from the service name by a
+colon.
+If this is done, the string before the colon in the first field
+indicates what local address
+.Nm
+should use when listening for that service.
+Multiple local addresses
+can be specified on the same line, separated by commas.
+Numeric IP
+addresses in dotted-quad notation can be used as well as symbolic
+hostnames.
+Symbolic hostnames are looked up using
+.Fn gethostbyname .
+If a hostname has multiple address mappings, inetd creates a socket
+to listen on each address.
+.Pp
+The single character
+.Dq \&*
+indicates
+.Dv INADDR_ANY ,
+meaning
+.Dq all local addresses .
+To avoid repeating an address that occurs frequently, a line with a
+host address specifier and colon, but no further fields, causes the
+host address specifier to be remembered and used for all further lines
+with no explicit host specifier (until another such line or the end of
+the file).
+A line
+.Dl *:
+is implicitly provided at the top of the file; thus, traditional
+configuration files (which have no host address specifiers) will be
+interpreted in the traditional manner, with all services listened for
+on all local addresses.
+.Pp
+The
+.Em service-name
+entry is the name of a valid service in
+the file
+.Pa /etc/services .
+For
+.Dq internal
+services (discussed below), the service
+name
+.Em must
+be the official name of the service (that is, the first entry in
+.Pa /etc/services ) .
+When used to specify a Sun-RPC
+based service, this field is a valid RPC service name in
+the file
+.Pa /etc/rpc .
+The part on the right of the
+.Dq /
+is the RPC version number.
+This can simply be a single numeric argument or a range of versions.
+A range is bounded by the low version to the high version -
+.Dq rusers/1-3 .
+.Pp
+The
+.Em socket-type
+should be one of
+.Dq stream ,
+.Dq dgram ,
+.Dq raw ,
+.Dq rdm ,
+or
+.Dq seqpacket ,
+depending on whether the socket is a stream, datagram, raw,
+reliably delivered message, or sequenced packet socket.
+.Pp
+The
+.Em protocol
+must be a valid protocol as given in
+.Pa /etc/protocols .
+Examples might be
+.Dq tcp
+or
+.Dq udp .
+RPC based services are specified with the
+.Dq rpc/tcp
+or
+.Dq rpc/udp
+service type.
+.Dq tcp
+and
+.Dq udp
+will be recognized as
+.Dq TCP or UDP over default IP version .
+It is currently IPv4, but in the future it will be IPv6.
+If you need to specify IPv4 or IPv6 explicitly, use something like
+.Dq tcp4
+or
+.Dq udp6 .
+.Pp
+The
+.Em wait/nowait
+entry is used to tell
+.Nm
+if it should wait for the server program to return,
+or continue processing connections on the socket.
+If a datagram server connects
+to its peer, freeing the socket so
+.Nm inetd
+can receive further messages on the socket, it is said to be
+a
+.Dq multi-threaded
+server, and should use the
+.Dq nowait
+entry.
+For datagram servers which process all incoming datagrams
+on a socket and eventually time out, the server is said to be
+.Dq single-threaded
+and should use a
+.Dq wait
+entry.
+.Xr comsat 8
+.Pq Xr biff 1
+and
+.Xr talkd 8
+are both examples of the latter type of
+datagram server.
+.Xr tftpd 8
+is an exception; it is a datagram server that establishes pseudo-connections.
+It must be listed as
+.Dq wait
+in order to avoid a race;
+the server reads the first packet, creates a new socket,
+and then forks and exits to allow
+.Nm inetd
+to check for new service requests to spawn new servers.
+The optional
+.Dq max
+suffix (separated from
+.Dq wait
+or
+.Dq nowait
+by a dot) specifies the maximum number of server instances that may be
+spawned from
+.Nm inetd
+within an interval of 60 seconds.
+The default is unlimited (setting a limit may actually make it easier for
+an attacker to create a denial-of-service, and is not recommended).
+.Pp
+Stream servers are usually marked as
+.Dq nowait
+but if a single server process is to handle multiple connections, it may be
+marked as
+.Dq wait .
+The master socket will then be passed as fd 0 to the server, which will then
+need to accept the incoming connection.
+The server should eventually time
+out and exit when no more connections are active.
+.Nm
+will continue to
+listen on the master socket for connections, so the server should not close
+it when it exits.
+.Xr identd 8
+is usually the only stream server marked as wait.
+.Pp
+The
+.Em user
+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.
+.Pp
+The
+.Em server-program
+entry should contain the pathname of the program which is to be
+executed by
+.Nm inetd
+when a request is found on its socket.
+If
+.Nm inetd
+provides this service internally, this entry should
+be
+.Dq internal .
+.Pp
+The
+.Em server program arguments
+should be just as arguments
+normally are, starting with argv[0], which is the name of
+the program.
+If the service is provided internally, the word
+.Dq internal
+should take the place of this entry.
+.Pp
+.Nm inetd
+provides several
+.Dq trivial
+services internally by use of routines within itself.
+These services are
+.Dq echo ,
+.Dq discard ,
+.Dq chargen
+(character generator),
+.Dq daytime
+(human readable time), and
+.Dq time
+(machine readable time,
+in the form of the number of seconds since midnight, January
+1, 1900).
+All of these services are TCP based.
+For details of these services, consult the appropriate
+.Tn RFC
+from the Network Information Center.
+.Pp
+.Nm inetd
+rereads its configuration file when it receives a hangup signal,
+.Dv SIGHUP .
+Services may be added, deleted or modified when the configuration file
+is reread.
+.Nm inetd
+creates a file
+.Em /var/run/inetd.pid
+that contains its process identifier.
+.Ss IPv6 TCP/UDP behavior
+If you wish to run a server for IPv4 and IPv6 traffic,
+you'll need to run two separate process for the same server program,
+specified as two separate lines on
+.Pa inetd.conf ,
+for
+.Dq tcp4
+and
+.Dq tcp6 .
+.Pp
+Under various combination of IPv4/v6 daemon settings,
+.Nm
+will behave as follows:
+.Bl -bullet -compact
+.It
+If you have only one server on
+.Dq tcp4 ,
+IPv4 traffic will be routed to the server.
+IPv6 traffic will not be accepted.
+.It
+If you have two servers on
+.Dq tcp4
+and
+.Dq tcp6 ,
+IPv4 traffic will be routed to the server on
+.Dq tcp4 ,
+and IPv6 traffic will go to server on
+.Dq tcp6 .
+.It
+If you have only one server on
+.Dq tcp6 ,
+only IPv6 traffic will be routed to the server.
+.El
+.Sh BUGS
+Host address specifiers, while they make conceptual sense for RPC
+services, do not work entirely correctly.
+This is largely because the
+portmapper interface does not provide a way to register different ports
+for the same service on different local addresses.
+Provided you never
+have more than one entry for a given RPC service, everything should
+work correctly.
+(Note that default host address specifiers do apply to
+RPC lines with no explicit specifier.)
+.Pp
+.Dq rpc
+or
+.Dq tcpmux
+on IPv6 is not tested enough.
+Kerberos support on IPv6 is not tested.
+.Sh SEE ALSO
+.Xr comsat 8 ,
+.Xr fingerd 8 ,
+.Xr ftpd 8 ,
+.Xr rexecd 8 ,
+.Xr rlogind 8 ,
+.Xr rshd 8 ,
+.Xr telnetd 8 ,
+.Xr tftpd 8
+.Sh HISTORY
+The
+.Nm
+command appeared in
+.Bx 4.3 .
+Support for Sun-RPC
+based services is modeled after that
+provided by SunOS 4.1.
+IPv6 support and IPsec hack was made by KAME project, in 1999.