Configuring fedd

As noted in installation, many of these parameters define the layout of the fedd instantiation on your machine, so read the reference below and look at the examples to make sure you understand how fedd is working on your testbed.

Fedd is broken into 4 components: experiment control, access control, project allocation, and experiment description parsing (most installations will not need this component). There is a global configuration file with subsections devoted to each of these components. Each component also has an access database that defines the services they grant to a given fedid. We described the global configuration file first, and then the access databases.

The main configuration file is in /usr/local/etc/fedd.conf by default, though the --config option can redirect it. It of the basic format parsed by a python ​SafeConfigParser. Basically this format is sections headed by []'s with attribute/value pairs in for each section following. One can use any of the substitution tricks in the python documentation as well. There are 5 sections, one for each component and one for global options.

Global options are in the section following the [globals] header. The following attributes are used:

accessdb

global fedid -> access attribute mapping database. See the discussions of the project allocation and splitting databases below for the format of this file and how to generate one.

cert_file

the file containing the X509 certificate and private key for this server, in pem format.

cert_pwd

if the private key in cert_file has a password, it is given here.

trusted_certs

a file containing the trusted CAs used for SSL validation. If this is not present, no certificate path checking is done.

Each of these can be affected by other sections. For example, if the [access] section specifies a cert_file and cert_pwd, those will be used rather than those in [globals]. Similarly, [allocation] and [splitter] sections can include their own attribute databases. Note that the presence of another database does not invalidate the global access database, but adds to it.

Access control sections follow the [access] header. The following are valid attributes:

accessdb

The mapping of three level names to local project and users (for creation and services). See below for the format of this DB.

access_state

Name of the file where current access state is saved. This state includes the access granted to each federated experiment request and is used to decide what to release and when. Must be specified for access decisions to survive fedd failures or node reboots. A file in /var/db/fedd is often used.

allow_proxy

Allow this fedd to act as a proxy for others in making access requests. This functionality is in development and not intended for use yet.

cert_file

Certificate used to assert identity of the access component. It uses this certificate when proxying requests.

cert_pwd

Password for the private key in cert_file.

project_priority

When considering two possible resolutions of wildcarded access control db entries, give priority to a project match over a user match. Default is to give priority to the user match.

testbed

A comma separated list of URLs that this fedd answers requests on. Requests for testbeds other that these will be denied, or proxied if allow_proxy is true (which it shouldn't be).

trusted_certs

a file containing the trusted CAs used for SSL validation. If this is not present, no certificate path checking is done.