| 183 | The configuration on `boss` is simpler. First the `/usr/local/etc/fedd.conf`: |
| 184 | |
| 185 | {{{ |
| 186 | [globals] |
| 187 | # This machine's identity |
| 188 | cert_file: /usr/local/etc/fedd/fedd.pem |
| 189 | # The global access DB is given below. This controls access to the allocation service. |
| 190 | accessdb: /usr/local/etc/fedd/access_db |
| 191 | |
| 192 | # Supply services on the usual fedd port. You may choose a different one for further obfuscation. |
| 193 | services: 23235 |
| 194 | |
| 195 | [access] |
| 196 | # The [access] section must appear, even though no access operations are done here. |
| 197 | # The internals are structured so that allocation is a subtask of access, so the presence |
| 198 | # of this section signals that a non-null access component should be created. |
| 199 | log_level: debug |
| 200 | |
| 201 | # Note that there is no accessdb specified. Even if an access request arrives, it will be |
| 202 | # denied. |
| 203 | |
| 204 | [allocate] |
| 205 | log_level: debug |
| 206 | # Again, allocate keys and types dynamically |
| 207 | allocation_level: dynamic_keys |
| 208 | |
| 209 | # Use the specialized scripts |
| 210 | addpubkey: /usr/testbed/sbin/taddpubkey |
| 211 | grantnodetype: /usr/testbed/sbin/tgrantnodetype |
| 212 | |
| 213 | # Save the allocation state on boss |
| 214 | allocation_state: /var/db/fedd/alloc.state |
| 215 | }}} |
| 216 | |
| 217 | The db in `/usr/local/etc/fedd/access_db` contains: |
| 218 | |
| 219 | {{{ |
| 220 | fedid:12ecc7415746281efa0ed58e180c51a5cba13a57 allocate |
| 221 | }}} |
| 222 | |
| 223 | where that fedid is the one that the `users` `fedd` is identified by. |
| 224 | |
| 225 | == Dynamic Keying with Distributed Operation on Users and Boss and Experiment Control on Users == |
| 226 | |
| 227 | Extending the previous configuration to also provide facilities for creating and managing federated experiments as well as allowing others to use this testbed's resources requires expanding the main configuration on users and adding a couple more databases. |
| 228 | |
| 229 | Specifically the `users` configuration becomes: |
| 230 | |
| 231 | {{{ |
| 232 | [globals] |
| 233 | # Identify this fedd by the fedid encoded as a certificate file (user file protections to protect it) |
| 234 | cert_file: /usr/local/etc/fedd/fedd.pem |
| 235 | # Provide service on port 23235 |
| 236 | services: 23235 |
| 237 | |
| 238 | [access] |
| 239 | # Keep access state (which experiments are live) in this file |
| 240 | # Be sure it is writeable by the fedd user |
| 241 | access_state: /var/db/fedd/deter_access.state |
| 242 | |
| 243 | # Parameters for remote fedds to instantiate experiments |
| 244 | boss: boss |
| 245 | ops: users |
| 246 | domain: .isi.deterlab.net |
| 247 | fileserver: fs |
| 248 | eventserver: event-server |
| 249 | |
| 250 | # This machine's URI to discriminate proxy requests (NB: this runs on users) |
| 251 | testbed: https://users.isi.deterlab.net:23235 |
| 252 | |
| 253 | # The database that maps requester to local access projects (shown below) |
| 254 | accessdb: /usr/local/etc/fedd/deter_access |
| 255 | |
| 256 | [allocate] |
| 257 | # Contact boss for allocations |
| 258 | uri: https://boss.ucb.deterlab.net:23235 |
| 259 | |
| 260 | [experiment_control] |
| 261 | # Keys used to access the experiment creation testbed user account (may be installed |
| 262 | # by that testbed's fedd) |
| 263 | ssh_pubkey_file: /usr/local/etc/fedd/fedd_rsa.pub |
| 264 | ssh_privkey_file: /usr/local/etc/fedd/fedd_rsa |
| 265 | |
| 266 | # Save experiment control state in case of loss of the process or machine |
| 267 | experiment_state_file: ./deter.state |
| 268 | |
| 269 | # Which users can create experiments (see below) |
| 270 | accessdb: /users/faber/fedd/exp_access_db |
| 271 | |
| 272 | # How users name testbeds |
| 273 | mapdb: /users/faber/fedd/exp_map_db |
| 274 | |
| 275 | # Standard experiment instantiation software |
| 276 | fedkit: /usr/local/etc/fedd/fedkit.tgz |
| 277 | |
| 278 | }}} |
| 279 | |
| 280 | The [FeddDatabases#ExperimentControlComponentAccessDB experiment control accessDB] in `/users/faber/fedd/exp_access_db` would look like: |
| 281 | |
| 282 | {{{ |
| 283 | # bwilson |
| 284 | fedid:5bf3384e2cefca6ba8718958e488fe8bcbf1da2c->bwilson |
| 285 | fedid:5bf3384e2cefca6ba8718958e488fe8bcbf1da2c->(ddos,bwilson) |
| 286 | # jhickey |
| 287 | fedid:29f0436dac012086ca50fe31afb7d746268aefce->jhickey |
| 288 | fedid:29f0436dac012086ca50fe31afb7d746268aefce->(emulab-ops,jhickey) |
| 289 | fedid:29f0436dac012086ca50fe31afb7d746268aefce->(routing,jhickey) |
| 290 | fedid:29f0436dac012086ca50fe31afb7d746268aefce->(worm,jhickey) |
| 291 | }}} |
| 292 | |
| 293 | and the [FeddDatabases#ExperimentNameMappingDB name mapping DB] in `/users/faber/fedd/exp_map_db` would look like: |
| 294 | |
| 295 | {{{ |
| 296 | deter:https://users.isi.deterlab.net:23235 |
| 297 | ucb:https://users.ucb.deterlab.net:23235 |
| 298 | }}} |
| 299 | |
| 300 | Other files on `users` and all files on `boss` would be unchanged from the previous configuration. |
| 301 | |
| 302 | There are other possible layouts, but hopefully these have highlighted the use of the various [FeddConfig configuration parameters] and their related [FeddDatabases databases]. |