= 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 [FeddConfig configuration files] and [FeddDatabases databases] work together.

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

The layout is:

[[Image(user_fedd.png)]]

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)
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
domain: .isi.deterlab.net


# 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 [FeddDatabases#AccessComponentAccessDB 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):

{{{

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

This is the layout:

[[Image(boss_fedd.png)]]

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 [FeddDownload#AdditionalScripts 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
domain: .isi.deterlab.net

# 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 [FeddDatabases#AccessComponentAccessDB 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):

{{{
# 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 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:

[[Image(2fedds.png)]]

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
domain: .isi.deterlab.net

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

{{{

# 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 used.
(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> (Federation, fedd, <same>)
(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, emulab-ops, <any>) -> (Federation, fedd, <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.

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