Changes between Version 3 and Version 4 of FeddConfig
- Timestamp:
- Dec 10, 2008 5:07:01 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FeddConfig
v3 v4 70 70 '''cert_file''':: 71 71 Certificate used to assert identity of the access component. It uses this 72 certificate when proxying requests. Note that the certificates used in the [allocate] section are used to contact a remote allo action `fedd`.72 certificate when proxying requests. Note that the certificates used in the [allocate] section are used to contact a remote allocation `fedd`. If this field is not present and a '''cert_file''' is present in the [globals] section, the [globals] certificate will be used. 73 73 '''cert_pwd''':: 74 Password for the private key in '''cert_file'''. 74 Password for the private key in '''cert_file'''. If the [globals] certificate is used, so is the [globals] '''cert_pwd''', if any. 75 75 '''domain''':: 76 76 The trailing (common) parts of the domain name for various hosts. Returned to the requester to allow manipulation of resources. … … 91 91 '''trusted_certs''':: 92 92 a file containing the trusted CAs used for SSL validation. If this is not 93 present, no certificate path checking is done. 94 '''uri''':: 95 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. 93 present, no certificate path checking is done. If this field is not present and a '''trusted_certs''' field is present in the [globals] section, the [globals] certificates will be used. 96 94 97 95 === Allocation Options === … … 104 102 This option defines what `fedd` will try to do to grant access. The following are valid choices: 105 103 * '''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. 104 * '''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. 105 * '''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. 106 * '''none''' - The local Emulab is never changed, and no parameters are checked. This makes allocation a no-op. 106 107 '''allocation_state''':: 107 108 Name of the file where current allocation state is saved. This state includes … … 109 110 what to release and when. Must be specified for allocation decisions to survive 110 111 fedd failures or node reboots. A file in `/var/db/fedd` is often used. 111 * '''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.112 * '''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.113 * '''none''' - The local Emulab is never changed, and no parameters are checked. This makes allocation a no-op.114 112 '''addpubkey''':: 115 113 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. 116 114 '''cert_file''':: 117 Certificate used to assert identity of the allocation component. If '''uri''' is set in th e [access] section, this certificate is presented to the remote allocation `fedd`, if not this certificate is presented to the allocator making a request.115 Certificate used to assert identity of the allocation component. If '''uri''' is set in this section, this certificate is presented to the remote allocation `fedd`, if not this certificate is presented to the allocator making a request. If this field is not present and a '''cert_file''' is present in the [globals] section, the [globals] certificate will be used. 118 116 '''cert_pwd''':: 119 Password for the private key in '''cert_file'''. 117 Password for the private key in '''cert_file'''. If the [globals] certificate is used, so is the [globals] '''cert_pwd''', if any. 120 118 '''confirmkey''':: 121 119 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'. 120 '''debug''':: 121 If this boolean is true, a local allocating `fedd` will not execute the allocation commands, just log them (at debug priority). It has no effect on a `fedd` that is calling out to make allocations. 122 122 '''grantnodetype''':: 123 123 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. … … 136 136 '''trusted_certs''':: 137 137 a file containing the trusted CAs used for SSL validation. If this is not 138 present, no certificate path checking is done. 138 present, no certificate path checking is done. If this field is not present and a '''trusted_certs''' field is present in the [globals] section, the [globals] certificates will be used. 139 '''uri''':: 140 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`. 139 141 '''user_to_project''':: 140 142 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`. 143 144 === Experiment Control Options === 145 146 These options control how `fedd` embeds an experiment into the requested testbeds, including acquiring access and starting the experiment. 147 148 '''access_db''':: 149 Database that indicates who can request services from this `fedd` and what three-level names the `fedd` will attest on their behalf. The specification is here. 150 '''cert_file''':: 151 Certificate used to assert identity of the experiment control component. If this field is not present and a '''cert_file''' is present in the [globals] section, the [globals] certificate will be used. 152 '''cert_pwd''':: 153 Password for the private key in '''cert_file'''. If the [globals] certificate is used, so is the [globals] '''cert_pwd''', if any. 154 '''create_debug''':: 155 If this boolean is true, this component will not create the experiment, though it will make access control requests to remote testbeds. 156 '''fedkit''':: 157 Location of the tar file containing the federation software to establish the expriment. There is a version available here. 158 '''experiment_state_file''':: 159 Name of the file where current experiment state state is saved. This state includes 160 the allocations made to support each federated experiment request as well as the information necessary to release those resources. Must be specified for experiment to survive 161 fedd failures or node reboots. A file in `/var/db/fedd` is often used. 162 '''log_level''':: 163 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. 164 '''mapdb''':: 165 Database that controlls the default mapping from testbed name to contact URI. 166 '''ssh_pubkey_file''':: 167 The public key that this `fedd` will use to access remote Emulab services. Required. 168 '''ssh_privkey_file''':: 169 The private key corresponding to the key in '''ssh_pubkey_file'''. This should be accessibel without a password, and properly protected, for example in a local filesystem with appropriate permissions, or with `fedd` running under an ssh agent. 170 '''ssh_keytype''':: 171 Type of key generated for internal accesses in the experiment. It can be either dsa or rsa, but probably does not need to be changed. 172 '''splitter_url''':: 173 Contact point for using a remote experiment splitter. Generally this should be set to !http://users.isi.dertelab.net:23235 . 174 '''tcl_splitter''':: 175 Path to the tcl-based splitter program to be used if splitting is done locally. If '''splitter_url''' is set, this has no effect. 176 '''trusted_certs''':: 177 a file containing the trusted CAs used for SSL validation. If this is not 178 present, no certificate path checking is done. If this field is not present and a '''trusted_certs''' field is present in the [globals] section, the [globals] certificates will be used.
