Re: inetd Enhancements

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

> In the case of inetd, the definition of a service is not really
> configuration.

I could quibble, but, really, this is a very important insight, which I
have seen nowhere else, leading me to think everyone else - including
me - had completely missed it.  Thank you very much for pointing it
out.

There's a critical mindset change involved here.  inetd.conf was
presumably designed as a configuration file for inetd, telling inetd
what to do.  It works well for that.  What you have seen is that it is
much better to see it as specifying two different aspects of the
overall system config, aspects which are better split apart.  From the
mindset of "configure inetd", the response of "why would I shatter
inetd's config into even *more* pieces?" seems sensible.  It's only
upon shifting to seeing it as *system* config instead of *inetd* config
that this makes sense.

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

Well, I'd argue that commenting it out (or removing it entirely) also
qualifies, but that's just a quibble.

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

On *almost* all systems, yes.  See below.

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

Not quite.  The service definitions themselves also need to be
comprehensible, because sooner or later something is going to need
touching there.  (Later rather than sooner, if it's done right, but
still.  If nothing else, eventually an admin will want to add a service
that doesn't come in a prepackaged box.)

Furthermore, occasionally, a system will be used in an unusual enough
way that the admin _does_ need to fiddle something more than the on/off
switch or a few flags.  (For example, on at least two occasions I've
put a daemon other than the system-supplied one into my ftp line.)

> (And yes, that's a real drawback, but not a huge one.)

Agreed, on both counts.

> For the newbie sysadmin there's a minor advantage, namely that they
> can't break it accidentally by editing it wrong, e.g. [...]

Well...they still can break it by editing it wrong

	-ntalk on flags -l
	+ntalk ooffflags -l

but it is, admittedly, a harder mistake to make and an easier one to
find, and, importantly, easier to warn about most cases of.  (There's
not much you can do about something like

	-ntalk off
	+ntalk on flags -k

(assuming ntalkd doesn't take -k).)

> Now, in this new world [...] it makes _no sense whatsoever_ to split
> inetd.conf up into tiny files in a subdirectory.

Yes and no.  I think you will still see people arguing for it so that
automated package installation can just drop a file in rather than
having to edit a line into an existing file.

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

Yes, but adding a line so it's obvious it's there to be turned on is a
reasonable thing to want to do.  (It might be possible to address this
other ways; for example, if inetd could be run in a way that warns if a
service is defined but has no entry at all in the config.)

> (I'm aware that in the Linux world installing a daemon seems to also
> imply turning it on automatically.  This is just wrong.)

Most of the time, I agree.

But occasionally there are things that should be enabled on
installation because the package imposes restrictions rather than
adding capabilities.  (Firewalling might be an example.)  I can't
offhand think of any that would go in inetd.conf, but I'm not at all
certain there are none.

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

And (c) it's not so bad that it actually slows down system startup
significantly.  (Yes, I think that's unlikely.  No, I don't think it's
impossible, especially on slower hardware.)

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

I'm not sure I agree that it's not system configuration.  I consider
"what services are available to be turned on" a part of system
configuration - if I take an ordinary system and strip out (say)
ntalk's definition, I'd classify that as a configuration change.  An
unusual one, but still.

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

Little I've seen from the Linux world has gotten pretty much anything
right, but the Linux things I tend to notice and remember are the
things it gets wrong, so that may not mean much.

/~\ 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