All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

Commit 6bd26211 authored by Kevin Atkinson's avatar Kevin Atkinson

Removed web pages that are now in the WIKI. See MOVED-TO-WIKI.

parent 6bdf04b5
This diff is collapsed.
Copyright (c) 2000-2003, 2005 University of Utah and the Flux Group.
All rights reserved.
Overview of the Authorization Scheme, Policy, <br> 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.
<h3>Who can start a project?</h3>
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
<a href="">
Emulab Approval Committee</a>. See the next section for the
reasoning behind this rule.
<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.
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 <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 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
<a href="faq.php3">Emulab FAQ</a>.
<h3>Another way of saying the same thing</h3>
If you didn't understand that, then how about this. Use this set of
Web pages:
<li> to gain authorization to use the testbed, either as
<li> a project leader ("principal investigator") who is
starting a new project ("start project"), or
<li> as a worker bee in a particular project ("join project");
<li> as a project leader, to approve or deny pending project members;
<li> to authenticate ("login") to the Web-based testbed services.
When your project or membership request is approved or denied you will
receive email.
<h3>Seems awfully complicated</h3>
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.
<h3>I've been approved. How do I use my account?</h3>
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
"", and from there will be able to access the test
nodes' serial line consoles via 'console' as well as access console log
# Copyright (c) 2000-2008 University of Utah and the Flux Group.
# All rights reserved.
# Standard Testbed Header
<h3>Getting Started on the Testbed</h3>
<p>These documents are highly recommended reading for all Emulab users.</p>
<dt><b><a href="docwrapper.php3?docname=auth.html">
How to get an account on the Testbed</a></b></dt>
<dd>Starting or joining projects, authorization, and policies.</dd>
<dt><b><a href="tutorial/docwrapper.php3?docname=tutorial.html">
Emulab "Getting Started" Tutorial</a></b></dt>
<dd>The basics of creating experiments, and a quick intro to frequently
used features, avoiding common pitfalls, and quick solutions to the
most common problems people encounter.</dd>
<dt><b><a href="faq.php3">
Frequently Asked Questions (FAQ)</a></b></dt>
<dd>Probably our most important reference document. Check here before
asking for help. Includes sections on "Getting Started" on Emulab,
using the testbed, hardware setup, software setup, security issues,
and troubleshooting. Over 50 questions and answers.</dd>
<dt><b><a href="doc/docwrapper.php3?docname=plab.html">
Emulab PlanetLab Interface</a></b></dt>
<dd>Documentation for our interface to PlanetLab.</dd>
<h3>Reference Material</h3>
<li><b><a href="tutorial/docwrapper.php3?docname=tutorial.html#Advanced">
Emulab Advanced Tutorial</a></b>
<li><b><a href="tutorial/docwrapper.php3?docname=advanced.html">
Emulab Advanced Example</a></b>
# Link to kb-search through $TBBASE (https:), not $TBDOCBASE (http:).
# On https:, the browser sends HashCookie, so we get CHECKLOGIN_LOGGEDIN
# status. Going via http:, we get CHECKLOGIN_MAYBEVALID, and can't know
# whether to show admin KB entries.
echo "<li><b><a href=\"$TBBASE/kb-search.php3\">\n
Search or Browse the Emulab Knowledge Base</a></b>\n";
<li><b><a href="tutorial/docwrapper.php3?docname=nscommands.html">
Emulab-specific NS Extensions Reference Manual</a></b>
<li><b><a href = "xmlrpcapi.php3">Emulab's XML-RPC interface reference</a></b>
<li><b><a href = "docwrapper.php3?docname=swapping.html">
Node Usage Policies and "Swapping" Experiments</a></b>
<li><b><a href = "doc/docwrapper.php3?docname=netbuilddoc.html">
NetBuild Reference Manual</a></b>
<li><b><a href = "docwrapper.php3?docname=security.html">
Security Issues</a></b>
<li><b><a href = "docwrapper.php3?docname=groups.html">
About Project Groups</a></b>
<li><b><a href = "doc/docwrapper.php3?docname=internals.html">
Emulab Internals</a></b>
<li><b><a href = "doc/docwrapper.php3?docname=hw-recommend.html">
Want to build your own Testbed?</a></b>
<li><b><a href = "hardware.php">
Current Hardware Overview</a></b>
<li><b><a href = "docwrapper.php3?docname=software.html">
Current Software Overview</a></b>
<li><b><a href = "docwrapper.php3?docname=policies.html">
Administrative Policies and Disclaimer</a></b>
<li><b><a href = "docwrapper.php3?docname=sponsors.html">
Emulab Sponsors</a></b>
<li><b><a href = "news.php3">
Current and Past Emulab News Items</a></b>
<li><b><a href = "doc/docwrapper.php3?docname=ChangeLog.txt">
Changelog/Technical Details</a></b>
<li><b><a href = "pubs.php3">
Papers and Talks</a></b>
<a name="tutorial">
<h3>SIGCOMM Tutorial</h3>
You might also find it helpful to look through the tutorial given at
SIGCOMM '02 by Jay Lepreau, Robert Ricci, and Mac
Newbold, entitled "How To Use the Netbed (Emulab++) Network Testbeds."
<li><b>Slides</b> from the tutorial are available in
<a href = "">
PowerPoint Format</a>,
and as PDFs, with
<a href = "">
2 slides per page (full color)</a>, and
<a href = "">
6 slides per page (greyscale)</a>.
<li><b>Tutorial files</b> such as NS files for the experiments, are available
as a
<a href = "">
tarball</a>, or
<a href = "">
<font size=-2>
# Standard Testbed Footer
Copyright (c) 2005 University of Utah and the Flux Group.
All rights reserved.
<h1>Motes on E-Motes</h1>
<li> <a href="#INTRO">Introduction</a>
<li> <a href="#HARDWARE">Hardware</a>
<li> <a href="#SPECIFICATION">Specification in NS Files</a>
<li> <a href="#PROGRAMMING">Programming Motes</a>
<li> <a href="#SERIAL">Serial Consoles</a>
<li> <a NAME="INTRO"></a>
The <a href="/tutorial/mobilewireless.php3">mobile wireless testbed</a>
includes two static nodes hosted on
<a href="">E-Mote</a>
Ethernet gateways. This document describes how these devices fit into the
larger Emulab system.
<li> <a NAME="HARDWARE"></a>
The static motes in Utah's emulab are hosted on E-Motes. E-Motes (also known
as the MIB600CA) from <a href="">Crossbow</a> provide three
key features:
<li>They have a power supply that comes from the power grid, so there is no
need to worry about battery life on the attached mote.</li>
<li>They provide the ability to reprogram the attached mote over Ethernet -
thus you don't need to worry about wedging your motes, we can simply
reprogram them to recover them to a known state.</li>
<li>They export the mote's serial console to a TCP port. This opens up
several possibilities. First, it means that you can use any of them as base
stations to gateway between the Internet and your mote network. Second, it
provides a back channel over which to send commands to the motes or extract
data from them.</li>
The overall goal of the second two features for us is to provide something
analogous to our PCs'
<a href="/tutorial/docwrapper.php3?docname=tutorial.html#ControlNet">control
<h3>Specification in NS Files</h3>
Since motes in Emulab are hosted on other nodes such as E-Motes and Stargates,
you must specify two nodes in your NS file: the mote itself and its host. A
mote specification in your NS file may look something like this:
<blockquote style="border-style:solid; border-color:#bbbbbb; border-width: thin">
set inky [$ns node]
set inkyhost [$ns node]
tb-set-hardware $inky mica2
tb-set-hardware $inkyhost motehost
tb-fix-node $inky $inkyhost
tb-set-node-os $inky TinyOS-CntRfm
This code asks for a Mica2 mote, which we name <code>inky</code>, and places it
on a host called <code>inkyhost</code>. By giving the generic type
<code>motehost</code>, we are saying that we don't care what this mote is
attached to. If we wanted an e-Mote, we could have set the type to
<code>emote</code>, or <code>garcia</code> if we wanted it hosted on a robot.
The <code>tb-set-node-os</code> command sets the image to be loaded on the node
- we'll cover that in the next section.
If you want to get a specific mote, use the <code>tb-fix-node</code> to fix the
mote's host. For example, if we wanted to put <code>inkyhost</code> on the
emote named <code>em1</code>, we would use <code>tb-fix-node $inkyhost em1</code>.
<li> <a NAME="PROGRAMMING"></a>
<h3>Programming Motes</h3>
Uploading your own code to run on the motes is easy. Just build your TinyOS app
normally (ie. '<code>make mica2</code>'). Then, upload the binary that gets
placed in <code>build/mica2/main.srec</code> to our
<a href="/newimageid_ez.php3?nodetype=mote">mote image
creation page</a>. This page will ask you for a 'descriptor'. This
descriptor can then be used in <code>tb-set-node-os</code> lines in your
NS files, and your app will be automatically loaded on the appropriate mote(s).
At this time, we don't have a TinyOS installation on the Emulab servers, so
you'll need to have a TinyOS installation to build from on your desktop
machine, or some other machine you control. We hope to provide a way for you
build TinyOS apps on Emulab in the near future. Also, at the current time, all
of our motes have radios in the 900MHz band, so see the TinyOS
<a href="">CC1000
radio document</a> to make sure you're tuning the radios to the right band.
When you inevitably make changes to your code, you can simply place the new
kernel in the path that was automatically constructed for you by the image
creation page; the next time you use that OS in an NS file, the new version
will be loaded. If you'd like to load your node code onto your motes without
starting a new experiment, you have two options:
<li> <code>os_load</code> allows you to load an kernel that has already been
defined as an image, as above. You give it the image descriptor with its
<code>-i</code> argument, and you can either give the physical names of all
motes you want to reload, or a <code>-e pid,eid</code> argument to reload
all nodes in the given experiment.
<li> <code>tbuisp</code> allows you to load a file directly onto your motes
without having to register it as an image. This can be a quick way to do
development/debugging. Just pass it the operation <code>upload</code>, the
path to the file you wish to load, and the physical names of your motes.
Both of these are commands in /usr/testbed/bin on They are
also available through our
<a href="/xmlrpcapi.php3">XML-RPC interface</a>, so you
can run them from your desktop machine to save time - the file given as an
argument to tbuisp is sent with the XML-RPC, so you don't need to copy it onto
our servers.
<li> <a NAME="SERIAL"></a>
<h3>Serial Consoles</h3>
The serial consoles on your motes can be reached by connecting to TCP port
10002 of the E-Mote. You can do this, for example, with <code>telnet</code>, or
with the TinyOS SerialForwarder program. The E-Mote is configured to talk to
the mote at 57600 baud.
Copyright (c) 2000-2008 University of Utah and the Flux Group.
All rights reserved.
<h3>Classes that have used Emulab:</h3>
<!-- In Firebird at least, the stupid colon between the </b> and the <br> prevents
an extraneous blank line from being displayed after the header. Jeez! Should
check on other browsers, but I bet that's why Chad did it this way.
<!--COMP8320 <br>--><b>Auburn University</b>:<br>
<a href="">COMP8320 Research Topics in Computer Networks</a>
<!--NIUNet <br>--><b>Baylor University</b>:<br>
<a href="">"Now I Understand Networking" Project</a>
<!--CMUDDE Spring 2004 <br>--><b>Carnegie Mellon University</b>:<br>
<!--SE17-654 Fall 2004 <br>-->
<a href="">Analysis of Software Artifacts</a>
<a href="">18-846/17-654 Dependable Distributed Middleware Systems (Dependable Distance Education)</a>
<!--cs184net2 <br>--><b>George Washington University</b>:<br>
<a href="">CS184 Networks II Class Project</a>
<!--HMC_CS134 <br>--><b>Harvey Mudd College</b>:<br>
<a href="">CS134 Advanced Operating Systems</a>
<a href="">CS147 Computer Systems Performance</a>
<b>Mills College</b>:<br>
<!-- MCS-Security, Fall 04 -->
<a href="">MCS180 Network Security</a>
<img src="/new.gif" alt="[NEW]">
<!--MIT-829 <br>--><b>MIT</b>:<br>
<a href="">6.829 Computer Networks Class Project</a>
<!--Distribclass <br>--><b>Mount Holyoke College</b>:<br>
<a href="">CS341 Distributed Systems Class Project</a>
<!-- xxx URL goes to a PDF file; needs fixing -->
<!--CS590D <br>--><b>Purdue University</b>:<br>
<a href="">CS50D Security Topics in Networks and Distributed Systems</a>
<img src="/new.gif" alt="[NEW]">
<!--HAPPY Fall 2004 <br>-->
<a href="">CS590T: Insider Threats to Information Systems </a>
<!--CN4 <br>--><b>Technical University Darmstadt</b>:<br>
<a href=>Performance of Communication Networks (Communication Networks 4)</a>
<!--TempleCIS662 <br>--><b>Temple University</b>:<br>
<a href="">CIS662 Networking</a>
<!--CIS662 (sic) <br>--><b>University of Delaware</b>:<br>
<a href="">CIS659 Introduction to Network Security</a>
<a href="">CIS859 Advanced Topics in Network Security</a>
<img src="/new.gif" alt="[NEW]">
<!--MMNetworking <br>--><b>University of North Carolina-Chapel Hill</b>:<br>
<a href="">COMP249 Multimedia Networking</a>
<a href="">COMP290 Research Topics in Networking</a>
<b>University of Washington</b>:<br>
<a href="">CSE 481g P2P Distributed Systems Capstone</a>
<a href="">CSEP 590A Distributed Systems</a>
<!--cs740Project <br>--><b>University of Wisconsin-Madison</b>:<br>
<a href="">CS740 Evaluating Network Inference Tools</a>
This diff is collapsed.
This diff is collapsed.
Copyright (c) 2000-2002 University of Utah and the Flux Group.
All rights reserved.
<h1>Introduction to Netbuild</h1>
<h2>Basic usage:</h2>
<li>To create a Node, click and drag the "new node" icon in the
palette (the left panel) to the work area (the middle panel.)</li>
<li>To link two nodes together, click one node, then hold "ctrl" and
click the node you want to link it to.</li>
<li>To create a LAN, click and drag the "new LAN" icon in the palette
to the work area.</li>
<li>To link a node to a LAN, click the node, then hold "ctrl" and
click on the LAN you want to link it to (or vice versa.)</li>
<li>Note that you may not link a LAN directly to a LAN.
<li>Nodes and LANs may be moved around the work area by clicking and
dragging them.</li>
<li>Nodes, links, and LANs may be eliminated by dragging them into the trash.</li>
<li>Little circles between links and nodes represent the network
interface on that node, and may not be moved or eliminated (though
eliminating the attached link will get rid of them.)</li>
<li>When your experiment topology has been built, clicking "create
experiment" will take you into the testbed experiment creation
page; from there, you may view the generated NS file as well as create
an actual experiment.</li>
<li>Clicking a single item in the work area will select it.</li>
<li>Clicking a single item while holding down shift will add it to the
pool of selected items (unless it was already selected, then it will
become deselected.)</li>
<li>Clicking an empty part of the canvas will deselect everything.</li>
<li>Clicking an empty part of the canvas and dragging will create a
selection rectangle. When the mouse button is released, all items in
the rectangle will be selected.</li>
<li>When multiple items are selected, clicking one selected item and
dragging it will drag all selected items.</li>
<li>When multiple items are selected, clicking one selected item and
dragging it into the trash will eliminate all selected items.</li>
<li>When one item is selected, a properties view will open in the
rightmost panel. This is where properties, including name, may be
<li>Invalid characters typed into a properties text box will be
<li>If a property is "&lt;auto&gt;," it will automatically be determined in
the experiment creation process. Change this to specify your own value
for the property.</li>
<li>Clicking "default" will reset the property of the adjoining box to
its default value (in many cases "&lt;auto&gt;.")</li>
<li>If multiple items of the same type are selected, some boxes may
show up as "&lt;multiple&gt;." This means that the value of this property is
different between at least two nodes in the selection. Changing such a
property value (or setting it to default) will result in <i>all</i>
selected nodes assuming the new value for that property. Some
properties (such as name and IP address) may not be set simultaneously
in this way.</li>
<li>If multiple items of varying types are selected, the property
boxes will still appear on the right, but may be in a collapsed state.
Clicking the '+' will expand one of these.</li>
<li>Clicking the '-' on an expanded box will collapse it again.</li>
<li>Click "copy selection" to make a duplicate of the current
Copyright (c) 2007 University of Utah and the Flux Group.
All rights reserved.
<h1>The "pc2000" Nodes</h1>
<li> <a href="#machines">Machines and Interfaces</a>
<li> <a href="#images">Images and Kernel Support</a>
<li> <a href="#caveats">Caveats</a>
<a NAME="machines"></a><h2>Machines and Interfaces</h2>
The "pc2000" machines are
<a href="">
Dell Precision Workstation 340s</a>
with a single 2GHz processor, 512MB of RAMBUS RAM, and 2 7,200&nbsp;RPM 20GB IDE disks.
Each has 4 available 100Mb experimental net interfaces in the form of 2
dual port Intel Pro/100 PCI cards.
Each node also has a single Intel IXP1200 Network Processor in the form of
an ENP2505 (Bridalveil) card.
See the
<a href="../tutorial/docwrapper.php3?docname=ixp.html">
Emulab IXP document</a> for details on how these are integrated into Emulab.
All machines have serial console lines accessible from via
the "console" command or remotely via the
<a href="">tiptunnel</a> interface.
<a NAME="images"></a><h2>Images and Kernel Support</h2>
Currently, the Emulab standard FreeBSD images prior to FreeBSD 7
and Linux images (RHL90-STD, FC4-STD, "legacy" RHL73-STD)
will run on these machines.
<b>NOTE:</b> at this time, only the RHL73-IXPHOST image has IXP support.
The IXP will be ignored in all other kernels
(see <a href="#caveats">Caveats</a> below).
For custom images, no special drivers are needed
if you do not want to use the IXP devices.
<a NAME="caveats"></a><h2>Caveats</h2>
<li> <b>Windows does not run on these nodes.</b>
We have never been able to make a Windows system work on these,
possibly because of the IXP cards.