r170 - in /web: deps/dep9.mdwn index.mdwn
sez at users.alioth.debian.org
sez at users.alioth.debian.org
Mon Feb 28 16:49:06 UTC 2011
Author: sez
Date: Mon Feb 28 16:49:03 2011
New Revision: 170
URL: http://svn.debian.org/wsvn/dep/?sc=1&rev=170
Log:
initial check-in of dep9 draft
Added:
web/deps/dep9.mdwn
Modified:
web/index.mdwn
Added: web/deps/dep9.mdwn
URL: http://svn.debian.org/wsvn/dep/web/deps/dep9.mdwn?rev=170&op=file
==============================================================================
--- web/deps/dep9.mdwn (added)
+++ web/deps/dep9.mdwn Mon Feb 28 16:49:03 2011
@@ -1,0 +1,209 @@
+[[!meta title="DEP-8: inet-superserver configuration by maintainer scripts"]]
+
+ Title: inet-superserver configuration by maintainer scripts
+ DEP: 8
+ State: DRAFT
+ Date: 2011-02-28
+ Drivers: Serafeim Zanikolas <sez at debian.org>
+ URL: http://dep.debian.net/deps/dep8
+ License: http://www.jclark.com/xml/copying.txt
+ Abstract:
+ Motivation, requirements and functional overview of a successor
+ configuration tool for inetd superservers.
+
+[[!toc ]]
+
+# Introduction
+
+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.
+
+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.
+
+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:
+
+* the standard configuration files of inetd and xinetd must remain the
+ authoritative files;
+* the solution must not change the way system administrators configure inetd,
+ and must have no impact on maintainers of "Provides: inet-superserver"
+ packages;
+* reconf-inetd must be capable of co-existing with update-inetd, so as
+ to allow a gradual transition.
+
+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.
+
+# Motivation
+
+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.
+
+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.
+
+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.
+
+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 that may be the case because it is not
+well integrated in Debian.
+
+
+# Outline of reconf-inetd operation
+
+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.
+
+With reconf-inetd, inet-superserver configuration will occur as follows:
+
+* reconf-inetd will provide the directory /usr/share/reconf-inetd, and declare a
+ dpkg trigger for that directory
+* server packages that can use inetd, will depend on reconf-inetd and install
+ a reconf-inetd fragment in /usr/share/reconf-inetd
+* reconf-inetd will be invoked via a dpkg trigger to update /etc/inetd.conf
+ using the fragments in /usr/share/reconf-inetd
+
+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).
+
+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:
+
+* to identify inetd.conf entries that have been added by reconf-inetd (as
+ opposed to update-inetd or a user)
+* to determine whether an inetd.conf entry, that has been previously added by
+ reconf-inetd, is intact or has had local modifications
+
+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).
+
+/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.
+
+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.
+
+<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>
+
+An inetd.conf entry is considered disabled when it starts with "#<off># ",
+ and disabled by a user when commented-out simply with '#'.
+
+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.
+
+Follows a detailed description of the aforementioned scenarios.
+
+* an non-commented-out inetd.conf entry will be removed, regardless of whether
+ it is enabled or disabled, when it:
+ - refers to a non-existing server file
+ - has no matching reconf-inetd fragment
+ - is identical to a matching shadow fragment
+
+* a disabled inetd.conf entry will be enabled when it
+ - refers to an existing server file
+ - it has a matching reconf-inetd fragment
+ - and a matching shadow fragment (identical or not)
+
+* a new inetd.conf entry wll be added when there exists a reconf-inetd fragment
+ that:
+ - refers to an existing server file
+ - has no matching (enabled, disabled, commented-out or not) inetd.conf
+ entry
+ - has a matching reconf-inetd fragment
+
+
+# Transition of "Depends: update-inetd" packages
+
+A time-limited transition is not a strict requirement, since reconf-inetd and
+update-inetd can co-exist without problems.
+
+Server packages that depend on update-inetd can be converted as follows:
+
+* remove any references of update-inetd in post{inst,rm} scripts;
+* install a reconf-inetd fragment in /usr/share/reconf-inetd, as a regular
+ file (ie. not as a conffile);
+* replace the dependency on update-inetd with one on reconf-inetd
+
+
+# xinetd support
+
+xinetd configuration with reconf-inetd will become trivial because server
+packages will have to ship reconf-inetd (ie. xinetd.conf(5) compatible)
+fragments anyway.
+
+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.
+
+
+# Open issues
+
+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.
+
+Making this distinction so that unmodified inetd.conf entries are removed only
+upon package purge is possible but would incur some extra runtime overhead (to
+find the package in which a reconf-inetd fragment belongs to, and the
+package's state (uninstalled or purged)).
Modified: web/index.mdwn
URL: http://svn.debian.org/wsvn/dep/web/index.mdwn?rev=170&op=diff
==============================================================================
--- web/index.mdwn (original)
+++ web/index.mdwn Mon Feb 28 16:49:03 2011
@@ -37,6 +37,7 @@
[DEP 6](deps/dep6)|**REJECTED**|[*Meta-Package debian/control field*](deps/dep6)|[svn](svn://svn.debian.org/svn/dep/web/deps/dep6.mdwn) [web](http://svn.debian.org/wsvn/dep/web/deps/dep6.mdwn?op=log&rev=0&sc=0&isdir=0)
[DEP 7](deps/dep7)|**DRAFT**|[*Java Web Application Packaging*](deps/dep7)|[svn](svn://svn.debian.org/svn/dep/web/deps/dep7.mdwn) [web](http://svn.debian.org/wsvn/dep/web/deps/dep7.mdwn?op=log&rev=0&sc=0&isdir=0)
[DEP 8](deps/dep8)|**DRAFT**|[*automatic as-installed package testing*](deps/dep8)|[svn](svn://svn.debian.org/svn/dep/web/deps/dep8.mdwn) [web](http://svn.debian.org/wsvn/dep/web/deps/dep8.mdwn?op=log&rev=0&sc=0&isdir=0)
+[DEP 9](deps/dep9)|**DRAFT**|[*inet-superserver configuration by maintainer scripts*](deps/dep9)|[svn](svn://svn.debian.org/svn/dep/web/deps/dep9.mdwn) [web](http://svn.debian.org/wsvn/dep/web/deps/dep9.mdwn?op=log&rev=0&sc=0&isdir=0)
"""]]
Additional information
More information about the dep-commits
mailing list