We use a hierarchical structure: we authorize a project under a principal
investigator (e.g. a faculty member) and delegate authority to that person
to authorize the project's members-- and accountability for their
behavior. Please read our Security Policies and
Administrative Policies for important additional
Who can start a project?
In general, a faculty member or well-known senior staff member must start
each project. Students cannot lead projects unless they have had prior
approval by the Emulab Approval Committee.
See the next section for the reasoning behind this rule.
How do I get started?
Briefly, you use the Signup button on the Emulab front page to create
and join projects. Typically, someone who will be the project leader
requests permission from Testbed Ops/Admin, via the web interface, to
create a project. In academic parlance, a project leader is a "principal
investigator." That person is expected to be someone who is responsible,
whose position is more or less verifiable by us, and is therefore
accountable. Specifically, the project leader is held responsible for the
actions of members of his/her project.
For example, if you are a grad student who "owns" a project and no faculty
member is really involved, normally you should still get your advisor or
other professor to be the project leader. Exceptions could include your
being a senior student well-known in the research community. If you are not
a student, but a senior/core member of an open source project, either you
or someone more official in the project should be leader, as
appropriate. If you are in a research lab and are not brand new there, you
would probably be the project leader.
Typically, after an hour to a day later, or up to week (rarely), you will
receive email from the testbed administrators, either approving or denying
your project. You will then be able to really use the testbed: you will be
able to perform various functions through the Web interface and through a
Unix login account.
People working on the project (students, staff, etc.) will request
permission from the project leader, also via the web interface, to join
the project. These requests can precede project approval; they will be
queued. Once project members have been authorized by the leader, they can
use the Web interface and their Unix login to start and run experiments,
reserve and configure nodes, etc.
Another way of saying the same thing
If you did not understand that, then how about this. Use this set of Web pages:
to gain authorization to use the testbed, either as
a project leader ("principal investigator") who is starting a new
project ("start project"), or
as a worker bee in a particular project ("join project");
as a project leader, to approve or deny pending project members;
to authenticate ("login") to the Web-based testbed services.
When your project or membership request is approved or denied you will
Seems awfully complicated
Experience shows that it is far easier in practice than it sounds.
We need accountability. However, we want to avoid slowing things down by
checking every user-- thus we delegate that authority to the PI's. Since
the PI (project leader) has so much authority, we need more info from them,
such as their postal address.
If you think this sounds bad, try getting access to a telescope or
I've been approved. How do I use my account?
The first step would be to come back here and log in to the Web
interface. That will update the list of options in the dropdown menus. You
might be authorized to start projects or experiments, or maybe just to use
the nodes in an experiment. Either way, your options will show up in the
menus. Those will normally include starting a new "experiment" which
leads to reserving a set of nodes, which leads to automatic creation of
Unix accounts on those nodes for all members in your project. You will be
able to use ssh to log into those machines.