If you are new to the Testbed, simply click on the "Start Project" link on the Emulab Home Page. 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 can be found in Authorization Page.
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.
If you are new to the Testbed, simply click on the "Join Project" link on the Emulab Home Page. 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 Project Leader will have told you the name of the project). Then click on the "Submit" button, 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.
Once you have been approved to start (or join) your first project, you will be able to log into Emulab's user machine, users.emulab.net. We require that all Emulab users use ssh. For example, if your Emulab account name is "joe", then you would do:
ssh users.emulab.net -l joe
Your password starts out the same as the password you initially supplied to the Start (or Join) web page. The skeleton dot files that are provided to all new Emulab users will contain /usr/testbed/bin in the PATH setting. This directory holds a number of utilities and programs that some (but not all) Emulab users will need in order to conduct experiments.
Yes. You may join (and/or start) as many projects as you like, subject to Emulab administrative policies.
Yes. You can change your Emulab Web password and your Emulab login password (the password you use to log into users.emulab.net, 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 passwd utility when logged into users.emulab.net.
If you cannot find an answer to your question in the Emulab Documentation, then you can send email to Testbed Operations (testbed-ops@flux.cs.utah.edu). We will try to answer your question as quickly as we can.
Yes, we have an extensive tutorial on using the Testbed.
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 membership request.
Root privileges are granted via the sudo command. The
tutorial describes
this in more detail.
Yes. Each of the PCs has its own serial console line that you can interact with using the unix tip utility. To "tip" to "pc01" in your experiment, ssh into users.emulab.net, and then type tip pc01 at the unix prompt. You may then interact with the serial console.
The Sharks also have serial console lines, but because of the limited number of serial ports available on users.emulab.net, only one Shark, the last or "eighth", on each shelf has a console line attached. To tip to that shark, you would type tip shXX 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.
Each project has its own directory, rooted at /proj, 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.
Project members are encouraged to store any files needed by their experiments in the corresponding /proj project directory.
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.
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/
Please see the Hardware Overview page for a description and count of the computers that comprise the Testbed.
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.
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 duplex-link statement, while packet loss rate is specified with the Emulab tb-set-link-loss extension to NS. You may also specify delay, bandwidth, and packet loss rate between nodes in a regular LAN.
Please see the Extensions page for a summary of all Emulab NS extensions, and the Emulab Tutorial for an example.
Please see the Software Overview page for a description of the Operating Systems that can be run on each of the Testbed nodes.
When a choice of OS is available, you may specify which one you prefer for each node in the NS file using the Emulab tb-set-node-os 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.
Please see the Extensions page for a summary of all Emulab NS extensions, and the Emulab Tutorial for an example.
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 tb-set-node-rpms 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).
Please see the Extensions page for a summary of all Emulab NS extensions, and the Emulab Tutorial for an example.
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 tb-set-node-startup 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.
Please see the Extensions page for a summary of all Emulab NS extensions, and the Emulab Tutorial for an example.
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 ready bits mechanism. The ready bits are really just a way of determining how many nodes have issued the ready 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!
Use of the ready bits is described in more detail in the Emulab Tutorial and in the Testbed Master Control Daemon documentation.
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 OSKit 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 other minor requirements which are detailed in the Custom OS documentation page. The procedure for creating and installing your custom OS are also described in this document.
Yes. Emulab blocks all of the low numbered 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.