« back to all changes in this revision
Viewing changes to debian/xinetd.org-FAQ.html
- browse files at revision 3
- compare with another revision
- download diff
- download tarball
- view history from revision 3
- Committer: Bazaar Package Importer
- Author(s): Thomas Seyrat
- Date: 2005-03-10 11:03:24 UTC
- mfrom: (2.1.1 hoary)
- Revision ID: james.westby@ubuntu.com-20050310110324-h5m7w5atoamxflgi
Tags: 1:2.3.13-3
* -stayalive option in /etc/default/xinetd instead of init script
to make behaviour change easier. (closes: #294665)
* Applied patch from Andreas Jochens <aj@andaco.de> to build
on amd64 with gcc-4.0 (closes: #297911)
* Run /etc/init.d/inetd in postrm only if it exists (closes: #295554)
* Fixed erroneous itox.8 man page (closes: #287814)
* Included xinetd.org FAQ as /usr/share/doc/xinetd/xinetd.org-FAQ.html
* Edited README.update-inetd (closes: #287821)
* Applied patch to xconv.pl by Javier Fernández-Sanguino Peña to fix
- what Amanda needs (closes: #167367)
(http://www.amanda.org/docs/install.html)
- numerically-specified services (closes: #176464)
- TCP Wrappers
to make behaviour change easier. (closes: #294665)
* Applied patch from Andreas Jochens <aj@andaco.de> to build
on amd64 with gcc-4.0 (closes: #297911)
* Run /etc/init.d/inetd in postrm only if it exists (closes: #295554)
* Fixed erroneous itox.8 man page (closes: #287814)
* Included xinetd.org FAQ as /usr/share/doc/xinetd/xinetd.org-FAQ.html
* Edited README.update-inetd (closes: #287821)
* Applied patch to xconv.pl by Javier Fernández-Sanguino Peña to fix
- what Amanda needs (closes: #167367)
(http://www.amanda.org/docs/install.html)
- numerically-specified services (closes: #176464)
- TCP Wrappers
added
removed
debian/xinetd.org-FAQ.html
1
<html>
2
<head>
3
<title>xinetd faq</title>
4
</head>
5
<body bgcolor=#ffffff link="blue" vlink="blue">
6
<center><h2>xinetd FAQ</h2></center>
7
<hr noshade>
8
9
<dl>
10
<dt><a href="#what">What is xinetd</a>
11
<dt><a href="#compat">Is it compatible with inetd ?</a>
12
<dt><a href="#why">Why should I use xinetd?</a>
13
<dt><a href="#who">Who is responsible for xinetd?</a>
14
<dt><a href="#2.2">What's up with xinetd 2.2.1?</a>
15
<dt><a href="#care">I am not a system administrator; what do I care about an inetd replacement ?</a>
16
<dt><a href="#where">Where can I get xinetd?</a>
17
<dt><a href="#qmail">Has anyone gotten xinetd working with qmail?</a>
18
<dt><a href="#support">What platforms does xinetd work on?</a>
19
<dt><a href="#itox">How do I use itox?</a>
20
<dt><a href="#libwrap">Does xinetd support tcpwrappers?</a>
21
<dt><a href="#ipv6">Does xinetd support IPv6?</a>
22
<dt><a href="#v6error">No services start with IPv6! What's the deal?</a>
23
<dt><a href="#bsd">What's this setgroups(0, NULL) error?</a>
24
<dt><a href="#telnet">Why can't telnetd start normally on Linux?</a>
25
<dt><a href="#stunnel">How can I use xinetd to wrap SSL around services?</a>
26
<dt><a href="#cvss">How do I setup a cvs server with xinetd?</a>
27
</dl>
28
<hr noshade>
29
<strong><a name="what">Q. What is xinetd ?</a><br></strong>
30
A. xinetd is a replacement for inetd, the internet services daemon.<br>
31
<br>
32
<strong><a name="care">Q: I am not a system administrator; what do I care about an inetd replacement ?</a></strong>
33
<br>
34
A: xinetd is not just an inetd replacement. Anybody can use it to start servers
35
that don't require privileged ports because xinetd does not require that the
36
services in its configuration file be listed in /etc/services.
37
<br>
38
<br>
39
<strong><a name="compat">Q. Is it compatible with inetd ?</a><br></strong>
40
A. No, its configuration file has a different format than inetd's one
41
and it understands different signals. However the signal-to-action
42
assignment can be changed and a program has been included to convert
43
inetd.conf to xinetd.conf.
44
<br>
45
<br>
46
<br>
47
<strong><a name="why">Q. Why should I use it ?</a><br></strong>
48
A. Because it is a lot better (IMHO) than inetd. Here are the reasons:
49
<br>
50
<br>
51
<dl>
52
<dt> 1) It can do access control on all services based on:
53
<dl>
54
<dt> a. address of remote host
55
<dt> b. time of access
56
<dt> c. name of remote host
57
<dt> d. domain name of remote host
58
</dl>
59
<dt> 2) Access control works on all services, whether multi-threaded or
60
single-threaded and for both the TCP and UDP protocols.
61
All UDP packets can be checked as well as all TCP connections.
62
63
<dt> 3) It provides hard reconfiguration:
64
<dl>
65
<dt> a. kills servers for services that are no longer in the
66
configuration file
67
<dt> b. kills servers that no longer meet the access control criteria
68
</dl>
69
<dt> 4) It can prevent denial-of-access attacks by
70
<dl>
71
<dt> a. placing limits on the number of servers for each service
72
(avoids process table overflows)
73
<dt> b. placing an upper bound on the number of processes it will fork
74
<dt> c. placing limits on the size of log files it creates
75
<dt> d. placing limits on the number of connection a single host can initiate
76
<dt> e. place limits on the rate of incoming connections
77
<dt> f. discontinue services if the load exceeds specified limit
78
</dl>
79
<dt> 5) Extensive logging abilities:
80
<dl>
81
<dt> a. for every server started it can log:
82
<dl>
83
<dt> i) the time when the server was started
84
<dt> ii) the remote host address
85
<dt> iii) who was the remote user (if the other end runs a
86
RFC-931/RFC-1413 server)
87
<dt> iv) how long the server was running
88
<dt> (i, ii and iii can be logged for failed attempts too).
89
</dl>
90
<dt> b. for some services, if the access control fails, it can
91
log information about the attempted access (for example,
92
it can log the user name and command for the rsh service)
93
</dl>
94
<dt> 6) No limit on number of server arguments
95
<dt> 7) You can bind specifc services to specific IP's on your host machine
96
</dl>
97
<br>
98
<br>
99
<strong><a name="who">Q. Whom should I thank/blame for this program ?</a><br></strong>
100
A. panos@cs.colorado.edu originally wrote this program, but
101
<a href="mailto:bbraun@synack.net">I</a> am fielding
102
bug reports at this time.
103
<br>
104
<br>
105
<strong><a name="2.2">Q. What's up with 2.2.1 version of xinetd?</a></strong>
106
<br>
107
A. The most recent original version of xinetd was 2.1.1 with patches bringing it up to 2.1.8. Nick Hilliard created xinetd 2.2.1, based off an unreleased xinetd 2.2.0 by Panos. The copyright included with xinetd specified the required versioning to be the official release of xinetd (2.1.8 in this case) and a fourth version number tacked on to indicate the modification level. This is the versioning I have adopted. xinetd 2.1.8.X, which is available here, is not based off xinetd 2.2.0 or higher. It was created from the codebase of xinetd 2.1.8, although I have re-implemented some of the features introduced in xinetd-2.2.1.
108
<br>
109
<br>
110
<strong><a name="where">Q. Where can I find the latest-and-greatest version ?</a><br></strong>
111
A. The xinetd source can be obtained from
112
<a href="http://www.synack.net/xinetd">http://www.synack.net/xinetd</a>
113
<br>
114
<br>
115
<strong><a name="qmail">Q. Has anyone been able to get qmail working with xinetd?</a><br></strong>
116
A. yes, here is the entry info
117
<pre>
118
service smtp
119
{
120
flags = REUSE NAMEINARGS
121
socket_type = stream
122
protocol = tcp
123
wait = no
124
user = qmaild
125
server = /usr/sbin/tcpd
126
server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd
127
}
128
</pre> Contributed by: Anthony Abby<br>
129
This method will allow you to set environment variables and whatnot
130
in <tt>/etc/hosts.allow</tt>. Although xinetd can be compiled with libwrap
131
support, this doesn't mean it can completly replace tcpd's functionality.
132
xinetd calls <tt>host_access()</tt>, which performs the access control
133
documented in <tt>host_access(5)</tt> man page. This is a subset of the
134
features offered by tcpd.
135
<br>
136
<br>
137
<strong><a name="support">Q. What platforms is xinetd know to work on?</a><br></strong>
138
A. I have run it on Solaris 2.6 (sparc and x86), Linux, BSDi, and
139
IRIX 5.3 and 6.2. The original package ran on SunOS 4 and Ultrix.
140
<br>
141
<br>
142
<strong><a name="chroot">Q. How to do setup a chrooted environment for a service?</a></strong><br>
143
A. Here is the config file entry:
144
<pre>
145
service telnet_chroot
146
{
147
log_on_success = HOST PID DURATION USERID
148
log_on_failure = HOST RECORD USERID
149
no_access = 152.30.11.93
150
socket_type = stream
151
protocol = tcp
152
port = 8000
153
wait = no
154
user = root
155
server = /usr/sbin/chroot
156
server_args = /var/public/servers /usr/libexec/telnetd
157
}
158
</pre> Contributed by: lburns@sasquatch.com
159
<br>
160
<br>
161
<strong><a name="itox">Q. How do I use itox?</a></strong><br>
162
A. itox reads in a regular inetd.conf file from stdin and writes an xinetd.conf
163
file to stdout. In general, you use the command:<br>
164
<tt>itox < /etc/inetd.conf > /etc/xinetd.conf</tt>
165
<br>
166
If your inetd.conf does not have explicit paths to each of the
167
daemons, you must use the <i>-daemon_dir</i> option. Suppose all your
168
daemons live in /usr/sbin, use the following command:<br>
169
<tt> itox -daemon_dir=/usr/sbin < /etc/inetd.conf > /etc/xinetd.conf</tt>
170
<br>
171
itox is rather old and hasn't been updated for a while. xconv.pl is a
172
perl script that is a little better about converting modern inetd.conf
173
files. It's usage is similar to itox's.
174
<br>
175
<br>
176
<strong><a name="libwrap">Q. Does xinetd support libwrap (tcpwrappers)?</a></strong><br>
177
A. Yes. xinetd can be compiled with libwrap support by passing
178
<tt>--with-libwrap</tt> as an option to the <tt>configure</tt> script.
179
When xinetd is compiled with libwrap support, all services can use the
180
<tt>/etc/hosts.allow</tt> and <tt>/etc/hosts.deny</tt> access control.
181
xinetd can also be configured to use tcpd in the traditional inetd style.
182
This requires the use of the NAMEINARGS flag, and the name of the real
183
daemon be passed in as server_args. Here is an example for using telnet
184
with tcpd:
185
<pre>
186
service telnet
187
{
188
flags = REUSE NAMEINARGS
189
protocol = tcp
190
socket_type = stream
191
wait = no
192
user = telnetd
193
server = /usr/sbin/tcpd
194
server_args = /usr/sbin/in.telnetd
195
}
196
</pre>
197
<strong><a name="ipv6">Q. Does xinetd support IPv6?</a></strong><br>
198
A. Yes. xinetd can be compiled with IPv6 support by adding the
199
<tt>--with-inet6</tt> option to the <tt>configure</tt> script.
200
Access control is functional with IPv6. You can use ipv4 mapped
201
addresses, or give normal dotted quad ipv4 addresses for access
202
control, and xinetd will map them to ipv6 addresses.
203
<br>
204
<br>
205
<strong><a name="v6error">Q. No services start with IPv6! What's the deal?</a></strong><br>
206
A. When you compile IPv6 support in, all sockets are IPv6 sockets.
207
If your kernel doesn't understand what an IPv6 socket is, all attempts
208
to create sockets will fail, and no services will start. Only compile
209
xinetd with IPv6 support if your kernel supports IPv6.
210
<br>
211
<br>
212
<strong><a name="bsd">Q. What's this setgroups(0, NULL) error?</a></strong><br>
213
A. By default, xinetd does not allow group permissions to the server
214
processes, and it does this by setting the groups of the child process
215
to nothing. Some BSD's have a problem with this. To avoid this error,
216
put the directive <tt>groups = yes</tt> into your services. This says
217
to allow the server process to have all the group privleges entitled
218
to the user the server process is running as.
219
<br>
220
<br>
221
<strong><a name="telnet">Q. Why can't telnetd start normally on Linux?</a></strong><br>
222
A. On some Linux distributions, the telnet daemon starts as a nonprivleged
223
user, but the user belongs to groups that allow it to open new tty's, and
224
to update utmp. By default, xinetd does not allow group permissions to the
225
server process, so telnetd can fail to start properly. To get the server
226
process to posess the proper groups, use the <tt>groups = yes</tt> directive
227
for the telnet service. This will tell xinetd that it is OK for the server
228
process to start with all the groups the user has access to.
229
<br>
230
<br>
231
<strong><a name="stunnel">Q. How do I use xinetd to wrap SSL around services</a></strong><br>
232
A. Use the program <a href="http://www.stunnel.org">
233
stunnel</a> to wrap SSL around services. This can actually be used
234
by an inetd.
235
<br>
236
<br>
237
<strong><a name="cvss">Q. How do I setup a cvs server with xinetd?</a>
238
</strong><br>
239
A. A user wrote in with this suggestion: <BR>
240
<pre>
241
cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver
242
</pre>
243
If you want to make the same work under xinetd, you save a config file
244
in /etc/xinetd.d
245
called cvspserver, (where the last line tells it the names of your
246
repositories):
247
<pre>
248
service cvspserver
249
{
250
socket_type = stream
251
protocol = tcp
252
wait = no
253
user = root
254
passenv =
255
server = /usr/bin/cvs
256
server_args = --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver -f
257
}
258
</pre>
259
All the other cvs setup stuff is the same. This seems to work, afaik.
260
<br>
261
<br>
262
</body>
263
</html>
Loggerhead is a web-based interface for Breezy
Version: 2.0.1