Return to outline CVS log

Up to [Research Unix] / researchv10dc / cmd / odist

Annotation of researchv10dc/cmd/odist/outline, revision 1.1.1.1

1.1       root        1: 1.  intro:
                      2:        talk about the source code problem, cascaded redistribution solution
                      3:        implies that distribution scheme should be simple.  (rdist is hairy
                      4:        and so is coda, because of exotic config file syntax.)
                      5:        survey three existing systems: coda, rdist, ship.
                      6:                taxonomy of existing systems:
                      7:                        rdist: config file driven, server pushes
                      8:                        ship: command driven, server pushes
                      9:                        coda: config file driven, client calls
                     10:                our system completes the square:
                     11:                        dist: command driven, client calls
                     12: 2.  can be divided into four phases:
                     13:        build
                     14:        package
                     15:        transmit
                     16:        install
                     17:        heterogeneous networks solved by recursively applying this scheme
                     18:        (actually 'recursively' isn't quite right: we need only one level of cascade
                     19:        if all machines are on the same network.  multiple network types are also
                     20:        solved by cascading, of course...)
                     21:        notice that the 'package' and 'install' phases are coupled by a common
                     22:        package file format, but the rest of the system is relatively decoupled.
                     23: 3.  the build phase
                     24:        there's lots of room here for variability, and the later phases
                     25:        in order to support cascaded redistribution, this has to be fairly standard.
                     26:        don't really care how things get built, so long as they get built!
                     27:        we decided to support recompilation of C programs in a minimal ANSI
                     28:        and POSIX.1 environment (with research extensions) to start with.
                     29:        finally, we use 'mk' to recompile, with a few standard targets.
                     30: 4.  the package phase
                     31:        we use standard (Posix) tar files
                     32:        finding existing Posix tar programs to be of questionable portability (GNU tar)
                     33:        or gargantuan (Pax), we wrote a few commands for creating and manipulating
                     34:        tar files (tarc, tarx, tarf)
                     35:        we introduce a simple filter, "tarf", that allows us to transform path
                     36:        names and user id's in the tar file in a uniform way.
                     37:        all packages contain absolute path names for files to be installed;
                     38:        non absolute path names are reserved for control files of the distribution
                     39:        system (for example, the file 'distcmds', if present, contains commands to be
                     40:        executed after the files are installed)
                     41: 5.  the transmission phase
                     42:        we operate on a variety of networks on a 'client calls' basis.
                     43:        we do only hostname authentication on the server (although this could
                     44:        be changed), and send all queued distributions at once; the client
                     45:        then determines which distributions it will attempt to install, which
                     46:        it will defer, and which it will reject.  (idea: should deferred
                     47:        distributions go to a holding area on the client rather than continuing
                     48:        to be held on the server--we could do this with 'dist localhost' and
                     49:        hence supersede any previous version of the deferred distribution!!!)
                     50:        security: since installation always procedes on the basis of whatever
                     51:        user id is calling, we can ignore the issue of client security.
                     52:        we regard this as a substantial advantage over 'server pushes' type
                     53:        remote distribution systems.
                     54:        there should be a notify mechanism, but it is not yet clear how it should
                     55:        work.  i'll figure it out before i'm done.
                     56:        on the client, we can check the plausibility of a given distribution
                     57:        before installing it.  we use simple heuristics to do this rather than
                     58:        trying to do a perfect job of predicting whether a given user will be
                     59:        able to install a given distribution successfully.  if the heuristics
                     60:        fail, then we report installation errors.
                     61: 6.  the installation phase
                     62:        installation proceeds in passes:
                     63:        1.  a backup is made of all files to be clobbered by the distribution
                     64:        2.  'remove' commands are executed.
                     65:        3.  the distribution is installed.
                     66:        4.  directory contents not clobbered by installing the new distribution
                     67:        are clobbered.
                     68:        5.  any associated cmd file is executed.
                     69:        6.  the backup allows the distribution process to be unwound.  if there
                     70:        are any failures.  if there are failures, report a failure transcript
                     71:        to the server.
                     72: 7.  more detailed comparison to existing systems
                     73:        rdist, coda -- config files, "exception" files, how do i do that stuff
                     74:        with 'dist'
                     75:        improvements over Koenig's 'ship'
                     76: 8.  some lessons learned:
                     77:        if there is any one big lesson i learned (really, relearned) in developing
                     78:        this system, it is that: there is a simpler way.
                     79:        i started out initially to build a software distribution system;
                     80:        i began by collecting wish lists from users.  this was obviously necessary,
                     81:        but was also in some sense a mistake: the wish lists were a mile long!
                     82:        had i implemented every user's wish list, the system would be a lot bigger,
                     83:        a lot buggier, and a lot more incomprehensible.
                     84:        now, it is possible to "build a software distribution system" in the
                     85:        most direct brute force way, but it is much simpler to decompose the
                     86:        problem into phases and consider them independently.
                     87:        corollary: use existing mechanisms whenever possible.  for example,
                     88:        (Posix) tar files for packages, existing network authentication mechanisms.
                     89:        reinventing the wheel will only cause somebody else more grief later.
                     90: 9.  acknowledgements and bibliography

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.