Commit a56b4bd8 authored by Leigh Stoller's avatar Leigh Stoller

My first cut at document reorganization! Many new things. Many things

deleted. Many things changed.
parent 649139a0
......@@ -19,7 +19,7 @@ include $(TESTBED_SRCDIR)/GNUmakerules
#
# Generate a list of all the files we want to install from the current
# directory and the source directory.
#
#
FILES = $(wildcard *.css *.jpg *.gif *.html *.php3)
FILES += $(wildcard $(SRCDIR)/*.css)
FILES += $(wildcard $(SRCDIR)/*.jpg)
......@@ -31,6 +31,12 @@ PIXFILES = $(wildcard $(SRCDIR)/pix/*.jpg)
PIXFILES += $(wildcard $(SRCDIR)/pix/*.gif)
DOCFILES = $(wildcard $(SRCDIR)/doc/*.html)
DOCFILES += $(wildcard $(SRCDIR)/doc/*.jpg)
DOCFILES += $(wildcard $(SRCDIR)/doc/*.gif)
TUTFILES = $(wildcard $(SRCDIR)/tutorial/*.html)
TUTFILES += $(wildcard $(SRCDIR)/tutorial/*.jpg)
TUTFILES += $(wildcard $(SRCDIR)/tutorial/*.gif)
#
# Kill the directory part of the names. The vpath rule will do the rest.
......@@ -38,9 +44,11 @@ DOCFILES = $(wildcard $(SRCDIR)/doc/*.html)
ALLFILES = $(notdir $(FILES))
ALLPIXES = $(notdir $(PIXFILES))
ALLDOCS = $(notdir $(DOCFILES))
ALLTUTS = $(notdir $(TUTFILES))
install: $(addprefix $(INSTALL_WWWDIR)/, $(ALLFILES)) \
$(addprefix $(INSTALL_WWWDIR)/pix/, $(ALLPIXES)) \
$(addprefix $(INSTALL_WWWDIR)/tutorial/, $(ALLTUTS)) \
$(addprefix $(INSTALL_WWWDIR)/doc/, $(ALLDOCS))
$(INSTALL_WWWDIR)/%: %
......
<html>
<head>
<title>Utah Network Testbed - Policy</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
<link rel='stylesheet' href='tbstyle-doc.css' type='text/css'>
</head>
<body>
<center>
<h1>
Overview of the Authorization Scheme, Policy, <br> and "How To Get Started"
</h1>
</center>
<h1>Overview of the authorization scheme, policy, and how to</h1>
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>How do I get started?</h3>
<p>
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
......@@ -20,8 +27,8 @@ 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>
<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
......@@ -31,15 +38,14 @@ 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.
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.
<p>
Within a week 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.
<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.
......@@ -48,80 +54,71 @@ 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.html">FAQ</a>. -->
<p>
In the future we will enable the leader to provide a list of
project members.
More detailed information on this
process can be found in the <a href="faq.html">FAQ</a>.
<h3>Another way of saying the same thing</h3>
If you didn't understand that, try this.
<p>
If you didn't understand that, then how about this. Use this set of
Web pages:
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> 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");
</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>
<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>
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>
<p>
If you think this sounds bad, try getting access to a telescope
or supercomputer.
<p>
<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>
<h3>A mini-FAQ</h3>
<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
<li><h4>Someone told me to join their project. How do I do that?</h4>
<p>
Go to the 'Join 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>
<li><h4>I'm already a testbed user, but I'm collaborating with
another project. Can I join that project too?</h4>
<p>
Yes, if that project leader approves you.
Do the appropriate stuff on the 'Join a Project' page.
</p>
Do the appropriate stuff on the 'Join Project' page.
<li><h3>I've been approved. How do I use my account?</h3>
<p>
<li><h4>I've been approved. How do I use my account?</h4>
<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.
......@@ -132,14 +129,15 @@ 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 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.
</p>
<li><h3>You still haven't answered my question. Who can I ask?</h3>
<p>
<li><h4>You still haven't answered my question. Who can I ask?</h4>
<p>
You can try the other web pages for the testbed, located on the
<a href="http://www.cs.utah.edu/flux/testbed/">testbed
......@@ -148,13 +146,16 @@ homepage</a>, or in the
documentation</a>. After checking those, you may
<a href="mailto:testbed-ops@flux.cs.utah.edu">
send e-mail to testbed-ops@flux.cs.utah.edu</a>.
</p>
</ul>
<hr>
<address>testbed-www@flux.cs.utah.edu<br>
Last modified on Mar 10, 2001</address>
</body>
<address>
<a href=\"mailto:testbed-ops@flux.cs.utah.edu\">
Testbed Operations (testbed-ops@flux.cs.utah.edu)</a>
<br>
Last modified on Mar 10, 2001
</address>
</body>
</html>
<html>
<head>
<title>Utah Network Testbed - Tutorial</title>
<link rel='stylesheet' href='../tbstyle2.css' type='text/css'>
</head>
<body>
<h1>Utah Network Testbed - Tutorial</h1>
<h3>Logging Into the System</h3>
<p>
First of all, make sure you have
an account on the Utah Network Testbed. Log in via the
<a href="https://www.emulab.net/tbdb.html">Testbed Web Interface.</a>
If you don't yet have an account, don't worry--
the login page contains detailed information about obtaining and
verifying an account.
</p>
<h3>Designing a Network Topology</h3>
<p>
The Utah Network Testbed's power lies in its ability to assume many
different topologies; the description of a such a topology is a necessary
part of an experiment.
</p>
<p>
The Utah Network Testbed uses the "NS" ("Network Simulator")
format to describe network topologies.
This is substantially the same
<a href="http://www.scriptics.com/software/tcltk/">Tcl</a>-based
format used by <a href="http://www.isi.edu/nsnam/ns/">ns-2</a>.
Since the Utah Network Testbed offers emulation,
rather than simulation, these files are interpreted in a somewhat
different manner than ns-2.
Therefore, some ns-2 functionality may work
differently than you expect, or may not be implemented.
If you feel there is useful functionality missing, please let us know.
Also, some
<a href="nscommands.html">testbed-specific commands</a>
have been added. These begin with "#TB";
they will be ignored as comments by ns utilities outside of the testbed.
In short, most NS files should work on both the Testbed and ns-2, most
of the time.
</p>
<p>
For those unfamiliar with the NS format, here is an example.
Let's say we are trying to create a test network which looks like
the following:
<br>
<img src="vlanpic.png">
<br>
(A is connected to B, B to C, and B to D.)
<br>
An NS file which would describe such connectivity is as follows:
</p>
<pre>
# begin example.ns
# This is a simple ns script. Comments start with #.
set ns [new Simulator]
</pre><p class="comment">First, define some nodes:</p><pre>
set NodeA [$ns node]
set NodeB [$ns node]
set NodeC [$ns node]
set NodeD [$ns node]
</pre><p class="comment">Second, make some links between them,
specifying bandwidth, latency, and queue type:</p><pre>
$ns duplex-link $NodeA $NodeB 100Mb 60ms DropTail
$ns duplex-link $NodeB $NodeC 100Mb 30ms DropTail
$ns duplex-link $NodeB $NodeD 100Mb 40ms DropTail
</pre><p class="comment">If you are running FreeBSD or Linux on any nodes
you can set the IP addresses like this:
</p><pre>
#TB set-ip-interface
</pre><p class="comment"> For instance, the next line sets the IP address
of node B on the port going to node C:</p><pre>
#TB set-ip-interface NodeB NodeC 192.168.42.42
</pre><p class="comment"><i>Note: The initial '#' is required to insure that 'ns'
will ignore these testbed-only commands.</i></p>
<p class="comment"> The Testbed software will choose IP addresses for you, but you can choose
them if you prefer. It is generally a good idea to have every link from
any given node be on a different subnet, and to have both ends of a link
on the same subnet.</p><pre>
$ns run
# end example.ns
</pre>
<p>Another example ns script that shows off using the power of Tcl to generate
topologies is <a href=example.ns>here</a>.
</p>
<h3>Beginning the Experiment</h3>
<p>
After logging on and validating to the Testbed Web Interface,
choose "Begin an Experiment." Fill in the Name and Long Name fields.
In the "Your NS file" field, place the <i>local path</i> of a NS file
which you have created to describe your network topology. This file
will be uploaded through your browser when you choose "Submit."
</p>
<p>
After submission, the testbed interface will begin processing your
request. This could take a few minutes, depending on how many nodes you
are using and what other features (such as delay nodes and bandwidth limits)
you are using. Once processing is done, the interface will present you with
a list of nodes allocated for the experiment.
</p>
<p>
If you use the above .NS file, you should get a set of allocated nodes similar
to this (physical machine names will likely be different:)
</p>
<pre>
Node Mapping:
Virtual Physical
-------------------- --------------------
delay1 tbpc15
A tbpc16
delay2 tbpc21
B tbpc19
C tbpc11
D tbpc18
delay0 tbpc07
IP Addresses:
Node IFC Destination IP
-------------------- -------------------- --------------------
B eth0 C 192.168.42.42
B eth2 A 192.168.2.2
A eth0 B 192.168.2.3
C eth0 B 192.168.42.2
D eth0 B 192.168.3.2
B eth1 D 192.168.3.3
</pre>
<p class="comment">
Notice that three "delay nodes" have been allocated to accomodate the
60ms/30ms/40ms delay times, as specified in the .NS file.
</p>
<h3>So now you have your nodes...</h3>
<h4>Logging in</h4>
<p>
For each node allocated for an experiment,
a clean operating system is installed, the node is rebooted,
and all members of your Project are given login accounts.
Your username and password for testbed machines
will be the same as the one you use on the web interface.
You may also use this username and password to log on to
<code>ops.emulab.net</code> through ssh.
Nodes are configured by default to run <code>sshd</code>;
From <code>ops.emulab.net</code>, you can then log in using <code>ssh <i>machinename</i></code>.
(<code>tbpc15</code> is one machinename in the above example.)
If you are concerned about ssh traffic interfering with an experiment,
or if you have configured a machine to run an operating system which does not
support incoming ssh connections, log in to <code>ops</code> and run
<code>tip <i>machinename</i></code>, which communicates directly with a machine's
serial port. The standard FreeBSD and Linux installations listen for logins
on this port.
</p>
<p>
Once you are logged in, use <code>/usr/local/bin/sudo</code> to run commands as root (if your account was given permission to do so by your project leader.)
</p>
<h4>Powercycling Nodes</h4>
<p>
Nodes may be rebooted or powered off using local commands on the
machine, if available. In addition, machines are connected to a power controller,
accessable through <code>ops.emulab.net</code>.
While logged into <code>ops.emulab.net</code>,
use the commands
<code>power on <i>machinename</i></code>,
<code>power off <i>machinename</i></code>, and
<code>power cycle <i>machinename</i></code> to control power to your nodes.
</p>
<h4>Reconfiguring Node Operating Systems</h4>
<p>
Each PC on the testbed has three hard disk partitions.
One partition contains Redhat Linux 6.2, another FreeBSD 4.0, and the last
can be loaded with an operating system of your choice.
Unless specified otherwise in the .NS file, normal nodes will default to Linux, while
delay nodes must run FreeBSD.
</p>
<p>
Node operating systems can be initially configured using the following command
in a .NS file:
</p>
<pre>
#TB <a href="nscommands.html#set-node-os">set-node-os</a> <i>nodename</i> <i>imagename</i>
</pre>
<p class="comment">
(<i>nodename</i> is the machine name you're using in your NS file.
</p>
<p class="comment">
<i>imagename</i> is <code>RHL62-STD</code>, <code>FBSD40-STD</code>, or an image of your own devising.)
</p>
<p>
Node operating systems can also be changed while an experiment is underway,
via the web interface. Go to the
"Experiment Information" page, select your experiment, then select the
name of a machine from the list of those allocated for that experiment.
This will bring up the Node Control Center.
In the box labeled "Def boot image" choose <code>RHL62-STD</code> or <code>FBSD40-STD</code>,
or an image of your own devising (this is documented elsewhere.)
Submit the change, and if all goes well, the node will be reconfigured.
The changes will take effect next time the machine is rebooted.
</p>
</body>
</html>
\ No newline at end of file
<html>
<head>
<title>Utah Network Testbed - Web Interface FAQ</title>
<title>Utah Network Testbed - FAQ</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
</head>
<body>
<h1>Utah Network Testbed - Web Interface FAQ</h1>
<h1>Utah Network Testbed - FAQ</h1>
<ul>
<li> Web Interface
<ul>
<li> to gain authorization to use the testbed, either as
</ul>
<li>
</ul>
<hr>
<h2>
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
......@@ -15,11 +25,11 @@ of at least 800x600 to avoid excessive scrolling.
<p>
</ol>
<hr>
<address>testbed-www@flux.cs.utah.edu<br>
Last modified on Oct 27, 2000</address>
</body>
Last modified on Mar 8, 2001</address>
</body>
</html>
<html>
<head>
<title>Emulab - Hardware Overview</title>
<link rel='stylesheet' href='tbstyle-doc.css' type='text/css'>
</head>
<body>
<center>
<h1>
Hardware Overview
</h1>
</center>
<ul>
<li>40 PC nodes (<b>tbpc01-40</b>), consisting of:
<ul>
<li> 600MHz Intel Pentium III "Coppermine" processors.
<li>
<a
href="http://www.asus.com/Products/Motherboard/Pentiumpro/P3b-f/index.html">
Asus P3B-F (6 PCI/1 ISA slot)</a> motherboard (old reliable BX chipset).
<li> 128MB PC100 ECC SDRAM.
<li> 5 Intel EtherExpress Pro/100B 10/100Mbps Ethernet cards.
<li> <a href="http://www.storage.ibm.com/hardsoft/diskdrdl/desk/ds34gxp.htm">
13GB IBM 34GXP DPTA-371360 7200RPM IDE</a> hard drive.
<li> Floppy drive
<li> Cheap video card (Jaton Riva 128ZX AGP w/4MB video RAM)
<li> All in a nice but overweight rackmount case on rails:
<a href = "http://www.antec-inc.com/product/cases/en_rack.html">
Antec IPC3480B</a>, with 300W PS and extra fan.
</ul>
<p>
<li>160 <a href = "http://www.research.digital.com/SRC/iag/">
Compaq DNARD "Sharks"</a> as edge nodes. 233 Mhz StrongARM processors,
32M memory, 10Mbps ethernet, diskless.
Runs NetBSD and custom kernels (OSKit, etc.)
<p>
<li> a server (<b>users.emulab.net</b>), consisting of:
<ul>
<li> Dual 500MHz Intel Pentium III cpus
<li> <a href="http://developer.intel.com/design/servers/l440gx/index.htm">
Intel L440GX+</a> motherboard (the GX+ chipset)
<li> 512MB PC100 ECC SDRAM
<li> 90 GB disk space: 5
<a href="http://www.quantum.com/products/hdd/atlas_iv/atlas_iv_overview.htm">
Quantum Atlas IV 18GB 7200RPM Wide LVD SCSI</a> hard drives
<li>64 port
<a href="http://www.cyclades.com/dat-z.html">
Cyclades-Ze PCI Multiport Serial Board</a>
<br><em>Soon</em> 64 more ports.
</ul>
<p>
<li> 3 <a href = "http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/c6000_ds.htm">
Cisco 6509 high-end switches</a>. Two function as the "testbed backplane," each filled with a
<a href = "http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/6nam_ds.htm">
Network Analysis Module</a>
and seven 48-port 10/100 ethernet modules,
giving 336 100Mbps ethernet ports on each.
The third 6509 functions as the core router for the testbed and
is configured with an assortment of router hardware
and software, Gigabit ethernet, OC-12 ATM (~600Mbps), and more
10/100 Ethernet ports. A fourth 6509 provides expansion room.
<!-- Another, but no pix: http://www.cisco.com/univercd/cc/td/doc/pcat/ca6000.htm -->
<p>
<li>10 APC MasterSwitch AP9210 8 port power controllers.<br>
(The AP9210 is discontinued; replaced in the product line by the
<a href="http://www.apc.com/products/masterswitch/index.cfm">AP9211</a>.)
<p>
<li>10 <a href = "http://www.wrightline.com/products/freestnd.htm">
Wrightline "Tech I" racks</a>: 44U, 34" deep, 8 are 19" wide, 2 are
24" with cable management.<br>
<p>
</ul>
<p><h2>Layout</h2><p>
The first 4 ethernet ports of each PC node are connected to one of the
big Cisco switches.
All 160 ports can be connected in arbitrary ways by setting up VLANs
on the switches by using <a href = "snmpit.html">snmpit</a>.
Cisco 6500 Switch backplane bandwidth is supposed to be near 50Gb/s.
<!-- but we've heard rumors that it's worse. -->
<p>
The fifth ethernet port is connected to another Cisco 6509. They
each have full duplex 100Mbps connections. These are for dumping
data off of the nodes and such, without interfering with
the experimental interfaces. The only impact on the node is
processor and disk use, and bandwidth on the PCI bus.
<p>
The DNARD Sharks are also attached to the big Cisco switch by way of a
8+2 10/100 ethernet switch from Asante. Each shelf of 8 sharks
is capable of generating up to 80Mbps, and shares one
100Mbps link to the Cisco.
<hr>
<address>
<a href=\"mailto:testbed-ops@flux.cs.utah.edu\">
Testbed Operations (testbed-ops@flux.cs.utah.edu)</a>
<br>
Last modified on Mar 10, 2001
</address>
</body>
</html>
......@@ -27,12 +27,5 @@
server certificate, be sure to accept it.
</em>
</center>
<p>
More info is available on 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>
testbed pages.
</body>
</html>
<html>
<head>
<title>Utah Network Testbed - Policy</title>
<link rel='stylesheet' href='tbstyle.css' type='text/css'>
<link rel='stylesheet' href='tbstyle-doc.css' type='text/css'>
</head>
<body>
<center>
<h1>Administrative Policies</h1>
</center>
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.
<h2>Acceptable Use, Allocation Priority, Reporting, Governance, Disclaimer</h2>
......@@ -73,14 +79,18 @@ 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.
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 31, 2000</address>
<address>
<a href=\"mailto:testbed-ops@flux.cs.utah.edu\">
Testbed Operations (testbed-ops@flux.cs.utah.edu)</a>
<br>
Last modified on Mar 10, 2001
</address>
</body>
</html>
<html>
<head>
<title>Emulab - Pubs and Talks</title>
<link rel='stylesheet' href='tbstyle-doc.css' type='text/css'>
<base href='http://www.cs.utah.edu/flux/testbed/'>
</head>
<body>
<center>
<h1>
Publications and Talks
</h1>
</center>
<h3>Documents:</h3>
<ul>
<li> <a href = "glossy.pdf"> A one-page "glossy" testbed overview</a>
</ul>
<h3>Talks:</h3>
<ul>
<li> SIGCOMM'99 New Research Session,
in <a href = "sigcomm99-wip.ppt">Powerpoint</a> and
<a href = "sigcomm99-wip/index.htm">HTML</a> formats.
<li> SOSP'99 Work-in-progress talk,
in <a href = "sosp99-wip.ppt">Powerpoint</a>
and <a href = "sosp99-wip/index.htm">HTML</a> formats.
<li> Utah CHPC Cluster workshop slides, with lots of goofy pictures,
in <a href = "testbed-chpc.ppt">Powerpoint</a> and
<a href = "testbed-chpc/index.htm">HTML</a> formats.
</ul>
<hr>
<address>
<a href=\"mailto:testbed-ops@flux.cs.utah.edu\">
Testbed Operations (testbed-ops@flux.cs.utah.edu)</a>
<br>
Last modified on Mar 10, 2001
</address>
</body>
</html>
<html>
<head>
<title>Security</title>
<link rel='stylesheet' href='tbstyle-doc.css' type='text/css'>
</head>
<body>
<center>
<h1>
Security Issues
</h1>
</center>
Here is a brief rundown of some important security issues you should
be aware of.
<h3>Cookies</h3>
<p>
To enhance operation and security, we make use of a "Cookie" that
holds your login name. Therefor, you will need to enable cookies on
your browser. Please contact us if you have questions about how to do
that in your browser.
<h3>SSL</h3>
<p>
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>SSH</h3>
We require all users to use Secure Shell (SSH) to log into Emulab
nodes.
<h3>Accounts</h3>
<p>
We make use of Unix user and group mechansisms to provide protection
between users and projects. Each new user gets a new Unix UID, and
each new project gets a new Unix GID. Users are members of the Unix
groups that correspond to each of the projects they are working on,
and thus may share files with other members of those projects. The
default directory permissions are set so that project files are not
readable by members of other projects.
<p>
Each project gets its own directory hierachy (again, protected by the
Unix group mechanism) that is NFS-exported only to that project'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.
<html>
<head>
<title>Emulab - Software Overview</title>
<link rel='stylesheet' href='tbstyle-doc.css' type='text/css'>
</head>
<body>
<center>
<h1>
Software Overview
</h1>
</center>
<ul>
<li><b>users.emulab.net</b>: Control node, NFS server, serial line server
<p>
Runs FreeBSD 3.4-STABLE. This is the main server machine for
the testbed and is where home directories and all project files
live. While most of the Testbed configuration process is done via
the Web interface, a few things must be done while logged into
users.emulab.net. These Testbed specific commands and programs are