X-Bone Internal Page

This page describes how to allocate a machine for your use, and the conventions to follow using that machine.

Facilities

Group members have access to four sets of machines:

The following machines are reserved: a.postel.org (Postel Lab), run.isi.edu (Network Lab). DO NOT experiment with these machines. Other resources include two Cisco 2500 switches and IXIA high throughput packet generator.

Reserving a Lab Machine

Before using one of the machines in the lab, it must be reserved using the reservation form at

http://www.isi.edu/cgi-bin/xbone/lab/status.pl

There are two types of reservations, shared and exclusive. A shared reservation indicates that you are using the machine, and others can also do so without interfering with you. An exclusive reservation means that no one else should use the machine, and that the person with the exclusive reservation may reboot the machine at any time. You should get an exclusive reservation if you are doing the following types of work:

1. Kernel swapping
2. Performance measurements that will be distorted by other users
3. Development that has a significant chance of rebooting the machine accidentally (this includes loadable driver development)

Shared reservations should be used if you want to pin down a machine for something use as a debugging console, or user level development on a lab machine.

The scheduler is a good tool for making sure that the machines are allocated fairly in times of high use. Use common sense and courtesy in its use. If you want to try a ten minute test and the machines are all idle, you probably do not need a reservation. If you want to guarantee that the machine isn't rebooted while you video conference from there, make the reservation. On the other hand if you made an exclusive reservation two minutes before you plan to use a machine, log on and find someone using the machine, let them know you have reserved the machine before rebooting it.

An exclusive reservation gives you the right to reboot the machine and to have anyone else who is logged onto the machine log out. (Rebooting the machine is a pretty good way to remove all users, actually.)

Lab Machine Etiquette

You should return any machine you reserve exclusively to the same state you it was in when you reserved it. This state includes:

1. The kernel that is running
2. The state of all network connections (especially physical connections)
3. The state of any other special interfaces

Again, restoring the system state is tempered with common sense. If you have a long suite of experiments to run using a non-standard network configuration, its acceptable to note the change to the xbone mailing list (described below) and leave things set up. Again, the important point is that people who may want to use the machines know how they are configured, and how to restore them to a default configuration.

Remote Lab Usage

For many people it's more convenient to use the lab from home or USC. Remember that the lab's golden rule is: Leave Your Machines Like You Found Them

When you're remote, there's a second important rule: Be Secure In All Lab Access

What do these rules really mean?

To Leave Your Machines Like You Found Them, you need to make sure that you can reboot your machines with the current default kernels. If you're remote, you should be sure that you're not going to hang the machine in some horrible way that prevents you from Leaving Them Like You Found Them. Remember, you can't physically go to the console and power cycle the thing if it hangs when you're remote. Therefore either

1. do only things you already know don't hang the machine
2. have someone it ISI pre-arranged to reboot the machine at your request
3. both

If these options fall through, you should be prepared to drive from where you are to ISI in order to power cycle/reboot the machine before your reservation expires. Simply extending your reservation to cover until the next time you plan to be in is considered antisocial.

To Be Secure in All Lab Access, you need to be aware that each su1 command requires you to type in the root password. Since there have been snooping attacks between campus and ISI before, this means you must insure that your network connection is encrypted. The best way to do this is to use the secure shell (ssh2 with public key) to log in to your machines.

Finally, if your terminal is in a public or only moderately secure place, make sure you lock it (perhaps with xautolock or xlock) before leaving it unattended.

Software Installation on the FreeBSD Systems

In an effort to minimize confusion, we are trying to make sure that the same software is installed on all the machines. We are making use of both the FreeBSD package system and the shared repository at boreas:/home/xbone

A cron job on each host automatically check the central repository for updates and download them. Hosts might reboot automatically after such updates.

A FreeBSD version-specific install file containing a shell script with embedded instructions is used for installations. One version for FreeBSD 4.9 is available here Follow the instructions closely.

Consult group members for other installations as well as host specific overrides.

Read the Frequently Asked Questions mainly written by Lars Eggert

Some useful information on the ports from Yu-Shun Wang

Handling Machines

Make sure that the machine is registered for Warranty. Check the configuration regularly for faulty drives, memory, screen etc. Register for software updates. Update the BIOS when informed.

Contact

That should be enough to get you started on the machines. If you have problems not covered in this document, send a mail to xbone@isi.edu