[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: update-inetd migration to dpkp-triggers

Hello world,

As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
proposal below to migrate it to dpkg triggers [0]

The Current Messy State of Affairs

update-inetd script is problematic (maintainer scripts use it to update the
/etc/inetd.conf conffile leading to local-policy overrides and confusion) and
doesn't support xinetd (#8927)

The Rosy Future

* update-inetd will drop its current switches to
  add/remove/enable/disable services; instead deamon packages will install
  fragments under /etc/inetd.conf.d/ and any other kind of change will be made
  only by the sysadmin

* abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
  /var/lib/update-inetd/inetd.conf and auto-populate fragments in
  /var/lib/update-inetd/xinetd.d/ using xinetd fragments installed by deamon
  packages in /etc/inetd.conf.d/

* document that local policy will live in /etc/inetd.conf.d/ and any manual
  changes will be made effective by running update-inetd

* all (4) superservers will lookup their config under /var/lib/update-inetd/

* after deamon package installations, update-inetd will be invoked via a file
  trigger on /etc/inetd.conf.d/ to update the (x)inetd's actual configuration
  under /var/lib/ and reload (x)inetd

The advantages of this proposal are, idempotency, respect of local policy,
ability to switch transparently between inetd and xinetd, and possibility to
support future inetds that might use a different configuration file syntax.

How to Get There

The migration could(?) be done within one stable release, but I assume a more
conservative approach over two releases.

* squeeze
    * all deamon packages that use update-inetd [1]:
        * should version-depend in the update-inetd version that is shipped in
          squeeze (so that /etc/inetd.conf.d/ is in place)
        * should install xinetd fragments in /etc/inetd.conf.d/ (and in
          /etc/xinetd.d/ if they did so already)
        * must continue calling update-inetd in postinst/prerm scripts as
    * update-inetd will:
        * install /etc/inetd.conf.d/ and declare file-trigger interest in it
        * keep the old functionality, but additionally to updating
          /etc/inetd.conf, also update /var/lib/update-inetd/* using as input
          both /etc/inetd.conf and /etc/inetd.conf.d (and /etc/xinetd.d if

* squeeze+1
    * all deamon packages that use update-inetd [1]:
        * should drop their dependency in update-inetd and should not call
          anymore update-inetd in postinst/prerm scripts
        * must install xinetd fragments in /etc/inetd.conf.d/
        * must not install fragments in /etc/xinetd.d/ (to allow for future
          potential extensions to the xinetd vocabulary to accommodate
          features of yet-to-come more advanced inetds)
    * all ``Provides: inet-superserver'' packages must [2]:
        * version-depend on the squeeze+1 update-inetd
        * be patched to read their config from /var/lib/update-inetd
    * update-inetd must:
        * sync effective inetd configurations based on /etc/inetd.conf.d/ and
          reload inetd when invoked without any arguments
        * only run as as result of being triggered by a deaemon
          (un)installation, or an explicit user invocation
        * drop the old functionality and print a warning but otherwise succeed
          when invoked with any of the old command line switches

Open Issues

Removed deamon packages that are not purged (default) will leave behind
fragments in /etc/inetd.conf.d. This will result in errors in deamon.log for
missing server binaries. Some options are (in order of preference):

* ignore fragments referring to non-existent server binaries (doesn't work for
  internal services)
* do nothing (the approach taken by xinetd) apart from documenting it
* make deamon packages install an empty file in
  /usr/share/update-inetd/installed-packages, to enable update-inetd to
  tell apart which fragments actually refer to installed packages (might cause
  problems with unofficially installed deamons)


[0] the main idea is due to Roger Leigh, but fire at me for anything you don't
[1] 40: the number of update-inetd's rdeps in main/unstable, excluding
    ``Provides: inet-superserver'' packages
[2] 4: the number of ``Provides: inet-superserver''

debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp

Reply to: