|
|
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](Security Policies) and
|
|
|
[Administrative Policies](Administrative Policies) for important additional
|
|
|
information.
|
|
|
|
|
|
### 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](mailto:testbed-approval@flux.utah.edu).
|
|
|
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
|
|
|
receive email.
|
|
|
|
|
|
### 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
|
|
|
supercomputer.
|
|
|
|
|
|
### 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. |