Configuration Examples

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 configuration files and databases work together.

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 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.

The layout is:

A commented fedd.conf (installed in /usr/local/etc/fedd.conf) on users.isi.deterlab.net might look like this:

[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
# 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
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]
# do not check allocations.  Assume that the static configuration of projects is correct.
allocation_level: none
# this could really be omitted.  Without modifications, there's no state to keep
allocate_state: /var/db/fedd/deter_allocate.state

In addition the access component accessdb in /usr/local/etc/fedd/deter_access might be similar to this one (the rules could be more explicit or looser, for example):

# 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

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.

This is the layout:

The configuration assumes that patched versions of addpubkey and grantnodetype have been installed as taddpubkey and tgrantnodetype in /usr/testbed/sbin as described in the installation section.

[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 boss)
testbed: https://boss.isi.deterlab.net:23235

# The database that maps requester to local access projects (shown below)
accessdb: /usr/local/etc/fedd/deter_access

[allocate]
# Allow keys and node types to be extended.
allocation_level: dynamic_keys

# Keep track of keys added and node types granted so that they can be removed when done.
allocate_state: /var/db/fedd/deter_allocate.state

# Use the extended commands
grantnodetype: /usr/testbed/sbin/tgrantnodetype
addpubkey: /usr/testbed/sbin/taddpubkey

In addition the access component accessdb in /usr/local/etc/fedd/deter_access might be similar to this one (the rules could be more explicit or looser, for example):

# 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

In this case two fedds 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:

The configuration file on users looks like:

[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

In addition the 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.

# 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>)

The configuration on boss is simpler. First the /usr/local/etc/fedd.conf:

[globals]
# This machine's identity
cert_file: /usr/local/etc/fedd/fedd.pem
# The global access DB is given below.  This controls access to the allocation service.
accessdb: /usr/local/etc/fedd/access_db

# Supply services on the usual fedd port.  You may choose a different one for further obfuscation.
services: 23235

[access]
# The [access] section must appear, even though no access operations are done here.
# The internals are structured so that allocation is a subtask of access, so the presence
# of this section signals that a non-null access component should be created.
log_level: debug

# Note that there is no accessdb specified.  Even if an access request arrives, it will be
# denied.

[allocate]
log_level: debug
# Again, allocate keys and types dynamically
allocation_level: dynamic_keys

# Use the specialized scripts
addpubkey: /usr/testbed/sbin/taddpubkey
grantnodetype: /usr/testbed/sbin/tgrantnodetype

# Save the allocation state on boss
allocation_state: /var/db/fedd/alloc.state

The db in /usr/local/etc/fedd/access_db contains:

fedid:12ecc7415746281efa0ed58e180c51a5cba13a57 allocate

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 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 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 configuration parameters and their related databases.