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

Re: xinetd is a viable inet-superserver



Steve Langasek <vorlon@debian.org> writes:

> On Wed, Nov 28, 2007 at 12:34:47PM +0100, Pierre Habouzit wrote:
>>   [0] the reasoning is: this is clear to me that through update-inetd
>>       that is the debian way to enable inet-like services, something
>>       that claims to be an inet-superserver must react on update-inetd
>>       triggered changes.  update-inetd atm only acts on /etc/inetd.conf,
>>       so as a consequences I believe it's necessary for an
>>       inet-superserver provider to grok /etc/inetd.conf.
>
> This is at odds with many years of discussion on this mailing list, where
> the consensus was that xinetd should have its own update-inetd that supports
> the xinetd config format natively.

The main problem (as I see it) is that the current update-inetd is too
complex, and can't migrate configurations between different inetd
config file formats.  And every maintainer script has to call
update-inetd to make it write package-specific information, which is
fragile; it only gets done when you install the package, and if you
screw up inetd.conf, too bad.

Why don't we take a leaf out of how other packages manage things and
do this:

- create a /etc/inetd.d directory
- each package providing an inetd service can contain a
  /etc/inetd.d/package file containing all the information about the
  service; it could be a superset of the information xinetd and all
  the other inet daemons require, and have a parameter to
  enable/disable the service.  This should be a conffile.
- update-inetd takes no arguments, it just reads all the files in
  /etc/inetd.d/ and then writes out an inetd.conf, or xinetd configs,
  whatever the daemon requires.

This has the big advantage of

- allowing the user-customisable bits to be in conffiles for
  preservation across upgrades
- makes the whole thing much simpler, maintainable and extensible
- each inetd can provide a *trivial* update-inetd to read through the
  config files

There will be a complication about preserving /existing/
configurations, but it shouldn't be difficult to handle this as a
one-time task on initial upgrade, especially considering that the
number of inetd-using packages is reasonably small.


IIRC I did mention something along these lines for consideration
post-etch last year or so, but I've been busy in the meantime.
However, such a migration should be doable for Lenny; it would just
need coordination to update all packages using update-inetd.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: pgpmbpSw6tJEp.pgp
Description: PGP signature


Reply to: