/usr/share/doc/reconf-inetd/dep9.html is in reconf-inetd 1.120603.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>DEP-9: inet-superserver configuration by maintainer scripts</title>
<link rel="stylesheet" href="../../style.css" type="text/css" />
<link rel="stylesheet" href="../../local.css" type="text/css" />
</head>
<body>
<div class="header">
<span>
</div>
<div class="actions">
<ul>
<li><a href="../../recentchanges/">RecentChanges</a></li>
<li><a href="http://svn.debian.org/viewvc/dep/web/deps/dep9.mdwn">History</a></li>
</ul>
</div>
<div id="content">
<pre><code>Title: inet-superserver configuration by maintainer scripts
DEP: 9
State: CANDIDATE
Date: 2012-06-03
Drivers: Serafeim Zanikolas <sez@debian.org>
URL: http://dep.debian.net/deps/dep9
Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep9.mdwn
License: http://www.jclark.com/xml/copying.txt
Abstract:
Motivation, requirements and functional overview of a successor
configuration tool for inetd superservers.
</code></pre>
<div class="toc">
<ol>
<li class="L1"><a href="#index1h1">Introduction</a>
</li>
<li class="L1"><a href="#index2h1">Motivation</a>
</li>
<li class="L1"><a href="#index3h1">Outline of reconf-inetd operation</a>
</li>
<li class="L1"><a href="#index4h1">Configuration of new server packages</a>
</li>
<li class="L1"><a href="#index5h1">Transition of "Depends: update-inetd" packages</a>
</li>
<li class="L1"><a href="#index6h1">Requirements for xinetd/reconf-inetd fragments</a>
</li>
<li class="L1"><a href="#index7h1">xinetd support</a>
</li>
<li class="L1"><a href="#index8h1">Clarification of behaviour on package removal versus package purge</a>
</li>
<li class="L1"><a href="#index9h1">Current status</a>
</li>
<li class="L1"><a href="#index10h1">Source code repo</a>
</li>
</ol>
</div>
<h1><a name="index1h1"></a>Introduction</h1>
<p>The inet-superserver facility (typically provided by the openbsd-inetd
package) listens to certain sockets and invokes the right server upon the
arrival of an incoming request. Servers that are meant to be invoked by inetd
must add a service entry to /etc/inetd.conf upon package installation (and
remove the entry upon package purge). Maintainer scripts that modify
inetd.conf must currently do so using a utility called update-inetd, as per
Policy 11.2.</p>
<p>However, update-inetd has a problematic interface that leads to several kinds
of bugs, including cross-package ones. Fixing update-inetd is largely a matter
of fixing its interface, which would break backwards-compatibility. With that
cost as a given (ie. the cost of revising all maintainer scripts of
update-inetd's reverse-depends), one might as well create a successor tool
with a cleaner interface.</p>
<p>This DEP proposes such a successor inetd configuration tool, hereafter called
reconf-inetd. reconf-inetd, in addition to providing the existing functionality,
must meet the following requirements:</p>
<ul>
<li>the standard configuration files of inetd and xinetd must remain the
authoritative files;</li>
<li>the solution must not change the way system administrators configure inetd,
and must have no impact on maintainers of "Provides: inet-superserver"
packages;</li>
<li>reconf-inetd must be capable of co-existing with update-inetd, so as
to allow a gradual transition.</li>
</ul>
<p>Note that the first requirement above implies that inetd.conf entries that
have been (i) added by reconf-inetd and (ii) were subsequently modified by the
user, shall not be removed even on package purge.</p>
<h1><a name="index2h1"></a>Motivation</h1>
<p>The main problem of update-inetd is that the service entry to be enabled,
disabled or removed, is selected in terms of a service name, such as "ftp".
This limitation typically leads to cross-package bugs because of the
difficulty to distinguish between independent implementations (eg. ftpd-ssl
versus proftpd), or an ipv4 versus an ipv6 implementation of the same kind of
service. As an example, in #168847, ftpd-ssl's invocation of update-inetd
enables the service entry of (the previously uninstalled) proftpd because both
packages' entries have an "ftp" service name.</p>
<p>As of now, one can try to avoid the above problem as follows. A maintainer
script may (i) further specify the acted-upon service entry in terms of a
regular expression (which is matched against the whole service entry, instead
of just the service name); (ii) override the default comment-prefix
("#<off># "), to distinguish service entries of different packages that provide
the same kind of service (eg. "#<off-ftpd-ssl-ipv4># " vs
"#<off-proftpd-ipv4># "). These features work when used correctly, but at the
cost of fragile logic in maintainer scripts.</p>
<p>To summarise, the interface of update-inetd is inadequate in that it does not
require that the following three elements are specified to select an entry:
service name, protocol type, and path to server program.</p>
<p>A secondary issue, but nevertheless one that would be nice to solve, is
support for configuration updates of xinetd (#8927). xinetd has a relatively
low popcon but one could argue that may be the case because it is not well
integrated in Debian.</p>
<h1><a name="index3h1"></a>Outline of reconf-inetd operation</h1>
<p>reconf-inetd will operate similarly to update-inetd, ie. add, remove, enable and
disable service entries in /etc/inetd.conf. The main difference is that where
update-inetd uses command-line arguments, reconf-inetd will use xinetd.conf(5)
configuration fragments under /usr/share/reconf-inetd (hereafter called
reconf-inetd fragments, for brevity). Moreover, reconf-inetd will be invoked via a
dpkg trigger, as opposed to from maintainer scripts.</p>
<p>With reconf-inetd, inet-superserver configuration will occur as follows:</p>
<ul>
<li>reconf-inetd will provide the directory /usr/share/reconf-inetd, and declare a
dpkg trigger for that directory</li>
<li>server packages that can use inetd, will depend on reconf-inetd and install
a reconf-inetd fragment in /usr/share/reconf-inetd</li>
<li>reconf-inetd will be invoked via a dpkg trigger to update /etc/inetd.conf
using the fragments in /usr/share/reconf-inetd</li>
</ul>
<p>An inetd.conf service entry will be considered to be "matching" a reconf-inetd
fragment when the following fields are equal: service name, protocol, and
server program. In reconf-inetd fragments with "flags = NAMEINARGS" (eg. a tcpd
service entry), the actual server path will be extracted from the server_args
field, as per xinetd.conf(5).</p>
<p>Upon adding an entry to inetd.conf, reconf-inetd will make a shadow copy of the
related reconf-inetd fragment under /var/lib/reconf-inetd. This would allow to
determine the following after the uninstallation of the related package:</p>
<ul>
<li>to identify inetd.conf entries that have been added by reconf-inetd (as
opposed to update-inetd or a user)</li>
<li>to determine whether an inetd.conf entry, that has been previously added by
reconf-inetd, is intact or has had local modifications</li>
</ul>
<p>All reconf-inetd fragments will be considered enabled, regardless of the value
of the "disable" field, if such field exists. Servers that support inetd mode
but default to standalone operation must therefore not install a reconf-inetd
fragment (and should instead provide a sample inetd.conf entry that the user
has to add manually to /etc/inetd.conf).</p>
<p>/etc/inetd.conf (and /etc/xinetd.d) will remain the authoritative
configuration file for inetd (and xinetd). reconf-inetd fragments are only meant
for updating the standard configuration files.</p>
<p>An invocation of reconf-inetd (because of a fragment being installed or removed
from /usr/share/reconf-inetd) may result in a modification of /etc/inetd.conf
as summarised in the table below.</p>
<pre>
| server | status of | matching | shadow | reconf-inetd
| program | inetd.conf | reconf-inetd | fragment | action
| exists | entry | fragment | status |
---+---------+------------+--------------+------------+-----------
0| no | disabled | no | identical | remove
1| no | enabled | no | identical | remove
---+---------+------------+--------------+------------+-----------
2| yes | disabled | yes | different | enable
3| yes | disabled | yes | identical | enable
---+---------+------------+--------------+------------+-----------
4| yes | missing | yes | n/a | add
---+---------+------------+--------------+------------+-----------
5| commented-out inetd.conf entry | none
---+---------+------------+--------------+------------+-----------
6| any other combination | none
</pre>
<p>An inetd.conf entry is considered disabled when it starts with "#<off># ",
and disabled by a user when commented-out simply with '#'.</p>
<p>A shadow fragment status (ie. the fragment under /var/lib/reconf-inetd) is
considered identical to a matching inetd.conf entry, by comparing the
server arguments, if any.</p>
<p>Follows a detailed description of the aforementioned scenarios.</p>
<ul>
<li><p>an non-commented-out inetd.conf entry will be removed, regardless of whether
it is enabled or disabled, when it:</p>
<ul>
<li>refers to a non-existing server file</li>
<li>has no matching reconf-inetd fragment</li>
<li>is identical to a matching shadow fragment</li>
</ul></li>
<li><p>a disabled inetd.conf entry will be enabled when it</p>
<ul>
<li>refers to an existing server file</li>
<li>it has a matching reconf-inetd fragment</li>
<li>and a matching shadow fragment (identical or not)</li>
</ul></li>
<li><p>a new inetd.conf entry will be added when there exists a reconf-inetd fragment
that:</p>
<ul>
<li>refers to an existing server file</li>
<li>has no matching (enabled, disabled, commented-out or not) inetd.conf
entry</li>
<li>has a matching reconf-inetd fragment</li>
</ul></li>
</ul>
<p>Meaning of the above listed actions:</p>
<ul>
<li>add: add inetd.conf entry and a matching shadow fragment</li>
<li>remove: remove inetd.conf entry and matching shadow fragment</li>
<li>enable: enable inetd.conf entry</li>
</ul>
<h1><a name="index4h1"></a>Configuration of new server packages</h1>
<p>Packages that have never used update-inetd must do the following:</p>
<ul>
<li>depend on reconf-inetd</li>
<li>install a reconf-inetd fragment in /usr/share/reconf-inetd, as a regular
file (ie. not as a conffile);</li>
</ul>
<h1><a name="index5h1"></a>Transition of "Depends: update-inetd" packages</h1>
<p>A time-limited transition is not a strict requirement, since reconf-inetd and
update-inetd can co-exist without problems.</p>
<p>reconf-inetd will not touch any entries that have not been added by itself,
including entries added by update-inetd. Thus, a server package that is meant
to transition from update-inetd to reconf-inetd, must remove any entries that
it previously added using update-inetd.</p>
<p>Server packages that depend on update-inetd can be converted as follows:</p>
<p>0) in the first stable Debian release in which reconf-inetd is used by the
package:</p>
<ul>
<li>depend on both update-inetd and reconf-inetd</li>
<li>install a reconf-inetd fragment in /usr/share/reconf-inetd, as a regular
file (ie. not as a conffile);</li>
<li>drop any references to update-inetd in postrm</li>
<li>modify postinst to (i) remove any inetd.conf entries for that package that
were previously added using update-inetd, assuming they have not had local
changes; (ii) run reconf-inetd to re-add new inetd.conf entries that might
have been removed by update-inetd (if the reconf-inetd trigger ran before
postinst)</li>
</ul>
<p>Below is an example postinst snippet for the ftpd-ssl server package:</p>
<pre>
# exact inetd.conf entry previously added using update-inetd
OLD_FTPENTRY="ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd"
# first release that uses reconf-inetd
REL="x.y.z"
case $1 in
configure)
# remove inetd.conf entry if not modified locally, and not managed
# already by reconf-inetd
if dpkg --compare-versions "$2" lt-nl "$REL"; then
if fgrep -qx "$OLD_FTPENTRY" || fgrep -qx '#<off># $OLD_FTPENTRY"; then
# remove all inetd.conf entries for ftpd-ssl
update-inetd --multi --pattern ftpd-ssl --remove ftp || true
# re-add entries that are managed by reconf-inetd
reconf-inetd || true
fi
fi
;;
esac
</pre>
<p>If you are going to invoke update-inetd using --multi as shown above (to avoid
prompting the user about multiple entries) you need update-inetd (>= 4.43).</p>
<p>1) in later stable Debian releases, simply drop update-inetd all together
(dependency and postinst snippet)</p>
<h1><a name="index6h1"></a>Requirements for xinetd/reconf-inetd fragments</h1>
<p>According to xinetd.conf(5), xinetd fragments must have the following fields:</p>
<pre>
socket_type (mandatory)
wait (mandatory)
user (non-internal services only)
server (non-internal services only)
protocol (RPC and unlisted services only)
port (unlisted non-RPC services only)
</pre>
<p>If the protocol field is omitted and the service is listed, reconf-inetd will
assume the protocol of the first matching entry from /etc/services. That will
be tcp or udp, which currently implies IPv4, so if the intention is IPv6, then
tcp6 or udp6 should be explicitly specified in the protocol field.</p>
<p>Unlike, regular xinetd fragment files, reconf-inetd fragment files must have
only one service per file. If your package provides more than one service,
please install a separate fragment file for each service. This is the case to
allow for removal of individual services, by simply removing the related file.</p>
<p>The disable field in reconf-inetd fragments is completely ignored.
reconf-inetd has no notion of maintainer-disabled inetd.conf entries</p>
<h1><a name="index7h1"></a>xinetd support</h1>
<p>xinetd configuration with reconf-inetd will become trivial because server
packages will have to ship reconf-inetd (ie. xinetd.conf(5) compatible)
fragments anyway.</p>
<p>Synchronisation between inetd.conf and reconf-inetd fragments is outside this DEP's
scope. The fact that inetd.conf (and /etc/xinetd.d) remains the authoritative
configuration file implies that any synchronisation requires a user-initiated
action, and is thus best implemented as a separate tool.</p>
<h1><a name="index8h1"></a>Clarification of behaviour on package removal versus package purge</h1>
<p>According to rules 0 and 1 in the previously listed table, reconf-inetd does
not distinguish between package removal and purge. In other words,
/etc/inetd.conf entries that were added by reconf-inetd will be removed upon
package removal, as long as they have not been locally modified. Similarly, a
locally-modified inetd.conf entry will not be removed even if the associated
package is purged. This is in line with Debian policy, on the basis that
inetd.conf is a configuration file, but not a conffile.</p>
<h1><a name="index9h1"></a>Current status</h1>
<p>http://packages.qa.debian.org/r/reconf-inetd.html</p>
<h1><a name="index10h1"></a>Source code repo</h1>
<p>http://git.debian.org/?p=collab-maint/reconf-inetd.git;a=summary</p>
</div>
<div id="footer">
<div id="pageinfo">
<div class="pagedate">
Last edited <span class="date">Sun, 03 Jun 2012 22:16:25 +0000</span>
</div>
</div>
<!-- from Debian Enhancement Proposals -->
</div>
</body>
</html>
|