Changes between Version 4 and Version 5 of FeddConfigExamples


Ignore:
Timestamp:
Dec 11, 2008 2:57:54 PM (16 years ago)
Author:
faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FeddConfigExamples

    v4 v5  
    66
    77This is the simplest configuration of `fedd`, used to allow users of other testbeds to use resources from yours using pre-configured projects.  The layout assumes that for each [FeddAbout#GlobalIdentifiers:Three-levelName three-level name] you are willing to allow to use your testbed, you have set up a project that already has proper keys installed.  Because no local projects or local users need to be modified, `fedd` does not need access to boss.
     8
     9The layout is:
     10
     11[[Image(user_fedd.png)]]
    812
    913A commented fedd.conf (installed in `/usr/local/etc/fedd.conf`) on `users.isi.deterlab.net` might look like this:
     
    5963In this case there is still one running `fedd`, but it runs on `boss`, where it can add keys to user accounts and change project permissions.  While projects and users need to be kept in sync, the user keys need not.  The changes here are largely in the allocation section of the global configuration.
    6064
     65This is the layout:
     66
     67[[Image(boss_fedd.png)]]
     68
    6169The configuration assumes that patched versions of `addpubkey` and `grantnodetype` have been installed as `taddpubkey` and `tgrantnodetype` in `/usr/testbed/sbin` as described in the [FeddDownload#AdditionalScripts installation section].
    6270
     
    122130[[Image(2fedds.png)]]
    123131
    124 The configuration file on users looks like:
     132The configuration file on `users` looks like:
    125133
    126134{{{
     
    155163}}}
    156164
    157 In addition the [FeddDatabases#AccessComponentAccessDB access component accessdb] in `/usr/local/etc/fedd/deter_access` might be similar to the following.  Note that the users `fedd` contains all the information to make the decisions about access.
     165In addition the [FeddDatabases#AccessComponentAccessDB access component accessdb] in `/usr/local/etc/fedd/deter_access` on users might be similar to the following.  Note that the users `fedd` contains all the information to make the decisions about access.
    158166
    159167{{{
     
    173181}}}
    174182
     183The configuration on `boss` is simpler.  First the `/usr/local/etc/fedd.conf`:
     184
     185{{{
     186[globals]
     187# This machine's identity
     188cert_file: /usr/local/etc/fedd/fedd.pem
     189# The global access DB is given below.  This controls access to the allocation service.
     190accessdb: /usr/local/etc/fedd/access_db
     191
     192# Supply services on the usual fedd port.  You may choose a different one for further obfuscation.
     193services: 23235
     194
     195[access]
     196# The [access] section must appear, even though no access operations are done here.
     197# The internals are structured so that allocation is a subtask of access, so the presence
     198# of this section signals that a non-null access component should be created.
     199log_level: debug
     200
     201# Note that there is no accessdb specified.  Even if an access request arrives, it will be
     202# denied.
     203
     204[allocate]
     205log_level: debug
     206# Again, allocate keys and types dynamically
     207allocation_level: dynamic_keys
     208
     209# Use the specialized scripts
     210addpubkey: /usr/testbed/sbin/taddpubkey
     211grantnodetype: /usr/testbed/sbin/tgrantnodetype
     212
     213# Save the allocation state on boss
     214allocation_state: /var/db/fedd/alloc.state
     215}}}
     216
     217The db in `/usr/local/etc/fedd/access_db` contains:
     218
     219{{{
     220fedid:12ecc7415746281efa0ed58e180c51a5cba13a57 allocate
     221}}}
     222
     223where that fedid is the one that the `users` `fedd` is identified by.
     224
     225== Dynamic Keying with Distributed Operation on Users and Boss and Experiment Control on Users ==
     226
     227Extending the previous configuration to also provide facilities for creating and managing federated experiments as well as allowing others to use this testbed's resources requires expanding the main configuration on users and adding a couple more databases.
     228
     229Specifically the `users` configuration becomes:
     230
     231{{{
     232[globals]
     233# Identify this fedd by the fedid encoded as a certificate file (user file protections to protect it)
     234cert_file: /usr/local/etc/fedd/fedd.pem
     235# Provide service on port 23235
     236services: 23235
     237
     238[access]
     239# Keep access state (which experiments are live) in this file
     240# Be sure it is writeable by the fedd user
     241access_state: /var/db/fedd/deter_access.state
     242
     243# Parameters for remote fedds to instantiate experiments
     244boss: boss
     245ops: users
     246domain: .isi.deterlab.net
     247fileserver: fs
     248eventserver: event-server
     249
     250# This machine's URI to discriminate proxy requests (NB: this runs on users)
     251testbed: https://users.isi.deterlab.net:23235
     252
     253# The database that maps requester to local access projects (shown below)
     254accessdb: /usr/local/etc/fedd/deter_access
     255
     256[allocate]
     257# Contact boss for allocations
     258uri: https://boss.ucb.deterlab.net:23235
     259
     260[experiment_control]
     261# Keys used to access the experiment creation testbed user account (may be installed
     262# by that testbed's fedd)
     263ssh_pubkey_file: /usr/local/etc/fedd/fedd_rsa.pub
     264ssh_privkey_file: /usr/local/etc/fedd/fedd_rsa
     265
     266# Save experiment control state in case of loss of the process or machine
     267experiment_state_file: ./deter.state
     268
     269# Which users can create experiments (see below)
     270accessdb: /users/faber/fedd/exp_access_db
     271
     272# How users name testbeds
     273mapdb: /users/faber/fedd/exp_map_db
     274
     275# Standard experiment instantiation software
     276fedkit: /usr/local/etc/fedd/fedkit.tgz
     277
     278}}}
     279
     280The [FeddDatabases#ExperimentControlComponentAccessDB experiment control accessDB] in `/users/faber/fedd/exp_access_db` would look like:
     281
     282{{{
     283# bwilson
     284fedid:5bf3384e2cefca6ba8718958e488fe8bcbf1da2c->bwilson
     285fedid:5bf3384e2cefca6ba8718958e488fe8bcbf1da2c->(ddos,bwilson)
     286# jhickey
     287fedid:29f0436dac012086ca50fe31afb7d746268aefce->jhickey
     288fedid:29f0436dac012086ca50fe31afb7d746268aefce->(emulab-ops,jhickey)
     289fedid:29f0436dac012086ca50fe31afb7d746268aefce->(routing,jhickey)
     290fedid:29f0436dac012086ca50fe31afb7d746268aefce->(worm,jhickey)
     291}}}
     292
     293and the [FeddDatabases#ExperimentNameMappingDB name mapping DB] in `/users/faber/fedd/exp_map_db` would look like:
     294
     295{{{
     296deter:https://users.isi.deterlab.net:23235
     297ucb:https://users.ucb.deterlab.net:23235
     298}}}
     299
     300Other files on `users` and all files on `boss` would be unchanged from the previous configuration.
     301
     302There are other possible layouts, but hopefully these have highlighted the use of the various [FeddConfig configuration parameters] and their related  [FeddDatabases databases].