Changes between Version 5 and Version 6 of FeddConfigExamples

Timestamp:

Jun 5, 2010 2:59:54 PM (14 years ago)

Author:

faber

Comment:

--

FeddConfigExamples

@@ -3 +3 @@
 This page gives several `fedd` layouts and the configuration files that support them.  You can take them either as starting points from which to create your own configuration or as demonstrations of how the parameters in the [FeddConfig configuration files] and [FeddDatabases databases] work together.
 
-== Static Access Only on Users ==
+== Emulab Configurations ==
+
+=== Static Access Only on Users ===
 
 This 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.
@@ -16 +18 @@
 [globals]
 # Identify this fedd by the fedid encoded as a certificate file (user file protections to protect it)
- These types of node are not accessible by everyone
-restricted: rpc_30cert_file: /usr/local/etc/fedd/fedd.pem
+cert_file: /usr/local/etc/fedd/fedd.pem
 # Provide service on port 23235
 services: 23235
@@ -27 +28 @@
 
 # Parameters for remote fedds to instantiate experiments
-boss: boss
-ops: users
 domain: .isi.deterlab.net
-fileserver: fs
-eventserver: event-server
-
-# This machine's URI to discriminate proxy requests
-testbed: https://users.isi.deterlab.net:23235
+
 
 # The database that maps requester to local access projects (shown below)
@@ -49 +44 @@
 
 {{{
-# Overrides for the connector image and type
-attribute: connectorImage value: FBSD7-TVF
-attribute: connectorType value: pc3000_tunnel
 
 # map users from the given testbed in the Deter group into the local Federation project.  Experiments will
 # be created by the local user "fedd" and accessable by users with the same name as requesters.  This
 # will require coordination.
-(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> (Federation, fedd, <same>)
-}}}
-
-== Dynamic Keying only on Boss ==
+(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> access, (Federation, fedd, <same>)
+}}}
+
+=== Dynamic Keying only on Boss ===
 
 In 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.
@@ -82 +74 @@
 
 # Parameters for remote fedds to instantiate experiments
-boss: boss
-ops: users
 domain: .isi.deterlab.net
-fileserver: fs
-eventserver: event-server
-
-# This machine's URI to discriminate proxy requests (NB: this runs on boss)
-testbed: https://boss.isi.deterlab.net:23235
 
 # The database that maps requester to local access projects (shown below)
@@ -109 +94 @@
 
 {{{
-# Overrides for the connector image and type
-attribute: connectorImage value: FBSD7-TVF
-attribute: connectorType value: pc3000_tunnel
-
-# Nodes of this type are not generally accessible
-restricted: rpc_3000
-
 # Additional keys may be added to these groups.  Note that when a user with emulab-ops as the project in their 
-# three-level name accesses the testbed, the fedd project will be given access to the restricted node type 
-# rpc_3000.  Requesters with Deter as the project will be unable to successfully request access to such nodes.
-(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> (Federation, fedd, <same>)
-(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, emulab-ops, <any>) -> (Federation, fedd:rpc_3000, <same>)
-
-}}}
-
-== Dynamic Keying with Distributed Operation on Users and Boss ==
+# three-level name accesses the testbed, the fedd project will be used.
+(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> access, (Federation, fedd, <same>)
+(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, emulab-ops, <any>) -> access, (Federation, fedd, <same>)
+
+}}}
+
+=== Dynamic Keying with Distributed Operation on Users and Boss ===
 
 In this case two `fedd`s are running.  The one on users accepts and evaluates access requests but calls out to the `fedd` on boss to do the manipulation of local testbed state.  Boss may choose to firewall all other hosts (except users) away from the fedd port, though the    `fedd` access controls will also protect access.  The situation looks like this:
@@ -145 +122 @@
 
 # Parameters for remote fedds to instantiate experiments
-boss: boss
-ops: users
 domain: .isi.deterlab.net
-fileserver: fs
-eventserver: event-server
-
-# This machine's URI to discriminate proxy requests (NB: this runs on users)
-testbed: https://users.isi.deterlab.net:23235
 
 # The database that maps requester to local access projects (shown below)
