In article <199510222332.XAA02920@cloud9.net>,
Thor Lancelot Simon  <tls@cloud9.net> wrote:
> 
> I've been mulling over what it would take to add Hesiod support to NetBSD,
> and I am somewhat unhappy about some of the answers I've come up with.  I'd
> like to hear some suggestions, if anyone has them.
> 
> 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.  This

Ick. This still wouldn't "fix" getpwent, BTW. What if bob isn't logged
on, but someone tried to tab-complete "~bo" in bash (which I assume uses
getpwent for that)? It would seem a zone transfer would be needed,
either in a hacked login or in getpwent(), do implement the full
semantics of getpwent() correctly. Bleah.

> The unfeasibility of a getpwent() equivalent, however, raises some nasty issues.
> It would be pretty easy to add Hesiod support to getpwnam() and getpwuid(), I
> think, and that at least should be done.  But there are a lot of programs in
> the source tree that use getpwent -- csh being the most important -- and those
> simply _can't_ work with Hesiod unless rewritten to use getpwnam() or
> getpwuid(), which does at least seem feasible.

How badly do such programs loose if getpwent only returns entries from
the local password file (plus maybe the current user's entry, as a
compatibility helper)? What do they use getpwent for?

> 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.

Leave it in, but have it only read the local password file (plus the
current user, or maybe in a nsswicht-style implementation fall through
to "later" access methods). Document it that way, and maybe have a
linker warning to that effect.

> I would be interested to hear what other people think about this subject, and
> also of any legitimate use for getpwent() that can't be worked-around.

Well it DOES seem, just from general principles, that there should be a
way to enumerate all the entries in any database.  OTOH, I really want
Hesiod, and I don't see any reasonable way to provide that.  On the
third hand, the first hand's argument applies to DNS in general so
gethostent() should work with bind as well.  Maybe login should also
build /etc/hosts via recursive query of the full Internet namespace? ;-)

-- 
Ty Sarna                "I guess one person _can_ make a difference,
tsarna@endicor.com       but usually they shouldn't" -- Marge Simpson