Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!adm!bzs@bu-cs.bu.EDU From: bzs@bu-cs.bu.EDU Newsgroups: comp.unix.wizards Subject: Mixing vaxen and suns on NFS Message-ID: <5762@brl-adm.ARPA> Date: Wed, 25-Mar-87 17:50:55 EST Article-I.D.: brl-adm.5762 Posted: Wed Mar 25 17:50:55 1987 Date-Received: Fri, 27-Mar-87 05:23:41 EST Sender: news@brl-adm.ARPA Lines: 93 From: Boyd Roberts >Well, I would never ever suggest to anyone to run NFS >with your home directory on another machine. It's ok for the >5 minute mail read, but *where* are you when the server crashes? >It's barbed-wire canoe time. Boy, do I disagree with this statement. As I've mentioned before, BU-CS.BU.EDU is three SUN3/180s with 6 Eagles NFS'd together so as to make it irrelevant which system you log into or where your home directory is. I've had no complaints in the 15 months we've been running the entire CS and Math faculty this way. We have typically 40-50 users logged into the three systems and 250 entries in our passwd file. If there were major problems with this I think I would have found out by now. A server who physically has your directory crashing is only slightly different from the system you are logged into crashing; in the NFS case you don't lose any work (ie. it's better.) In either case you are going to wait for the system to come back, what possible difference could it make? Just that the user can get at some files but not others while the server is coming back up versus being dropped? Would your users prefer it if, when their home dir is inaccessible, they were just thrown off the system (drop DTR)? That *would* add to transparency, I suppose it could be arranged. >Sourcing a disparate .profile amidst the ``not found'' and ``core dumped'' >gnashing of teeth, is going to cause you a small amount of trouble. I don't understand what the problem is here. Where I want a different profile or login file read in I simply have a different subdir in my "home" dir entered into the passwd file on that machine, thus /usr1/bzs/.login vs /usr1/bzs/buit4/.login. It's only come up once for all the systems (the login file for my diskless 3/160 is different than all the others [which are themselves all the same.]) Another "problem" I've never run into with my user community (and if you think it's because they're all computer sophisticates you should see the questions we get from the theoreticians.) >And, who *wants* to dump core across the wire? Never had any problem, remember, disks are hooked up with wires also, sounds like more superstition. >You've got to log in to a local disk. Otherwise, the solution is to build >stuff into your .profile that goes... > > case "`hostname`" in > ...) > client dependant junk... > ;; > > esac > >But, that'll become a real problem. Why?! Sounds like a fine suggestion for how to deal with such a .login file. Not the only way (see above for different home subdirs), but very rational, what's the problem? It's probably barely necessary in practice (the same .login is usually sufficient for all systems, I mean msgs is msgs), but there you have it, one possible solution. I think given a template like you showed above even a fairly novice user could customize as well as they could a simpler .login file. >NFS doesn't address the presentation layer. XDR is a hack, there are wider >issues that it doesn't cater for. NFS is only *really* usable in >a homogeneous or text file environment. Forget anything but textfiles in a >hetrogeneous environment. And then, the text had better make sense on the >client. In what way does having two different home dirs on two different systems solve this problem? Are you comparing a local disk to a remote disk or simply pointing out utopias you have imagined? Why is XDR "a hack"? What are the "wider issues"? Why do you just ramble on with unsupported statements (I know, now you'll reply with all the detail you should have provided in the first place, remember when you're typing in your pearls that I was replying to *this* note, mind-reading is not something I dabble in.) Seriously, is this sincere, experienced advice or are you free associating in public? You are making claim after claim with no substantiation as if you assume we all agree with you. I for one disagree and have over a year's experience with a large, public system that sez yer wrong. I'll grant that the homogeneity of my systems makes some things easier, but we also have (besides SUNs) Celerity's hooked up with NFS for a few months now and still have yet to discover all these problems you claim knowledge of. The benefits have far, far outweighed the disadvantages which fall more in the realm of security administration and user education about all the neat things they have now and how to use them rather than all these horrible problems which would make them better off without NFS (?!?) -Barry Shein, Boston University