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
$package?
> 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: