Hi Debian-QA,

While working on a bug in a package that involved an update-inetd rathole(#24043) I got to thinking about it.

It's got some really old bugs and can't handle a bunch of cases we care
about. There was the reconf-inetd effort
https://dep-team.pages.debian.net/deps/dep9/
but that is marked obsolete with the explanation

"As of Feb 2014: With a dynamic init system in Debian finally being
adopted, inetd is irrelevant, hence reconf-inetd too, so I mark this DEP
as obsolete, since it's not worth the migration effort."

Now that systemd provides a simple way to do socket activated services,
I think maybe we should stop automatically enabling things in maintainer scripts with update-inetd. People not using systemd or preferring other inet-superservers can still enable it for things they want. (1)

I guess update-inetd as a utility might still have some use, it doesn't necessarily need to go away, just the calling of it in maintainer scripts.

If I search for things still using it there is not much:

https://codesearch.debian.net/search?q=update-inetd+--add&literal=1

(NOTE: search is explicitly for --add, more stuff has postrm things
cleaning it up since they dropped it).

Also there was this old thread about packages depending on update-inetd

https://lists.debian.org/debian-devel/2007/07/msg01013.html

TL;DR packages shouldn't depend on update-inetd but instead should
depend on inet-superserver and packages that provide that will have the dependency.

apt-cache rdepends shows maybe 20-25 things that depend on it (that
aren't themselves an inet-superserver). I have not reviewed those to see
which already ship systemd files. I guess each of those would need one
if they didn't already one, cleanup any --add's, and document things in changelog/NEWS. Next step would be reviewing these and mass bug filing,
if people think this is a good idea.

NOTE: I am not (yet) advocating for getting rid of inetd in general,
maybe some people still prefer it, hosts.allow/deny/etc. But we could eventually have that discussion if people want.

1. I suppose it might be possible to have a debhelper tool that knows
about systemd and inetd and activates things accordingly but I have no
idea how much demand there would be for such a thing.

--
Matt Taggart
matt@lackof.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Mon, 2022-07-25 at 12:43:56 -0700, Matt Taggart wrote:

While working on a bug in a package that involved an update-inetd rathole(#24043) I got to thinking about it.

Now that systemd provides a simple way to do socket activated services, I think maybe we should stop automatically enabling things in maintainer scripts with update-inetd. People not using systemd or preferring other inet-superservers can still enable it for things they want. (1)

That'd mean having to add those manually, which seems inconvenient,
and a loss of existing functionality.

TL;DR packages shouldn't depend on update-inetd but instead should depend on inet-superserver and packages that provide that will have the dependency.

I've been working on switching the current implementation into a
declarative mode, and as part of that improving its parser:

https://git.hadrons.org/cgit/debian/update-inetd.git/log/?h=pu/declarative

I still need to add few more test and rereview it, but should be
uploading that soon, given that there's been no upload for too long.

The declarative format I'm currently working with is something like
this (although I've got my reservations about TOML):

,--- inetd-provider.toml (such as inetutils-inetd) ---
[provider]
package = "provides-inetd"
service = "provides-inetd"
`---

,--- inetd-service.toml (such as inetutils-talk) ---
[service]
section = "OTHER"
name = "some-service"
socket-type = "dgram"
protocol = "udp4"
wait = true
user = "root"
group = "root"
program = "/usr/sbin/tcpd"
program-args = [ "/usr/sbin/some-serviced" ]
`---

This will allow generating xinetd fragment files too, and removing the update-inetd calls entirely from maintscripts, and switching those to
triggers.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)