DistOS 2018F 2018-09-26: Difference between revisions
Created page with "==Readings== V, Amoeba, Clouds: * [http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21/cheriton-v.pdf David R. Cheriton, "The V Distributed System." (1988)] * [http://..." |
|||
Line 7: | Line 7: | ||
==Notes== | ==Notes== | ||
in-class lecture notes: | |||
- V – Fast RPC but wanted to do software backed plain | |||
Non of them are saying let’s use UNIX so they tried other things but did not caught on | |||
Amoeba: | |||
Wanted to cluster computers so that users at terminals that could send load balanced jobs to the cluster and easier to implement than a pear implemented system. | |||
Bunch of servers do things, and file servers and then clients | |||
So distributed but specialized, not peer-to-peer | |||
File system implemented as a set of processes | |||
Had Unix interface but removed file system approach...had a notion of files but their files were different. Contiguous blocks but they were also immutable files .... replicated at will...powerful idea b/c we will see again...immutability why? Avoid the problem of shared state...when you replicate it, you replicate it and your done, don’t need to synchronize. If want something different, make a new file or segment. Distributed files, will see immutable stuff like Amazon S3; have versions but the underlying system is immutable. Git is immutable underneath b/c taking these things identified by hashes and that is being stored. | |||
Mutability to immutability with versions....can use kinda the same but the underlying system is very different. | |||
Ameoba is influential b/c they did a couple of things in an interesting way. Lessons learned from the dream of a distributed OS. Key lesson, how did they do permissions? Access control lists...no They had capabilties...big idea in access control b/c normally when we think of UNIX permissions access control lists....what’s the objects being controlled and who can access it. With a capability model instead we have a string set of bits and if you have these bits you can access the resource and if you don’t have it can’t access. Get the capability, and once have it can use it to access that resource. It means that the permission granting is separate from the permission check...don’t need to know who you are but that you have the correct capability. To make it work well you need something cryptographic...Ameoba didn’t have good cryptography (48 bits) but it was the concept model...distributed access control. | |||
Linux capabilities are not the same, same term but only some of the notions....capabilities is an un-forgable bit string to gain access to resource. Keys today are not b/c of performance reasons. | |||
Active directory in Windows is based on Kerberos and the server gives a ticket that allows access to resources...basically capabilities. | |||
Process model: | |||
Clouds | |||
What went wrong? Execution context are not indexed. Moving between address spaces. Normally execution context and state are connected. If you blow that up, what’s your security model? | |||
Why didn’t UNIX die? Programs and development environment would have to all be developed again from scratch. Get new OS that do new things when you have a reason, a use case. Unix is below, everything else on top. |
Latest revision as of 02:09, 3 October 2018
Readings
V, Amoeba, Clouds:
- David R. Cheriton, "The V Distributed System." (1988)
- Andrew Tannenbaum et al., "The Amoeba System" (1990)
- Partha Dasgupta et al., "The Clouds Distributed Operating System" (1991)
Notes
in-class lecture notes: - V – Fast RPC but wanted to do software backed plain
Non of them are saying let’s use UNIX so they tried other things but did not caught on
Amoeba:
Wanted to cluster computers so that users at terminals that could send load balanced jobs to the cluster and easier to implement than a pear implemented system.
Bunch of servers do things, and file servers and then clients
So distributed but specialized, not peer-to-peer
File system implemented as a set of processes
Had Unix interface but removed file system approach...had a notion of files but their files were different. Contiguous blocks but they were also immutable files .... replicated at will...powerful idea b/c we will see again...immutability why? Avoid the problem of shared state...when you replicate it, you replicate it and your done, don’t need to synchronize. If want something different, make a new file or segment. Distributed files, will see immutable stuff like Amazon S3; have versions but the underlying system is immutable. Git is immutable underneath b/c taking these things identified by hashes and that is being stored.
Mutability to immutability with versions....can use kinda the same but the underlying system is very different.
Ameoba is influential b/c they did a couple of things in an interesting way. Lessons learned from the dream of a distributed OS. Key lesson, how did they do permissions? Access control lists...no They had capabilties...big idea in access control b/c normally when we think of UNIX permissions access control lists....what’s the objects being controlled and who can access it. With a capability model instead we have a string set of bits and if you have these bits you can access the resource and if you don’t have it can’t access. Get the capability, and once have it can use it to access that resource. It means that the permission granting is separate from the permission check...don’t need to know who you are but that you have the correct capability. To make it work well you need something cryptographic...Ameoba didn’t have good cryptography (48 bits) but it was the concept model...distributed access control.
Linux capabilities are not the same, same term but only some of the notions....capabilities is an un-forgable bit string to gain access to resource. Keys today are not b/c of performance reasons.
Active directory in Windows is based on Kerberos and the server gives a ticket that allows access to resources...basically capabilities.
Process model:
Clouds
What went wrong? Execution context are not indexed. Moving between address spaces. Normally execution context and state are connected. If you blow that up, what’s your security model?
Why didn’t UNIX die? Programs and development environment would have to all be developed again from scratch. Get new OS that do new things when you have a reason, a use case. Unix is below, everything else on top.