Computer Science Department
University of Rochester
The policies described in this document govern the use of all accounts on machines belonging to the UR Computer Science Department. Policies are established on behalf of the faculty by the department's Laboratory Committee, with the advice of the laboratory staff.
This document is subject to change. The current version is always available on-line at http://www.cs.rochester.edu/undergrad/policy.html. Hard copies are available from Marty Guenther in room 735.
Laboratory policies, and laboratory procedures in general, are designed to meet the needs of a mutually-supportive and respectful community of users. The department implements obvious internal safety measures, but its principal security mechanism is to deny access completely to individuals who are unwilling to be part of such a community. The fundamental guidelines for all users are courtesy and common sense. This document provides some more specific rules, but does not attempt to describe all forms of inappropriate behavior.
All registered CS department majors receive accounts in the West lab (room 633). These accounts continue from semester to semester, provided the student maintains satisfactory progress toward the Bachelor's degree. Non-majors registered for upper-level CS courses (above 172) generally receive accounts In the instructional lab in Hylan 301. Accounts for majors expire one month after graduation. Accounts for non-majors expire two weeks after the final exam of the course(s) for which they were created.
Accounts are for the use of the owner only. You must not share your password with anyone else or allow anyone else to use your account while you are logged in. You must take reasonable precautions to keep your password safe and to set file permissions to prevent inappropriate access.
Non-major accounts should be used for CS coursework only. Major accounts may be used for other purposes, but at a lower priority: you should yield a machine to anyone who needs to get coursework done. Commercial or illegal activities are expressly forbidden for all accounts.
When you are seated at a workstation the machine is ``yours.'' You may ask remote users to log off (use the talk command). Since workstations are a somewhat scarce resource, do not leave one unattended for more than 10 minutes. For short breaks, use the xlock program to prevent unauthorized use of your machine. Do not log into the console of more than one workstation at a time.
If there is high demand for workstation seats, don't monopolize one for too long. If you need access, feel free to ask a current user to let you in for a while. If you receive such a request from someone else, please respond politely.
We have a limited number of ``floating licenses'' for certain software, notably Mathematica. Quit these programs when you're done with them, so others can use the license.
Respect the privacy of other users. Don't poke around in other people's files, even if they have not protected them against you (you don't feel invited to walk into a stranger's house just because someone forgot to lock the door). In addition to violating privacy, inappropriate access to files is often a violation of the University's policy on academic honesty.
Respect the integrity of the lab and its systems. Do not attempt to compromise physical or electronic security in any way. This includes propping lab doors open or letting unauthorized people in. ``Hacking'' of any kind-even the possession of worms, viruses, etc.-is expressly forbidden. If you think you have a legitimate reason to experiment with computer security, you must obtain special permission from the lab staff in advance.
Do not create a .rhosts file: they make it easier for outsiders to break into our systems. (If you don't know what a .rhosts file is, don't worry; you won't create one by accident.) If you discover a security problem, please report it.
Don't steal software. Some of our software (e.g. the GNU tools) can be freely redistributed. Much of it, however, is licensed to us and cannot be copied. If you have access to proprietary source code, be careful not to incorporate it into your own code unless you have written permission to do so, and take steps to ensure that you don't give access to anyone else.
Don't do anything to offend or harass others. This includes sending offensive e-mail, posting offensive news, or displaying offensive images on your own screen or anybody else's. The definition of ``offensive'' and ``harassment'' are at the discretion of the Lab Manager (subject to the advice and consent of the Lab Committee). Don't attempt to hide or misrepresent your identity in e-mail, news, or other on-line activities. Use common sense; be polite.
Physical access to the undergraduate labs is by electronic card reader. Swipe your UR id to get in. The department reserves the right to keep a record of who comes in when. This record is accessible only to department staff and faculty, and only for official purposes. If other people's cards don't work, it probably means they aren't supposed to be there; don't let them in!
Don't take any lab materials out of the room, even temporarily. This includes not only computers, but also manuals, chairs, tapes and disks, etc. Obviously, don't deliberately damage anything, and report any accidental damage (to firstname.lastname@example.org). If you are present when a piece of hardware or software fails, please report this also. We can't fix things if we don't know they're broken.
Don't attempt to fix things by yourself. In particular, don't power-cycle, re-cable, move, or otherwise mess with the hardware unless a staff member asks you to do so.
Food and drinks are not allowed in the undergraduate labs.
Before email reaches computer science it is scanned for spam and viral attachments. If email appears to have a high probability that it is spam it is quarantined. Users can access their quarantined messages with a web browser. See http://www.rochester.edu/it/spam/ for links to both the quarantine and the spam management interface that allows you set options and preferences for spam control.
** If your Netid is not currently associated with your cs.rochester.edu email address you should login to the spam management page and add it. https://urspam.ur.rochester.edu/
After you login with your Netid choose: "I want spam to be managed for a New email address"
This will provide you with a form that has a drop down list of all addresses associated with your Netid. If your cs.rochester.edu address is not in the drop down list then fill in the
"Add new Email Address for spam management" field and hit the "Create Service Request" button.
If you don't associate your cs.rochester.edu email address to your Netid, spam addressed to your cs.rochester.edu email address will not be viewable in your online quarantine.
Additionally Spamassassin is available locally to further manage spam. @see http://www.cs.rochester.edu/twiki/bin/view/Main/SpamAssassin
All users are required to maintain a WWW ``home page'' under /u/www/u/user_id. This page must contain, at a minimum: name, user id, type of account (major, course), and faculty sponsor (advisor or instructor). You are strongly encouraged to include your picture; Marty Guenther in room 735 can help you get it on-line. You are also welcome to embellish your page with other information. Note that these pages are accessible to anyone on the Internet; think twice about adding anything you wouldn't want your Mom to see. Also, note that you are forbidden by law from using copyrighted material on you web pages unless you have the explicit written permission of the owner. Several Universities have recently been sued over use of copyrighted material on student Web pages.
Black-and-white laser printers are available in all labs for CS coursework and research.
To minimize wear and tear, don't print multiple copies of anything; print a master and then go find a photocopier.
Don't print anything you don't have to! There's no point in wasting paper. Think twice about making hard copies of mail, webpages, etc.
Learn how to use on-line viewers. For postscript, use ghostview. For TEX use xdvi. If you must print a copy of something for reference or to proofread, try putting two pages on a single sheet of paper. The enscript utility prints ``two-up'' by default. You can get the same effect for postscript files by using the psnup program. Man pages for all of these utilities are available on-line (e.g., type ``man ghostview'').
When you send something to the printer, be sure to pick it up promptly. You can use the lpstat command to see if your job has reached the head of the queue. If you send something to the printer by accident, you can delete it with the cancel command. This works even if the job has already started printing, so if you accidentally start something huge, you can kill it after the first few pages. If you find someone else's printout on top of yours, stack it neatly near the printer. Feel free to recycle any printouts that remain unclaimed for more than 24 hours. Note, however, that printouts are personal property; they should not be copied or even read without permission from the owner.
Undergraduate lab accounts come with a disk space quota. If you run over the quota you will be unable to create new files. If there are special reasons why you need more than the usual amount of space, talk to your faculty sponsor.
Be aware that certain kinds of files take much more space than others. Executables, images, sound files, and rich-text documents (postscript or TEX dvi) tend to be very big. Learn to use ls -l, du, and quota -v to find out where your space is. Also be on the lookout for ``backup'' files created by the editor (these often have a tilde [~] at the end of the name). You can disable the backup file feature in emacs by putting the command (setq make-backup-files nil) in a file named .emacs in your home directory.
If you are developing software you will probably want to keep copies of old versions of your source code. Don't use cp to do this! Learn to use rcs; it maintains a record of only the changes in your files, and uses much less space. Read the man pages for ci, co, rcs, rlog, rcsdiff, and maybe rcsmerge.
In general, try to make sure that your use of lab facilities does not inconvenience others. Don't run lots of background tasks on the remote login servers, tie up huge amounts of network bandwidth, steal all the space in /tmp, or anything else that's likely to be annoying.
To help identify problems, the staff keeps a record of logins, network traffic, disk and printer usage, and various other activities. Like keycard door records, these logs are considered confidential information, and are available only to the staff and faculty, and only for official purposes.
Staff members have the ability, as ``superusers'', to read or write any file on our Unix systems. To the fullest extent possible, however, they will respect the privacy of users. They will read your files only when necessary to safeguard the rights of others and ensure the integrity of the system. They will read .forward files, or .rhosts files created in violation of the rules. They may check the permissions on the top layer or two of your directories. If a serious breach of policy occurs and they believe you are responsible, they may read through your files in an attempt to isolate the problem.
Most of the guidelines above also apply to the research labs. There are no disk quotas, though we keep an eye on things, and count on everyone to exercise restraint.
Undergrads will be given accounts in the research labs only with the active sponsorship of a faculty member. In most cases this happens when the student joins a department research project. It may also happen occasionally as part of a special course. To get a research account, obtain a form from Marty Guenther (room 735), take it to your advisor, and fill it out together. You will need to specify exactly what the account is for, and how much disk and other resources you will need. If you need the account on a long-term basis you will need to get your advisor to sign a new form every semester (and at the beginning of the summer). Remembering to do this is your responsibility; if you forget, your files will be moved to tape and the account will be deleted.
Undergraduate research accounts are to be used only for their official purpose. Other use is not allowed.
The robot lab has special rules. The arms are powerful pieces of equipment. You shouldn't operate them unless you know what you are doing, and you should make sure you are never within reach when they are on: they can move at over a meter per second, and a software or hardware error could be fatal. Also be aware that mistakes can damage some very expensive equipment. If you don't know exactly what you are doing, don't even think about doing it.
If the staff suspects that you have violated laboratory policy, they reserve the right to ``lock out'' your account in order to protect the rights and interests of others. (For minor violations they may just give you a warning.) If you are locked out, you will find that your id card will no longer operate the door locks, and you won't be able to log in, either in person or remotely. You should visit the staff immediately to resolve any possible misunderstanding.
If you believe you have been mistakenly accused and your account remains locked out, you may appeal to your faculty sponsor. If you and your sponsor are unable to resolve the conflict, you may appeal to the Laboratory Committee. Beyond the Lab Committee you must abide by the procedures of the University's Academic Honesty and/or Judicial systems. While your case is under review, the department reserves the right to keep your account locked out. We assume no obligation to help you find another way to get your work done, unless it turns out that you have been mistakenly accused. If you choose to appeal a lock-out beyond the Lab Committee, and are unable to complete a course, the department will at your request grant you an incomplete. If the appeal is decided in your favor we will negotiate a process for resolving the incomplete. Otherwise you will receive the fall-back grade specified on the incomplete form.
Revised 8/29/07 by Marty Guenther