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

Re: Status of inetd for etch

md@Linux.IT (Marco d'Itri) writes:

> On Aug 10, Roger Leigh <rleigh@whinlatter.ukfsn.org> wrote:
>>   installed, all using the same configuration file.  Is this a use
>>   case we really want to support?  Are there really setups running
>>   multiple inetds for a good reason?  Having a virtual
> A good reason usually is using features not available in a single
> package (especially inetd vs. inetd).
> It's not hard to manage anyway, my scheme allowed this.

We don't allow multiple mail-transport-agents, even though they have
different features.  Do we have a real, demonstrable, use-case for
permitting multiple inetds?  To me, it seems rather more manageable to
have just one, particularly because they all generally use the same
configuration file.

If this is something only one or two people with specialised needs do,
they can surely sort it out by themselves, as they would if they had a
specialised mail setup.

>> * netkit-inetd
> I agree that it should be removed from the distribution, or at least
> replaced by openbsd-inetd as the default inetd.

In that case, would it be possible for a netbase upload changing

Depends: openbsd-inetd | netkit-inetd


Depends: openbsd-inetd

or even

Depends: internet-super-server | openbsd-inetd

to allow for a future virtual package?  openbsd-inetd could implement
the virtual package right now, and the other inetds can fix up their
dependencies after.

>>   - The other packages have different init script names or need some
>>     work on the package dependencies (e.g. inetutils-inetd).  xinetd
>>     is in the same situation, but also needs some work on update-inetd
>>     before it will be suitable as a replacement.
> ITYM "lots of work".

Perhaps it simply needs approaching in a different way.  Rather than a
hugely complex update-inetd, why not have each inetd provide one which
works for them (with a common implementation for the traditional
format)?  On removal, they can (if using a file other than
/etc/inetd.conf) dump their configuration there to allow migration
between inetd packages and do the opposite on install.

>> * IPv6 transition
>>   - Should individual packages be made to listen on both tcp4 and tcp6
>>     sockets, or should this be done by the inetd itself, or even
>>     update-inetd?
> Only individual packages know if they support IPv6.

So what are you proposing as the solution here?

Should each package call update-inetd twice, for both v4 and v6?
(Assuming they support both.)

>>   - Some inetds automatically listen on v6, whereas others need it
> I call them "broken". I believe that administrators do not expect that
> services are exposed to IPv6 connections unless they are configured this
> way in inetd.conf.

Why?  All the other major daemons listen on both by default, and I do
expect inetd services to do the same where possible.  Most of the
services are already protected by TCP wrappers, so you would need to
explicitly add [::] to /etc/hosts.allow to get an IPv6 connection.

>>   Users upgrading from woody or sarge to etch will not be switched to
>>   openbsd-inetd, whereas new installs will use it by default.
> Did you actually test this?

I checked that new etch installs install openbsd-inetd.  Upgrades
won't be switched because the netbase dependency is already satisfied
by netkit-inetd.  In consequence, I think that netkit-inetd needs to
be removed from the netbase depends.


  .''`.  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: pgpGUSqcq2HRv.pgp
Description: PGP signature

Reply to: