andre@kulcs.UUCP (03/12/87)
We have a number of sun's and a number of vaxen, and plan to install
4.3BSD + NFS from Mt Xinu soon.
Once this has been installed, we would like to give our users a single
home directory, to be used both when the user logs in on a sun and when
he/she logs in on a vax.
Of course, this means our users will have to be aware of the fact they
cannot mix load modules and files containing data in internal
representation between vaxen and sun's. But what happens with
.login, .mailrc, .defaults, .suntools, etc ? Can they be mixed
without any problem ? Any other problems to be aware of ?
Has anyone already set up such a scheme ?
Any comments and/or suggestions welcome
--
Name: Andre De Deurwaerder Katholieke Universiteit Leuven
E-mail: andre@kulcs.UUCP or Department of Computer Science
...!mcvax!prlb2!kulcs!andre Celestijnenlaan 200 A
Phone: +(32) 16 20 0656 x3563 B-3030 Leuven (Heverlee), Belgiumboyd@basser.UUCP (03/24/87)
In article <669@kulcs.UUCP> andre@kulcs.UUCP (Andre De Deurwaerder) writes: >We have a number of sun's and a number of vaxen, and plan to install >4.3BSD + NFS from Mt Xinu soon. > >Once this has been installed, we would like to give our users a single >home directory, to be used both when the user logs in on a sun and when >he/she logs in on a vax. 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. Sourcing a disparate .profile amidst the ``not found'' and ``core dumped'' gnashing of teeth, is going to cause you a small amount of trouble. And, who *wants* to dump core across the wire? 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. Once logged on ok to a local disk you'll be ok to NFS to other things. But, ``you've got to ask yourself one question. do you feel lucky?'' I hate it when a server crashes. 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. Boyd Roberts boyd@basser.oz ``When the going gets weird, the weird turn pro...'' Copyright 1987 Boyd Roberts Restricted Redistribution Prohibited.
aps@granite.UUCP (03/25/87)
Refering to the article by boyd@basser.oz (Boyd Roberts), he comments on Andre's article ... >In article <669@kulcs.UUCP> andre@kulcs.UUCP (Andre De Deurwaerder) writes: >>We have a number of sun's and a number of vaxen, and plan to install >>4.3BSD + NFS from Mt Xinu soon. >> >>Once this has been installed, we would like to give our users a single >>home directory, to be used both when the user logs in on a sun and when >>he/she logs in on a vax. > >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. > >Sourcing a disparate .profile amidst the ``not found'' and ``core dumped'' >gnashing of teeth, is going to cause you a small amount of trouble. >And, who *wants* to dump core across the wire? > Although I am not going to start a debate about the goodness of NFS, I would say that the keywords ``NFS serious-braindamage'' is a little unfair, unkind, and untrue. NFS is fine when used with an understanding of its design goals ... At anyrate, to the point of this message. Our operations here implement what andre@kulcs describes: our 8XXX manages the disk farm of all the major file systems as well as all our users home directories. Everybody has a GPX or VSII workstation in their office (except me who has a VS100 and a VSII) which have local roots but mount *all* other file systems from the `main frame' VAX. One thing that is nice that a user can log into any machine and have their environment. (The password and other essential files get copied to all the workstations (and two other larger VAXen) late at night.) We run Ultrix and MIT's X. Using X, some of the people run some of their windows connected to processes on the main VAX. This seems to work well for us. Armando Stettner.
woof@psivax.UUCP (03/26/87)
In article <895@basser.oz> boyd@basser.oz (Boyd Roberts) writes: >In article <669@kulcs.UUCP> andre@kulcs.UUCP (Andre De Deurwaerder) writes: >>We have a number of sun's and a number of vaxen, and plan to install >>4.3BSD + NFS from Mt Xinu soon. >> >>Once this has been installed, we would like to give our users a single >>home directory, to be used both when the user logs in on a sun and when >>he/she logs in on a vax. > >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. > Well we have two VAXen running Mt. Xinu's 4.3 BSD + NFS and 4 Suns running Sun OS 3.2. The configuration here is just as Mr. De Deurwaerder would like to set his up. We are VERY happy with the ways things have worked out here. Now admittedly there are problems when one of our VAXen crash and a user on a Sun requires access to his accounts home directory or disk. The user may have to wait as much as 30 minutes for the VAX in question to reboot and be able to handle NFS requests. This problem is out weighed by the benefits we have reaped of our configuration. Each Sun has a very small disk attached to it with the minimum needed to boot UNIX and get NFS up on the air. They each have a small /tmp filesystem and a reasonably sized swap area. These are intended to speed up processing on the Suns. The filesystems on the Suns are backed up rarely, as it is intended that they never change. The VAXen (which are backed up daily) have all the files that do change, so when we added the Suns we really did add to the workload of the people doing backups. In general since we depend on the VAXen being up, we are betting on them being down only occasionally. We have been justified in this dependency since our VAXen have a very good record in terms of staying up. We are very happy with out current enviornment. -- Hal Schloss Pacesetter Systems Inc. {sdcrdcf|ttidca|scgvaxd|nrcvax|jplpro|hoptoad|csun|quad1| bellcore|logico|rdlvax|ihnp4}! psivax!woof
bzs@bu-cs.bu.EDU (03/26/87)
From: Boyd Roberts <boyd@basser.oz> >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
putnam@thuban.UUCP (03/26/87)
(The discussion was on having a home directory on a different type of machine than you login on...) Sitting on my desk is a sun 3 (with a disk even). My home directory is on a vax running betatest ultricks with NFS. The only problems i have had have been with the vax crashing from time to time (it seems to do it more frequently than the local suns), and with servers of various flavors being taken down without sufficient user notification. I do have a test in my profile that runs a locally installed program /bin/mach to see what kind of machine i am running on, and that modifies my path appropriately (personal vax executables go in ~/vbin, sun executables in ~/sbin and shell scripts in ~/shbin). Most of the machines sharing NFS have the directory structures looking about the same, and much of the larger stuff is simply shared. I am thinking about making /bin/mach more flexible so i can actually ask questions (ie, am i a vax? is this ultricks? and so forth) which would allow for greater ease in setting up my environment. Otherwise, no real problems. Well, shall we go? -- jefu (jeff putnam) Yes, lets go. -- UUCP: steinmetz!putnam (They do not move.) -- ARPA: putnam@ge-crd.com
boyd@ausmelb.UUCP (04/01/87)
Ok, lets look at what's been said. The people who say that it works
all run in a homgeneous environment. That are either all SUNs
or they are SUNs with VAX file-servers. That is a homogeneous environment.
NFS works in said role. But you've got to pay a price.
The price is -
- a flat namespace
- shiping copies of binaries to machine where they won't run
- administration limiting the size of hetrogenity
- the users must be educated to know where the files are
A file-server environment does not ``mix''. It leans to support
one dominant machine type. The NFS claim is to be able to get widely
disparate machines to function together. But, it provides none of
the tools needed to do this.
Where are the name servers? Don't say ``yp''. Because all it does is
is provide one global /etc/passwd. And, very badly at that. You can
do this by simply moving /etc/passwd to globally known place. And,
if you've got symbolic links you don't even need to do that (Sys V
NFS doesn't support them).
The point of a network file system is that a pathname is a pathname.
It doesn't matter where it is physically. It should be transparant.
NFS doesn't provide this sufficiently.
It should also work. What is the difference between a disk controller
barfing and a server crashing? If a disk controller dies you call
in the engineers. If a server crashes, what do you do? You say
reboot it? I say ``call in the engineers''. Things should work. Surely
you wouldn't pay for anything less. I wouldn't.
--
Boyd Roberts boyd@ausmelb.oz | boyd@basser.oz
When the going gets weird, the weird turn pro...
Dgeoff@eagle_snax.UUCP (04/02/87)
In article <135@ausmelb.OZ>, boyd@ausmelb.OZ (Boyd Roberts ) writes: > Ok, lets look at what's been said. The people who say that it works > all run in a homgeneous environment. That are either all SUNs > or they are SUNs with VAX file-servers. That is a homogeneous environment. I am writing this from my Compaq II, which is currently mounting file systems from three Suns and one Alliant. What do you mean, homogeneous? > NFS works in said role. But you've got to pay a price. > > The price is - > > - a flat namespace Doesn't compute. Flat how? From my PC I see the same hierarchy as from my Sun, and the only thing that's flat is space of hostnames. > > - shiping copies of binaries to machine where they won't run > Actually, I don't ship binaries around much, because of the ethics of license violations. We mainly share data, accessed by tools on ALL types of machines. Most Unix utilities don't care about an extra <CR> at each <EOL>. > - administration limiting the size of hetrogenity Administration is only a headache with sophisticated users. All of our less sophisticated users have the same 'fstab' (or AUTOEXEC.BAT on PC's) and get a true one-world view. > > - the users must be educated to know where the files are > How educated? Every system has a standard tree (well, all except for a couple of real individualists) and the navigation is no more complex than around your typical VAX. > A file-server environment does not ``mix''. It leans to support > one dominant machine type. The NFS claim is to be able to get widely > disparate machines to function together. But, it provides none of > the tools needed to do this. We have CAD tools which run on the Alliant and which everybody knows how to fire up (well, everybody that cares to). NFS per se doesn't provide the tools for heterogeneous networked applications, but RPC/XDR does. We are working on applications which will compile unchanged on PC's, Sun's and VAXen and will net to any of the servers. We don't yet support PC's as servers, but only because of DOS stupidities. > > Where are the name servers? Don't say ``yp''. Because all it does is > is provide one global /etc/passwd. And, very badly at that. You can > do this by simply moving /etc/passwd to globally known place. And, > if you've got symbolic links you don't even need to do that (Sys V > NFS doesn't support them). But what happens if the server that contains /etc/passwd is down? YP is primarily designed to remove single-point-of-failure situations (sorry if I'm underrepresenting it, Rusty), and secondarily to provide a clean standardized way to develop global data-lookup services. > > The point of a network file system is that a pathname is a pathname. > It doesn't matter where it is physically. It should be transparant. > NFS doesn't provide this sufficiently. It provides it as "sufficiently" as the Unix "mount" command does. That is, in a disciplined environment path names are globally unambiguous. If I ran my VAX (well, your VAX) in an random sort of way, popping in as super-user to mount and unmount partitions, then I'd get the same effect as on an NFS net where people randomly export filesystems. If you're saying that we need better administration tools to help people maintain this disciplined environment, EXCELLENT! Have we got a job for YOU!!!! > > It should also work. What is the difference between a disk controller > barfing and a server crashing? If a disk controller dies you call > in the engineers. If a server crashes, what do you do? You say > reboot it? I say ``call in the engineers''. Things should work. Surely > you wouldn't pay for anything less. I wouldn't. If my disk controller barfs and provokes my timesharing VAX into an unseemly panic, my application dies. If my file server crashes, I go have coffee until it finishes fsck'ing and go right on working. Which d'you think I'd prefer? > > > -- > Boyd Roberts boyd@ausmelb.oz | boyd@basser.oz > > When the going gets weird, the weird turn pro... > D -- [content-free messages need no disclaimer. is this content-free? who knows] Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS) UUCP: {ihnp4,decwrl,...}!sun!garnold <OR> decvax!eagle_snax!geoff
nowicki@rose.UUCP (04/03/87)
In article <135@ausmelb.OZ>, boyd@ausmelb.OZ (Boyd Roberts ) writes: > Where are the name servers? Don't say ``yp''. Because all it does is > is provide one global /etc/passwd. And, very badly at that. You can > do this by simply moving /etc/passwd to globally known place. I hope this pack of lies was an April fool! Yellow Pages is an network service that provides mappings between pairs of strings. We use this service to do the mappings that used to be done by some of the /etc/ files on stand-alone systems. However, YP also provides an update mechanism, higher performance, random access, load sharing, and many other features. For example, our YP domain has over 50 servers, about 700 machines and about 1500 users in several buildings in several cities. Try doing that with symbolic links! Administration of large networks is a hard problem; YP does not provide all the solutions, but some kind of network service is a start. - Bill Nowicki Sun Microsystems