Subject: Re: Hesiod thoughts
To: Ted Lemon <mellon@fugue.com>
From: Rob Healey <rhealey@kas.helios.mn.org>
List: current-users
Date: 10/23/1995 09:27:05
> > 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...
>
> > What I think I've come to is the realization that if we're going to add
> > Hesiod support to NetBSD, we have to declare getpwent() deprecated, add a
> > linker warning like for setreuid(), and excise it from our source tree.
>
> I think this is the right thing to do, although I'll probably go down
> in flames for saying so. An alternative would be to maintain a list
> in hesiod of all the usernames, and then use that list do implement
> getpwent. Ugly, but it would work. Ultrix does something like
> this.
>
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.
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.
-Rob