#define AUTHOR "rhealey@kas.helios.mn.org (Rob Healey)"

/*
 * > > To begin with, I don't think that the way Hesiod is used at MIT is "right".
 * > > At MIT, login uses hes_getpwnam() to get the user's password entry, and then
 * > > *adds it to the local /etc/master.passwd* and then runs pwd_mkdb.
 * > 
 * > Why not just put it in /etc/passwd, which isn't a critical file since
 * > it's derived from /etc/master.passwd?   Admittedly, this is still
 * > somewhat lame, but at least less so...

This is even worse, since what if someone logs in while root's doing
something?   Imagine this:

	User "joeblow" logs in.  /etc/passwd gets modified.
	Root calls "vipw".  /etc/master.passwd gets modified.
	Root exits.  /etc/passwd gets updated.

It's not difficult to imagine what happens next.

 * 	Isn't getpwnam() and company part of SPEC 1170? By ditching it
 * 	aren't we trashing the ability of NetBSD to be standards
 * 	conformant?
 * 
 * 	I know BSD'ers hate, loath and despise all things SVR4 and Solaris-ish
 * 	but I think something like a database service switch similar to
 * 	nsswitch.conf in Solaris is the better way to go for ALL services.
 * 	That way we can add arbitrary network database services by adding
 * 	a dynamic library and a directive to a config file.

I think this was hashed out some time ago, though not with any spectacular
results.  One of the sticking points is that with the special symbols at
the beginning of an entry one can cause the NIS/DNS/NIS+/Hesiod lookups
to happen at arbitrary points.  I've forgotten what it can buy you, but
it seemed important at the time.  I even suggested that, instead of
overloading symbols at the beginning of a database entry, we could preserve
'+' for backward combatability, and go forward with something like & or
whatever followed by [NIS],[DNS],[NSP],[HES] or whatever to indicate
that the appropriate lookup could be used at that point.

 * 
 * 	Work on this is already being done, why not accelerate that work
 * 	rather than removing functions that don't need to be removed? Plus
 * 	this method won't require N different function calls to do the
 * 	same thing for N different services.

nsswitch doesn't change this, fundamentally.  You still need to have
access to N different methods of information retrieval.  All the nsswitch
does is to internalise this to the get* routines.  In fact, we have now
added a level of indirection as the get* routines call something else
based on the nsswitch.  getpwnam() would now look like

struct passwd *
getpwnam(char *name)
{
	return (getnsswitch("passwd")->func)(name);
	/* no error checking; this is an example, not production code. */
}

i.e. getpwnam() has just become a wrapper.
	    

Now, if you mean that nsswitch does a better job of hiding the unnecessary
(non-)trivial details from the programmer/user, then I agree with you.
But the internal complexity does not decrease.

 * 
 * 		-Rob
 * 
 */

#undef AUTHOR	/* "rhealey@kas.helios.mn.org (Rob Healey)" */




				--*greywolf;
--
# greywolf@captech.com
# "...to raise a signal means to turn the light on; ... Responding to a
#  signal means turning the light off (and, under System V, hoping the bulb
#  won't blow when it's next turned on)..." -- Dan Bernstein