@BERKELEY.EDU> (01/09/87)
Yes, you can run NFS without yp. When we first started installing sun clusters , the yp packets were doing awfull things to the uvaxen on the same ethernet, so we turned off yp until such a time the uvaxen got fixed. And yes, some sort of service like yp is needed. However, yp is *not* the answer. Having two versions of some files, the need to use ypcat to get the "real" version of things, and the inability to get to the files if they are being updated are all lossages. A nice, simple approach would be to make /etc/hosts, and other such things a symlink onto a remote mounted file system. I can't see any problems with that approach, (other than needing the real files there while you boot), but there are probably some. Anyone tried something like this yet? <mike
shannon@sun.uucp (Bill Shannon) (01/10/87)
In article <2231@brl-adm.ARPA>, @BERKELEY.EDU> writes: > ... A nice, simple > approach would be to make /etc/hosts, and other such things a symlink > onto a remote mounted file system. I can't see any problems with that > approach, (other than needing the real files there while you boot), > but there are probably some. Well, you named one problem. Another is that you have no distribution of the data so if you have (say) 10 netowrks with 400 machines, they would all depend on one central machine for the databases. Also, think about what happens when that machine goes down. YP distributes that load among multiple servers and provides some fault tolerance in the face of YP server crashes. All of these are good reasons to keep the name server separate from the file server. As has been said elsewhere, in small configurations the costs may outweight the advantages. In large configurations I believe the opposite is true. Bill Shannon
bsteve@gorgo.UUCP (01/13/87)
In response to: mwm@violet.BERKELEY.EDU comp.unix.wizards Subject: YP required with NFS? >And yes, some sort of service like yp is needed. However, yp is *not* >the answer. ....A nice, simple >approach would be to make /etc/hosts, and other such things a symlink >onto a remote mounted file system. I can't see any problems with that >approach, (other than needing the real files there while you boot), >but there are probably some. Anyone tried something like this yet? > > <mike 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. Steve Blasingame (under Monster Island) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
jdb@mordor.s1.gov (John Bruner) (01/14/87)
I don't have any great love for YP (in fact, I really dislike it), but a YP-like scheme can address some problems which symlinks across remotely-mounted filesystems cannot. In a large network environment some files (e.g. the password file, the host table if you don't use the name daemon, the mail aliases file) are so large that a linear search of the ASCII file is too slow. 4.3BSD handles this by creating dbm-format files that can be accessed quickly. However, these binary files cannot be used in a heterogenous network environment (e.g. by both Suns and VAXes). YP solves this by creating dbm-format files and interposing an intermediate process (the YP server) to access them. Since YP is built upon RPC, multiple non-identical machines have a uniform interface to the data. BTW, has anyone noticed that the resolver library routines are absent from Sun 3.2's libc.a? All hostname lookups are supposed to go through the YP server, which will contact the name daemon if it needs to. Apparently Sun figured that noone would want to access the nameserver directly (e.g. to obtain MX RR's). (On our machines, I compiled the resolver library from 4.3BSD and installed it as "libresolv.a".) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.s1.gov (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
bzs@bu-cs.BU.EDU (Barry Shein) (01/15/87)
>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. > > Steve Blasingame (under Monster Island) 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 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. 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.) 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. -Barry Shein, Boston University
treese@athena.mit.edu (Win Treese) (01/19/87)
#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
bsteve@gorgo.UUCP (01/26/87)
>This scheme (symlinks) symlinks doesn't scale very well, though. One of the >main problems is robustness. Agreed. This is why the mapping should be done with more than one server. If the primary server dies, nothing should happen to the client machines. >A distributed nameserver package (such as >Berkeley's BIND, included with 4.3) offers this flexibility. This is also a nice idea, but doesn't really attack the problem of dealing with active processes on clients when a server host goes down. In reality (in response to Barry (flames in net.sources) Shein), I think that yp does a pretty good job of handling the problem on large networks. However, it has some *very* undesireable features. Users should not have to care about the location of a file on the network. When I type 'cat /etc/passwd', I should see the same version of the file on both servers and on my client machine OR I should see only the version of the file that is important on my client. The business of ypcat and its friends is klugy. Lets make them go away and fully abstract the mapping of files across the network as well as incorporate primary and secondary server hosts for groups of clients, to make the network more resistant to server crashes. To clarify all of this.. yp is not 'bad' pe se, but we need something better. Steve Blasingame ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
authorplaceholder@gorgo.UUCP.UUCP (01/26/87)
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
roy@phri.UUCP (02/06/87)
In article <59000005@gorgo.UUCP> bsteve@gorgo.UUCP writes: > Lets make them go away and fully abstract the mapping of files across the > network as well as incorporate primary and secondary server hosts for groups > of clients, to make the network more resistant to server crashes. How hard would it be to incorporate a "shadow server" mode into NFS? Imagine 2 servers serving the same file system. When a write request comes in, both servers do it and the client waits to hear an ack from both of them. When a read request comes in, both servers try to do it and the client takes the data from whichever server responds first. When one server goes down, the other one just pick up all the read requests and the write requests only get acked once (there has to be some way for the client to know it's only waiting for a single ack; this is a sticky point). There is nothing new here; schemes like this have been implemented many times before (I think DEC's HSC-50 can do this, for example). Usually, though, it's done at the physical disk level, not the file system level. What kinds of problems would you run into if the two copies of the file system had differing inode numbers, for example? What happens when these two supposedly identical file systems are almost full, but because of slightly different fragmentation, one gets full before the other? What other horrible things might make this idea not work? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"