> Iowa State, being the second largest Athena site outside of MIT,
> made extensive use of Hesiod.  And integrating a NetBSD system into
> that environment wasn't always trivial.  At the very least, it could
> be frustrating and time consuming because you had to do all the
> Hesiod and Kerberos integration yourself each time.

I don't understand the problems you're referring to.  At MIT, we've
had no particular trouble integrating NetBSD into the Athena
environment, and the Hesiod library required essentially no porting
effort.

You might be referring to the integration of the login system
(required in xlogin, login, and telnetd), since that's where YP is
built into the system and Hesiod/Kerberos require hacks.  The login
system required the most porting effort (partially because the
implementation is really broken right now, and partially because of
the BSD 4.4 passwd file layout); you can look at
/afs/sipb.mit.edu/project/sipb-athena/{xdm,login,telnet} for finished
ports of the login system.

We have had some problems with Hesiod and Linux, because MIT's use of
Hesiod plays fast and loose with ordering and Vixie's latest named
scrambles DNS lookups.  That's MIT's fault, though.

A couple of notes in response to James Graham while I'm here:

> Anywho, outside of generating a larger library (and that not by all
> that much, if you think about it), what's the problem with stuffing
> NIS into libc, bletcherous/wrong/insecure/stupid/crufty
> notwithstanding? :-)

YP requires hooks into several C library functions.to operate, such
that having a separate libyp wouldn't work very well.  At the same
time, you get parts of YP linked into your program when you don't use
it.  Sun solved part of this problem by having a layer called nsswitch
in gethostby{name,addr} which dynamically loads a library implementing
the resolver for whatever name services you've configured the system
to use.  Unfortunately, nsswitch conflicts with Hesiod in that Hesiod
wants to add a new kind of DNS query, but there's no nsswitch
interface for Hesiod queries and no analog to Hesiod's name/type query
in YP (although the Hesiod library provides standard lookups for
passwd, service, and pobox lookups, so there are presumably analogs in
Hesiod to some YP queries).  Fortunately, Sun includes the BIND
resolver in libresolv.a, but they made nsswitch reentrant and left
libresolv non-thread-safe, so Hesiod can't make use of Sun's reentrant
DNS resolver.

I've heard mumblings about Vixie wanting to do nsswitch "the right
way"; I don't know how this would interact with Hesiod.

> I think I just answered my own question and I keep wanting to say,
> "so let's move the NIS stuff into libyp" but I keep coming back to
> the answer that NIS is just more firmly entrenched than any other
> Network Information Database, along with BIND.  Unfortunately, BIND
> by itself has not (historically) served any other kinds of necessary
> information such as passwd, group, etc.  Had it done so from the
> outset, we probably would not see the abomination of NIS today.

Think of Hesiod as the client-side interface to doing passwd, group,
etc. distribution using DNS.  Indeed, all the Hesiod library does is
cons up a DNS query asking for text records for
name.type.ns.<hesiod-realm> with class HS instead of IN.