[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 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?

My opinion here is that one should be able to install any package
Providing inet-superserver and expect the configuration to be carried
over in some working form and get a working system.  The Provides
should be indicating some basic level of equivalence in functionality
between the packages.

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

You can break the configuration of packages registering their services
with update-inetd depending upon the specific order of installation
and removal, particularly when combined with the replacement of one
inet-superserver package with another.

>> 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?

Usually, yes.  But, it shouldn't need that in the first place.

One major issue I have is how packages are using update-inetd:

[ /var/lib/dpkg/info/leafnode.postinst ]
update-inetd --comment-chars "#disabled#" --disable nntp
update-inetd --group MAIL --add --comment-chars "#disabled#" \
                "nntp           stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/leafnode"

We are hardcoding a particular inetd.conf format as an argument,
rather than specifying the fields separately.  Additionally, we are
not supporting IPv6--tcp4 is hardcoded, and this requires either
adding a second entry or amending the existing one.  For proper IPv6
support we need to get inetd services using IPv6 services out of the
box.

>> 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.

But, the existing format is *already* doing this--with specially
marked up comment lines (as shown above, yech!).  And in most cases
the user won't need to modify it; IMO each service as a conffile makes
as much sense as /etc/pam.d and similar.

It also makes updating by the package easier--currently update-inetd
either preserves the user modification or it does not; the user can't
later merge would /would/ have been updated as can be done with
.dpkg-new and friends--it's lost unless you dig through maintainer
scripts.

> 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.

Well, my implication was that a format such as the xinetd format would
itself be such a superset--we don't need to invent a new format.  And,
incidentally, it also already has a "disable" parameter to do exactly
the above.  update-inetd then need only translate one format.  And,
this format supports global defaults such as IPv6 settings which the
existing scheme will never do; this can be translated into multiple
lines for the traditional inetd.conf, something the maintainer scripts
can not do currently.


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: pgpdLdFOBBQy1.pgp
Description: PGP signature


Reply to: