Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!bacchus!treese
From: treese@athena.mit.edu (Win Treese)
Newsgroups: comp.unix.wizards
Subject: Re: YP required with NFS?
Message-ID: <140@bacchus.MIT.EDU>
Date: Mon, 19-Jan-87 02:23:10 EST
Article-I.D.: bacchus.140
Posted: Mon Jan 19 02:23:10 1987
Date-Received: Mon, 19-Jan-87 19:01:57 EST
References: <3453@bu-cs.BU.EDU>
Sender: daemon@bacchus.MIT.EDU
Reply-To: treese@athena.mit.edu (Win Treese)
Organization: MIT Project Athena
Lines: 33

#include <line-eater-food.h>

Steve Blasingame writes:

>>Yes, yp is fundamentally the wrong way to do things. On SVR3 RFS you
>>can also do what you are talking about. Just use remote versions of any
>>files in question either via a symlink (on a sun) OR by just remotely
>>mounting
>>a subtree over the one on a client machine. This may cleaner and easier
>>to manage. I have seen the latter on RFS and it is much more reasonable.
>>The clients also tend to survive server crashes quite well.
>>

This scheme (symlinks) symlinks doesn't scale very well, though.  One of the
main problems is robustness.  In a large network (say, a couple of hundred
workstations), you may have several different servers for a particular
network service.  For something like hostname resolution, it is important to
be able to talk to a different server if your primary one crashes.  This
doesn't work with symbolic links.  A distributed nameserver package (such as
Berkeley's BIND, included with 4.3) offers this flexibility.

BIND may also be extended to provide more general resolution of names
on a network, giving information about locations of services (such as
printing) available through the network.  This may not seem important
on a local Ethernet with about six workstations on it, but can be a major
headache when trying to manage a few hundred all at once.

	Win Treese
	Systems Engineer
	MIT Project Athena

ARPA: treese@athena.MIT.EDU
UUCP: ...!decvax!genrad!mit-eddie!mit-athena!treese