Introduction

There are restrictions on the use of the Lab facilities:

• Only registered users may use it.
• Auditors cannot use the lab.
• Access to the lab is via SSH only. If you are running on a host that does not have SSH installed (for example on your Windows XP laptop from your dorm), then download a commercial version and then install it; alternatively, you can get a freely available version called Putty.
• Aside from getting SSH software, you will also need to have firewall access enabled for your SSH access to the OSlab. If you are working on campus, you automatically get access. But if you are working remotely, say from home, then you need to visit this secure Web site to enable remote SSH access through the OSLAB firewall. Note that you visit this Web site only after your OSLAB Unix account had gotten created.
• Lab use is for class work only and only for this class. DON'T USE THIS ACCOUNT FOR YOUR OTHER CLASSWORK OF ANY OTHER CLASS. Students caught using this account for other classes will have their accounts turned off and all files related to other classes deleted.
• People caught "hacking", cheating, or abusing the resources will be denied access to the facilities and be handled in accordance to the university's policies on academic dishonesty and computer use.

Getting Initial Access

1. First, be sure you have a place to sit and do you work remotely. These days many students prefer to use dorm room computers or personal laptops. You can also use any of the university's SINC sites, as well as the CS department TRANSLAB rooms.
2. Second, you must subscribe to class mailing list. A lot of useful information will be provided via the mailing list. Through the list, we can distribute information much more quickly to the class students than during the weekly lectures.

   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.

   Please do not set your list subscription mode to Digest because digests can take several days to get emailed to you.

3. Third, you need remote login access to the OSLAB, the lab that includes the machines on which you will program and test your programs. Note, you will not get physical access to this lab; you can only login to it remotely via SSH. Getting an OSLAB account takes several days, so start early. To apply for a OSLAB account, first register for the course, then use the CSE-376 Student OSLAB Account Request Form. Once you applied for this account, please wait 1–2 days for the account to get created (you will be informed via email, so make sure to put down a valid active email address you use).

   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.

4. Lastly, if you plan to work remotely (off campus), then you'll need access through our OSLAB firewall. After you get your OSLAB account activated (you'll get an email confirmation), then visit this secure Web site to enable remote SSH access through the OSLAB firewall.

Secure Shell (SSH) Access to OSLAB

Firewalled SSH Access to OSLAB

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.

X11 Tunneling

Trusted X11 Forwarding

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 :-)

Using the Class Work Machines (OSLAB)

To login to one of these machines (say, a-centos5):

ssh user@a-centos5.fsl.cs.sunysb.edu

Once you get into your one of the work machines machine, you can start editing source files and compiling as needed. Your home directory is shared using NFS across all of the aforementioned machines.

CVS: Submitting, committing, and backing up your code

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."

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."

1. Login to one of the oslab machines:

   ssh user@a-centos5.fsl.cs.sunysb.edu
   

   where user is your oslab/FSL Unix login name.
2. Check out a personal copy of your committed files. This step needs to be done only once throughout the whole semester.

   cd
   export CVS_RSH=ssh
   cvs -d user@cvs.fsl.cs.sunysb.edu:/home/cvsroot checkout cse376/user
   

   When this step is done, you will have four subdirectories created: cse376/user/hw1, cse376/user/hw2, cse376/user/hw3, and cse376/user/hw4: 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.
3. Next, copy your actual work files from where you were working on them, onto the proper CVS homework directory. Suppose your homework 1 files were located in the subdirectory hw1-template in your home directory:

   cd ~/hw1-template
   cp Makefile README *.c ~/cse376/user/hw1/
   

4. Now that you've copied the files into your checked out CVS repository, you must add them to the repository, since they are new files that have never been committed into CVS before. Note you need only add a file to a CVS repository once.

   cd ~/cse376/user/hw1/
   cvs add Makefile README *.c
   

   If 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."
5. If you wish to create subdirectories under a certain CVS repository, you can do so as follows. For example, to add a subdirectory "test" under hw1/:

   cd ~/cse376/user/hw1/
   mkdir test
   cvs add test
   

   The last command is crucial to tell CVS that "test" should now be version controlled. After that you can create new new files in test/ and "cvs add" them.
6. Now you can finally commit your files (for the first time) to the CVS server. It is only after you commit your files that they will actually be added to the repository:

   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 ~/cse376/user/hw1/ directory, where you can add new files and safely commit them to CVS for backup and submission purposes.

7. If you add new files that you want to commit, run "cvs add" on them. After editing your files, you can commit them using something like:

   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.
8. It is also important to check that you have submitted all of the necessary files to the CVS repository. First, check which files in your checked out repository are unknown to the CVS server:

   cvs -n update -d
   

   Any 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:/home/cvsroot checkout cse376/user/hw1
   cd ~/tmp/cse376/user/hw1
   make
   

   If 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).
9. When you're done testing the sources you committed in the temporarily checked out version, you can remove those temporary files (best not to leave a second copy of your work behind, which can be confused for the "master" copy):

   cd ~
   rm -fr ~/tmp/cse376/user/hw1
   

10. Now, suppose after you've committed your files, you lost one of your files (in the "master" checked out copy) because of it got removed by mistake:

    cd ~/cse376/user/hw1
    rm -f README
    

    Well, you can easily restore that file from your committed files as follows:

    cvs update -d
    

    CVS 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.)
11. Lastly, suppose you want to find out the history of a file (say foo.c) you've committed several times. You can check it's status using

    cvs status foo.c
    

    You can get a detailed history using the log command:

    cvs log foo.c
    

    The 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