Downloading and Installing fedd

This section describes how to get a copy of fedd for your testbed and install it. After this you will need to configure it.

Fedd is released under the GENI Public License

Fedd Roles: Experiment Control and Access Control

Fedd can act in two ways:

Experiment controller

The central coordinator for creating and managing a federated experiment

Access Controller

Responsible for negotiating access to local testbed resources. It both maps the user into the local access control and manipulates local resources.

Which role a fedd will act in depends on the configuration of the fedd. A single testbed is likely to run both an access controller to make its resources available to others and an experiment controller to create experiments for its local users. However, there is no requirement that experiment controllers run on testbed infrastructure. A trusted experiment controller may run on a desktop or elsewhere, as long as there are access controllers are willing to grant resources to three-level names that are anchored to its fedid.

What machines should run fedd

Under fedd version 2.0 or later, the experiment controller - the fedd that accepts user requests- may run on any machine. It will be asserting ​three-level names so it is intuitive to colocate a controller that will be asserting identities from a given testbed, but not required. Any host with a ​fedid can assert them, of course.

The following discussion applies to the access controllers running on emulab-style testbeds.

Depending on what sorts of resources you intend to make available to others and what modifications you are willing to make to your testbed, you may choose to run a fedd access controller in different configurations, with functionality partitioned between users and boss.

If you intend to allow an access controller to either create projects from whole cloth, or to modify the access rights of projects or keys of users, at least some of fedd will have to run on boss. You can choose to run a fedd install on boss only, or run the main instantiation of fedd on users and the project manipulation functionality on boss. This depends on your particular comfort level with outside access to boss. Fedd's local accesses are all encrypted and controlled via fedids, and potentially by SSL as well.

If you intend to only allow federation through static projects, fedd can run entirely on users, and need only be installed there.

Fedd also needs to run a modified ns2 parser to split experiments. DETER exports an interface to that parser at https://users.isi.deterlab.net:23235 , and the simplest configuration choice is to simply make use of that service. Should you choose to get the patches from us and run your own modified ns2 parser, you would probably want to run that service on your ops node.

The examples page has a concrete set of example layouts and appropriate configurations.

Downloading and Installing the tar file

The easiest way to get a copy of fedd installed on your machine is to download the python distutils tar file and install it. The current version is fedd-3.01.tar.gz​. Older sources are attached to this page.

You will need to have the following python packages installed as well.

• ZSI
• M2Crypto
• MySQLdb

Versions of M2Crypto before 0.18 will require

• pyasn1

Emulabs generally have MySQLdb installed already. All of the components above also have FreeBSD packages and ports, which can simplify installation.

Finally, if you are creating federated experiments, the graphviz package needs to be installed to generate legacy visualization information. Boss already will have this installed on most Emulab installs. This requirement will disappear in a future release.

Once those packages are installed, the following commands will install fedd:

$ tar xzf -C /tmp fedd-3.00.tar.gz
$ cd /tmp/fedd-3.00
$ sudo python ./setup.py install
$ cd 
$ sudo rm -rf /tmp/fedd-3.00

Your install will include the python package called federation and the following scripts:

/usr/local/bin/confirm_sshkey.py

used in certain static project installs, see configuring

/usr/local/bin/exp_access_db.py

application to simplify creating experiment creation databases

/usr/local/bin/fedd.py

fedd itself

/usr/local/bin/fedd_client.py

legacy fedd command line access

/usr/local/bin/fedd_create.py

creates federated experiments

/usr/local/bin/fedd_ftopo.py

returns a general logical to physical mapping

/usr/local/bin/fedd_image.py

generates images of federated topologies

/usr/local/bin/fedd_info.py

provides general information about federated experiments

/usr/local/bin/fedd_multiinfo.py

provides general information about multiple experiments

/usr/local/bin/fedd_multistatus.py

provides summary information of the status of experiments accessible by this user

/usr/local/bin/fedd_new.py

gets a new federated experiment reservation without attaching resources to it

/usr/local/bin/fedd_ns2topdl.py

converts an ns2 representation of an experiment to a topdl one

/usr/local/bin/fedd_spewlog.py

monitor the process of creating an experiment

/usr/local/bin/fedd_terminate.py

ends an experiment

/usr/local/bin/fedd_client.py

command line tool for accessing fedd services

/usr/local/bin/fedid.py

command line tool for getting fedids from X509 certificates

/usr/local/bin/user_to_project.py

used in dynamic project installs, see configuring

These scripts are documented in more detail on the commands page.

DRAGON install

If you are installing a DRAGON access controller, you must also download and install the ​OSCARS configuration software. The DRAGON project provides ​detailed instructions for doing that.

Additional scripts

If you intend to use dynamic project manipulation, you will need to install patched versions of the addpubkey and grantnodetype scripts on boss. These patches extend those commands to revoke access/keys or confirm the presence of access or keys.

The patches are here:

• addpubkey​
• grantnodetype​

To avoid inadvertently interfering with testbed operation, we suggest making modified shadow commands on boss called taddpubkey and tgrantnodetype. Note the leading 't' on the shadow commands. You can do this by doing the following on boss (where the patch files come from wherever you saved them):

$ cd /tmp
$ cp /usr/testbed/sbin/addpubkey .
$ patch < addpubkey.patch
$ sudo mv addpubkey /usr/testbed/sbin/taddpubkey
$ sudo chown root:wheel /usr/testbed/sbin/taddpubkey
$ sudo chmod 4755 /usr/testbed/sbin/taddpubkey

$ cd /tmp
$ cp /usr/testbed/sbin/grantnodetype .
$ patch < grantnodetype.patch
$ sudo mv grantnodetype /usr/testbed/sbin/tgrantnodetype
$ sudo chown root:wheel /usr/testbed/sbin/tgrantnodetype

Note that taddpubkey will be setuid root (just like addpubkey is) and that grantnodetype will not. The permissions need to match those of the original command. They will fail with different ones.

Once the scripts exist, make sure you configure the [allocate] section of the configuration file to use them, e.g.:

[allocate]
addpubkey: /usr/testbed/sbin/taddpubkey
grantnodetype: /usr/testbed/sbin/tgrantnodetype

See the configuration section for more detail.

Federation Kit

The federation kit includes the software that provides the shared environment in the federated experiment. It is described in more detail in the overview of the system. The version we primarily use is available for download​. Download it, put it somewhere that fedd can read it, like /usr/local/etc/fedd and set the fedkit parameter in the [experiment_control] section of the config file to be the pathname of the tar file.

Subversion access

If you prefer to live more dangerously, you can download a recent tree from the subversion repository on this site and install it. The same packages must be installed as for the tar file version. The commands to check out a local copy from the subversion repository and install from it are:

$ svn checkout http://fedd.isi.deterlab.net/svn/fedd/trunk some_dir
$ cd some_dir
$ make dist
$ cd dist

And from there, install from the tar file in dist, as above.

You can also browse the source on the web.