Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Becomingaprotogenisite


Becoming a ProtoGENI Site

Becoming a ProtoGENI Site

This page describes the process of integrating a working Emulab installation into the ProtoGENI federation.

Emulab Software

Must update to latest Emulab software release. Unfortunately that requires your boss and ops to be updated to freebsd 6.3. Our new Trac wiki has extensive upgrade and installation instructions.

The protogeni subsystem has its own installation script that creates various certificates and registers them at the clearinghouse. Local resources are also registered at the clearing house. Also some new ports are installed and some configuration files are modified. It's mostly automatic, with a few minor tasks that need to be done by the testbed administrator. Takes about 5 minutes. More detailed instructions are available about running the ProtoGENI software either standalone (on a normal Emulab), or within an Emulab-in-Emulab environment.

Trust Model

Web of trusted roots. Each site has the complete set of root certificates from all of the members of the federation. The bottom line is that anyone in the federation implicitly trusts any certificate (or credential) from anyone else in the federation. Rights to do things are defined in the actual credentials. As new sites are added, a daemon running on each Boss will download a new set of root certificates.

See details about Protogeni's authentication implementation.

Interface to ProtoGENI

Each boss runs two trusted XMLRPC servers. One implements the Slice Authority API and the other is the Component Manager API. The CM is actually an aggregate component manager.

Each user who wants to use the geni interfaces creates a password protected ssl certificate via the Emulab web interface. If not obvious, only registered emulab users at one of the federation sites can use the geni APIs. You then use your favorite xmlrpc client to talk to the servers; we prefer python cause its really easy to write a client program. The source code has a bunch of test programs that demonstrate how to do this and use the APIs. There is also a detailed Tutorial to help you get started.


A "sliver" can consist of local cluster nodes, including vlan links between them, cluster nodes at different sites with gre tunnels between then, and planetlab nodes.

Unlike Emulab experiments, raw geni nodes are just that, raw. None of the emulab setup is done on those nodes, like experimental interfaces initializing interfaces with IP addresses, building accounts for other project members, starting programs automatically with the event system, etc. This will eventually be supported in the "cooked" interface.


The clearinghouse runs at Utah. The clearinghouse has a record of all of the slices created, and list of all resources, but does not currently record sliver creations or implement other clearinghouse functions (which are actually not well defined in the spec yet).

The ClearingHouse API is accessible by anyone holding a valid ProtoGeni certificate (registered with an Emulab site in the ProtoGeni federation).

Slice Authority

Each federate runs a Slice Authority RPC server, accessible by locally registered users of that federate.

Component Manager

Each federate runs a Component Manager RPC server, accessible by anyone with the appropriate credentials.


We have implemented a few simple policies that federates can apply to remote users. It is ultimately up to a federate whether they want to grant a specific ticket (promise of resources); the policies we have implemented so far are by no means a complete set, and it's possible for federates to implement their own policies if they wish.

  • Individual nodes may be prevented from being viewed and allocated by remote users
  • All access for remote users can be turned off (eg. during times of high local need, such as near the end of a semester)
  • The total number of nodes allocated to remote users can be limited

User Management

The Geni architecture is somewhat ambiguous on how to deal with user management. In order to make ProtoGeni easy to use, we have added APIs that allow users to be bound to slices, as well as ssh key distribution. Users may be bound to a slice at both the Slice Authority and the Component manager, by anyone holding a valid credential for the slice. Being bound to a slice means that you can control the slice, and that an account will be created for that user on each node in the sliver. In addition, a set of ssh keys may be passed to the Component Manager when binding a user. These keys will be placed in the user's .ssl directory on each node in the sliver. Please see the test scripts in the protogeni/test directory for examples.

Emergency Shutdown

A rudimentary form of emergency shutdown has been implemented. Anyone holding a slice credential can request a shutdown at the Slice Authority for the slice. There is also an administrative interface (read: perl script) that can be invoked at the Slice Authority, or on the clearinghouse. More details can be found in in the ClearingHouse API document.

Firewalled Slivers

Firewalled slivers have been implemented using Emulab's existing firewall support. When requested to do so in the rpsec (using an undocumented flag), the wrapper experiment for the sliver will include a firewall that will block all but essential ports from traversing onto the Internet.

Fixing Problems

If you are actively modifying your ProtoGENI system on top of Emulab, you may run into situations where the ProtoGENI database gets into an inconsistent state. We've developed a few tools and techniques for fixing such problems and releasing locked resources. See RepairingEmulabProtoGENI for details.

Pieces that need more work

  • The SA does not register new users yet. Only existing Emulab users can use the federation.
  • Primitive resource discovery. Simply a ptop (Rob defines this) xml file of free nodes and their network interfaces. Also the features list for each node.
  • Its prototype prototype, so its all very fragile. We have to do a lot more robustness work.
  • Very little logging and statistics gathering.
  • Slice update is only partially done.