faq.html 19.4 KB
Newer Older
1 2 3 4 5 6 7 8
<html>
<head>
	<title>Emulab.Net - Frequently Asked Questions</title>
	<link rel='stylesheet' href='tbstyle-plain.css' type='text/css'>
</head>
<body>
<basefont size=4>

9
<center>
10
<h2>Frequently Asked Questions</h2>
11 12 13
</center>

<h2>Contents</h2>
14
<ul>
15 16 17 18
<li> <a href="#GS">Getting Started</a>
     <ul>
     <li> <a href="#GS-1">How do I start a project?</a>
     <li> <a href="#GS-2">How do I join a project?</a>
19 20 21 22
     <li> <a href="#GS-3">I have an Emulab account. Now what?</a>
     <li> <a href="#GS-4">Can I be in more than one project?</a>
     <li> <a href="#GS-5">Can I change my Emulab password?</a>
     <li> <a href="#GS-6">Where do I get help?</a>
23 24 25 26 27 28
     </ul>

<li> <a href="#UTT">Using the Testbed</a>
     <ul>
     <li> <a href="#UTT-1">Is there a tutorial?</a>
     <li> <a href="#UTT-2">Do I get root access on my nodes?</a>
29
     <li> <a href="#UTT-3">Do my nodes have consoles I can look at?</a>
30 31 32
     <li> <a href="#UTT-4">Can I reboot (power cycle) my nodes?</a>
     <li> <a href="#UTT-5">Where do I store files needed by my experiment?</a>
     <li> <a href="#UTT-6">Are my files on <b>users.emulab.net</b>
33
                           backed up (filesaved)?</a>
34
     <li> <a href="#UTT-7">Are the nodes in my experiment backed up
35
                           (filesaved)?</a> 
36 37 38 39 40
     </ul>

<li> <a href="#HDS">Hardware setup</a>
     <ul>
     <li> <a href="#HDS-1">How many nodes are there?</a>
41 42 43
     <li> <a href="#HDS-2">How many nodes are currently available?</a>
     <li> <a href="#HDS-3">How many ethernet cards are on each node?</a>
     <li> <a href="#HDS-4">Can I do traffic shaping on my links?</a>
44 45 46 47 48
     </ul>

<li> <a href="#SWS">Software setup</a>
     <ul>
     <li> <a href="#SWS-1">What OS do the nodes run?</a>
49 50 51
     <li> <a href="#SWS-2">How do I select which OS to run on each node?</a>
     <li> <a href="#SWS-3">Can I load my own software (RPMs) on my nodes?</a>
     <li> <a href="#SWS-4">Can I schedule programs to run
52 53 54 55
                           automatically when a node boots?</a>
     <li> <a href="#SWS-5">How can I turn on routing or set up routes
			   automatically in my nodes?</a>
     <li> <a href="#SWS-6">How does my software determine when other
56
                           nodes in my experiment are ready?</a>
57
     <li> <a href="#SWS-7">Can I run my own Operating System?</a>
58
     </ul>
59 60 61 62 63

<li> <a href="#SEC">Security Issues</a>
     <ul>
     <li> <a href="#SEC-1">Is Emulab Firewalled?</a>
     </ul>
64 65 66
</ul>

<hr>
67

68 69 70 71
<a NAME="GS"></a>
<h3>Getting Started</h3>
<ul>
<li><a NAME="GS-1"></a>
72
    <h3>How do I start a project?</h3>
73 74
    <p>
    If you are new to the Testbed, simply click on the "Start Project"
75
    link on the Emulab <a href="https://www.emulab.net">Home
76 77 78 79
    Page</a>. You will need to fill in the forms with your personal
    information and information about the project. Then click on the
    "Submit" button. Within a few days you will be contacted via email
    with an approval message. More information about starting projects
80 81
    can be found in <a href="docwrapper.php3?docname=auth.html">
    Authorization Page</a>.
82
    </p>
83 84 85 86 87 88 89
    <p>
    If you already have an Emulab account, and wish to start a second
    project, first log into the Web Interface. Then select the "Start
    Project" link; all of the personal information will already be
    filled in. You will need to complete just the project information
    section. 
    </p>
