Commit bf2ad9b5 authored by Robert Ricci's avatar Robert Ricci
Browse files

Remove some old files that are about things that don't even exist

any more!
parent 20e4dd56
From: Leigh Stoller <stoller@fast.cs.utah.edu>
To: "Dorsch, Matthew D." <mddorsch@tasc.com>
Cc: Testbed Project <testbed@fast.cs.utah.edu>
Subject: RE: Scheduling a test for all 40 PC nodes
In-Reply-To: <85BBA452EB26D511B388009027283DC16CE461@ntrema50.read.tasc.com>
References: <85BBA452EB26D511B388009027283DC16CE461@ntrema50.read.tasc.com>
X-Mailer: VM 6.92 under Emacs 20.7.1
FCC: ~/mail/outgoing
--text follows this line--
> From: "Dorsch, Matthew D." <mddorsch@tasc.com>
> Subject: RE: Scheduling a test for all 40 PC nodes
> Date: Fri, 22 Jun 2001 11:25:55 -0400
>
> Is there a particular command availble to the NS file that would
> instruct the system to copy our image to the extra partition then boot it?
> The available docs indicate it is possible to boot my own image, but do not
> indicate the process for this.
Many parts of the custom OS support are in place, but there are still some
pieces missing. In addition, 40 nodes presents a special challenge because
of the amount of bandwidth needed to load 40 multigigbyte images.
First off, you use an NS command (an extension we added) to tell the system
what OS to boot. For example:
tb-set-node-os $nodeA RHL62-STD
Where RHL62-STD is what we call an OSID. There are several builtin OSIDs
(for our linux and freebsd images, and a few others). You will create an
OSID of your own to describe your custom OS. There is a web interface to do
this:
https://www.emulab.net/newosid_form.php3
It has not been used by anyone outside our group, so please let us know if
its confusing. The OSID you pick needs to be globally unique, and it will
let you know if you have picked something that is already used.
The OSID describes the OS. Next you need to describe the actual disk
image. We call that an IMAGEID :-) There is supposed to be a web interface
to do that, but I have not had time to gen one up. Basically, the IMAGEID
says where the disk file lives (usually in /proj), where to load it on the
disk (what slices, how many slices), and most importantly, what OSID is on
each slice. When the node boots, our first level boot program talks to the
testbed database to find out what slice to boot from. As you have probably
guessed, the tb-set-node-os command tells what OSID, and the IMAGEID maps
that to a particular slice on each node. If the web interface is not in
place by the time you get this far, I'll just stick the info in by hand for
you. Lets say you end up calling your OSID "RHL62-SANDS" and your IMAGEID
"SANDS-RHL62-IMAGE."
Okay, now you have your image loaded on one of our testbed machines and its
all ready to go. The thing to do now is snapshot the disk (or slice) using
our FS compression utility. Basically, this is a domain specific
compression program that knows how to read the linux filesystem, and
compress all of the allocated blocks, and skip all the unallocated blocks.
When you get this far, I will describe how to create this snapshot.
Once you have the snapshot, we have a special kernel that knows how to lay
the image back onto the disk, and its how we can load our 6.5 gig image in
just 88 seconds! The backend script to do that is called os_load, and you
invoke it like this:
os_load SANDS-RHL62-IMAGE pc34
You would use this command only to test that the image is created properly
and loading okay, by starting an experiment with a single node, running the
os_load, and then checking to see that it worked okay by rebooting (You can
change the OSID for a node after an experiment starts via the web
interface).
Now you are ready to put it all together. You would do this in your NS
file:
tb-set-node-os $nodeM RHL62-SANDS
One of two things will happen at this point. Either one of us will preload
your image on all 40 nodes, or we will add the little bit of glue that
takes your tb-set-node-os command and autoloads the image on the nodes that
get allocated to the experiment. This isn't that hard to do, but to do it
so that the switch and network are not overwhelmed is slightly more
challenging. But, we will figure something out by then. Promise!
Note to testbed. I'm archiving this message in doc/custimage.txt
Lbs
----------------------------------------------------------------------
Conventions:
Any line beginning with # should be ignored as a comment.
Lists are always space separated.
A labelvalue is either:
label: value
OR
label=
multi-line value
.
.
.
=
----------------------------------------------------------------------
Basic Layout:
The file is divided into a hierarchical array of sections bracketed with:
START <section>
END <section>
Sections can be within sections and no order is imposed.
----------------------------------------------------------------------
Sections:
Topology: describes the base desired topology of the network.
START topology
START nodes
# <node> <type> <links>
# <node> refers to a string name that should be easily mappable
# to a physical machine (IP address, hostname, etc.)
# <type> is usually "pc", "dnard", or "delay"
# <links> is a space separated list of link ids
END nodes
START links
# <link> <src> <srcport> <dst> <dstport> <bandwidth_min> <bandwidth_max> <delay_min> <delay_max> <loss_rate>
# <link> is a unique link identifier.
# <src> and <dst> are node identifiers (or lans).
# <srcport> and <dstport> are integers. A port of -1 indicates that
# this information is N/A or unknown.
# <bandwidth*> and <delay*> are optional. They specify the boundaries of
# bandwidth and delay.
# <loss_rate> is the rate of loss. If omitted assumed to be 0.
END links
START lans
# <lan> "<nodes>" <bw> <delay> <links>
# <lan> is a lan identifier and also acts as a node identifier for the
# purposes of links.
# <nodes> is a space seperated list of nodes
# <bw> is the bandwidth of the LAN
# <delay> is the latency of the LAN
END lans
END topology
Virtual: Describes the mapping of virtual objects to physical objects
START virtual
START nodes
# <virtual node> <physical node>
# <virtual node> is a string identifying a node in the virtual network.
# <physical node> is a node identifier
END nodes
START links
# <virtual link> <physical links>
# <physical links> is a space separated list of physical links making
# up the virtual link.
END links
START lans
# <virtual lan> <physical nodes>
END lans
END virtual
NodeInfo: Describes each physical node in more detail.
START nodeinfo
# This is a number of records of the form:
# node <node>
# labelvalue
# .
# .
# .
# end
#
# Existing labels are:
# type - the type of the node
# events - a multi-line field describing events in the form
# <time> <type> <parameters>
# links - redundant with topology
# delays - multiline spec of delay forwarding of the format:
# <port1> <port2> <bandwidth> <delay> <drop>
#
# Existing events are:
# down
# up
# reboot
# downinterface
# upinterface
END nodeinfo
LinkInfo: Describes each physical link in more detail.
START linkinfo
# Similar to nodeinfo.
# link <link>
# ...
# end
#
# Labels:
# src, dst, srcport, dstport - redundant with topology
END linkinfo
START assignment
# Information about how the mapping between physical and virtual
# seed <seed>
#
# seed is the random seed used by assign_hw.
END assignment
START vlan
# Records of the form:
# <vlan name> <mac1> <mac2> ... <macN>
# ...
#
# The contents are one vlan to each line.
# <vlan name> is usually the virtual link the vlan corresponds to.
END vlan
START events
# Records of the form:
# <offset in seconds (floating point)> <event> <arguments>
# Event types include:
# link_down <link>
# link_up <link>
# power_cycle <node>
# power_off <node>
# power_on <node>
# Future events might include traffic control, routing changes, etc.
END events
START ip
START map
# Records of the form
# <node> <dst> <ip>
END map
START mac
# Records of the form
# <mac> <ip>
END mac
END ip
START delay
# Records of the form
# <node> <bw> <delay> <loss> <macA> <macB>
# <node> is a virtual node name, <bw> is in MB, and <delay> is in ms.
# <loss> is the loss rate between 0.0 and 1.0
# <macA> and <macB> are the macs to delay between
END delay
START os
START images
# Records of the form
# <label> <path> <partition>
# These are the entries made to the disk_images table by create-os commands
END images
START nodes
# Records of the form
# <node> <label>
# One entry for every <node>. What image they should boot.
# <node> is a physical node and includes dnard number for dnards.
END nodes
END os
START cmdline
<node> <cmdline>
END cmdline
START rpms
<node> <rpms>
END rpms
START startup
<node> <runcmd>
END runcmd
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>Power Users Manual</title>
</head>
<body>
<h1>Power Users Manual</h1>
Power is a tool that uses SNMP to manage the APC Power Controllers
that are used in the Utah Testbed. It was designed to facilitate easy
control of power to the nodes in the testbed. It can turn on, turn
off, or power cycle (reboot) any machine that is plugged into an APC
power controller.
<p>
Along with power itself, there is a configuration file power.conf,
that should be found in /usr/testbed/etc/, which lists the machine
names and the IP addresses for thier power controllers and their
outlet numbers. (power itself is currently located in
/usr/testbed/bin/, and requires <a href="snmpit.html">snmpit</a> in
/usr/testbed/bin/ also)
<p>
<h3>Syntax</h3>
Syntax is as follows: (this message can be viewed by using
"<tt>power</tt>" without any parameters)
<pre>
Syntax:
power on &lt;machine> &lt;machine> ...
power off &lt;machine> &lt;machine> ...
power cycle &lt;machine> &lt;machine> ...
</pre>
<dl>
<dt><pre>power on &lt;machine> &lt;machine> ...</pre>
<dd>This command turns on the specified machines.
<dt><pre>power off &lt;machine> &lt;machine> ...</pre>
<dd>This command turns off the specified machines.
<dt><pre>power cycle &lt;machine> &lt;machine> ...</pre>
<dd>This command power cycles (reboots) the specified machines.
</dl>
Machines are specified using thier names: "<tt>tbpc01</tt>" through
"<tt>tbpc10</tt>", and "<tt>alpha</tt>" and "<tt>beta</tt>" for the
switches. Like most Unix commands, the keywords and machine names are
case-sensitive.
<h3>Power.conf Configuration File</h3>
A configuration file called "<tt>power.conf</tt>" should be found in
/usr/testbed/etc/, which should have the following format:
<pre>
#
#power.conf
#
# format:
# machine&lt;tab>PowerControlIP&lt;tab>Outlet#&lt;\n>
#Machine PowerControlIP Outlet#
tbpc01 155.99.214.100 1
tbpc02 155.99.214.100 2
tbpc03 155.99.214.100 3
tbpc04 155.99.214.100 4
tbpc05 155.99.214.100 5
tbpc06 155.99.214.100 6
tbpc07 155.99.214.100 7
tbpc08 155.99.214.100 8
tbpc09 155.99.214.99 6
tbpc10 155.99.214.99 5
alpha 155.99.214.99 7
beta 155.99.214.99 8
#
#end of power.conf
#
</pre>
As might be guessed, lines starting with "#" are comments, and the
format is simply a machine name, an IP address for its power
controller, and the outlet that it is using, all separated by tabs
(any spaces could cause incorrect results).
<p>
<address><font size=-1>
Power was written by Mac Newbold, of the Flux Research Group,
University of Utah Computer Science Dept., in April 2000.<br>
Please contact <a href="mailto:newbold@cs.utah.edu">
newbold@cs.utah.edu</a> for further information, including licensing
for use outside of the Utah Testbed, and concerning source code customization
issues.
<p>
Power &copy; 2000, Mac Newbold, Flux Research Group, Computer Science
Department, University of Utah
</font>
</address>
</body>
</html>
\ No newline at end of file
What needs to be done to get us off the ground...
Automatic VLAN configuration DONE (Mac)
Mapping algorithm DONE (Dave, Chris)
Building Steve and all
Setting up disks/systems Steve and Mike
Wiring ??? (Steve, Mac, Mike)
Monitor/Control node Steve, ???
Firewall Steve, Mac, ???
OS distribution (FTP, rsync, custom) Mike, Steve
Data recovery Mac
PR Jay
Reset Mike, Steve, Mac
Delays Rob, Chris
Events Chris and Mac
Improve assign Chris and Dave
ns to IR Rob, Chris
Monitoring software ???
Roatan Chris
Automatic traffic Kristin, Mac
Initial experiments Kristin, Mac
Extra:
Documentation Chris and Jay?
Later:
Automatic testing
Automatic routing
Automatic running
Full ns integration (includes most of above)
Publications
GUIs
Scheduler
Web Integration
Data visualization
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>snmpit/vsnmpit Users Manual</title>
</head>
<body>
<h1>snmpit/vsnmpit Users Manual</h1>
<code>snmpit</code> is a tool that uses SNMP to manage the Intel 510T
switches that are used in the Utah Testbed. Its abilities include VLAN
configuration (create, delete, [list, configure from a file]) and
configuration of port settings (enable/disable, auto-detect
speed/duplex, speed, duplex).
<p>
<code>vsnmpit</code> is a graphical interface to
<code>snmpit</code>. It does everything that snmpit does, but in a
prettier and more convenient way.
<p>
In the context of the testbed, this allows creating of the virtual
"links" in the topology using VLANs, and allows configuration of
different types of connections (100Mbps/10Mbps, Full/Half duplex), and
forcing a link to go down by disabling it on the switch.
<p>
snmpit is currently located in /usr/testbed/bin/ on plastic.
<ul>
<li><a href="#vsnmpit">vsnmpit</a>
<li><a href="#vVLAN">VLAN Setup Menu</a>
<li><a href="#vPort">Port Setup</a>
<li><a href="#voptions">Options Menu</a>
<li><a href="#snmpit">Command-line snmpit</a>
</ul>
<a name="vsnmpit"></a>
<h1>vsnmpit</h1>
<code>vsnmpit</code>, or Visual SnmpIt!, has no command line options,
and is simply run by typing <code>vsnmpit</code> or <code>vsnmpit
&</code> on the command line. When it starts, you will see this:
<p align=center>
<img src="pictures/vsnmpitopening.jpg"/>
<p>
The buttons at the top bring up their associated menus. As expected,
the Exit button in the top right corner closes vsnmpit.
(As you can see, all screen shots show vsnmpit as seen using the fvwm2
window manager, configured with red active borders.)
<a name="vVLAN"></a>
<h3>VLAN Setup</h3>
The VLAN Setup menu shows a table of all existing VLANs. In the Remove
column are buttons to select a set of VLANs to be removed. Each VLAN
also has a number and a name. Note that the Control cannot be
removed. Then each VLAN's members are listed. This shows that the
switch had 10 VLANs, that happened to make a fully connected graph of
5 nodes.
<p align=center>
<img src="pictures/vsnmpitvlan.jpg"/>
<p>
The process of removing VLANs is quite simple. First, select some
VLANs to remove. Like this:
<p align=center>
<img src="pictures/vsnmpitvlanr1.jpg"/>
<p>
Then press the Remove button, and you'll see this:
<p align=center>
<img src="pictures/vsnmpitvlanr2.jpg"/>
<p>
When it finishes, you'll get something like this:
<p align=center>
<img src="pictures/vsnmpitvlanr3.jpg"/>
<p>
The File button is used to add a set of VLANs specified in a setup
file. See <a href="#file">here</a> for details on making this file. It
is really quite simple. First, type in the file name. Here we use
<code>t1-10.i0</code>, a file that takes machines pc1 through
pc10, and adds their first interface, i0, to a VLAN. In this way,
all the machines can talk to each other on thier first interface.
<p align=center>
<img src="pictures/vsnmpitvlanf1.jpg"/>
<p>
Then it will show you this:
<p align=center>
<img src="pictures/vsnmpitvlanf2.jpg"/>
<p>
And when it finishes, the switch will be configured like this:
<p align=center>
<img src="pictures/vsnmpitvlanf3.jpg"/>
<p>
<a name="vPort"></a>
<h3>Port Setup</h3>
<p>
Choose a switch, and it will show you its ports, and the way they are
currently configured. Then make any changes you like, and hit the
update button.
</p>
<a name="voptions"></a>
<h3>Options</h3>
There are four global options for vsnmpit. They correspond with
options from snmpit. The first deals with VLANs only, and the last two
only pertain to port setup. This is what you'll see when you choose
this menu. Its pretty self explanatory. The default values are shown here.
<p align=center>
<img src="pictures/vsnmpitoptions.jpg"/>
<p>
<a name="snmpit"></a>
<h1>snmpit</h1>
<ul>
<li><a href="#syntax">snmpit Syntax</a>
<li><a href="#general">General Commands</a>
<li><a href="#VLAN">VLAN Configuration Commands</a>
<li><a href="#port">Port Control Commands</a>
<!-- <li><a href="#"></a> -->
</ul>
<a name="syntax"></a>
<h3>Syntax</h3>
Syntax is as follows: (this message can be viewed by with
"<tt>snmpit -h</tt>")
<pre>snmpit - A general purpose SNMP Tool - Version 1.1
Syntax:
snmpit [-h] [-v] -i&lt;ip>
[-u] [-l] [-m&lt;vlan name>] [-vlan&lt;MAC Addr.>]
[-f&lt;filename>] [-r&lt;vlan #> &lt;vlan #> ... ]
[+b|-b] [+c|-c] [-s] [-p&lt;port> &lt;port> &lt;x>..&lt;y> ... ]
[-d|-e] [+a|-a] [-s&lt;speed>] [-dup&lt;duplex>]
General:
-h Display this help message
-v Verbose mode (now off)
-i IP address or switch name
VLAN Control:
-u Wait for Update of VLAN tables (takes ~10 seconds)
-l List all VLANs on switch (ell, not #1)
-m Make a VLAN
-vlan Add MAC Address to VLAN
-f File mode - Automatically set up set of VLANs
-r Remove VLAN(s)
Port Control:
+b/-b Blocking mode (now off)
+c/-c Confirm Changes (now on)
-s Show Port Configurations
-p List of port numbers and ranges
-d Disable port(s)
-e Enable port(s)
+a/-a Enable/Disable Port Auto-Negotiation of speed/duplex
-spd Port Speed (10 or 100 Mbits)
-dup Port Duplex (half or full)
</pre>
<a name="general"></a>
<h3>General SnmpIt Commands</h3>
<pre>snmpit [-h] [-v] -i&lt;ip></pre>
<dl>
<dt><pre> -h Display this help message</pre>
<dd>When in doubt, use this for a full explanation of syntax.
<dt><pre> -v Verbose mode (now off)</pre>
<dd>Turns on extra output. Generally, SnmpIt won't say anything if it
did what you asked, but with this option, you can ask it for more
information. It will always give the appropriate error message when
something goes wrong, without regard to the verbose option.
<dt><pre> -i IP address or switch name</pre>
<dd>IP address of switch on which to operate. Also accepts names. The
Intel 510T switches now in use in the Testbed are the following:
<pre>Alpha/155.99.214.170
Beta/155.99.214.171
Gamma/155.99.214.172
Delta/155.99.214.173 </pre>
</dl>
<a name="VLAN"></a>
<h3>VLAN Control Commands</h3>
<pre>snmpit [-u] [-l] [-m&lt;vlan name>] [-vlan&lt;MAC Addr.>]
[-f&lt;filename>] [-r&lt;vlan #> &lt;vlan #> ... ]</pre>
<code>snmpit</code> also understands machine names and interfaces in
the format &lt;name>:&lt;interface>, such as pc1:0 or pc3:3, in
place of MAC addresses. Output of known MAC addresses will also be
converted to this format. Therefore, anywhere that a MAC address is
used, you may also supply a name/interface pair.
<dl>
<dt><pre> -u Wait for Update of VLAN tables (takes ~10 seconds)</pre>
<dd>Waits for switch to update its VLAN tables before returning. With
this option set, you may list the VLANs right after you change them,
and the new changes will be reflected. Otherwise, changes will not be
shown for several seconds after changes are made.
<dt><pre> -l List all VLANs on switch (ell, not #1)</pre>
<dd>As its name suggests, this command shows a table of all VLANs on
the switch, along with their names, numbers, and the MAC addresses
that they contain.
<dt><pre> -m Make a VLAN</pre>
<dd>This optional command takes a VLAN name as a parameter. If no name
is given when creating a VLAN, the VLAN number will be used as the name.
<dt><pre> -vlan Add MAC Address to VLAN</pre>
<dd>This is the command to make a VLAN. May be used in conjunction
with "<tt>-m</tt>". This command takes as its parameters a list of MAC
addresses. The list can include MAC addresses from any of the testbed
switches. MAC addresses are specified as 12 character
hexadecimal strings containing digits and the letters "a" through
"f". A possible command line for configuring a VLAN might be:
<pre>snmpit -i alpha -vlan 1C2B536AF27C 008b1ca721d0</pre>
This would put the network cards with MAC addresses "1C2B536AF27C" and
"008b1ca721d0" in a VLAN together, making a "link" in the topology, as
if it were hardwired with a cable. These two MAC addresses can now
only communicate with each other, whether by broadcast, unicast, or multicast.
<a name="file"/a>
<dt><pre> -f File mode - Automatically set up set of VLANs</pre>
<dd>This command takes as a parameter a file name. This file will
generally be output of the assignment algorithms used to map a virtual
topology to the physical topology of the testbed. They can also be
created by hand. The important section has the following format:
<pre>START vlan
link1 1C2B536AF27C 008b1ca721d0
link2 1073c38b28fd 283bc8a82f8c
...
&lt;name1> &lt;MAC 1> &lt;MAC 2>
&lt;name2> &lt;MAC 3> &lt;MAC 4>
...
a_b pc1:0 pc2:0
a_c pc1:1 pc3:0
a_d pc1:2 pc4:0
a_e pc1:3 pc5:0
b_c pc2:1 pc3:1
b_d pc2:2 pc4:1
b_e pc2:3 pc5:1
c_d pc3:2 pc4:2
c_e pc3:3 pc5:2
d_e pc4:3 pc5:3
END vlan</pre>
After starting the VLAN sectiom of the file each
line should contain a VLAN name and a list of MAC addresses to be put in a
VLAN together. There should be at least two, but the actual number is
unlimited. When finished, the VLAN section is closed. As