md@Linux.IT (Marco d'Itri) writes: > On Aug 10, Roger Leigh <email@example.com> 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 to 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. 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.
Description: PGP signature