90

91
<li><a NAME="GS-2"></a>
92
    <h3>How do I join a project?</h3>
93 94
    <p>
    If you are new to the Testbed, simply click on the "Join Project"
95
    link on the Emulab <a href="https://www.emulab.net">Home
96 97 98
    Page</a>. You will need to fill in the form with your personal
    information, and provide the name of the project you are trying to
    join (typically, the <i>Project Leader</i> will have told you the
99
    name of the project). Then click on the "Submit" button, and wait
100 101 102
    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.
103 104 105 106 107 108 109 110 111 112
    </p>

<li><a NAME="GS-3"></a>
    <h3>I have an Emulab account. Now what?</h3>
    <p>
    Once you have been approved to start (or join) your first project,
    you will be able to log into Emulab's user machine,
    <b>users.emulab.net</b>. We require that all Emulab users use ssh. For
    example, if your Emulab account name is "joe", then you would do:
    <pre>
113
	ssh users.emulab.net -l joe		</pre>
114 115 116 117 118 119 120 121 122 123 124 125 126 127
    </p>
    <p>
    Your password starts out the same as the password you initially
    supplied to the Start (or Join) web page. The skeleton <i>dot</i>
    files that are provided to all new Emulab users will contain
    <tt>/usr/testbed/bin</tt> in the <tt>PATH</tt> setting. This
    directory holds a number of utilities and programs that some (but
    not all) Emulab users will need in order to conduct experiments.
    </p>

<li><a NAME="GS-4"></a>
    <h3>Can I be in more than one project?</h3>
    <p>
    Yes. You may join (and/or start) as many projects as you like,
128 129
    subject to Emulab <a href="docwrapper.php3?docname=policies.html">
    administrative policies</a>.
130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147
    </p>

<li><a NAME="GS-5"></a>
    <h3>Can I change my Emulab password?</h3>
    <p>
    Yes. You can change your Emulab Web password and your Emulab login
    password (the password you use to log into <b>users.emulab.net</b>, as
    well as nodes in your experiments). To change your Web password,
    simply click on the "Update User Information" in the menu to your
    left, and then enter your new password in the location provided. 
    To change your login password, use the unix <tt>passwd</tt>
    utility when logged into <b>users.emulab.net</b>. 
    </p>

<li><a NAME="GS-6"></a>
    <h3>Where do I get help?</h3>
    <p>
    If you cannot find an answer to your question in the
148
    <a href="doc.php3">Emulab Documentation</a>, then you can
149 150 151 152
    send email to <a href="mailto:testbed-ops@flux.cs.utah.edu"> 
    Testbed Operations (testbed-ops@flux.cs.utah.edu)</a>. We will try
    to answer your question as quickly as we can.
    </p>
153
</ul>
154

Leigh B. Stoller's avatar
Leigh B. Stoller committed
155
<hr>
156 157 158 159 160

<a NAME="UTT"></a>
<h3>Using the Testbed</h3>
<ul>
<li><a NAME="UTT-1"></a>
161
    <h3>Is there a tutorial?</h3>
162
    <p>
163
    Yes, we have an extensive <a href="tutorial/tutorial.php3">tutorial</a>
164 165 166 167
    on using the Testbed.
    </p>

<li><a NAME="UTT-2"></a>
168
    <h3>Do I get root access on my nodes?</h3>
169 170 171 172 173 174
    <p>
    Yes. Project leaders get root access to all of the nodes in all of
    the experiments that are running in their project. Project members
    get root if their project leader grants them root access, when the
    leader approves the group <a href="#GS-1">membership request</a>.
    Root privileges are granted via the <code>sudo</code> command. The
175
    <a href="tutorial/tutorial.php3#RootAccess">tutorial</a> describes
176 177
    this in more detail.
    </p>
178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199

