There are restrictions on the use of the Lab facilities:
Note: I strongly encourage you to subscribe with your Stony Brook CS account. This will ensure that mail will arrive to you more quickly, and that you are less likely to run out of your mail quota than if you were using some other ISP's mail service. If I post an important message to the class list, and you don't get it because your mail quota has exceeded, I may get a bounce back saying so, but I will have no way to communicate back with you. It is therefore your responsibility to ensure that you can always read the class mailing list and to stay current with what I post there.
Finally, please do not set your list subscription mode to Digest because digests can take several days to get emailed to you.
Please note that you will get an OSLAB account that will allow you to log into several machines and possibly also a UG lab account. Do not send email to the TA or the instructor from these machines, nor should you expect to get email sent to you on these machines; they are not configured for email processing. Please do all your email communication through whatever email means and email ID you were using outside these labs. It is particularly important that you follow these instructions to ensure that you could communicate with the teaching staff promptly.
Note that if you use DHCP at the source (say, a DSL line at home), then your IP address may change over time. In that case, you will have to re-visit the above link periodically to re-enable your access for your new IP address Similarly, if you tend to ssh from multiple locations (home, work, etc.), then please revisit the above URL as many times as needed.
Be aware, however, that some times, the reason you cannot ssh into the OSLAB is due to a bad network connection somewhere outside campus, or outside the CS department: those situations are beyond my control. You are advised to start working on your homework early, and to ensure that you will always have a place to work on your assignments, even if much of the campus network is down (e.g., use the UG Lab).
I apologize in advance for this inconvenience. It was made necessary due to numerous break-in attempts daily through my lab SSH servers.
BTW, sometimes, to help minimize network traffic over the SSH tunnel (especially. if you're working from home over a slow ISP), you can use use "ssh -C". The "C" is for "Compress" -- it tends to improve performance when you tunnel a X11 session (b/c the X11 protocol is a network hog :-)
Note that command instructions below are written assuming you use a shell like Bourne Shell (/bin/sh), KSH, or BASH. If you're a user of CSH or another shell, apply the appropriate commands in your shell of choice.
We have a pool of several VMware host machines, on which you will run a VMware guest OS. The general name for accessing the pool in round-robin fashion is vmpool.oslab.cs.sunysb.edu. (Our "pool" currently includes 4 servers, with 4-64GB RAM and 4-16 CPUs/cores each.) Those are the machines that run the VMware software. The actual Linux version you will run is called the Guest OS and will be started on top of VMware.
Before you login to the class machines, set may have to set your DISPLAY variable:
Next, to login to one of the VMware host machines use the "vmpool.oslab.cs.sunysb.edu" name, which will pick one of the pool machines at random (thus helping to distribute the load among all class students):
SSH access is required and restricted by the lab's firewall: you can only come in from within the university, the CS department, and select addresses which I've authorized (e.g., subsets of optonline.net, etc.). If you cannot ssh into this host, it is likely that you are trying to connect from another host outside the university. First, find out what is your IP address by clicking here. Then, send me or the TA an email with the hostname/IP that you came from that the script reported, and we will add this to our firewall list. Note that you can always ssh first into one of the campus hosts, and from there ssh into the OSLAB hosts.
The first time you log into oslab, you must initialize your VMware configuration, a process that takes several minutes. This initialization is needed only once, or at any other time if your VMware guest OS disk has become corrupt (which could happen when debugging homework assignments). Run this script, follow its instructions, and wait for it to finish before proceeding:
Cannot open display.it means that your either did not set up your DISPLAY variable correctly, or your SSH client is not configured to forward X11 connections. In that case, log out, fix your setup or configuration, and try again.
Cannot initialize the widget set.
The first time you start vmware, you'll need to click to "Open a virtual machine", then click on "Browse", then click on your Home icon at the top left, browse to your "vmware" subdir, select the specific VM there, and then Open "*.vmx" virtual machine file. Then click to "Power on" that virtual machine. Once you successfully find and boot this VM, you won't have to browse for it again: VMware will remember its default location the next time you start vmware.
When the boot has finished, you will see a regular Linux Console login, and you will have a Linux system exclusively for your use (i.e., you can crash it, reboot using CTL-ALT-DEL, etc.). The name that is assigned to your guest OS is going to start with "dhcp".
You may now log into this machine with the same User-ID and password you used to connect to oslab. Once there, you can "su" to root to install new kernels, reboot, load and unload kernel modules, test them out, etc. (The root password will be given to you in class.)
WARNING: Do not share the root VMware password with anyone else outside class!!! In addition, do not use your vmware root privileges for anything other than to perform your homework assignments for this class. Any deviation or abuse of your privileges will be result in your account disabled, a grade of "F" for the class, and a referral to the Academic Judiciary Committee.
Nevertheless, a number of people experienced with Linux sometimes choose to work on their assignments elsewhere: at home, at work, in a dorm, on a personal laptop, etc. That is OK. However, it is solely your responsibility to ensure that your code is working and properly committed on the OSLAB VMware machines! If you choose to develop your code outside the OSLAB, be sure to give yourself enough time to migrate it into the VMware machines, test it there, debug it as needed, commit it to CVS, check out a test copy and test it, etc. Don't assume that just because it worked for you outside the lab, that it'll automatically work in the lab: there could be many reasons why your code may not work in other settings. We will not allow people to bring laptops or other machines to demo their code. We will not accept excuses such as "but it worked for me at home" or "it really works --- I just need to copy it over."
If you do choose to work elsewhere on your assignments, we recommend that you duplicate the same exact environment we have on the VMware machines (Red Hat Linux 9 with all of the latest patches, configured properly). We will try to help you to set up your personal machine appropriately, but please realize that our time and resources are limited to official class matters. Unfortunately, we do not have the time to help each student in the class to set up a separate, personal work environment, especially on esoteric machines. That's why we worked hard to prepare a standard work environment using VMware for the entire class.
The following annotated example shows you step by step the commands needed to build a Linux kernel:
ssh user@vmpool.oslab.cs.sunysb.edu
vmware &Note: from now on, all your commands should be executed inside your own virtual machine, the one you just rebooted.
cd /usr/src
wget ftp://ftp.fsl.cs.sunysb.edu/pub/linux/kernel/v2.6/linux-2.6.30.5.tar.bz2or
ncftpget ftp://ftp.fsl.cs.sunysb.edu/pub/linux/kernel/v2.6/linux-2.6.30.5.tar.bz2Note that the first assignment must be done in linux version 2.6.30.5 Subsequent assignments may be required to use a different version of the kernel. In that case, replace "2.6.30.5" in the instructions the follow with the newer version of the kernel.
tar jxf linux-2.6.30.5.tar.bz2
rm linux-2.6.30.5.tar.bz2
cd linux-2.6.30.5
make menuconfig
An easier alternative to configuring a kernel is to use one of my own kernel configuration files, designed for VMware:
cd linux-2.6.30.5 wget http://www.cs.sunysb.edu/~ezk/cse506-f09/vmware.config mv kernel.config .config make oldconfigNote that if you choose to use my pre-configured kernel configuration file, you still have to know how to configure Linux kernels (and you'll be tested on it).
make
Note: in the following instructions, commands which appear in red are executed as root. Then run these commands:
/bin/su -
make modules_install
make install
emacs /etc/grub.confThe entry you can add has the following text:
# to boot from the first IDE drive, first partition title test kernel (2.6.30.5 ide) root (hd0,0) kernel /boot/vmlinuz-2.6.30.5 ro root=/dev/hda1 # to boot from the first SCSI drive, first partition title test kernel (2.6.30.5 scsi) root (hd0,0) kernel /boot/vmlinuz-2.6.30.5 ro root=/dev/sda1Be careful not to change anything else in grub.conf, or you could render your system unbootable and then you'll need to reinitialize your vmware. In particular, leave behind the original entry for the default Red Hat kernel. When you're done adding the new kernel entry to grub.conf, save the file, and exit the editor.
rebootWhen the system will boot, you will see a GRUB menu that now lists two possible kernels to boot. The first (default) one is the one that came with the system and is always good to boot into as a backup solution. The second entry should be the one that you just installed. Use the arrow keys to select the second one (within 10 seconds) then hit ENTER to select it. Your system should now boot your new kernel. When it comes up, login as yourself to ensure that everything appears to be in working order.
Do not wait until the last minute before submission time to figure out how to submit your homework assignment. Learn these procedures well ahead of time, experiment with them, and try and try again. You can submit your assignment as many times as you'd like, but we will consider the last set of files you've submitted as the ones you want us to grade. Don't be late because we won't accept late submission excuses such as "CVS didn't work for me."
To simplify matters for you we've set up CVS repositories for everyone.
Warning: protect your homework from accidental loss! All of the files you have in your home directories are not being backed-up. That means that if you remove your files my mistake (happens a lot, often right before a due date), you will lose all of your data and won't have anything to submit. Using CVS you can make a copy of your files and more: record each version of your files as you change them. It is your responsibility to use CVS often. The graders will not accept excuses such as "I just removed all my files and can't submit my homework."
ssh user@vmpool.oslab.cs.sunysb.eduwhere user is your oslab/FSL Unix login name.
cd export CVS_RSH=ssh cvs -d user@cvs.fsl.cs.sunysb.edu:/scm/cvsroot checkout cse506/userWhen this step is done, you will have four subdirectories created: cse506/user/hw1, cse506/user/hw2, cse506/user/hw3, and cse506/user/hw4 (depends if there are three or four assignments total): one for each homework assignment. Note again that this checkout procedure must be done only once: repeating it can confuse CVS into using recursive repositories, and your homework could be lost.
cd ~/hw1-template cp Makefile README *.c *.h ~/cse506/user/hw1/
cd ~/cse506/user/hw1/ cvs add Makefile README *.c *.hIf you have other files to include in your submission, you should "cvs add" them as well. But, do not submit or add/commit binaries or other object files: those can be produced easily by running "make."
cd ~/cse506/user/hw1/ mkdir test cvs add testThe last command is crucial to tell CVS that "test" should now be version controlled. After that you can create new files in test/ and "cvs add" them.
cvs commit -m"message"Replace message with a descriptive message that will help you and us know what was the purpose of your commit. For example:
cvs commit -m"saving initial hw1 files"At this point you have committed the first version of your files. This committal is in fact a submission method: we get an email notification each time you commit files, so we know which files were committed and when.
Now you can go ahead and edit your sources, add new ones, compile your code, etc. In fact, from this point on, you should not continue to work in your older ~/hw1-template/ directory. Instead, work in the ~/cse506/user/hw1/ directory, where you can add new files and safely commit them to CVS for backup and submission purposes.
cvs commit -m"add support for encryption"It's perfectly OK for you to commit (read: submit) your files as many times as you'd like. If you submit many times, we will grade the very last version of your files which you've submitted.
cvs -n update -dAny file listed as a result of the above command, and which has a "?" symbol in front of it, is a file which the CVS server doesn't know about (meaning it does not get committed by default). You may see object files and other temporary editor files listed as unknown. That's OK, because they are not supposed to be committed anyway. But any other file, especially a source file, must be "cvs add"ed and committed.
Second, you can check out a second, temporary version of your own committed files and verify that they compile and run as you expect them to:
mkdir ~/tmp cd ~/tmp export CVS_RSH=ssh cvs -d user@cvs.fsl.cs.sunysb.edu:/scm/cvsroot checkout cse506/user/hw1 cd ~/tmp/cse506/user/hw1 makeIf the above "make" command succeeds, you know for example that the code you've committed indeed compiles. You may now test that code inside VMware to ensure that it works (just because it compiles doesn't mean that it works).
cd ~ rm -fr ~/tmp/cse506/user/hw1
cd ~/cse506/user/hw1 rm -f READMEWell, you can easily restore that file from your committed files as follows:
cvs update -dCVS will check back out any files that were committed into the CVS repository but are now no longer in your checked out copy. (If you're going to try this, be careful not to remove a file that you haven't really committed, or it'll be lost forever.)
cvs status foo.cYou can get a detailed history using the log command:
cvs log foo.cThe latter will show you your log messages and version numbers of foo.c. You could then, for example, check what changes you've made between version 1.2 and 1.3:
cvs diff -u -r1.2 -r1.3 foo.c
