Project Athena ( was Re: Non Destructive Version of rm)

[The Grand Master]

In article <1991May7.224644.16951 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
}In article <12021 at mentor.cc.purdue.edu>, asg at sage.cc.purdue.edu (The Grand Master) writes:
}|> Are you telling me that when you log in, you have to wait for your home
}|> directory to be mounted on the workstation you log in on?
}  Yes.
}|> - This is 
}|> absolutely Horid!!
}  I would suggest, Bruce, that you refrain from commenting about things about
}which you know very little.  Your entire posting is filled with jibes about
}the way Project Athena does things, when you appear to know very little about
}*how* we do things or about the history of Project Athena.

Well I am glad you are expanding my knowledge

}  I doubt that DEC and IBM would have given Athena millions of dollars over
}more than seven years if they thought it was a "kludge".  I doubt that
}Universities and companies all over the world would be adopting portions of
}the Project Athena environment if they thought it was a "kludge".  I doubt DEC
}would be selling a bundled "Project Athena workstation" product if they
}thought it was a "kludge".  I doubt the OSF would have accepted major portions
}of the Project Athena environment in their DCE if they thought it was a
}"kludge".

The old Iidea that "it is a good idea if people put money into it" Remember
the HUNDREDS OF MILLIONS SPENT ON PET ROCKS?? THe fact that money has been
put into the project is not indicative of Project Athena's worthefullness.
Ford put alot of money into the Edsel.

}  You have the right to express your opinion about Project Athena.  However,
}when you opinion is based on almost zero actual knowledge, you just end up
}making yourself look like a fool.  Before allowing that to happen any more, I

The good old JIK tactic - when someone disagrees with you, tell them they
look like a fool.

}suggest you try to find out more about Athena.  There have been several

I am attempting to do just that so that I have an example of how *NOT*
to administrate a network.

}  You also seem to be quite in the dark about the future of distributed
}computing.  The computer industry has recognized for years that personal
}workstations in distributed environments are becoming more popular.  I have
}more computing power under my desk right now than an entire machine room could
}hold ten years ago.  With the entire computing industry moving towards
}distributed environments, you assert that Project Athena, the first successful
}large-scale distributed DCE in the world, would be better off "to have a few
}powerful centralized systems with Xwindow terminals instead of separate
}workstations."  Whatever you say, Bruce; perhaps you should try to convince
}DEC, IBM, Sun, HP, etc. to stop selling workstations, since the people buying
}them would obviously be better off with a few powerful centralized systems.

You do not however have any more power (in fact quite a bit less) than systems
which now occupy about the same volume as my desk.
}
}|> Next, at the top level of each filesystem you but a directory named
}|> tomb - in other words, instead of the jik directory being the only 
}|> directory on your partition, there are two - jik and tomb.
}
}  "Filesystems" are arbitrary in our environment.  I can mount any AFS
}directory as a "filesystem" (although AFS mounts are achieved using symbolic
}links, the filesystem abstraction is how we keep NFS and AFS filesystems
}parallel to each other).  Furthermore, I can mount any *subdirectory* of any
}NFS filesystem as a filesystem on a workstation, and the workstation has no
}way of knowing whether that directory really is the top of a filesystem on the
}remote host, or of getting to the "tomb" directory you propose.

You dinna read then. Since the filesystem(s) in question would
be remote filesystems, and rpc protocal would be sent TO THE SYSTEM THAT
ACTUALLY HAS THE DIRECTORY MOUNTED ON IT!!! Therefore there is no problem
in finding the root of the filesystem.
}
}  If your site uses "a few powerful centralized systems" and does not allow
}mounting as we do, then your site can use the entomb stuff.  But it just
}doesn't cut it in a large-scale distributed environment, which is the point
}I've tried to make in my previous two postings (and in this one).

You can have a large scale distributed environment without allowing
people to mount their own directories. We have such at Purdue with the
few centralized systems (yes, you can all sing along) with Xwindows
terminals. We also have it here at GE where each person who has a workstation
can still log into anny workstation and be able to access his disk without
having to do mounting all over the place. If I want to get to a directory
/tmp on the system a294 I do cd //a294/tmp - no problem.
}
}  In any case, mounting user home directories on login takes almost no time at
}all; I just mounted a random user directory via NFS and it took 4.2 seconds. 
}That 4.2 seconds is well worth it, considering that they can access their home
4.2 seconds is too long in my book when it can be done without having
to wait to mount your home directory.
}directory on any of over 1000 workstations, any of which is probably as
}powerful as one of your "powerful centralized systems."