<li><a NAME="UTT-3"></a>
    <h3>Do my nodes have consoles I can look at?</h3>
    <p>
    Yes. Each of the PCs has its own serial console line that you can
    interact with using the unix <tt>tip</tt> utility. To "tip" to
    "pc01" in your experiment, ssh into <b>users.emulab.net</b>, and
    then type <tt>tip pc01</tt> at the unix prompt. You may then
    interact with the serial console.
    </p>
    <p>
    The Sharks also have serial console lines, but because of the
    limited number of serial ports available on <b>users.emulab.net</b>, only
    one Shark, the last or "eighth", on each shelf has a console line
    attached. To tip to that shark, you would type <tt>tip shXX</tt>
    at the unix prompt, where "XX" is the shark shelf number. The
    shark shelf number is the first digit in the name. Using shark
    sh16-8 as an example, the shelf number is sixteen, and the number
    of the node on the shelf is eight.
    </p>

<li><a NAME="UTT-4"></a>
200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215
    <h3>Can I reboot (power cycle) my nodes?</h3>
    <p>
    Yes. Each of the PCs is independently power controlled. If your
    node becomes wedged, or otherwise unresponsive, you can use the
    <tt>node_reboot</tt> command, as discussed in the
    <a href="tutorial/tutorial.php3#Wedged">Emulab Tutorial.</a>
    </p>
    <p>
    The Sharks are also power controlled, but because of the limited
    number of power ports available, the entire shelf of 8 sharks is
    on a single controller. The <tt>node_reboot</tt> does its best to
    cleanly reboot individual sharks, but if a single shark is
    unresponsive, the entire shelf will be power cycled.
    </p>

<li><a NAME="UTT-5"></a>
216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232
    <h3>Where do I store files needed by my experiment?</h3>
    <p>
    Each project has its own directory, rooted at <tt>/proj</tt>,
    which is available via NFS to all of the nodes in experiments
    running in that project. For example, when the "RON" project was
    created, a directory called /proj/RON was also created. This
    directory is owned by the project creator, and is in the unix
    group "RON." Its permission (mode) is 770; read/write/execute
    permitted by the project creator and by all of the members of the
    project RON, but protected against all access by people outside
    the RON project.
    </p>
    <p>
    Project members are encouraged to store any files needed by their
    experiments in the corresponding /proj project directory. 
    </p>

233
<li><a NAME="UTT-6"></a>
234 235 236 237 238 239 240 241 242
    <h3>Are my files on <b>users.emulab.net</b> backed up (filesaved)?</h3>
    <p>
    Yes. All of the files in your home directory on /users, and all of
    the files in your project directory in /proj are filesaved. While
    we can restore lost files in an emergency, we encourage you to
    back up critical data on your own to avoid (possibly long) delays
    in conducting your experiments.
    </p>
    
243
<li><a NAME="UTT-7"></a>
244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272
    <h3>Are the nodes in my experiment backed up (filesaved)?</h3>
    <p>
    No! The nodes in your experiment are not filesaved. Any changes
    you make to the local filesystems will be lost if the event of a
    disk failure. We plan to provide a mechanism for experimenters to
    create snapshots of their node state, but that is not done yet. In
    the meantime, any files that must not be lost should be stored in
    the project directory (/proj/<project_name>), which is available
    via NFS to all of the nodes in your experiment. You may also store
    files in your home directory (/users/<login>), also available via
    NFS to all of your nodes, but that is not the preferred location
    since quotas on /users are relatively small.
    </p>
    
</ul>

<hr>


<a NAME="HDS"></a>
<h3>Hardware Setup</h3>
<ul>
<li><a NAME="HDS-1"></a>
    <h3>What kind of computers are used for my nodes?
<li><a NAME="HDS-2"></a>
    How many nodes are there?
<li><a NAME="HDS-3"></a>
    How many ethernet cards are on each node?</h3>
    <p>
273 274 275
    Please see the <a href="docwrapper.php3?docname=hardware.html">
    Hardware Overview</a> page for a description and count of the
    computers that comprise the Testbed.
276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297
    </p>
    
<li><a NAME="HDS-4"></a>
    <h3>How many nodes are currently available (free)?</h3>
    <p>
    If you click on the "Node Reservation Status" link in the menu to
    your left, you will see a summary of the number of nodes (by type)
    that are currently available, followed by a listing of the
    reservation status of each individual node.
    </p>
    
