Re: inetd Enhancements

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> We are a team of senior CS students from Western Washington
> University, and we are currently working a project to implement the
> enhancements to inetd as described here:

> https://wiki.netbsd.org/projects/project/inetd-enhancements/

> We want to get community input, so that the changes we make will be
> as convenient, helpful, and unintrusive as possible.

Well, in my role as gadfly and iconoclast.... :-/

> When it comes to adding per-service configuration files, our current
> plan is to add a new configuration command, simlar to xinetd's
> "includedir", that allows for specification of a per-service
> configuration directory.

Personally, I think this is a bad idea, most fundamentally because it
enables, even encourages, administration without understanding.

Not that my opinion really matters.  NetBSD long ago ditched support
for the niche I belong to; I'm still here partly out of inertia, partly
for work, but mostly because NetBSD, even decade-old NetBSD, is better
for my use cases than the alternatives I'm aware of.  And I still care
enough to try to be a voice, even if only a lone voice, crying for a
return to some semblance of sanity.

> 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).

"Cleaner" and "easier to read" are matters of opinion and taste.
Personally, I find the description I managed to find of what xinetd
does to be significantly less clean and harder to work with.  (Easier
to read, I'm not sure.  Easier to read for someone not used to it,
probably, but harder to read for someone used to it, because it's
substantially wordier.)  Less clean because the additional syntax fluff
is an analog to what Tufte's delightful book _The Visual Display of
Quantitative Information_ calls "non-data ink": it is redundant, it is
in-file bytes that carry far less information content than that many
bytes are capable of.

Of course, the flip side of this is flexibility.  Personally, I would
look for a way to express the flexibility in a more compact way, one
that doesn't invalidate existing files and doesn't take a dozen lines
to express what used to be one line.

> 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.

I think that would be another disaster.  I would look for a design that
supports the flexibility without invalidating old files and without so
much fluff, or at least without *requiring* so much fluff.

You started off speaking of being unintrusive.  I find it hard to see
how changing the config file syntax so as to invalidate existing
configurations could possibly be considered unintrusive.

> Our reasoning behind making these changes is that it will clean up
> the inetd.conf file, as well as allow for easier implementation of
> per-service rate limiting.

"Clean up" I addressed above - I don't find xinetd-style configuration
cleaner; quite the opposite.

As for rate limiting, well, inetd as of even 1.4T had per-service rate
limiting, in the form of a per-service maximum number of requests per
minute.  Perhaps you're just talking about more flexible,
comprehensive, or otherwise better rate limiting - I find it hard to
see how it could get much easier than adding a number to the service's
line.  Or perhaps modern NetBSD has lost that, in which case I'd be
more concerned about why and how such a crippling regression was
introduced.  (And, for the sake of logical completeness, there's the
possibility that modern NetBSD has it but you think it doesn't, but I
would hope you'd know more than that about inetd if you're planning to
rewrite its configuration file support.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B