Re: inetd Enhancements

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Nov 22, 2020 at 09:53:27PM -0500, Mouse wrote:
 > Not quite.  It's not about the admin having to pass a test in order to
 > be one of the elite who get to use $PACKAGE.  (I know that's going
 > beyond what you actually wrote; it's approximately what I suspect a lot
 > of people will read into what you wrote, whether you meant it or not.)
 > It's more that I don't like automated administration of the "I'm going
 > to put all these pieces in what I fondly hope are the correct places
 > and hide it all from the admin" sort.

Done properly, it doesn't do that.

The main (and rather large) downside of making a directory full of
tiny files for each config task, instead of a single file, is that
it's a large and untidy mess and it makes it hard to get an overview
of what's going on, hard to keep track of changes, and also hard to
make updates.

The main advantage is that the resulting files can be handled by
package managers, whereas merging stuff from packages into a single
file is complicated and fragile.

The important issue is: what's this crap being added by packages
anyway?

In the case of inetd, the definition of a service is not really
configuration. Sure, it configures inetd in the sense that it tells
inetd what to do, but modulo the possibility of passing flags to
daemons there's only one correct way to define any given inetd
service. They are not configuration in the sense of material edited by
the sysadmin to adjust how the system operates.

For example:

   ntalk   dgram udp wait   nobody:tty   /usr/libexec/ntalkd ntalkd

If you change anything on that line, apart from "nobody" or adding one
of talkd's minimal command-line options, it won't work correctly. And
changing "nobody" is not a good idea or necessary in any reasonable
case. The only things you can actually _do_ with it as a sysadmin are
(a) comment it out (that is, turn it on or off) and (b) add those
options.

If inetd.conf instead contained something like

   ntalk on flags -l

and the service definition were elsewhere, the only drawback to the
experienced sysadmin is that it's not the traditional syntax so they
have to read the directions. (And yes, that's a real drawback, but not
a huge one.) For the newbie sysadmin there's a minor advantage, namely
that they can't break it accidentally by editing it wrong, e.g. by
doing

   -ntalk   dgram udp wait   nobody:tty   /usr/libexec/ntalkd ntalkd
   +ntalk   dgram udp wait   nobody:tty   /usr/libexec/ntalkd -l ntalkd

instead of

   -ntalk   dgram udp wait   nobody:tty   /usr/libexec/ntalkd ntalkd
   +ntalk   dgram udp wait   nobody:tty   /usr/libexec/ntalkd ntalkd -l

(which is an easy mistake to make).


Now, in this new world where inetd.conf contains

   ntalk on flags -l

and somewhere else there's a service definition that says e.g.

   ntalk   dgram udp wait   nobody:tty   /usr/libexec/ntalkd ntalkd ${FLAGS}

it makes _no sense whatsoever_ to split inetd.conf up into tiny files
in a subdirectory. In this new form, there's nothing whatsoever in it
that should be getting adjusted by package management -- both the
on/off switch and the flags are system configuration that should be
changed only by the sysadmin. (I'm aware that in the Linux world
installing a daemon seems to also imply turning it on automatically.
This is just wrong.)

(If you have the misfortune to be using puppet or ansible or similar
tools, those should be blatting in the whole inetd.conf file at once,
and there's still no reason to subdivide the file.)

On the other hand, the _service definitions_ can come from one file or
ten files or a gazillion files and nobody needs to care as long as (a)
inetd can find them and (b) they get installed into the right place.
For these it is definitely convenient to have a subdirectory scheme so
that packages can install inetd service definitions. Right now the
state of the art for that is for the package to print a message at
install time and hope the sysadmin notices, which is useless enough
that very few third-party packages ever shipped as inetd clients even
back in the days when most systems would have had inetd running and
serving various standard things.

Note though that this directory is not system configuration and
doesn't belong in /etc. It should be /usr/share/inetd, plus also
/usr/pkg/share/inetd, and for completeness /usr/local/share/inetd.

xinetd does not get this right. Few if any of the foo.d schemes
arising from the Linux world have gotten this right.

Getting it right requires at least two things that demand a deeper
understanding of system design than the Linux world seems to be able
to muster in general: (a) understanding the difference between genuine
sysadmin-facing configuration and other material; and (b) setting up
configuration schemas to respect this difference.

-- 
David A. Holland
dholland%netbsd.org@localhost