Changes between Version 1 and Version 2 of FeddConfig

Timestamp:

Dec 10, 2008 3:01:27 PM (16 years ago)

Author:

faber

Comment:

--

FeddConfig

@@ -15 +15 @@
 first, and then the access databases.
 
+== Main Configuration File (`fedd.conf`) ==
+
 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
@@ -21 +23 @@
 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 ===
 
 Global options are in the section following the [globals] header.  The
@@ -45 +49 @@
 database, but adds to it.
 
-Access control sections follow the [access] header.  The following are
-valid attributes:
+=== Access Options ===
+
+Access control sections follow the [access] header.  These attributes concern the how `fedd` grants access to remote experimenters through their `fedd`.  Some of the parameters are directly related to whether access is granted and some are parameters returned to the requester so it can manipulate the resources once granted.
+The following are valid attributes:
 
  '''accessdb'''::
@@ -59 +65 @@
   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.
+ '''boss'''::
+  Hostname to report as boss to remote testbeds granted access.  A requesting `fedd` uses this to configure internals of the 
+  federated experiment.  This is just the first component of the name, the '''domain''' option provides the rest.
  '''cert_file'''::
   Certificate used to assert identity of the access component.  It uses this
-  certificate when proxying requests. 
+  certificate when proxying requests. Note that the certificates used in the [allocate] section are used to contact a remote alloaction `fedd`.
  '''cert_pwd'''::
   Password for the private key in '''cert_file'''.
+ '''domain'''::
+  The trailing (common) parts of the domain name for various hosts.  Returned to the requester to allow manipulation of resources.
+ '''eventserver'''::
+  Hostname of the machine that forwards events in this testbed. Returned to the requester to allow manipulation of resources.
+ '''fileserver'''::
+  Hostname of the machine that serves user files in this testbed. Returned to the requester to allow manipulation of resources.
+ '''log_level'''::
+  The level of logging to produce from this component.  One of `debug`, `info`, `warning`, `critical`, and `error`.  See the [http://www.python.org/doc/current/library/logging.html standard python logging system] for details.
  '''project_priority'''::
   When considering two possible resolutions of wildcarded access control db
@@ -75 +92 @@
   a file containing the trusted CAs used for SSL validation.  If this is not
   present, no certificate path checking is done.
+ '''uri'''::
+  If present this gives the uri of the `fedd` that will perform the manipulation of the local project database to grant and revoke access to the testbed.  In installations where `fedd` runs on both users and boss, this will tell the users `fedd` where to reach the boss `fedd`.  The certificates and trusted certificates specified in the [allocate] section establish the identity of this `fedd` when communicating with the remote `fedd`.  The certificates in the [access] section are used for proxying access requests only.
 
+=== Allocation Options ===
+
+The [allocation] section controls how Emulab project allocation is carried out on the host where `fedd` is running.  If the '''uri''' option is set in the [access] section, the [allocation] section defined the parameters used to communicate with the remote `fedd`.  If not, project allocation will occur on this machine and the parameters apply to the manipulation of the local Emulab state to grant access.
+
+The following options are valid:
+
+ '''allocation_level'''::
+  This option defines what `fedd` will try to do to grant access.  The following are valid choices:
+
+
+   '''dynamic_projects'''::
+    Add new projects and users to the local Emulab in response to requests.  What users and projects and who may successfully request them is a function of the access DB below.  The access component decides what projects and users to add and the allocation component does the work.
+   '''dynamic_keys'''::
+    No projects or users are added to the local Emulab, but addtional keys may be granted access to user accounts and projects may have their access rights expanded.  Again the access component decides which users and projects to expand and the allocation system does so.
+   '''confirm_keys''':
+    The local Emulab is never changed, but the allocating `fedd` confirms that the users specified may be accessed by the given keys.  In effect, it confirms that the if the changes were requested, they would succeed.
+ '''addpubkey'''::
+  Path to the `addpubkey` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/addpubkey` is usually insufficient.  See the instructions in [FeddDownload installing] for information on how to construct and install the `taddpubkey` version, and set this option to point at it.  Note that if you are not dynamically allocating resources, you need not create the new script nor set this option.
+ '''cert_file'''::
+  Certificate used to assert identity of the allocation component.  If '''uri''' is set in the [access] section, this certificate is presented to the remote allocation `fedd`, if not this certificate is presented to the allocator making a request.
+ '''cert_pwd'''::
+  Password for the private key in '''cert_file'''.
+ '''confirmkey'''::
+  Path to the Emulab command used to confirm a user's public SSH key.  Only useful for local allocation.  The default of `/usr/testbed/sbin/addpubkey` is usually insufficient.  If you are interested in dynamic allocation, the same modifications that make `taddpubkey` sufficient as for use in adding and removing public SSH keys are sufficent for this use as well.  Follow the instructions in [FeddDownload installing] for information on how to construct and install the `taddpubkey` version, and set this option to point at it.  If you are not allocating resources dynamically, you can use the `confirm_sshkey.py` script packaged with `fedd` for this purpose.  By default it is installed as `/usr/local/bin/confirm_sshkey.py'.
+ '''grantnodetype'''::
+  Path to the `grantnodetype` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/grantnodetype` is usually insufficient.  See the instructions in [FeddDownload installing] for information on how to construct and install the `tgrantnodetype` version, and set this option to point at it.  Note that if you are not dynamically allocating resources, you need not create the new script nor set this option.
+ '''mkproj'''::
+  Path to the `mkproj` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/mkproj` is usually correct.
+ '''newproj'''::
+  Path to the `newproj` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/newproj` is usually correct.
+ '''newuser'''::
+  Path to the `newuser` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/newuser` is usually correct.
+ '''rmproj'''::
+  Path to the `rmproj` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/rmproj` is usually correct.
+ '''rmuser'''::
+  Path to the `rmuser` Emulab command.  Only useful for local allocation.  The default of `/usr/testbed/sbin/rmuser` is usually correct.
+ '''trusted_certs'''::
+  a file containing the trusted CAs used for SSL validation.  If this is not
+  present, no certificate path checking is done.
+ '''user_to_project'''::
+  Script to attach a new local (Emulab) user to a local (Emulab) project.  The `user_to_project.py` script shipped with `fedd` is used for this purpose by default.  Specifically, the default value of this option is `/usr/local/bin/user_to_project.py`.