Commit c5c469be authored by Jay Lepreau's avatar Jay Lepreau
Browse files

pid/eid -> myproj/myexpt or proj/expt

parent bb907b4e
......@@ -36,7 +36,7 @@ each sliver can be addressed like
<code>node</code> is the name of the node in your slice (if you used the 'EZ'
form, the names will be 'node-N', starting with 'node-1', up to the number of
nodes in your slice). <code>exp</code> is the name of your experiment (same as
the slice name) and <code>pid</code> is the name of your project on Emulab.
the slice name) and <code>proj</code> is the name of your project on Emulab.
......@@ -30,7 +30,7 @@ your experimental nodes is easy. When you are logged into
cd /sfs/netbed/nodeA.myexp.mypid </code></pre>
cd /sfs/netbed/nodeA.myexp.myproj </code></pre>
If instead you have copied your emulab private key to your home
......@@ -39,7 +39,7 @@ following <em>certprog</em> to your agent:
sfskey certprog -p netbed dirsearch \
cd /sfs/netbed/nodeA.myexp.mypid </code></pre>
cd /sfs/netbed/nodeA.myexp.myproj </code></pre>
As with SSH public keys, we distribute SFS public keys to all of the
......@@ -60,7 +60,7 @@ in to another node. To log into one of your experimental nodes with
rex -x /sfs/netbed/nodeA.myexp.mypid </code></pre>
rex -x /sfs/netbed/nodeA.myexp.myproj </code></pre>
To rex into <tt></tt>:
......@@ -801,8 +801,8 @@
We have a command called <code>portstats</code> that allows you access
to some of the port counters on our switches. To use it, you'll need
to ssh to <b></b>. '<code>portstats &lt;pid&gt;
&lt;eid&gt;</code>' will get you stats for all experimental interfaces in
to ssh to <b></b>. '<code>portstats &lt;proj&gt;
&lt;exp&gt;</code>' will get you stats for all experimental interfaces in
your experiment. Run '<code>portstats -h</code>' to get a list of other
options, such as different sets of stats.
......@@ -914,7 +914,7 @@
<tt></tt>, you may do the following:
eventsys_control [-f] replay pid eid
eventsys_control [-f] replay proj expt
......@@ -239,7 +239,7 @@ Last event: 160.000 seconds </code></pre>
You can get a full listing of the events for your experiment by running
<code>tbreport -v pid eid</code> on <tt></tt>. This
<code>tbreport -v proj expt</code> on <tt></tt>. This
report will include a section like this:
......@@ -301,7 +301,7 @@ event injection is accomplished via the <em>Testbed Event Client</em>
<tt></tt>. The command line syntax for <tt>tevc</tt>
tevc -e pid/eid time objname event [args ...]</code></pre>
tevc -e proj/expt time objname event [args ...]</code></pre>
where the <tt>time</tt> parameter is one of:
......@@ -372,7 +372,7 @@ example:
<td> tevc:</td>
<td><code></pre>tevc -e pid/eid +3.0 link0 down</pre></code>
<td><code></pre>tevc -e proj/expt +3.0 link0 down</pre></code>
......@@ -23,7 +23,7 @@ to <i>router</i>. In order to get router to correctly forward packets
between client and server, you would add this line to your NS file:
tb-set-node-startcmd $router /proj/pid/router-startup
tb-set-node-startcmd $router /proj/myproj/router-startup
This will make router run the <code>router-startup</code> script
......@@ -49,8 +49,8 @@ Now to get client and server to talk to each other through this router,
you would add these lines to your NS file:
tb-set-node-startcmd $client /proj/pid/clientroutecmd
tb-set-node-startcmd $server /proj/pid/serverroutecmd
tb-set-node-startcmd $client /proj/myproj/clientroutecmd
tb-set-node-startcmd $server /proj/myproj/serverroutecmd
This will have the client and the server each call a small script
......@@ -119,8 +119,8 @@ You can make a single script that will handle all end nodes, by replacing
and specifying the router in your NS file:
tb-set-node-startcmd $clientA {/proj/pid/router-startup router0}
tb-set-node-startcmd $clientB {/proj/pid/router-startup router1}
tb-set-node-startcmd $clientA {/proj/myproj/router-startup router0}
tb-set-node-startcmd $clientB {/proj/myproj/router-startup router1}
For multiple routers, the startup script for each router will need to
......@@ -143,7 +143,7 @@ then
sudo sysctl -w net.ipv4.conf.all.forwarding=1
sudo gated -f /proj/pid/gated.conf
sudo gated -f /proj/myproj/gated.conf
exit 0
......@@ -713,8 +713,8 @@ specify a (space separated) list of RPMs to install on each of your
nodes when it boots:
tb-set-node-rpms $nodeA /proj/pid/rpms/silly-freebsd.rpm
tb-set-node-rpms $nodeB /proj/pid/rpms/silly-linux.rpm </code></pre>
tb-set-node-rpms $nodeA /proj/myproj/rpms/silly-freebsd.rpm
tb-set-node-rpms $nodeB /proj/myproj/rpms/silly-linux.rpm </code></pre>
The above NS code says to install the <tt>silly-freebsd.rpm</tt> file
on <tt>nodeA</tt>, and the <tt>silly-linux.rpm</tt> on <tt>nodeB</tt>.
......@@ -740,7 +740,7 @@ specify absolute pathnames in your tarfile, which many modern tar
programs balk at.
tb-set-node-tarfiles $nodeA /usr/site /proj/pid/tarfiles/silly.tar.gz </code></pre>
tb-set-node-tarfiles $nodeA /usr/site /proj/myproj/tarfiles/silly.tar.gz </code></pre>
The above NS code says to install the <tt>silly.tar.gz</tt> tar file
on <tt>nodeA</tt> from the working directory <tt>/usr/site</tt> when
......@@ -768,11 +768,11 @@ should cd to the directory you need). You can specify the same program
for each node, or a different program. For example:
tb-set-node-startcmd $nodeA "/proj/pid/runme.nodeA"
tb-set-node-startcmd $nodeB "/proj/pid/runme.nodeB" </code></pre>
tb-set-node-startcmd $nodeA "/proj/myproj/runme.nodeA"
tb-set-node-startcmd $nodeB "/proj/myproj/runme.nodeB" </code></pre>
will run <tt>/proj/pid/runme.nodeA</tt> on nodeA and
<tt>/proj/pid/runme.nodeB</tt> on nodeB. The programs must reside on
will run <tt>/proj/myproj/runme.nodeA</tt> on nodeA and
<tt>/proj/myproj/runme.nodeB</tt> on nodeB. The programs must reside on
the node's local filesystem, or in a directory that can be reached via
NFS. This is either the project's <tt>/proj</tt> directory, in the
<tt>/group</tt> directory if the experiment has been created in a
......@@ -782,7 +782,7 @@ output into a file. You can place the file on the local node, or in
one of the NFS mounted directories mentioned above. For example:
tb-set-node-startcmd $nodeB "/proj/pid/runme >& /tmp/foo.log" </code></pre>
tb-set-node-startcmd $nodeB "/proj/myproj/runme >& /tmp/foo.log" </code></pre>
The exit value of the start command is reported back to the Web
Interface, and is made available to you via the "Experiment
......@@ -805,7 +805,7 @@ object(s) yourself by restarting the
on <tt></tt>:
eventsys_control replay &lt;pid&gt &lt;eid&gt </code></pre>
eventsys_control replay &lt;proj&gt &lt;expt&gt </code></pre>
You can also control each program object by sending it events, either
with the NS "at" command:
......@@ -817,8 +817,8 @@ with the NS "at" command:
or you can use the event program on <tt></tt>
tevc -e mypid/myeid now nodeA_startcmd stop
tevc -e mypid/myeid now nodeA_startcmd start </code></pre>
tevc -e myproj/myexpt now nodeA_startcmd stop
tevc -e myproj/myexpt now nodeA_startcmd start </code></pre>
The start command is especially useful when
combined with <a href="#BatchMode"><i>batch mode</i></a> experiments.
......@@ -1238,7 +1238,7 @@ default images as a base, goes like this:
above). Recreate the image as needed:
create_image -p &lt;pid&gt &lt;imageid&gt &lt;node&gt </pre></code>
create_image -p &lt;proj&gt &lt;imageid&gt &lt;node&gt </pre></code>
<li> Once your image is working properly, you can use it in any NS
file by using the <tt>tb-set-node-os</tt>.
......@@ -1251,7 +1251,7 @@ of your images or with one of the default images, you can use the
<tt>os_load</tt> command. Log into <tt>users</tt> and run:
os_load -p &lt;pid&gt -i &lt;imageid&gt &lt;node&gt </pre></code>
os_load -p &lt;proj&gt -i &lt;imageid&gt &lt;node&gt </pre></code>
This program will run in the foreground, waiting until the image has
been loaded. At that point you should log in and make sure everything
Supports Markdown
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