<li><a NAME="HDS-5"></a>
    <h3>Can I do traffic shaping on my links?</h3>
    <p>
    Yes! You can specify the delay, bandwidth, and packet loss rate
    between any two nodes in your topology. Bandwidth and delay are
    specified in the NS <tt>duplex-link</tt> statement, while packet
    loss rate is specified with the Emulab <tt>tb-set-link-loss</tt>
    extension to NS. You may also specify delay, bandwidth, and packet
    loss rate between nodes in a regular LAN.
    </p>
    <p>
298 299
    Please see the
    <a href="docwrapper.php3?docname=tutorial/nscommands.html">Extensions</a>
300
    page for a summary of all Emulab NS extensions, and the
301
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
302 303 304 305 306 307 308 309 310 311 312 313
    example. 
    </p>
</ul>

<hr>

<a NAME="SWS"></a>
<h3>Software Setup</h3>
<ul>
<li><a NAME="SWS-1"></a>
    <h3>What OS do the nodes run?</h3>
    <p>
314 315 316
    Please see the <a href="docwrapper.php3?docname=software.html">
    Software Overview</a> page for a description of the Operating
    Systems that can be run on each of the Testbed nodes.
317 318 319 320 321 322 323 324 325 326 327 328
    </p>

<li><a NAME="SWS-2"></a>
    <h3>How do I select which OS to run on each node?</h3>
    <p>
    When a choice of OS is available, you may specify which one you
    prefer for each node in the NS file using the Emulab
    <tt>tb-set-node-os</tt> extension to NS. When your experiment is
    configured, the appropriate disk image will be loaded on your
    nodes, and the selected operating system will boot up on each.
    </p>
    <p>
329 330
    Please see the
    <a href="docwrapper.php3?docname=tutorial/nscommands.html">Extensions</a>
331
    page for a summary of all Emulab NS extensions, and the
332
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349
    example. 
    </p>    
    
<li><a NAME="SWS-3"></a>
    <h3>Can I load my own software (RPMs) on my nodes?</h3>
    <p>
    Yes! If have an RPM (or more than one) that is appropriate for
    loading on the OS you have selected, you can arrange to have them
    loaded automatically when your experiment is configured. The
    Emulab NS extension <tt>tb-set-node-rpms</tt> is used in the NS
    file to specify a list of RPMS to install. You may specify a
    different list for each node in the experiment. When the node
    first boots after the experiment is configured, each of the RPMs
    will be installed (but only RPMs that have not already been
    installed). 
    </p>
    <p>
350 351
    Please see the
    <a href="docwrapper.php3?docname=tutorial/nscommands.html">Extensions</a>
352
    page for a summary of all Emulab NS extensions, and the
353
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
354 355
    example. 
    </p>    
356
    
357 358 359 360 361 362 363 364 365 366 367 368 369 370
<li><a NAME="SWS-4"></a>
    <h3>Can I schedule programs to run automatically when a node boots?</h3>
    <p>
    Yes! You can arrange to run a single program or script when your
    node boots. The script is run as the UID of the experiment
    creator, and is run after all other node configuration (including
    RPM installation) has completed. The exit status of the script (or
    program) is reported back and is made available for you to view in
    Experiment Information link in the menu at your left. The Emulab
    NS extension <tt>tb-set-node-startup</tt> is used in the NS file
    to specify the path of the script (or program) to run. You may
    specify a different program for each node in the experiment.
    </p>
    <p>
371 372
    Please see the
    <a href="docwrapper.php3?docname=tutorial/nscommands.html">Extensions</a>
373
    page for a summary of all Emulab NS extensions, and the
374
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
375 376
    example.
    </p>    
377

378
<li><a NAME="SWS-5"></a>
379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436
    <h3>How can I turn on routing or set up routes automatically 
    in my nodes?</h3>
    <p>
    You can use command mentioned above (<tt>tb-set-node-startup</tt>)
    in your NS file to specify a simple script in your home directory
    that will do this. For instance, if I had a node called router,
    and wanted to turn on routing in it, I would add these two lines
    to my NS file:
