Changes between Version 1 and Version 2 of FeddDownload


Ignore:
Timestamp:
Dec 10, 2008 1:59:52 PM (15 years ago)
Author:
faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FeddDownload

    v1 v2  
    1 = The DETER Federation Architecture (DFA) =
    21
    3 This is a basic overview of the DETER federation system.  More details
    4 on this implementation and configuration are in later documents.  You
    5 can also read these academic papers that capture the evolution of the
    6 design to this point.
     2= Downloading and Installing fedd =
    73
    8 DFA is a system that allows a researcher to construct experiments that
    9 span testbeds by dynamically acquiring resources from other testbeds and
    10 configuring them into a single experiment.  As closely as possible that
    11 experiment will mimic a single DETER/Emulab experiment.
     4This section describes how to get a copy of fedd for your testbed and
     5install it.  After this you will need to configure it.
    126
    13 Though the experiment appears to be a cohesive whole, the testbeds that
    14 loan the resources retain control of those resources.  Because testbeds
    15 retain this control, each testbed may issue credential necessary for
    16 manipulating the federated resources.  For example, a testbed that has
    17 loaned nodes to an experiment may require the experimenter to present a
    18 credential issued by that testbed (e.g., an SSH key or SSL certificate)
    19 to reboot those nodes.  The system acquires those credentials on behalf
    20 of experimenters and distributes them on behalf of testbeds.
     7== What machines should run fedd ==
    218
    22 Testbed administrators may use the system to establish regular policies
    23 between testbeds to share resources across many users of a testbed.
    24 Similarly, a single user with accounts on multiple testbeds can use the
    25 same interfaces to coordinate experiments that share his testbed
    26 resource, assuming sharing those resources does not violate the policy
    27 of any of the constituent testbeds.
     9Depending on what sorts of resources you intend to make available to
     10others and what modifications you are willing to make to your testbed,
     11you may choose to run fedd in different configurations, with
     12functionality partitioned between users and boss.
    2813
    29 = Fedd: The DETER Federation Daemon =
     14If you intend to allow fedd to either create projects from whole cloth,
     15or to modify the access rights of projects or keys of users, at least
     16some of fedd will have to run on boss.  You can choose to run a fedd
     17install on boss only, or run the main instantiation of fedd on users and
     18the project manipulation functionality on boss.  This depends on your
     19particular comfort level with outside access to boss.  Fedd's local
     20accesses are all encrypted and controlled via fedids, and potentially by
     21SSL as well.
    3022
    31 Fedd is the daemon process responsible for:
     23If you intend to only allow federation through static projects, fedd
     24can run entirely on users, and need only be installed there.
    3225
    33  * Creating and terminating federated experiments
    34  * Requesting access to remote resources on an experimenter's behalf
    35  * Granting access to local resources based on the testbed's policy
     26Fedd also needs to run a modified ns2 parser to split experiments.
     27DETER exports an interface to that parser at
     28!https://users.isi.deterlab.net:23235 , and the simplest configuration
     29choice is to simply make use of that service.  Should you choose to get
     30the patches from us and run your own modified ns2 parser, you would
     31probably want to run that service on your ops node.
    3632
    37 Generally fedd is configured by the testbed's administration to allow
    38 controlled sharing of the resources, though the same software and
    39 interfaces can be used by single users to coordinate federated
    40 resources.
     33== Downloading and Installing the tar file ==
    4134
    42 Creating a federated experiment consists of breaking an annotated
    43 experiment into sub-experiments, gaining access to testbeds that can
    44 host those experiments, and coordinating the creation and connection of
    45 those sub-experiments.  Fedd insulates the user from the various
    46 complexities of creating sub-experiments and dealing with cleanup and
    47 partial failures.  Once an experiment is created, fedd returns
    48 credentials necessary to administer the experiment.
     35The easiest way to get a copy of fedd installed on your machine is to
     36download the python distutils tar file and install it.  The current
     37version is fedd-1.0.tar.gz.
    4938
    50 On termination, fedd cleans up the various sub-experiments and
    51 deallocates any dynamic resources or credentials.
     39You will need to have the following python packages installed as well.
    5240
    53 = Access Control =
     41 * ZSI
     42 * M2Crypto
     43 * MySQLdb
    5444
    55 This section describes the basic model of access control that fedd
    56 implements.  We start by explaining how users are represented between
    57 fedds and then describe the process of acquiring and releasing access to
    58 a testbed's resources.
     45Versions of M2Crypto before 0.18 will require
    5946
    60 This section documents the current access control system of fedd.  It is
    61 undergoing development.
     47 * pyasn1
    6248
    63 == Global Identifiers: Fedids ==
     49Emulabs generally have MySQLdb installed already.  All of the components above also have
     50FreeBSD packages and ports, which can simplify installation.
    6451
    65 In order to avoid collisions between local user names the DFA defines a
    66 global set of names called DETER federation IDs, or more concisely
    67 fedids.  A fedid has two properties:
     52Once those packages are installed, the following commands will install
     53fedd:
    6854
    69  * An entity claiming to be named by a fedid can prove it interactively
    70  * Two entities referring to the same fedid can be sure that they are referring to the same entity
     55{{{
     56$ tar xzf -C /tmp fedd-1.0.tar.gz
     57$ cd /tmp/fedd-1.0
     58$ sudo python ./setup.py install
     59$ cd
     60$ sudo rm -rf /tmp/python-1.0
     61}}}
    7162
    72 An example implementation of a fedid is an RSA public key.  An entity
    73 claiming to be identified by a given public key can prove it by
    74 responding correctly to a challenge encrypted by that key.  For a large
    75 enough key size, collisions are rare enough that the second property
    76 holds probabilistically.
     63Your install will include the python package federation, the following
     64scripts:
    7765
    78 We adopt public keys as the basis for DFA fedids, but rather than tie
    79 ourselves to one public key format, we use subject key identifiers as
    80 derived using method (1) in RFC3280.  That is, we use the 160 bit SHA-1
    81 hash of the public key.  While this allows a slightly higher chance of
    82 collisions than using the key itself, the advantage of a single
    83 representation in databases and configuration files outweighs the
    84 increase in risk for this application.
     66 * `/usr/local/bin/confirm_sshkey.py`
     67  * used in certain static project installs, see [FeddConfig configuring]
     68 * `/usr/local/bin/exp_access_db.py`
     69  * application to simplify creating experiment creation databases
     70 * `/usr/local/bin/fedd.py`
     71  * fedd itself
     72 * `/usr/local/bin/fedd_client.py`
     73  * command line tool for accessing fedd services
     74 * `/usr/local/bin/fedid.py`
     75  * command line tool for getting fedids from X509 certificates
     76 * `/usr/local/bin/user_to_project.py`
     77  * used in dynamic project installs, see [FeddConfig configuring]
    8578
    86 == Three-level Names ==
     79Finally a set of sample configuration files will be installed in `/usr/local/share/fedd/`
    8780
    88 In Emulab, projects are created by users within projects and those
    89 attributes determine what resources can be accessed.  We generalized
    90 this idea into a testbed, project, user triple that is used for access
    91 control decisions.  A requester identified as ("DETER", "proj1",
    92 "faber") is a user from the DETER testbed, proj1 project, user faber.
    93 Testbeds contain projects and users, projects contain users, and users
    94 do not contain anything.
     81== Additional scripts ==
    9582
    96 Parts of the triple can be left blank: (,,"faber") is a user named faber
    97 without a testbed or project affiliation.
     83If you intend to use dynamic project manipulation, you will need to
     84install patched versions of the addpubkey and grantnodetype scripts on
     85boss.  These patches extend those commands to revoke access/keys or
     86confirm the presence of access or keys.
    9887
    99 Though the examples used simple strings, the outermost non-blank field
    100 of a name must be a fedid to be valid, and are treated as the entity
    101 asserting the name.  Contained fields can either be fedids or local
    102 names.  This allows a testbed to continue to manage its namespace
    103 locally.
     88The patches are here:
     89        addpubkey
     90        grantnodetype
    10491
    105 If DETER has fedid:1234 then the name (fedid:1234, "proj1", "faber")
    106 refers to the DETER user faber in proj1, if and only if the requester
    107 can prove they are identified by fedid:1234.  Note that by making
    108 decisions on the local names a testbed receiving a request is trusting
    109 the requesting testbed about the membership of those projects and names
    110 of users.
     92To avoid inadvertently interfering with testbed operation, we suggest
     93making modified shadow commands on boss called taddpubkey and
     94tgrantnodetype.  Note the leading 't' on the shadow commands.  You can
     95do this by doing the following on boss (where the patch files come from
     96wherever you saved them):
    11197
    112 Testbeds make decisions about access based on these three level names.
    113 For example, any user in the "emulab-ops" project of a trusted testbed may
    114 be granted access to federated resources.  It may also be the case that
    115 any user from a trusted testbed is granted some access, but that users
    116 from the emulab-ops project of that testbed are granted access to more
    117 kinds of resources.
     98{{{
     99$ cd /tmp
     100$ cp /usr/testbed/sbin/addpubkey .
     101$ patch < addpubkey.patch
     102$ sudo mv addpubkey /usr/testbed/sbin/taddpubkey
     103$ sudo chown root:wheel /usr/testbed/sbin/taddpubkey
     104$ sudo chmod 4755 /usr/testbed/sbin/taddpubkey
     105}}}
    118106
    119 These three level names are used only for testbed access control.  All
    120 other entities in the system are identified by a single fedid.
     107{{{
     108$ cd /tmp
     109$ cp /usr/testbed/sbin/grantnodetype .
     110$ patch < grantnodetype.patch
     111$ sudo mv grantnodetype /usr/testbed/sbin/tgrantnodetype
     112$ sudo chown root:wheel /usr/testbed/sbin/tgrantnodetype
     113}}}
    121114
    122 == Granting Access: Emulab Projects ==
     115Note that taddpubkey will be setuid root (just like addpubkey is) and
     116that grantnodetype will not.  The permissions need to match those of the
     117original command.  They will fail with different ones.
    123118
    124 Once a fedd has decided to grant a researcher access to resources, it
    125 implements that decision by granting the researcher access to an Emulab
    126 project with relevant permissions on the local testbed.  The terminology
    127 is somewhat unfortunate in that the fedd is configured to grant access
    128 based on the global three-level name that includes project and user
    129 components and implements that decision by granting access to a local
    130 Emulab project and Emulab user.
     119Once the scripts exist, make sure you configure the [allocate] section
     120of the configuration file to use them, e.g.:
    131121
    132 The Emulab project to which the fedd grants access may exist and contain
    133 static users and resource rights, may exist but be dynamically
    134 configured by fedd with additional resource rights and access keys, or
    135 may be created completely by fedd.  Completely static projects are
    136 primarily used when a user wants to tie together his or her accounts on
    137 multiple testbeds that do not bar that behavior, but do not run fedd.
     122{{{
     123[allocate]
     124addpubkey: /usr/testbed/sbin/taddpubkey
     125grantnodetype: /usr/testbed/sbin/tgrantnodetype
     126}}}
    138127
    139 Whether to dynamically modify or dynamically create files depends
    140 significantly on testbed administration policy and how widespread and
    141 often federation is conducted.  In Emulabs projects are intended as
    142 long-term entities, and creating and destroying them on a per-experiment
    143 basis may not appeal to some users.  However, static projects require
    144 some administrator investment per-project.
     128See the [FeddConfig configuration section] for more detail.
    145129
    146 = Experiments =
     130== Subversion access ==
    147131
    148 A federated experiment exports a master testbed's runtime environment
    149 into the other testbeds.  The resulting experiment exports the shared
    150 file space of the home testbed, though a different filesystem, SMB, is
    151 used to export it.  Emulab events can be sent to nodes throughout the
    152 federated experiment, though some naming slight-of-hand may be required.
    153 Users who want to reboot nodes or links in federated testbeds will need
    154 to access those testbeds directly using the credentials provided by
    155 fedd.
     132If you prefer to live more dangerously, you can download a recent tree
     133from the subversion repository on this site and install it.  The
     134same packages must be installed as for the tar file version.  The
     135commands to access the subversion repository and install are:
    156136
    157 Currently experiments are described in the same ns2 syntax that DETER
    158 and Emulab use, except that additional annotations for the testbed on
    159 which to place each node have been ad dded.  (The extension is
    160 set-node-testbed, and described elsewhere.)  The testbed name here is a
    161 local string meaningful to the experimenter.  Each fedd knows some set
    162 of such strings, and experimenters can also inform fedd of the
    163 appropriate mapping between local testbed name and fedd address to
    164 contact.
     137{{{
     138$ svn checkout http://fedd.isi.deterlab.net:8088/svn/fedd/trunk some_dir
     139$ cd some_dir
     140$ make dist
     141$ cd dist
     142}}}
    165143
    166 An experimenter creates an experiment by presenting it to a fedd that
    167 knows him or her - usually the fedd on their local testbed - along with
    168 the master testbed name, local Emulab project to export and local
    169 mappings.  That fedd will map the local user into the global (testbed,
    170 project, user) namespace and acquire and configure resources to create
    171 the experiment.  A fedd may try different mappings of the experimenter
    172 into the global namespace in order to acquire all the resources.  For
    173 example a local experimenter may be a member of several local Emulab
    174 projects that map into different global testbed-scoped projects.
     144And from there, install from the tar file in dist, as above.
    175145
    176 Once created the user receives the various keys under which he or she
    177 can access the sub-experiment services and a local and global name by
    178 which the experiment can be referenced.  (Experiments are identified by
    179 fedids).  The local name is mnemonic and can be used locally to access
    180 information about the experiment and to terminate it.  The experimenter
    181 can suggest a name when requesting experiment creation.
    182 
    183 In order to create a fedid, a key pair is created.  The public and
    184 private keys for the fedid representing the experiment are returned in
    185 an encrypted channel from fedd to the requesting experimenter.  The
    186 experimenter can use this key pair as a capability to grant access to the
    187 experiment to other users.
    188 
    189 While an experiment exists, experimenters can access the nodes directly
    190 using the credentials passed back and can acquire information about the
    191 experiment's topology from fedd.  Only the experimenter who created it
    192 or one given the capability to manipulate it can get this information.
    193 
    194 Finally, fedd will terminate an experiment on behalf of the experimenter
    195 who created it, or one who has been granted control of it.  Fedd is
    196 responsible for deallocating the running experiments and telling the
    197 testbeds that this experimenter is done with their access.
    198 
    199 = Interfaces to fedd =
    200 
    201 The fedd interfaces are completely specified in WDSL and SOAP bindings.
    202 For simplicity and backward compatibility, fedd can export the same
    203 interfaces over XMLRPC, where the message formats are trivial
    204 translations.
    205 
    206 All fedd accesses are through HTTP over SSL.  Fedd can support
    207 traditional SSL CA chaining for access control, but the intention is to
    208 use self-signed certificates representing fedids.  The fedid semantics
    209 are always enforced.
    210 
    211 There are also several internal interfaces also specified in WSDL/SOAP
    212 and accessible through XMLRPC used to simplify the distributed
    213 implementation of fedd.  You can read about those in the development
    214 section.