= 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 [source:fedd/trunk/README 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 [FeddAbout#GlobalIdentifiers:Three-levelNames three-level names] that are anchored to its [FeddAbout#GlobalIdentifiers:Fedids 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 [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Three-levelNames 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 [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Fedids 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 [FeddConfigExamples 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 [attachment:fedd-3.01.tar.gz 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 (version [http://sourceforge.net/projects/pywebsvcs/files/ZSI/ZSI-2.0/ 2.0] - 2.1a is incompatible) * M2Crypto (requires [http://www.swig.org/ swig]. Most package systems will fetch and install swig as well) * MySQLdb Versions of M2Crypto before 0.20 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 [FeddConfig 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/fedid.py`:: command line tool for getting fedids from X509 certificates `/usr/local/bin/user_to_project.py`:: used in dynamic project installs, see [FeddConfig configuring] These scripts are documented in more detail on the [FeddCommands commands page]. === DRAGON install === If you are installing a DRAGON access controller, you must also download and install the [https://wiki.internet2.edu/confluence/display/DCNSS/Java+Client+API OSCARS] configuration software. The DRAGON project provides [https://wiki.internet2.edu/confluence/display/DCNSS/Java+Client+API 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: * [attachment:addpubkey.patch addpubkey] * [attachment:grantnodetype.patch 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 [FeddConfig 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 [FeddAbout#TheFederationKit overview of the system.] The version we primarily use is available for [attachment:fedkit.tgz 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 [FeddConfig#ExperimentControlOptions 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/wsdl/trunk wsdl $ 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. The build scripts expect the wsdl interface descriptions to be in {{{../wsdl }}} relative to the source directory. SOAP/Web Services interface code is generated from those files. When the tarfile is used, the generated files are included, so the {{{wsdl}}} directory is not delivered. You can also browse the source [source:/fedd/trunk on the web].