Where you get this I have no idea. I want to see your workstations if they are
as powerful as a Sequent Symmetry. Pretty damn good workstations I guess.
}
}|> What these functtions will actually do is
}|> call on a process entombd (which runs suid to root - ohmigod) to move
}|> your files to the tomb directory.
}
}  One more time -- setuid does not work with authenticated filesystems, even
}when moving files on the same filesystem.  Your solution will not work in our
}environment.  I do not know how many times I am going to have to repeat it
}before you understand it.
So automated tasks are impossible (or at least more difficult) on  your
authenticated filesystem - I am begining to see the merits in Athena.
( ;-) added for the humor impaired )
}
}|>   If the file to be entombed is NFS mounted from a remote
}|>      host, the entomb program would be unable to move it to the
}|>      tomb because of the mapping of root (UID 0) to nobody (UID
}|>      -2).  Instead, it uses the RPC mechanism to call the entombd
}|>      server on the remote host, which does the work of entombing.
}
}  We considered this too, and it was rejected because of the complexity
}argument I mentioned in my last posting.  Your daemon has to be able to figure
}out what filesystem to call via RPC, using gross stuff to figure out mount
}points.  Even if you get it to work for NFS, you've got to be able to do the
}same thing for AFS, or for RVD, which is the other file protocol we use.  And
}when you add new file protocols, your daemon has to be able to understand them
}to know who to do the remote RPC too.  Not generalized.  Not scalable.

It is ALREADY WORKING! 
}
}  Furthermore, you have to come up with a protocol for the RPC requests.  Not
}difficult, but not easy either.
The protocol has been defined since it is already working.
}
}  Furthermore, the local entombd has to have some way of authenticating to the
}remote entombd.  In an environment where root is secure and entombd can just
}use a reserved port to transmit the requests, this isn't a problem.  But in an
}environment such as Athena's where anyone can hook up a PC or Mac or
}workstation to the network and pretend to be root, or even log in as root on
}one of our workstations (or public workstation root password is "mroot";
[Give me the addresses (or do I have to log in from the console?)]
}enjoy it), that kind of authentication is useless.

Oh, I like your setup even better now. Give all the users root! Very
tidy, and secure. You were complaining aboutquota's earlier and you 
give you users all root privs????????? I know. That is the reason for the
elaborate autentication system - but tell me, if you dinna let your
users have root privs would you NEED the elaborate authentication
system?
}
}  No, I'm not going to debate with you why people have root access on our
}workstations.  I've done that flame once, in alt.security shortly after it was
}created.  I'd be glad to send via E-mail to anyone who asks, every posting I
}made during that discussion.  But I will not debate it again here; in any
}case, it is tangential to the subject currently being discussed.

yes - email them to me
}
}  By the way, the more I read about your entomb system, the more I think that
}it is a clever solution to the problem it was designed to solve.  It has lots
}of nice features, too.  But it is not appropriate for our environment.

And giving away root privs is. What is the purpose of having semarate 
accounts then? Or do you have to give some kind of Kerberos authentication code
for every damn thing you do?
}
}|> }  Um, the whole idea of Unix is that the user knows what's in the file
}|> }hierarchy.  *All* Unix file utilities expect the user to remember where files
}|> 
}|> Not exactly true. Note this is the reason for the PATH variable, so that
}|> you do not have to remember where every God-blessed command resides.
}
}  Running commands is different from manipulating files.  There are very few
}programs which manipulate files that allow the user to specify a filename and
}know where to find it automatically.  And those programs that do have this
}functionality do so by either (a) always looking in the same place, or (b)
}looking in a limited path of places (TEXINPUTS comes to mind).  I don't know
}of any Unix program which, by default, takes the filename specified by the
}user and searches the entire filesystem looking for it.  And no, find doesn't

I did not propose looking through the whole filesystem, just looking
through a certain number of specific places (the tomb directories). In fact,
you only have to look in one at a time (the tomb dir on your filesystem).
}
}|> Well, then this is an absolute kludge. How ridiculous to have to mount and
}|> unmount everyones directory when they log in/out. ABSURD!.
}
}  See above.  What you are calling "ABSURD" is pretty much accepted as the
}wave of the future by almost every major workstation manufacturer and OS
}developer in the world.  Even the Mac supports remote filesystem access at
}this point.

