Commit 9caf0f7a authored by Jay Lepreau's avatar Jay Lepreau
Browse files

real stuff now

parent 32315484
<html>
<head>
<title>Utah Network Testbed - Policy</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
<!-- <base href='https://www.emulab.net/' target='dynamic'>
-->
</head>
<body>
<h1>Overview of the authorization scheme, policy, and how to</h1>
<h3>How do I get started?</h3>
Briefly, you use the links at your left to create and join
<em>projects</em>. Typically, someone who will be the <em>project
leader</em> requests permission from Testbed Ops/Admin, via the web
interface, to <em>create</em> 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.
<p>
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.
<p>
Within a week, say, you will receive email from the testbed admin
folks, either approving or denying your project.
<!-- XXX login to web interface and ops node, or has web interface
login enablement already happened? Clarify below. -->
You will then be able to login to the testbed.
<p>
People working on the project
(students, staff, etc.) will request permission from the project
leader, also via the web interface, to <em>join</em> the project.
These requests can precede project approval; they will be queued.
Once project members have been authorized by the leader, they can log onto the
testbed ops node to start an experiment, reserving and
configuring nodes as necessary.
<!--
More detailed information on this
process can be found in the <a href="faq.html">FAQ</a>. -->
<p>
In the future we will enable the leader to provide a list of
project members.
<h3>Another way of saying the same thing</h3>
If you didn't understand that, try this.
<p>
Use this set of Web pages
<ul>
<li> to gain authorization to use the testbed, either as
<ul>
<li> a project leader ("principal investigator" in academic
parlance) who is starting a new project
("start project"), or
<li> as a worker bee in a particular project ("join project");
</ul>
<li> as a project leader, to approve or deny pending project members;
<li> to authenticate ("login") to the Web-based testbed services.
</ul>
<p>
When your project or membership request is approved or denied you will
receive email.
<h3>Seems awfully complicated</h3>
It should be a lot easier in practice than it sounds.
<p>
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.
<p>
If you think this soounds bad, try getting access to a telescope
or supercomputer.
<p>
We are certainly open to suggestions, however, and already plan
to improve the interface in a number of ways.
<h2>A mini-FAQ</h2>
<ul>
<li><h3>Someone told me to join their project. How do I do that?</h3>
<p>
Go to the 'Join a Project' page, fill out the
form, and wait for the project leader to approve you. When
approved you will receive an email message saying so,
and you can then log into the Testbed.
<!-- Not implemented:
Your project leader will
control how much access you have to Testbed resources, within
the limits given to the project as a whole.
-->
</p>
<li><h3>I'm already a testbed user, but I'm collaborating with
another project. Can I join that project too?</h3>
<p>
Yes, if that project leader approves you.
Do the appropriate stuff on the 'Join a Project' page.
</p>
<li><h3>I've been approved. How do I use my account?</h3>
<p>
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.
<p>
You will also receive an account on the operations machine
"ops.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.
</p>
<li><h3>You still haven't answered my question. Who can I ask?</h3>
<p>
You can try the other web pages for the testbed, located on the
<a href="http://www.cs.utah.edu/flux/testbed/">testbed
homepage</a>, or in the
<a href="http://www.cs.utah.edu/flux/testbed/doc/">testbed
documentation</a>. After checking those, you may
<a href="mailto:testbed-ops@flux.cs.utah.edu">
send e-mail to Testbed Ops</a>(testbed-ops@flux.cs.utah.edu).
</p>
</ul>
<hr>
<address>testbed-www@flux.cs.utah.edu<br>
Last modified on Oct 27, 2000</address>
</body>
</html>
<html>
<head>
<title>Utah Network Testbed - Policy</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
<!-- <base href='https://www.emulab.net/' target='dynamic'>
-->
</head>
<body>
<h1>Administrative Policies</h1>
<h2>Acceptable Use, Allocation Priority, Reporting, Governance, Disclaimer</h2>
Our current and anticipated policies follow. We expect these to
evolve as experience demands, and we are open to constructive
suggestions concerning them.
<h3>Acceptable Use</h3>
In principle, almost any research or experimental use of the testbed
by experimenters that have a need for it is appropriate.
<p>
"Abuse" of the facility or its other users, in any form, will of course
result in termination of access. Abuse includes using the facility
for other than a project's stated purpose.
<h3>Allocation Priority</h3>
When the testbed become oversubscribed we will be allocating its
resources based on some function-- currently vague but in roughly
this order-- of
perceived research value and broader impact,
the testbed's uniqueness as a suitable platform for the research,
novelty as a testbed application,
resources required (typically: number of nodes),
experimenters' contribution to testbed software development,
experimenters' lack of access to other appropriate facilities,
sponsorship by our primary sponsors (currently NSF and Cisco),
educational value,
affiliation with an academic institution,
whether the project is funded/peer-reviewed,
and for commercial users, their willingness to help defray costs, i.e., pay.
<p>
Many development-oriented commercial experiments and evaluations will
be allowed, but low priority.
<h3>Reporting</h3>
In order to assess the testbed's impact and report to our sponsors, we
simply require notice of all publications or patents to which the testbed
contributed. Formal acknowledgement in such publications is required
as well. Finally, we will be soliciting feedback and suggestions from
our users.
<h3>Governance</h3>
An administrative board, including representatives from our major
sponsors, will be involved in setting broad policy and have review
authority. Typically, a small executive committee composed of members
from the University of Utah Flux research group will decide most
resource allocation issues.
<p>
A Technical Advisory Board is also being formed, containing distinguished
members of the network and distributed systems research communities.
<h3>Disclaimer</h3>
We are providing broad access to the testbed in the hopes that it will
be useful, but we do so WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<p>
We disclaim all liability from errors in results or security breaches
resulting from the testbed's use. The system is currently not even at
"alpha" level and will be undergoing rapid development for some time.
We are making some effort to provide inter-project security, but users
must realize that security is unlikely in
i) such a new and rapidly evolving system,
ii) where users have such complete control over hardware and software resources,
and
iii) in such a public facility that will attract attack.
<hr>
<address>testbed-www@flux.cs.utah.edu<br>
Last modified on Oct 27, 2000</address>
</body>
</html>
<html>
<head>
<title>Utah Network Testbed - Operations Home</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
<base href='https://www.emulab.net/' target='dynamic'>
</head>
<body>
<h1>Testbed Operations</h1>
<head>
<title>Utah Network Testbed - Operations Home</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
<!-- <base href='https://www.emulab.net/' target='dynamic'>
-->
</head>
<body>
<h1>Testbed/Emulab Operations</h1>
This is the Web-based operational interface to the testbed.
For information on the testbed itself, see the
For details on the testbed itself and why it's special, see the
<a href = "http://www.cs.utah.edu/flux/testbed/">base</a> and
<a href = "http://www.cs.utah.edu/flux/testbed/doc/">documentation</a> pages.
<p>
OUTLINE
Policy
Authorization Scheme
What is it?
Raw hardware and management and configuration tools.
In practice, provide some default software that many users
may want. But fundamentally, the software you run on it,
including all bits on the disks, is up to you.
What do users get?
Home dir on login node.
<h2>Overview of the authorization scheme and policy</h2>
<h2>Policy</h2>
<ul><b>Appropriate Use:</b>
In principle, almost any research or experimental use of the testbed
by experimenters that have a need for it is appropriate.
To protect data you submit, SSL is used to encrypt data as it
is transferred accross the Internet. Therefore, you will need to
access these pages with a browser that supports SSL. We recommend
Netscape 4.0 or later, or presumably a recent IE, and also recommend a
screen resolution of at least 800x600 to avoid excessive scrolling.
<h3>What is it?</h3>
<!-- XXX find hardware page -->
<a href = "http://www.cs.utah.edu/flux/testbed/doc/">Raw hardware</a>--
lots of it-- with configuration and management tools.
<!-- lots of them. [not yet so many] -->
During an experiment's time slots, the experiment (and associated researchers)
get exclusive use of the
assigned machines, including root access if desired. Until we finish designing
and building smarter scheduling and state-saving software, and obtain the
disk space, scheduling is manual and done at course granularity
(days).
<p> We provide some default software (e.g. Linux and
FreeBSD on the PCs, NetBSD on the Sharks) that many users may want.
But fundamentally, the software you run on it, including all bits on
the disks, is replaceable and up to you. The same applies to the network's
characteristics, including its topology: configurable by users.
<h3>A few hardware and usage details, please</h3>
Right now: a FreeBSD operations node with 90 GB of disk space,
on which all users get full Unix accounts, ssh-accessible from the world.
40 PCs each with 5 100 Mbit cards and a 13 GB disk, plus 160
StrongARM-based "Sharks," all connected by 2 miles of cable thru high
end Cisco switches. Full details available on the
<!-- XXX check this URL -->
<a href = "http://www.cs.utah.edu/flux/testbed/doc/">hardware page</a>.
<p>
When our resources become oversubscribed we will be allocating
resources based on some currently vague function of perceived research
value, resources required (typically number of nodes and weirdness
of software), the testbed's uniqueness as a suitable platform for the
research,
When an experiment's machines are active, appropriate Unix accounts
are also provided on those nodes.
sponsorship by our primary sponsors (currently NSF and Cisco),
affiliation with an academic institution, funded project,
and for commercial users, ability to pay.
<h3><a href = "policies.html">Administrative Policies and Disclaimer</a></h3>
Most any legitimate research/experimental use is allowed, including
use by companies. Of course, when demand exceeds supply we will have
to assign priorities to projects, but the hardware base will be expanding.
Many commercial users would also be allowed
<h3><a href = "auth.html">Authorization Scheme, Policy, and "How To Get Started"</a></h3>
It's hierarchical: 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.
<h3>Notes on security</a></h3>
<!-- <a href = "security.html"> -->
Use this set of pages
<ul>
<li> to gain authorization to use the testbed, either as
<ul>
<li> a project leader ("principal investigator" in academic
parlance) starting a new project ("start project"), or
<li> as a worker bee in a particular project ("join project");
</ul>
<li> as a project leader, to approve or deny pending project members;
<li> to authenticate ("login") to the Web-based testbed services.
</ul>
<p>
Each project gets a unique Unix group and its own protected subtree on
the ops node. That subtree is NFS-exported only to that group's
assigned test machines. We don't currently protect against spoofing
on the control network, so there are vulnerabilities. The test networks
are fully separated between experiments by way of VLANs.
When your project or membership request is approved or denied you will
receive email.
<h3>How to contact Testbed Ops</h3>
<h2>How do I get started</h2>
Briefly, you use the links at your left to create and join
<em>projects</em>. Typically, a project leader will request
permission from Testbed Ops, via the web interface, to
<em>create</em> a project. Then, people working on project
(students, staff, etc.) will request permission from the Project
Leader, also via the web interface, to <em>join</em> the project.
Once project members have been authorized, they can log onto the
Testbed interface to start an experiment, reserving and
configuring nodes as necessary. More detailed information on this
process can be found in the <a href="faq.html">FAQ</a>.
<h2>How to contact Testbed Ops</h2>
For questions or problems, send email to
<a href="mailto:testbed-ops@flux.cs.utah.edu">
Testbed Ops (testbed-ops@flux.cs.utah.edu)</a>.
<p>
For questions or problems, send email to
<a href="mailto:testbed-ops@flux.cs.utah.edu">
Testbed Ops (testbed-ops@flux.cs.utah.edu)</a>.
<p>
</body>
<hr>
<address>testbed-www@flux.cs.utah.edu<br>
Last modified on Oct 27, 2000</address>
</body>
</html>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment