Subject: Re: nsswitch implementation questions...
To: Peter Svensson <firstname.lastname@example.org>
From: Greg Hudson <ghudson@MIT.EDU>
Date: 01/20/1996 07:52:59
> I believe the conclusion you'll come to is that libc should parse the
> nsswitch.conf file at startup time and not make use of a db file.
> I reach the conclusion that many other databases used by libc needs
> updating. Perhaps a standard method for handling these would be
That would certainly be better than gradually adding more and more
code for each configuration file. But since people don't reach the
same conclusion as I do after looking at libc, I'd like to make the
following arguments (this is really a response to Luke's most recent
message, which I deleted too hastily):
* If you're concerned about speed, turning a small
configuration file into a db file probably won't help you
any. Caching the file contents in memory is a much better
Note that the existing configuration files which use
database files (/etc/aliases and /etc/master.passwd come to
mind) are actually system databases which are expected to
grow very large on some systems.
* If you're concerned about having to restart a daemon in
order to make a configuration file change happen, consider
that libc can't prevent this from being necessary. The
daemon may have cached any amount of information about the
system in application data (the hostname, the port for the
"telnet" service, the passwd entry for "root" and half a
dozen users, etc.), and libc can't do anything about that.
Thus it seems questionable to me that you want to add a lot
of complexity to libc without solving the problem. In
general, when you want to change your system's parameters at
a low level (your hostname, the resolvers in
/etc/resolv.conf, group membership, etc.), you don't expect
all running processes to pick up those changes.
* If you're concerned about getting partial data while editing
a configuration file, then libc isn't really equipped to
handle the situation alone. Currently the local filesystem
passwd database is the only libc configuration file which
tries to handle changes in a robust manner (although its
locking discipline is broken), and it uses a separate
command to guarantee atomic update of the file (as well as
to regenerate its database files).
Clearly this kind of makeshift solution can't go on until we
have "newaliases" and "vipw" variants for everything from
/etc/group to /etc/motd. It's not clear to me that we
really need to address this problem, but if we do, then we
- Modify vi and ed to do atomic updates, emacs-style,
with the corresponding risk of leaving temporary
files in random directories.
- Write a generic configuration file editor which is
also equipped to recognize the need for and generate
database files, following some convention (which the
passwd database would almost certainly not conform