I never said remote filesystem access was a kludge. Having to wait for
your home directory, and users being allowed to moun other directories
at will, and users being given the root pasword, and then creating an
authentication system to close up the wholes made by giving users access
to root privs  - now *THAT* is a kludge.

}
}  How else do you propose a network of 1000 workstations deal with all the
}users' home directories?  Oh, I forgot, you don't think anyone should need to
}have a network of 1000 workstations.  Right, Bruce.

I think that there are other viable solutions. But as I said, it is
still possible to handle users directories on a net of 1000 workstations
without your ridiculous kludge. As GE has done.
}
}|>   In fact, what you have appearantly makes it impossible for me to access
}|> any other users files that he might have purposefully left accessable
}|> unless he is logged into the same workstation.
}
}  No, we have not.  As I said above, you don't know what you're talking about,
}and making accusations at Project Athena when you haven't even bothered to try
}to find out if there is any truth behind the accusations is unwise at best,
}and foolish at worst.  Project Athena provides "attach", an interface to
}mount(2) which allows users to mount any filesystem they want, anywhere they
}want (at least, anywhere that is not disallowed by the configuration file for
}"attach").  All someone else has to do to get to my home directory is type
}"attach jik".

first - I said appearantly, which denotes some measure of uncertainty. 
Second - Well, I just don't think it is wise to allow others to mount
filesystems when and where they want at will.
}
}  Do not assume that Project Athena is like Purdue and then assume what we don
}on that basis.  Project Athena is unlike almost any other environment in the
}world (although there are a few that parallel it, such as CMU's Andrew system).
}
I never assumed Athena was anything like Purdue. Purdue's environment
is set up sanely.
}|> And if I am working on a workstation and 10 people happen to rlogin
}|> to it at the same time, boy are my processes gonna keep smokin. 
}
}  Workstations on Project Athena are private.  One person, one machine (there
}are exceptions, but they are just that, exceptions).
}
Oh, you do not support rlogin - ic.
So tell me, how do I get at my files from a remote location?
}|>   No the idea of an Xterminal with a small processor to handle the 
}|> Xwindows, and a large system to handle the rest is MUCH MUCH more reasonable
}|> and functional.
}
}  You don't know what you're talking about.  Project Athena *used to be*
}composed of several large systems connected to many terminals.  Users could
}only log in on the cluster nearest the machine they had an account on, and
}near the end of the term, every machine on campus was unuseable because the
}loads were so high.  Now, we can end up with 1000 people logged in at a time
}on workstations all over campus, and the performance is still significantly
}better than it was before we switched to workstations.

Maybe that is also because computer technology has improved. How many
computers did you have in your "cluster"?  What kind of processors did they
have. Our Sequent's (sage is one of them) often have 200 users working
fervently to finish a CS project, withe very little appreciable slow-dowm.
And this is just with 8 of the 40 processors that a Sequent can hold.
When I say powerful central computers, I *MEAN* *POWERFUL* . I do not 
mean one centralized workstation, or even a VAX. Don't tell me that a
cluster of 25 or more sequents won't do the same job that 1000
workstations can do.
}
}|> It is my perogative to announce my opinion on whatever the hell I choose,
}|> and it is not yours to tell me I cannot. Again this seems like a worthless
}|> stupid kludge. What is next - a password so that you can execute ls?
}
}  You asserted that we should not be writing to system source code with our
}own account.  I responded by pointing out that, in effect, we are not.  We
}simply require separate Kerberos authentication, rather than a completely
}separate login, to get source write access.  Now you respond by saying that
}that authentication is wrong, when it is in fact what you implied we should be
}doing in the first place.
}
I feel the authentication is unneccesarily neccesary. You have made
it a neccesity by putting power in the users' hands that should not
be there. I will not applaud you for making things more difficult.
Why should I have to use a password every time I execute a command?
(I know, you don't have to for *EVERY* command - yet). What is the 
purpose of separate accounts? It is so that you have to enter a 
password only once. If not, you could just have open connected terminals
and require a password for any special commands (ls, vi, rm, kill).
No need for accounts.
}-- 
}Jonathan Kamens			              USnail:
}MIT Project Athena				11 Ashford Terrace
}jik at Athena.MIT.EDU				Allston, MA  02134
}Office: 617-253-8085			      Home: 617-782-0710


Just get a room full of Sequent Symmetry's. You will have more computing
power than you know what to do with.
---------
                                   ###             ##
Courtesy of Bruce Varney           ###               #
aka -> The Grand Master                               #
asg at sage.cc.purdue.edu             ###    #####       #
PUCC                               ###                #
;-)                                 #                #
;'>                                #               ##