<pre>
tb-set-node-os $router FBSD40-STD
tb-set-node-startup $router /users/myname/router-startup
</pre>
    That would cause router to boot FreeBSD, and call my
    router-startup script, which should look like this:
<pre>
#!/bin/sh
/usr/site/bin/su1 sysctl -w net.inet.ip.forwarding=1
/usr/site/bin/su1 sysctl -w net.inet.ip.fastforwarding=1
exit 0
</pre>
    That will make sure that routing gets turned on when my router
    node boots. Now say I have a client on one side of the router,
    and a server on the other side, and I want to establish a route
    from the client to the server through the router, and vice
    versa. I would add these lines to my NS file:
<pre>
tb-set-node-startup $client /users/myname/clientroutecmd
tb-set-node-startup $server /users/myname/serverroutecmd
</pre>
    This will have the client and the server each call a small script
    to set up routes. To add a route (on client) to interface 0 of the
    server through router, I would run a script called clientroutecmd
    that looks like this (for a node running FreeBSD):
<pre>
#!/bin/sh
sudo route add server-0 router
exit 0
</pre>
    Similarly, to add a route (on server) to interface 0 of the client
    through router, I would use this serverroutecmd script:
<pre>
#!/bin/sh
sudo route add client-0 router
exit 0
</pre>
    That should do it. We now will have a router node that really
    routes and forwards packets, and a client and a server that know
    how to talk to each other through a gateway router.
    </p>
    <p>
    Please see the
    <a href="docwrapper.php3?docname=tutorial/nscommands.html">Extensions</a>
    page for a summary of all Emulab NS extensions, and the
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
    example.
    </p>
    
<li><a NAME="SWS-6"></a>
437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452
    <h3>How does my software determine when other nodes in my
    experiment are ready?</h3>
    <p>
    If your application requires synchronization to determine when all
    of the nodes in your experiment have started up and are ready to
    proceed, then you can use the Testbed's <i>ready bits</i>
    mechanism. The ready bits are really just a way of determining how
    many nodes have issued the <b>ready</b> command, and is returned
    to the application as a simple N of M string, where N is the
    number that have reported in, and M is the total number of nodes
    in the experiment. Applications can use this as a very simplistic
    form of barrier synchronization, albeit one that can be used just
    once and one that does not actually block!
    </p>
    <p>
    Use of the ready bits is described in more detail in the <a href =
453 454 455
    "tutorial/tutorial.php3">Emulab Tutorial</a> and in the <a href =
    "docwrapper.php3?docname=doc/tmcd.html"> Testbed Master Control
    Daemon</a> documentation.
456 457
    </p>
    
458
<li><a NAME="SWS-7"></a>
459 460 461 462 463 464 465 466 467 468 469
    <h3>Can I run my own Operating System?</h3>
    <p>
    Yes! You can run your own OS on any of the PCs (the Sharks do not
    support custom operating systems as this time, however you can run
    <a href = "http://www.cs.utah.edu/flux/oskit/">OSKit</a> kernels
    on the PCs or the Sharks). Each of the PCs is partitioned so that
    the 4th DOS slice (about 6GB) is unused and available to be loaded
    with whatever OS you want to run. The only requirement is that
    your image contain a proper DOS boot record in the first sector
    (first sector of the 4th DOS slice) which can be invoked by the
    DOS Master Boot Record in the first sector of the disk. There are
470 471 472 473
    other minor requirements which are detailed in the <a
    href="tutorial/tutorial.php3#CustomOS">Custom OS</a> documentation
    page. The procedure for creating and installing your custom OS are
    also described in this document.
474
    </p>
475 476
</ul>

477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493
<hr>

<a NAME="SEC"></a>
<h3>Security Issues</h3>
<ul>
<li><a NAME="SEC-1"></a>
    <h3>Is Emulab Firewalled?</h3>
    <p>
    Yes. Emulab blocks all of the <i>low numbered</i> ports (ports
    below 1024), with the exception of port 22 (Secure Shell). This is
    for the protection of experimentors, as well as to ensure that an
    errant application cannot become the source of a Denial of Service
    attack to sites outside of Emulab. If your application requires
    external access to other low numbered ports, please contact us to
    make special arrangements.
    </p>
</ul>