Re: inetd Enhancements

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

On Sat, Nov 21, 2020 at 08:24:56PM -0800, James Browning wrote:
 > 2. To inquire about the ideal way to implement per-service
 > configuration files in inetd.

Please see the other post I just wrote, even though it's somewhat deep
in the thread. (You don't necessarily need to read the rest of that
branch of the thread first.)

Per-service configuration files are a mistake. As the project
definition partly says, what you want are per-service _service
definitions_ and a single master config file that turns services on
and off. (And, perhaps, allows setting command-line flags, though
that's somewhat of a can of worms.) This seems to have migrated to
"nice to have" but is really essential for doing this correctly.

The other post explains in substantially more detail.

 > In addition we are considering also changing the syntax of the
 > inetd configuration file to be cleaner and easier to read
 > (something more in line with what xinetd does). We would like to
 > know if this change would be worth it at the cost of users
 > potentially needing to change their inetd config files to conform
 > to the new format.

You need to extend it, not change it. The current syntax has been
extended well past its elastic limit, so what this means in practice
is: continue to accept the old syntax but also accept files that begin
with "syntax v2" or "inetd.conf v2" or some other magic sequence that
isn't easily confused with a valid traditional inetd.conf line, and
are read with a different parser and have a completely different
syntax.

IIRC at one point there was a suggestion to use "#@" (by analogy to
"#!") for these markings but that may not be a good idea.

Don't follow xinetd blindly; there's nothing especially good about its
syntax and it doesn't have the service definition vs. configuration
decomposition.

 > per-service rate limiting.

This is also configuration, not part of the service definition, so it
doesn't belong in the service definition files. (Though a service
definition might want to come with a default set of rate limiting
settings.)

As other people have noted, the rate limiting is already at least
somewhat per-service and has been since at least 4.3BSD. I can't
remember how that clause got into the project description in its
current form; it's probably edit sausage. My recollection is that the
goal was to make the rate limiting more flexible than it currently is,
but I don't remember how and I haven't thought about this in years so
I'm not sure at the moment what would be useful.

Probably a good first step is to allow more reactions than
unceremoniously shutting off for a fixed (and rather long) period of
time. Configuring that period is an obvious direction. It should also
be possible to continue accepting connections but limit the rate at
which it happens (giving those who don't get in ECONNREFUSED).

Limits based on system load average, or the number of subprocesses
_running_ rather than the fork rate, are probably also useful.

 > [...]

Another important thing often gotten wrong doing this in the Linux
world: when pointed at a directory, don't read _every_ file in the
directory; read only the ones whose names match "*.conf" or "*.inetd"
or something like that. Otherwise you inevitably end up editor backups
or scratch files or other miscellaneous rubbish and problems ensue.

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