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

Re: xinetd is a viable inet-superserver

On Thu, Nov 29, 2007 at 10:17:22PM +0000, Roger Leigh wrote:
> 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.

Why should that be the job of the current update-inetd?

> And every maintainer script has to call update-inetd to make it write
> package-specific information, which is fragile

Fragile in what sense?

> it only gets done when you install the package, and if you screw up
> inetd.conf, too bad.

Er?  Screw it up how?  Why would it not be fixable with dpkg-reconfigure

> 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

Using conffiles is a big *DIS*advantage.  Conffiles are only minimally
appropriate when there's a stock config which is expected to work for most
users, and in the best of cases are annoying for users who diverge even
minimally.  When we're potentially talking about a config file format that
contains the information about whether a service is enabled or disabled,
that's a Bad Idea.

You're also talking about a totally new config format that nothing actually
*reads* today, so now instead of doing the right thing and teaching a tool
to parse & output the existing formats, we instead have a tool that parses
one format and outputs another with the result that there are two copies of
the information stored on the system - one in the place where existing users
expect to find it which is *not* authoritative, and one in a totally new
format that is authoritative.

This is also a Bad Idea.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: