|
|
1.1 root 1: "Automatic Software Distribution and the Tower of Bable"
2: (really the Tower of Babble, or more accurately, the Network of Babble)
3: ### slide: chopped down version of this outline
4: * motivation and history
5: * consistency across a network of machines
6: * first publicly described for unix by Koenig (ship)
7: * rdist (Berkeley)
8: * coda (Rich $alz, BBN)
9: * previous work
10: * samples of ship, rdist, and coda
11: ### slide: samples of ship, rdist, and coda
12: * simple ship command, command options
13: * rdist Distfile
14: * coda Codafile
15: * differences between ship rdist and Coda
16: * ship is command-oriented
17: * rdist and coda work from a configuration file
18: * ship and rdist work from master machines to slave machines
19: * coda provides a service--client machines in control
20: * problems with previous designs
21: * ship and rdist have too much control
22: * ship usage is strange
23: * rdist and coda config files are hard to use for simple things
24: * config files do not interact well with the rest of the system
25: * rdist and coda are monolithic
26: * ship, rdist, and coda are network dependent
27: * the design of dist
28: * problems to solve
29: * distribution on a heterogeneous network of heterogenous machines
30: * cascaded redistribution
31: ### slide: picture of cascaded redistribution
32: * completing the square
33: ### slide: square containing ship, rdist, dist, and coda
34: * dist is command-line driven
35: * dist provides a service machine for client machines
36: * example of dist usage
37: * dist operates on multiple networks
38: * implementation
39: ### slide: picture of distribution crossing a network
40: * cleanly dividing along functional lines
41: * packaging
42: * queueing and transmission
43: * unpackaging
44: * packaging is decoupled from transmission
45: * written mostly as a collection of shell programs
46: * problems and their solutions
47: * problem: whining about networks
48: ### slide: sample v10 & Berkeley network code, sample machine names
49: * network programming interfaces
50: * incompatible naming conventions
51: * solutions: isolate network dependencies
52: * we want reliable byte streams but don't care how
53: * isolate network dialers from the rest of the program
54: * provide easily-replaced heuristics to make sense of names
55: * problem: atomic installation
56: * hypothetical case study of partial installation
57: * want dist to succeed completely or fail completely
58: * solution: install package script in the unix style
59: ### slide: excerpt from insdist shell script
60: * build a backup copy of stuff to be replaced
61: * install new stuff
62: * remove any remaining old stuff not replaced by new stuff
63: * problem: writing bulletproof programs
64: * bulletproof is necessary for security
65: * funny names confuse people and are insecure
66: * funny names confuse programs and are insecure
67: * solution: new shell utilities
68: * qargs and uargs
69: * serendepitous interaction with xargs
70: * conclusions and lessons learned
71: * problem decomposition wins again
72: * dist is smaller than ship
73: * network pain is isolated and easily replaced with future upgrades
74: * security issues are isolated and hence more easily controlled
75: * careful use of existing tools allowed atomic installation to be
76: coded and tested within an hour
77: * shell programs are a tremendous benefit
78: * they aid and in fact encourage clean problem decomposition
79: * contrary to popular belief, can easily be made bulletproof
80: * shell programs are very easy to make portable
81: * future work
82: * demonstrate cascaded redistribution (use dist to maintain itself)
83: * focus on the notifier (isolate security/policy dependencies here)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.