Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!sun-barr!newstop!sundc!pitstop!helium!db
From: db@helium.east.sun.com (David Brownell)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reconciling /etc/hosts, yp, and named?
Summary: corrections about Sun386 story
Message-ID: <684@pitstop.West.Sun.COM>
Date: 26 May 89 11:43:56 GMT
References: <8905161521.AA02497@dsys.icst.nbs.gov> <7080016@eecs.nwu.edu>
	<8905180702.AA07229@sluggo.Eng.Sun.COM>
Sender: news@pitstop.West.Sun.COM
Reply-To: db@east.sun.com (David Brownell)
Organization: Sun Microsystems, Billerica MA
Lines: 50

In article <7080016@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
>/ comp.protocols.tcp-ip / melohn@ENG.SUN.COM (Bill Melohn) / May 18, 1989 /
>> In article <7080015@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:

	[ someone said, "Sun doesn't ** make ** you run YP" ]

>> >They do force it if you are their customer.  Their setup scripts tipically
>> >give you three choices:
>> >	1. YP server
>> >	2. YP client
>> >	3. not networked at all
>> 
>> This is misleading; the installation procedure used in the current
>> versions of SunOS allow you to choose one of the following options for
>> YP: server, master, client, or none. Independent of this choice is the
>> configuration option for network interface.
>
>I apologize.  I have only dealt with 4.0.1 on the 386i.

Actually, it's slightly misleading even on the Sun386i packaging of SunOS,
though the point that you weren't originally intended to network it without
YP is correct.  (No flames please; I really didn't like this, and this
restriction ** is ** being removed in the next release.)

The first choice is "yp master" (with extra services to maintain YP
remotely); slaves have to be set up separately.  Also, the only way a yp
master is different from a non-networked system is that the non-networked one
uses the internal loopback network for all its network traffic, not an
Ethernet ... they're both YP masters.

The reason behind this was to simplify things so that there would be just a
single straightforward way to administer things.  That's still something
that'd be great to see, but it can't be done with the existing YP protocols.
One of the main reasons is that YP doesn't have the kind of support that the
name server does, allowing multiple domains to chat with one another.  You
really ought to be able to set up a machine as a domain all by itself and
then use standard protocols to talk between domains, or to cooperatively
construct larger domains from sets of smaller ones.

I for one really look forward to using something that looks more like X.500
than YP, but that's a ways off into the future.  Even then, I suspect that
different sorts of applications will still need different ways to manipulate
their own naming/configuration data.

    David Brownell			dbrownell@sun.com
    Sun Entry Systems Software		sun!suneast!db
    Billerica, MA
    David Brownell			dbrownell@sun.com
    Sun Entry Systems Software		sun!suneast!db
    Billerica, MA