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 requires SSH. 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 one from the CS department or from DoIT, and then install it; alternatively, you can get a freely available version called Putty.
• 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 computer labs.
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 an account on the OSLAB network. If you are a registered student in this class, your account is already active. You don't need to apply specially for it. (This is a simplification/improvement over past methods.)

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 (e.g., CS's MS Exchange email system). It is particularly important that you follow these instructions to ensure that you could communicate with the teaching staff promptly.

Using the Class Work Machines (OSLAB)

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

ssh -p 130 user@a-centos56.cs.stonybrook.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 -p 130 user@a-centos56.cs.stonybrook.edu
   

   where user is your CS AD login name.
2. The CVS server you need to connect to runs SSH on a non-standard port (130). So you need to setup a simple script to connect to this machine, as follows. First, create a text file in your home directory (using a text editor), called "myssh". The contents of the file should be exacyly this:

   #!/bin/sh
   exec ssh -p 130 "$@"
   

   Then run the following command to ensure the file, a shell script, has the right execution mode:

   chmod 500 myssh
   

3. 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="${HOME}/myssh"
   cvs -d user@scm.cs.stonybrook.edu:/home/SCM/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.
4. 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/
   

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

8. 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.
9. 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="${HOME}/myssh"
   cvs -d user@scm.cs.stonybrook.edu:/home/SCM/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).
10. 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
    

11. 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.)
12. 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