@@ -166 +136 @@
 
 {{{
-# Overrides for the connector image and type
-attribute: connectorImage value: FBSD7-TVF
-attribute: connectorType value: pc3000_tunnel
-
-# Nodes of this type are not generally accessible
-restricted: rpc_3000
 
 # Additional keys may be added to these groups.  Note that when a user with emulab-ops as the project in their 
-# three-level name accesses the testbed, the fedd project will be given access to the restricted node type 
-# rpc_3000.  Requesters with Deter as the project will be unable to successfully request access to such nodes.
+# three-level name accesses the testbed, the fedd project will be used.
 (fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> (Federation, fedd, <same>)
-(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, emulab-ops, <any>) -> (Federation, fedd:rpc_3000, <same>)
+(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, emulab-ops, <any>) -> (Federation, fedd, <same>)
 
 }}}
@@ -223 +186 @@
 where that fedid is the one that the `users` `fedd` is identified by.
 
-== Dynamic Keying with Distributed Operation on Users and Boss and Experiment Control on Users ==
-
-Extending 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.
-
-Specifically the `users` configuration becomes:
-
-{{{
-[globals]
-# Identify this fedd by the fedid encoded as a certificate file (user file protections to protect it)
-cert_file: /usr/local/etc/fedd/fedd.pem
-# Provide service on port 23235
-services: 23235
-
-[access]
-# Keep access state (which experiments are live) in this file
-# Be sure it is writeable by the fedd user
-access_state: /var/db/fedd/deter_access.state
-
-# Parameters for remote fedds to instantiate experiments
-boss: boss
-ops: users
-domain: .isi.deterlab.net
-fileserver: fs
-eventserver: event-server
-
-# This machine's URI to discriminate proxy requests (NB: this runs on users)
-testbed: https://users.isi.deterlab.net:23235
-
-# The database that maps requester to local access projects (shown below)
-accessdb: /usr/local/etc/fedd/deter_access
-
-[allocate]
-# Contact boss for allocations
-uri: https://boss.ucb.deterlab.net:23235
-
-[experiment_control]
-# Keys used to access the experiment creation testbed user account (may be installed 
-# by that testbed's fedd)
-ssh_pubkey_file: /usr/local/etc/fedd/fedd_rsa.pub
-ssh_privkey_file: /usr/local/etc/fedd/fedd_rsa
-
-# Save experiment control state in case of loss of the process or machine
-experiment_state_file: ./deter.state
-
-# Which users can create experiments (see below)
-accessdb: /users/faber/fedd/exp_access_db
-
-# How users name testbeds
-mapdb: /users/faber/fedd/exp_map_db
-
-# Standard experiment instantiation software
-fedkit: /usr/local/etc/fedd/fedkit.tgz
-
-}}}
-
-The [FeddDatabases#ExperimentControlComponentAccessDB experiment control accessDB] in `/users/faber/fedd/exp_access_db` would look like:
-
-{{{
-# bwilson
-fedid:5bf3384e2cefca6ba8718958e488fe8bcbf1da2c->bwilson
-fedid:5bf3384e2cefca6ba8718958e488fe8bcbf1da2c->(ddos,bwilson)
-# jhickey
-fedid:29f0436dac012086ca50fe31afb7d746268aefce->jhickey
-fedid:29f0436dac012086ca50fe31afb7d746268aefce->(emulab-ops,jhickey)
-fedid:29f0436dac012086ca50fe31afb7d746268aefce->(routing,jhickey)
-fedid:29f0436dac012086ca50fe31afb7d746268aefce->(worm,jhickey)
-}}}
-
-and the [FeddDatabases#ExperimentNameMappingDB name mapping DB] in `/users/faber/fedd/exp_map_db` would look like:
-
-{{{
-deter:https://users.isi.deterlab.net:23235
-ucb:https://users.ucb.deterlab.net:23235
-}}}
-
-Other files on `users` and all files on `boss` would be unchanged from the previous configuration.
-
 There are other possible layouts, but hopefully these have highlighted the use of the various [FeddConfig configuration parameters] and their related  [FeddDatabases databases].
+
+== ProtoGENI Configuration ==
+
+
+Basic ProtoGENI configuration
+
+{{{
+[DEFAULT]
+base: /usr/local/etc/fedd
+
+[access]
+project_priority: false
+log_level: debug
+access_state: %(base)s/protoGENI_access.state
+accessdb: %(base)s/protoGENI_access
+certdir: %(base)s/certs
+userconfdir: %(base)s/userconf
+
+domain: .emulab.net
+renewal: 10080
+
+# Stage files on ops.emulab.net in a geni directory
+staging_dir: /proj/geni/tarfiles
+staging_host: ops.emulab.net
+
+# Some custom ssh settings, the one in use when this file was written was too old to support federation
+sshd: /proj/geni/tarfiles/TIED/sshd
+sshd_config: /proj/geni/tarfiles/TIED/sshd_config
+ssh_port: 20200
+
+# The standard start commands
+portal_startcommand: sudo -H /usr/bin/perl -I/usr/local/federation/lib /usr/local/federation/bin/combo.pl --use_file >& /tmp/bridge.log
+node_startcommand: sudo -H /usr/bin/perl -I/usr/local/federation/lib /usr/local/federation/bin/federate.pl --install_samba >& /tmp/federate
+smbshare: FS
+
+ch_url: https://www.emulab.net:443/protogeni/xmlrpc/ch
+sa_url: https://www.emulab.net:443/protogeni/xmlrpc/sa
+cm_url: https://www.emulab.net:443/protogeni/xmlrpc/cm/1.0
+
+
+federation_software: /usr %(base)s/fedkit.tgz rpm %(base)s/python2.4-2.4-1pydotorg.i586.rpm
+portal_software: /usr/local %(base)s/seer-all-current.tgz
+
+[allocate]
+debug: true
+log_level: debug
+allocation_level: none
+
+[globals]
+cert_file: %(base)s/fedd.pem
+cert_pwd: alkdfh
+services: 13234
+
+access_type: protogeni
+
+}}}
+
+Simple access database maps [FeddAbout#GlobalIdentifiers:Three-levelNames three names] to a certificate, username, ssh key, and ssh password.
+{{{
+(fedid:b55205ac843c40ce9c9feb3b358bff782ed337fd, TIED, <any> ) -> access, (/users/faber/fedd-config/protoGENI/ProtoGENI.pem, faber, /users/faber/fedd-config/protoGENI/fedd_rsa, aldkfh)
+}}}
+
+== DRAGON configuration ==
+
+Here is a pretty standard dragon configuration:
+
+{{{
+[DEFAULT]
+base: /usr/local/etc/fedd
+[access]
+
+project_priority: false
+log_level: debug
+access_state: %(base)s/dragon_access.state
+accessdb: %(base)s/dragon_access
+certdir: %(base)s/certs
+userconfdir: %(base)s/userconf
+type: dragon
+
+# Here is where the OSCARS software and support have been installed
+cli_dir: %(base)s/OSCARS-client-api/examples/
+axis2_home: %(base)s/axis2-1.4.1
+
+#The IDC where the certificate below is valid.
+idc: https://idc.dragon.maxgigapop.net:8443/axis2/services/OSCARS
+
+
+[allocate]
+debug: true
+log_level: debug
+allocation_level: none
+
+[globals]
+cert_file: %(base)s/fedd.pem
+cert_pwd: lkajdgl
+services: 23229
+
+access_type: dragon
+}}}
+
+This access DB maps to a single repo directory that contains appropriate certificates (see the OSCARS documentation)
+
+{{{
+(fedid:b55205ac843c40ce9c9feb3b358bff782ed337fd, <any>, mcgeer) -> access, (repo)
+(fedid:b55205ac843c40ce9c9feb3b358bff782ed337fd, TIED, <any>) -> access, (repo)
+}}}