Changes between Initial Version and Version 1 of FeddConfig

Timestamp:

Dec 10, 2008 2:16:48 PM (16 years ago)

Author:

faber

Comment:

--

FeddConfig

@@ +1 @@
+
+= 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.
+