Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!sundc!nears!occrsh!occrsh.UUCP!gorgo.UUCP!authorplaceholder
From: authorplaceholder@gorgo.UUCP.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: YP required with NFS?
Message-ID: <59000006@gorgo.UUCP>
Date: Mon, 26-Jan-87 11:21:00 EST
Article-I.D.: gorgo.59000006
Posted: Mon Jan 26 11:21:00 1987
Date-Received: Tue, 3-Feb-87 19:31:24 EST
References: <2231@brl-adm.ARPA>
Lines: 67
Nf-ID: #R:brl-adm.ARPA:-223100:gorgo.UUCP:59000006:000:3204
Nf-From: gorgo.UUCP!bsteve    Jan 26 10:21:00 1987


In response to bzs@bu-cs:

>Well, puff puff puff.
>
>I don't think it's obvious that "yp is fundamentally the wrong way
>to do things" [I'm not even sure what it means.]

This is very impressive stuff coming from someone who posts diatribe
in net.sources...

>This idea of mapping a single file might be fine in a trivial network,
>but what exactly do you do when your hosts file (for example) is
>mapped out across many systems, such as the internet's is (and
>maintained in pieces by many entities, who are the only one's who have
>the slightest idea what new machines are coming and going in their
>region.) Yp may not fully solve this (tho it sort of does now by
>interfacing to the name server, thanks Bill), but mapping a flat file
>will surely never solve it.

This may be partly true, but what is needed is more comprehensive still.
It should be such that at the user and application level only the 'complete'
file is visible. Also, on a very large network, we don't want to have to
search in lots of places across the net media very often. This is particularly
true of the internet. Even with better nameservers things could get alot
slower than they are now.

>Similarly for password files, can this scheme allow a local, user
>editable password file and a remote, more global password file? The
>root password on my diskless SUN is surely different than the server's
>(a local entry overrides) but otherwise I just map into the server's
>file (security problem you say? what isn't! and I don't see how this
>scheme for RFS ameliorates this problem except perhaps by severely
>restricting possibilities.)

The business of server and client password files is just fine, but is
also problematic. It presents multiple views of the same file. And as
for security, one will ordinarily want most of the passwd file entries
from client machines to map to the server for consistency. As for the
passwd file... I don't think that it should be necessary to share this.
The mapping should be handled either directly by a nameserver or (for
file sharing purposes) by a uid/gid driven nameserver. This eliminates
the security hole.

>Far be it for me to say that yp is perfect, but I don't think bashing
>it as fundamentally wrong is any help either, the people that designed
>it weren't idiots, mapping a file over NFS would have been the easy
>thing to do (and is done sometimes, our termcap entries are like this
>tho it could be yp'd to some advantage, minor issue.) There were real
>issues it addresses. Let's not let some operational issues besmear a
>fundamentally good idea.
>
I am still of the opinion that it is (while a clever solution) not
a sufficient method of addressing the fundamental problem of distributed
files. I am not sure that its primary uses (on suns) are even necessary.
It appears to address problems that should have been handled with a more
fundamental change in the operating system architecture.

>	-Barry Shein, Boston University

I am not bashing it Barry, but I do think that we need something else. I
only wish that you and I were clever enough to figure out what it should
be.

	Steve Blasingame (on Monster Island)
	ihnp4!occrsh!gorgo!bsteve
	bsteve@eris.berkeley.edu