Subject: Re: /etc/default
To: Captech) <email@example.com (James Graham>
From: Theo de Raadt <firstname.lastname@example.org>
Date: 07/27/1995 04:44:24
> * nsswitch.conf
> This is rather interesting. I think they tried to do something right
> here, but they threw in the "compat" keyword which is only valid with
> two databases: passwd and group. If we were to do something like
> this, the obvious thing which would occur to me is that NIS stuff
> should be drawn in iff it hits a '+' in the file and possibly '@'
> for hesiod stuff (i.e. "compat" mode should be the default).
> On the other hand, it is kind of nice to be able to specify the order
> in which you want your databases read. For lookups to default to NIS
> for all other maps (Sun ignores many local files completely if NIS is
> running) is absurd. This is, of course, easily overcome by the rules
> above. I think Theo brought this up. It's a good point.
> As I don't have a running system yet (I intend to cure this real
> soon now), I can't check the specifics, so I don't know the order
> in which host resolution is done (i.e. is it files/DNS/NIS or
> files/NIS/DNS or is NIS ignored altogether? etc.).
let's look at a few files:
bootparams supports +
networks should be deprecated, to use standard hosts lookups
hosts has a flag to indicate checking sequence
group must support + in sequence for proper ordering
passwd must support + in sequence for proper ordering
ethers supports +
protocols could support +
rpc should support +
services could support +
any other files? i don't see anything else which seriously requires a
global special file to be added. all the support functions (for the
above files) can simply be written to handle a + if they see it. then
put just regular data in the file
put data followed by a +
put a + followed by data
put just a +
or heavens yes, put a + in the middle of the data if you wanted.
and if you wanted to support hesiod for these things too, you could
very easily use the @ hack that i've yammered about for a few years.
in my mind it is stupid to try to centralize the control of data files
when the control can be interspersed with the data.