software.html 4.84 KB
Newer Older
Leigh Stoller's avatar
Leigh Stoller committed
1 2
   Copyright (c) 2000-2002 University of Utah and the Flux Group.
Leigh Stoller's avatar
Leigh Stoller committed
4 5
   All rights reserved.
6 7
    Overview of Installed Software
9 10 11 12

<li><b>Wide-area nodes</b>: FreeBSD 4.6 with additions for robustness
    and for participation in the wide area Netbed.
15 16

<li><b></b>: Master server, database, web server, name server, trusted disk-image server
    Also known as <b></b>.
    Runs FreeBSD.  This is the master machine for the testbed
    software.  Runs all the critical software components and thus is not
    directly accessible by testbed users.  Mediates (via the database)
23 24 25 26
    access to node power cycling and disk-image loading as well as providing
    DNS and web services.

27 28 29
<li><b></b>:  NFS and SFS file server, login/control/console access point,
    serial line server.

31 32 33 34
    Also known as <b></b> and <b></b>.
    Currently runs FreeBSD 4.5-RELEASE.  This is the main server machine for users
    of the testbed and is where shared 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
36  These testbed specific commands and programs are
    contained in <code>/usr/testbed/bin</code>. Your skeleton login
    files already have this directory in your path.
39 40
    This is also one of Emulab's "serial-line console" servers.  Experimenters can access
    the console of any testbed node (using the <code>console</code> program) from here.
    Console output of all nodes is also logged here.

46 47
<h3>Machines used only for ``Emulab Classic'':</h3>

49 50 51
<li><b></b>: additional test node serial line server
    Runs FreeBSD 4.5-RELEASE.
53 54 55
    Provides physical serial line ports for additional testbed nodes.
    Not directly accessible by testbed users, hosted serial lines are
    accessed by users via a proxy agent on
56 57

<li><b>pc[1-40]</b>: <a href="hardware.html#tbpc600">pc600</a> testbed PC nodes
    The testbed nodes can dual boot FreeBSD 4.5 and RedHat Linux 7.1.
    You may also boot your own OSKit kernels on them. Alternatively, you
62 63 64 65
    can run whatever OS you like by loading your own OS image onto the
    the 4th DOS slice using the Testbed configuration software.

    Each node has 5 100/MBbps ethernet cards. The first four
67 68 69
    interfaces are connected to the "experimental network," and are
    used to "wire up" your specific network topology. The last
    interface is connected to the "control network," and is used
70 71 72
    for configuration and for login access from
    In FreeBSD this card is named <code>fxp4</code>,
    and in Linux and OSKit kernels it is <code>eth4</code>
73 74

    All of these nodes have their COM1 serial interface (console
    port) connected to The port is configured to run
    at 115K baud, and are accessible from via
    <code>console</code> using the appropriate "pc" names; e.g., "pc6."
79 80 81 82 83

<li><b>pc[41-168]</b>: <a href="hardware.html#tbpc850">pc850</a> testbed PC nodes
    Same as "pc600" nodes from a software perspective:
    dual booting FreeBSD 4.5 and RedHat Linux 7.1, or capable of running
85 86 87 88 89 90 91 92 93 94
    custom OSKit kernels.
    However, due to differences in the hardware configuration,
    the "control" interface is <code>fxp0</code> under FreeBSD,
    <code>eth2</code> under Linux, and <code>eth0</code> under OSKit kernels.

    As these testbed nodes support true console redirection,
    BIOS interaction, as well as OS kernel interaction, is possible via
    the console serial lines.  However, the BIOS is password-protected
    and only read-only access is allowed without the password.
95 96

97 98
<li><em>(Currently unavailable)</em><br>
<b>sh[1-20]-[1-8]</b>: testbed <a href="hardware.html#tbshark">Shark</a> nodes
    The Sharks run NetBSD by default, with the filesystems provided via
101 102
    NFS. You may also boot your own OSKit kernels. At this time, no support
    is provided for running your own operating system on the Sharks.
103 104 105 106 107 108 109 110 111 112 113 114

    Each Shark has a single 10Mbps ethernet which serves as both the control
    and experimental interface. This is done with IP "aliasing", and
    causes experimental traffic to be routed to the experimental
    network instead of the control network.

    All nodes use the serial port as their console, but due to the
    limited number of serial ports on the control node, only the last
    Shark on each shelf is connected to the control node.  These
    designated Shark console lines are accessible from
115 (via the <code>console</code> command) using the appropriate
Leigh Stoller's avatar
Leigh Stoller committed
    "tbsh" shelf names; e.g., "sh16."
117 118