Re: inetd enhancements - config syntax

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 18 Jan 2021 22:15:30 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <YAYIgi3V31qvd3+j%netbsd.org@localhost>

  | ...and also, for your own and the operator's sanity, skip anything
  | else beginning with '.',

That one is probably reasonable (and also possibly some other odd
character, to give an easy way to "turn off" a file in a directory,
without removing it - and without 'hiding' it using a '.' name).

  | names that don't end in ".conf" (or ".inetd"
  | or whatever you think the proper suffix should be),

But please, no, file name suffixes are a horrible idea, invented to
cope with file systems with either no (rational) directory scheme
(ie: like one big flat directory for everything) or where using
directories is either very inconvenient or costly.  There's no reason or
need to invent such a scheme for this, accept almost anything as
the file name (with no semantics applied to it at all).

  | and anything that isn't a regular file (DT_REG).
  |
  | (If you get DT_UNKNOWN it's reasonable to call stat to get the real
  | type rather than just skipping it, and you might want to allow
  | symlinks, but definitely skip directories, devices, named pipes, etc.)

Devices and pipes, etc, yes, but I thought the idea was to allow recursion
through directory trees.   For that just skipping directories isn't the
right approach.  What's more being able to do that seems useful to me.

  | ...also I strongly recommend against having global settings that are
  | meant to change around as things are included

While in general I think I agree with what you mean, I wouldn't write
it like that.   What I'd say instead is that anything in an included
file can affect only that file, and other files included below it,
nothing should be exported back to wherever the file was included from.

That I think allows plenty of generality, and

  | (such that the order includes are processed in matters)

would not be an issue (obviously, when includes are specified
	include A
	include B
A would naturally be included first, then B, though even there, it
shouldn't matter, but
	include DIR
can simply include all (appropriately filtered) files from inside
the named directory in whatever order they're encountered.

And replying to a second message, all in this one reply:

    Date:        Mon, 18 Jan 2021 18:32:16 -0500 (EST)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202101182332.SAA15621%Stone.Rodents-Montreal.ORG@localhost>

  | > and anything that isn't a regular file (DT_REG).
  |
  | I don't recall whether this is relevant (it's been quite a while since
  | I did anything with d_type), but I strongly believe that symlinks
  | should be followed before any such test.

That makes not much sense, the d_type tells you it is a symlink, so
the test comes first, and after that you decide what to do with it.

But I agree with the sentiment, if the code is to use the d_type field
as an optimisation (which for this purpose I'm not sure is really worth
it, since not all filesystems contain such a thing, resulting in DT_UNKNOWN
for almost everything, the code to stat() needs to be there anyway,
I'd just use it, and ignore d_type - it isn't as if inetd reading its
config files is ever likely to be a very time consuming task, however it
is implemented, and it doesn't happen very frequently).   For the stat()
code I'd be using stat(), not lstat(), which nicely deals with the symlink
issue...

  | If such a check does go in, well, I don't *think* O_PLAIN (fail if the
  | putatively-opened object isn't a plain file) dates back far enough I
  | got it into NetBSD's tree,

We have no such flag:

jinx$ grep O_PLAIN /usr/include/* /usr/include/sys/*
jinx$

  | I may - occasionally - write code that uses global variables that way,
  | depending on precisely what you mean.  I definitely think there is a
  | place for (to borrow from the current syntax for a moment)
  |
  | 10.10.10.10:
  | .include "private-stuff/"
  | 20.20.20.20:
  | .include "world-facing-stuff/"
  | *:
  | .include "everybody-stuff/"
  |
  | This may or may not be an example of what you're talking about.

I agree that should work, and should still work no matter how deep
down include file nesting it occurs.   The question really is
what happens with

  | 10.10.10.10:
  | .include "private-stuff/"
  | *:
  | .include "everybody-stuff/"

if private-stuff/service1 contains

	1.2.3.4:
	<whatever spec to start the first server>

and private-stuff/service2 contains just

	<whatever spec to start the second server>

and then does it matter whether sevice2 is included before or after
service1.   If before, then it is clear that the second server would
listen only on 10.10.10.10, but if service1 is included first, then
the listen addr (depending upon the semantics specified) for the
second server might now be 1.2.3.4 (which it clearly is intended to
be, for either include order, for the first server).

  | I do think the order in which the directory entries appear in the
  | directory should not matter;

I agree, in the above, I'd have the 1.2.3.4: line only apply for the
rest of the file in which it appears (including any files included from
that file).   My point in the previous message was that the semantics
of all of this need to be clearly specified first - and that that is a
much more important issue than anything related to the syntax in which
the <whatever spec...> is encoded, which is, by comparison, trivia.

kre