There is a fairly complete list in the course web page of Fall 2004. The working environment is almost identical to that of Fall 2004, except that we are no longer working with Linux but with OSKit. You are going to build your own kernel from scratch.

1. Accessing your CLIC machine

Your team will be given one of the CLIC Lab machines (the host machine), on which the virtual machine (VM) for your team has been installed. The operating system of the host machine is Redhat Linux 9. Half of these machines are located on the left-hand side of the CLIC Lab, and the rest of them are on the racks of the CRF machine room. The latters must be accessed remotely. Even if the machine assigned to your team is located in the CLIC Lab, more often than not you cannot access directly from its console, so you need to know how to remotely connect the machine that hosts your VM.

1.1 Secured shell (SSH)

If you are using a modern Unix-based operating system, (e.g., Linux machines on the left-hand side of CLIC or Solaris-based Sun-Ray consoles on the right-hand side, or MAC OS X) you should already have SSH installed. Using the following command to login your VM host machine (replace <machine> with the machine name assigned to you):

ssh -X <machine>.clic. cs.columbia.edu
If you are running Windows, you need to install an SSH software. One of the choices is Cygwin, a software package emulating Linux systems with most of the Unix commands included. You can also use a stand-alone SSH client software, e.g. PuTTY or TeraTerm(with SSH2). Use SSH protocol version 2 if you have a choice. SSH protocol version 1 is known to have security problems.

1.2 X Server

SSH only provides a telnet-like interface. To run GUI applications such as VMware, you need an X server installed on your desktop. The X-server displays windows and dialogs of (and also sends your keyboard and mouse inputs to) the client process running on a remote machine (known as X-client) in a so-called >X protocol. Here the remote machine is your VM host machine. However, there is an alternative way, please see the next section: using VNC.

Firewall issues. If your desktop computer is behind a firewall, you may have trouble with your X server, since the X server is listening for incoming network connections initiated by X-clients. These connections must go from your VM machine to your desktop through the firewall. If you are using Windows XP/SP2 with firewall enabled, you have to unblock the network access to the X-server (e.g., cygwin whose X-server process is `xwin.exe', or the X-Win32 process). If you have no privilege to change the firewall configurations, or you are in some more complicated scenarios (e.g., NAT), use VNC instead - see the next section.

X forwarding in SSH. As mentioned earlier, the data transmitted in the X protocol are encrypted if you are using `ssh -X'. If you are using a stand-alone SSH software package on a Windows system, try to find and enable the option 'X forwarding'. With X forwarding, you may circumvent the firewall issue in the same way as using `ssh -X'. If your SSH software package does not support X forwarding, you can type the following command after SSHing to your VM host machine:

export DISPLAY=<your_desktop_pc_name_or_IP>:<your_X_server_display_number>
Usually <your_X_server_display_number> is 0. Make sure that your X-server accepts connections from your VM machine. With this solution, the data transmitted in the X protocol are NOT encrypted, which means potentially some malicious programs on the network may eavesdrop what you see and type in your X Window. Also, you may have to solve the firewall issue.

1.3 Virtual Networking Computing (VNC)

In fact, there are two different VNC projects: RealVNC and TightVNC. They are both backward compatible to the aged VNC 3.x. The recent Fedora Core 2/3 is using RealVNC, whereas in Redhat Linux 9, TightVNC is installed.

There are several advantages to using VNC over X-server.

However, there are a few drawbacks:

VNC Infrastructure

Three computers are involved in VNC communication: the remote computer, say A, your desktop computer, say C, and the computer where VNC server resides, say B. The communication between A and B is in the X protocol, where B is the X-server. The communication between B and C is in a protocol defined by VNC itself, where B again is the server. One may consider the VNC server, B, as an X proxy. Hence, if both A and C are behind their firewalls, you can still find a way to access A from C through a B which resides outside both firewalls. In our cases A and B are the same computer.

Using VNC: A Quick Start

2. Collaborating with your teammates

Your team is free to choose methods regarding coordination of your team development. However, we strongly suggest to use some source code management systems. Your team can also use Instant Messaging for quick communication, such as ICQ or MSN Messenger.

Source code management tools:

RCS, CVS, SVN are NOT backup tools. You are advised to make regular backups for your project. If you are using CVS, back up the CVS repository directory tree regularly. The VMware directory (usually /vmware1 on your VM host machine) should be fairly reliable, but it does not subject to human errors. If you plan to place your CVS repository in the VMware directory, the simplest way is to regularly compress your CVS repository to archive files, by using `tar/gzip/bzip' or `zip', and then place these files in your home directory, since your home directory is supposed to be nightly backed up.

$Id: tools.html,v 1.5 2005/01/27 20:45:26 hanhua Exp $