Overview of the Authorization Scheme, Policy,
and "How To Get Started"

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.

How do I get started?

Briefly, you use the links at your left 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 admin folks, 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.

More detailed information on this process can be found in the Emulab FAQ.

Another way of saying the same thing

If you didn't understand that, then how about this. Use this set of Web pages:

When your project or membership request is approved or denied you will receive email.

Seems awfully complicated

Experience shows that it's 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.

We are certainly open to suggestions, however.

  • 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 side bar. 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 side bar. 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.

    You will also receive an account on the users' master host "users.emulab.net", and from there will be able to access the test nodes' serial line consoles via 'tip' as well as access console log files.