CSE-376 Lab Facilities (Spring 2021)
Introduction
We have set up limited lab facilities for use by registered class students
during the semester. The lab's machines are accessible only remotely and
via a secure shell. Details are provided below. Note that the procedures
we describe here will be updated and adjusted as needed throughout the
semester.
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 an older version of Microsoft
Windows on laptop from your
dorm), then download
a freely available version
called Putty.
Note that Linux and Mac OS X systems all come with ssh clients, as well as
newer Windows systems (ssh client in PowerShell).
- 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.
The lab facilities are limited. Start your homework early! Don't wait
until the last minute. The more people compile code all at once, the slower
the lab facilities will be. Vary your time of work: some people prefer
day-time work, some like to work late at night, some over the weekends.
Check who else is on your system (by running /usr/bin/w) and what the load
is (using /usr/bin/uptime).
Getting Initial Access
To be able to do your homeworks, you need to do the following three things.
Both can be done independently.
-
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.
-
Second, you must subscribe to
class piazza forum (if you're not already subscribed by me).
A lot of useful information will be provided via
piazza. Through the forum, 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 forum, 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 your email and to stay current
with what I post there.
- Third, you need an account on the CS 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.)
The machines that we set up for your use are as follows. Note that this
list will be updated throughout the semester, so check this Web page
frequently.
| No. |
Host Name |
Running Operating System |
| 1 | cse376u18.cs.stonybrook.edu | Ubuntu 18 Linux (x86_64) |
| 2 | cse376b.cs.stonybrook.edu | Ubuntu 18 Linux (x86_64) |
Several more machines may be added throughout the semester.
To login to one of these machines (say, cse376u18):
ssh -p 130 user@cse376u18.cs.stonybrook.edu
Where user is your username for the account that was given to you on
the CS Active Directory (AD) server (your CS AD username is most likely the
same as your SBU NetID, but using a different password). If you are using
the same username, you can omit the "user@" part. Note you have to
use port 130 not the default port 22.
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.
This section includes information on how to submit your code
via GIT. This is not a comprehensive
guide to GIT, so consult the full
GIT manual for more help.
GIT is a superior Source Control Management (SCM) system than both CVS and
Subversion.
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 "GIT didn't
work for me."
 |
Warning: protect your homework from accidental loss!
All of the files you have in the virtual machines of this class
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 GIT 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 GIT often. The graders will not
accept excuses such as "I just removed all my files and can't submit my
homework."
|
To simplify matters for you we've set up GIT repositories for everyone.
- SSH to your VM:
ssh -p 130 user@cse376u18.cs.stonybrook.edu
where user is your CS AD login name.
- Retrieve the your sources via GIT. Each of you have been given
a personal GIT repository for each homework assignment.
git clone ssh://user@scm.cs.stonybrook.edu:130/scm/cse376git-s21/hw1-user
where user (twice in the above command) is
your AD username. You'll be prompted for your CS AD
password. (Note: the exact URL may be different, so use the one in the
actual homework description, if any.)
The initial checking out (or "cloning") of the git repository will take some
time. Using your checked out repository afterward will be faster.
Note again that this checkout procedure must be done only once: repeating it
can confuse GIT into using recursive repositories, and your homework could
be lost.
-
Next, you can modify any existing source file, then type "make" to compile
your changes, install them, and test them.
-
If you add new files to the repository, you will have to tell GIT to commit
them in the repository:
git add newfile.c
If you have other files to include in your submission, you should "git add"
them as well. But, do not submit or add/commit binaries or other object
files: those can be produced easily by running "make".
-
If you wish to create subdirectories under a certain GIT repository, you can
do so as follows. For example, to add a subdirectory "test":
mkdir test
git add test
-
You can check your uncommitted changes using:
git diff
-
You can list which files have changed using:
git status
-
When you are ready to commit changes, you first have to update the GIT index
of any changed file:
git update-index changedfile.c
- After updating the index of the file, you will have to commit it to your
local repository:
git commit
Be sure to provide a suitably detailed commit message to explain what you
did.
-
Note: at this point, all git did is commit your changes to
the local repository only. These changes are NOT safe from VM
corruption. To ensure that your changes have made it to the
remote (and save) copy on the "scm.cs.stonybrook.edu" machine, you have to
"push" the changes:
git push
- You can also check what was committed using
git log | more
There are many more GIT commands you could use. Check the documentation
online, man pages, and more.
Lastly, 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:
cd ~/tmp
git clone ...
cd hw1-user
git log | more
# configure/test your code, etc.
Last Updated: 2021-02-11
