On Wed, Jan 20, 2021 at 01:37:44AM +0700, Robert Elz wrote:
> Date: Mon, 18 Jan 2021 22:15:30 +0000
> From: David Holland <dholland-t...@netbsd.org>
> Message-ID: <yayigi3v31qvd...@netbsd.org>
>
> | ...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).
> [...]
> But please, no, file name suffixes are a horrible idea, invented to
> cope with file systems with either no (rational) directory scheme
Basically what you want is to read only files matching some glob that
matches the POLA reasonably well, like "*.conf".
The reason to have a suffix and only read files with that suffix is
that there are lots of ways to get extra files in the directory that
the user didn't mean for you to read, and ~98% of the time they won't
have the right suffix so filtering by suffix is a good way to skip
them and avoid trouble.
This doesn't just mean foo.conf~ files left behind by emacs, but also
files like foo.conv,v, directories named RCS, and things like that. :-p
Without the suffix filtering you just can't have a directory named RCS
in there.
Alternatively you could put the glob in the include explicitly
(that is, "include dir/*.conf"
> 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.
I don't think you want to include a whole subtree recursively. I can't
think of any tool that does that by default, including these read-a-
whole-directory tools meant to be fed by package managers.
> | ...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.
Perhaps. That's at least reasonably sane, but I think in general it's
better to design things so you don't need to do that either.
E.g. (partially cribbing from Mouse's example) to avoid pasting listen
addresses all over the place you might have some syntax like
10.10.10.10:
ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd
finger stream tcp nowait nobody /usr/libexec/fingerd fingerd
20.20.20.20:
httpd stream tcp nowait _httpd /usr/libexec/httpd httpd /var/www
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -ll
where the listen address is a global setting in the config file that
changes over time. Making changes to it not escape include files is
one way to avoid allowing regrettable things to happen, but something
like this also avoids the problem without need for the global
variable, plus works better with ipv6:
service ntalk type=dgram user=nobody:tty options?=
/usr/libexec/ntalkd ntalkd $(options)
service finger type=stream user=nobody
/usr/libexec/fingerd fingerd
service httpd type=stream user=_httpd dir?=/var/www
/usr/libexec/httpd httpd $(dir)
service ftpd type=stream user=root options?=
/usr/libexec/ftpd ftpd $(options)
interface inside ipv4=10.10.10.10 ipv6=fe80::...
interface outside ipv4=20.20.20.20 ipv6=1234::...
enable ntalk listen=inside
enable finger listen=inside
enable httpd listen=outside
enable ftpd listen=outside options=-ll
and among other things it also lets you quickly slap down things like
enable httpd listen=inside port=8080 dir=/var/www.new
for testing purposes.
--
David A. Holland
dholl...@netbsd.org
