xref: /netbsd-src/usr.sbin/inetd/inetd.8 (revision fdecd6a253f999ae92b139670d9e15cc9df4497c)
1.\" Copyright (c) 1985, 1991 The Regents of the University of California.
2.\" All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\"    notice, this list of conditions and the following disclaimer in the
11.\"    documentation and/or other materials provided with the distribution.
12.\" 3. All advertising materials mentioning features or use of this software
13.\"    must display the following acknowledgement:
14.\"	This product includes software developed by the University of
15.\"	California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\"    may be used to endorse or promote products derived from this software
18.\"    without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\"     from: @(#)inetd.8	6.7 (Berkeley) 3/16/91
33.\"	$NetBSD: inetd.8,v 1.10 1997/06/30 20:55:06 phil Exp $
34.\"
35.Dd March 16, 1991
36.Dt INETD 8
37.Os BSD 4.3
38.Sh NAME
39.Nm inetd
40.Nd internet
41.Dq super-server
42.Sh SYNOPSIS
43.Nm
44.Op Fl d
45.Op Fl l
46.Op Ar configuration file
47.Sh DESCRIPTION
48.Nm
49should be run at boot time by
50.Pa /etc/rc
51(see
52.Xr rc 8 ) .
53It then listens for connections on certain
54internet sockets.  When a connection is found on one
55of its sockets, it decides what service the socket
56corresponds to, and invokes a program to service the request.
57After the program is
58finished, it continues to listen on the socket (except in some cases which
59will be described below).  Essentially,
60.Nm
61allows running one daemon to invoke several others,
62reducing load on the system.
63.Pp
64The options available for
65.\" Why doesn't just `.Nm :' work?
66.Nm inetd Ns :
67.Bl -tag -width Ds
68.It Fl d
69Turns on debugging.
70.El
71.Pp
72.Bl -tag -width Ds
73.It Fl l
74Turns on libwrap connection logging.
75.El
76.Pp
77Upon execution,
78.Nm
79reads its configuration information from a configuration
80file which, by default, is
81.Pa /etc/inetd.conf .
82There must be an entry for each field of the configuration
83file, with entries for each field separated by a tab or
84a space.  Comments are denoted by a ``#'' at the beginning
85of a line.  There must be an entry for each field (except for one
86special case, described below).  The
87fields of the configuration file are as follows:
88.Pp
89.Bd -unfilled -offset indent -compact
90service name
91socket type
92protocol
93wait/nowait[.max]
94user[.group]
95server program
96server program arguments
97.Ed
98.Pp
99To specify an
100.Em Sun-RPC
101based service, the entry would contain these fields.
102.Pp
103.Bd -unfilled -offset indent -compact
104service name/version
105socket type
106rpc/protocol
107wait/nowait[.max]
108user[.group]
109server program
110server program arguments
111.Ed
112.Pp
113For Internet services, the first field of the line may also have a host
114address specifier prefixed to it, separated from the service name by a
115colon.  If this is done, the string before the colon in the first field
116indiciates what local address
117.Nm
118should use when listening for that service, or the single character
119.Dq \&*
120to indicate
121.Dv INADDR_ANY ,
122meaning
123.Sq all local addresses .
124To avoid repeating an address that occurs frequently, a line with a
125host address specifier and colon, but no further fields, causes the
126host address specifier to be remembered and used for all further lines
127with no explicit host specifier (until another such line or the end of
128the file).  A line
129.Dl *:
130is implicitly provided at the top of the file; thus, traditional
131configuration files (which have no host address specifiers) will be
132interpreted in the traditional manner, with all services listened for
133on all local addresses.
134.Pp
135The
136.Em service-name
137entry is the name of a valid service in
138the file
139.Pa /etc/services .
140For
141.Dq internal
142services (discussed below), the service
143name
144.Em must
145be the official name of the service (that is, the first entry in
146.Pa /etc/services ) .
147When used to specify a
148.Em Sun-RPC
149based service, this field is a valid RPC service name in
150the file
151.Pa /etc/rpc .
152The part on the right of the
153.Dq /
154is the RPC version number. This
155can simply be a single numeric argument or a range of versions.
156A range is bounded by the low version to the high version \-
157.Dq rusers/1-3 .
158.Pp
159The
160.Em socket-type
161should be one of
162.Dq stream ,
163.Dq dgram ,
164.Dq raw ,
165.Dq rdm ,
166or
167.Dq seqpacket ,
168depending on whether the socket is a stream, datagram, raw,
169reliably delivered message, or sequenced packet socket.
170.Pp
171The
172.Em protocol
173must be a valid protocol as given in
174.Pa /etc/protocols .
175Examples might be
176.Dq tcp
177or
178.Dq udp .
179Rpc based services are specified with the
180.Dq rpc/tcp
181or
182.Dq rpc/udp
183service type.
184.Pp
185The
186.Em wait/nowait
187entry is used to tell
188.Nm
189if it should wait for the server program to return,
190or continue processing connections on the socket.
191If a datagram server connects
192to its peer, freeing the socket so
193.Nm
194can receive further messages on the socket, it is said to be
195a
196.Dq multi-threaded
197server, and should use the
198.Dq nowait
199entry.  For datagram servers which process all incoming datagrams
200on a socket and eventually time out, the server is said to be
201.Dq single-threaded
202and should use a
203.Dq wait
204entry.
205.Xr Comsat 8
206.Pq Xr biff 1
207and
208.Xr talkd 8
209are both examples of the latter type of
210datagram server.
211.Xr Tftpd 8
212is an exception; it is a datagram server that establishes pseudo-connections.
213It must be listed as
214.Dq wait
215in order to avoid a race;
216the server reads the first packet, creates a new socket,
217and then forks and exits to allow
218.Nm
219to check for new service requests to spawn new servers.
220The optional
221.Dq max
222suffix (separated from
223.Dq wait
224or
225.Dq nowait
226by a dot) specifies the maximum number of server instances that may be
227spawned from
228.Nm
229within an interval of 60 seconds. When omitted,
230.Dq max
231defaults to 40.
232.Pp
233Stream servers are usually marked as
234.Dq nowait
235but if a single server process is to handle multiple connections, it may be
236marked as
237.Dq wait .
238The master socket will then be passed as fd 0 to the server, which will then
239need to accept the incoming connection.  The server should eventually time
240out and exit when no more connections are active.
241.Nm
242will continue to
243listen on the master socket for connections, so the server should not close
244it when it exits.
245.Xr identd 8
246is usually the only stream server marked as wait.
247.Pp
248The
249.Em user
250entry should contain the user name of the user as whom the server
251should run.  This allows for servers to be given less permission
252than root. An optional group name can be specified by appending a dot to
253the user name followed by the group name. This allows for servers to run with
254a different (primary) group id than specified in the password file. If a group
255is specified and user is not root, the supplementary groups associated with
256that user will still be set.
257.Pp
258The
259.Em server-program
260entry should contain the pathname of the program which is to be
261executed by
262.Nm
263when a request is found on its socket.  If
264.Nm
265provides this service internally, this entry should
266be
267.Dq internal .
268.Pp
269The
270.Em server program arguments
271should be just as arguments
272normally are, starting with argv[0], which is the name of
273the program.  If the service is provided internally, the
274word
275.Dq internal
276should take the place of this entry.
277.Pp
278.Nm
279provides several
280.Dq trivial
281services internally by use of
282routines within itself.  These services are
283.Dq echo ,
284.Dq discard ,
285.Dq chargen
286(character generator),
287.Dq daytime
288(human readable time), and
289.Dq time
290(machine readable time,
291in the form of the number of seconds since midnight, January
2921, 1900).  All of these services are tcp based.  For
293details of these services, consult the appropriate
294.Tn RFC
295from the Network Information Center.
296.Pp
297.Nm
298rereads its configuration file when it receives a hangup signal,
299.Dv SIGHUP .
300Services may be added, deleted or modified when the configuration file
301is reread.
302.Nm
303creates a file
304.Em /var/run/inetd.pid
305that contains its process identifier.
306.Sh BUGS
307Host address specifiers, while they make conceptual sense for RPC
308services, do not work entirely correctly.  This is largely because the
309portmapper interface does not provide a way to register different ports
310for the same service on different local addresses.  Provided you never
311have more than one entry for a given RPC service, everything should
312work correctly.  (Note that default host address specifiers do apply to
313RPC lines with no explicit specifier.)
314.Sh SEE ALSO
315.Xr comsat 8 ,
316.Xr fingerd 8 ,
317.Xr ftpd 8 ,
318.Xr rexecd 8 ,
319.Xr rlogind 8 ,
320.Xr rshd 8 ,
321.Xr telnetd 8 ,
322.Xr tftpd 8 ,
323.Xr hosts_access 5 ,
324.Xr hosts_options 5
325.Sh HISTORY
326The
327.Nm
328command appeared in
329.Bx 4.3 .
330Support for
331.Em Sun-RPC
332based services is modeled after that
333provided by
334.Em Sun-OS 4.1 .
335