Thomas Richard Stevenson writes:
> There must be some reason why the different DCE vendors didn't take
> the NIS approach. Does anyone know what that might be (I know that DCE
> does much more than NIS does, and I'm not suggesting for a second that
> NIS does anything else (other then in this one small area) better then
> DCE, so please lets not turn this into a religious war comparing NIS
> and DCE)?
The problem with the NIS approach is that the library (libc.a) has to
know how to handle the passwd file. That means the protocol used to
access the passwd file gets wired into every workstation, and every
program. If you change the protocol, then all the libc's have to be
changed, and all the programs that use libc have to be compatible with
whatever the new routines are. Because the protocol gets used by
untrusted programs, it's much harder to build proper security in. For
instance, secret key encryption is right out, because the program isn't
trusted. Public key technology has cumbersome domestic licensing.
Either public or secret key technology when used in untrusted programs
become a difficult export issue as well. NIS also has a serious scaling
issue: every program goes out through libc directly to the network to
get at the network database; so network load goes up more or less
as the square of the size of the user population (it's the product
of the size of the passwd file & the # of machines).
The obvious solution is to make some sort of local machine copy of the
passwd file. This reduces the the network load, because the contents
of the file now merely need be propagated once when changed on a
per-machine basis, not heavily redundantly piecemeal when needed on a
per-process basis. A monolithic trusted program now copies the file, so
secret key encryption can be used, & export issues become simplier to
resolve. Machine dependencies can then also be sorted out on a
per-machine basis by merging in some sort of local file and resolving
any conflicts in favor of the the local file.
This is, perhaps, not the final word on passwd files. It's still
handy to separate out issues of "who is allowed to log into X's
workstation" from "how do I get to Y's home directory". Ie, it's nice
if ~ file expansion works even for users who shouldn't be allowed to use
your workstation. There are still many vendors who persist in selling
machines that don't really support UID's greater than 65535. This
becomes a problem at a large site -- even if you don't anticipate any
particular machine having more than a few hundred users allowed to use
it, you are still constrained by having to have everyone share the same
low UID space. It would be nicer if out in the network, files were not
stamped with UID, but with something else, that could be mapped to low
UID's on a per-machine or per-workgroup sort of basis. Just to add
insult to injury, the limit isn't even 65535, that whole range around
60000 and above is a problem too, and there's even sort of another one
at about 32767, and of course, anything under 100 (or more usually,
under 1000) is just plain bad news. Very large flat passwd files have
bad lookup behavior; it's nice to have some sort of local dbm file to
speed up lookups. Propagating passwd files & managing changes to them
is another somewhat thorny issue. Users don't always like being told
"wait until tomorrow before your account will work". It would be nicer
if something very like the same callback mechanism one used to catch
changes to DFS files could be used to catch changes to the passwd
file. At the same time, it would be nice to keep a copy on more than
one fileserver, to replicate in case of server failure, and to
distribute the load. In a very large environment, it's nice to separate
out "giving home directories out" and delegate that to one or more
"account offices" who aren't necessarily directly able to create
filesets or make mountpoints. That essentially means some sort of "home
directory" server that can create home directories and do all the ugly
work itself, presenting a simple interface for "the front office".
-Marcus Watts
UM ITD PD&D Umich Systems Group
