= 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 [http://www.python.org/doc/current/library/configparser.html 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.