Policies and Guidelines
Department of Computer Science
University of Rochester
The policies and guidelines 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.
You can always find the most current version of this document available at http://www.cs.rochester.edu/undergrad/policy.html.
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.
Use of Accounts
All registered CS department majors receive linux shell accounts on the csug.rochester.edu instructional network to perform their coursework.Account access is available on lab machine in Wegmans Hall second floor lab room 2009. These accounts continue from semester to semester, provided the student maintains satisfactory progress toward the Bachelor's degree. Non-majors will not have access to the majors lab. Non-majors registered for upper-level CS courses (above 172) generally receive accounts in the instructional lab at Hylan 301. Accounts for majors expire following graduation. Accounts for non-majors expire following 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. 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 at deadline times, do not leave one unattended for more than 10 minutes. For short breaks, use a screen locking 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 Matlab. 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. 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, or 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.
Running of unattended distributed scripts, crawlers, or scrapers are prohibited on the network. Running of any bitcoin type mining software on CS equipment is expressly prohibited.
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.
Offensive or harassing behaviors are not allowed. This might include sending offensive or questionable e-mail, posting offensive news, or displaying potentially offensive or inappropraite images on your own screen or someone else's. The definition of *offensive*, *harassment*, or *inappropriate*, are at the discretion of the Lab Manager (subject to the advice and consent of the Lab Committee). Using common sense will serve you best.
Don't attempt to hide or misrepresent your identity in e-mail, news, or other on-line activities.
Remote access to your CS linux shell account can be accomplished via SSH. Use an ssh client to connect to one of the three inbound ssh servers (cycle1.csug.rochester.edu, cycle2.csug.rochester.edu, cycle3.csug.rochester.edu). Once connected to a cycle host you may then connect via ssh to other hosts on the csug.rochester.edu when appropropriate.
example: ssh -l MYUSERNAME cycle1.csug.rochester.edu
For some CS coursework special hosts may allow direct ssh access via a University VPN connection. http://tech.rochester.edu/services/remote-access-vpn/
The Undergraduate Labs
Physical access to the undergraduate labs is by electronic card reader. Swipe your UR id to get in. The access system is managed by the University and records of door access and times are stored in their management system. If you believe your card does not allow you access to a lab you believe you should have access to please report the trouble to the undergraduate coordinator (Brynn Wilkins). DO NOT ALLOW unauthorized people into the lab. DO NOT PROP DOORS open. DO NOT LEND your ID card to others.
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.
Don't deliberately damage anything, and report any accidental damage (to firstname.lastname@example.org) as soon as possible. If you are present when a piece of hardware or software fails, please report this also.
DO NOT rewire, recable, uncable, or connect other devices to network drops.
Food and drinks are not allowed in the undergraduate labs.
Black-and-white laser printers are available in all labs for CS coursework and research only. Personal printing is not permitted.
To minimize wear and tear, don't print multiple copies of anything; print a master and then go find a photocopier. Do not print unnecessarily. Do not print large documents when digital versions are available. Do not waste paper and printer consumables. Print in two-sided duplex mode when ever possible.
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 large, 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, video, images, sound files, and rich-text documents (postscript or TEX dvi) tend to be larger. Learn to use ls -l, du, and quota -v to find out where your space is.
Periodically scan your home directory for backup files, compilations, or unemptied trash bin contents to reclaim space. You may also find it useful to make use of zip or gzip compression on files to save space.
Learn to use source revision control software. Several are available, rcs, svn, git are examples of software to help you manage changes to your code during development.
Avoid spawning lots of background tasks on the remote login servers Avoid tying up large amounts of network bandwidth Avoid consuming excessive space in /tmp
Check that your project code has terminated when you are done testing it to avoid runaway resource hogging processes. If it hasn't exited gracefully use the kill command to stop it.
CS systems access is recorded and monitored by the staff (logins, printer use, network activity etc...) Abuse of CS systems will not be tolerated.
Staff system administrators can access all files on the system to troubleshoot and maintain the systems. Staff does not make a practice of regularly accessing user accounts or accounts contents but will do so when necessary to troubleshoot problems, investigate issues, or contain an ongoing event. If a user account is compromised it may be disabled and investigated by CS staff and University security personnel.
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.
If staff suspects that you have violated laboratory policy or presented some threat or abuse to CS resources, they reserve the right to disable your account in order to protect the rights and interests of others and protect department resources. For minor violations a simple warning may be issued. If your access is disabled, you may find that your id card will no longer operate the door locks, and you won't be able to log into your account, either in person or remotely. You should contact your instructor and/or the staff immediately to resolve any possible misunderstanding.
If you believe you have been mistakenly accused and your account remains disabled, 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 disabled. If you choose to appeal your access being disabled 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.
(department of computer science 9 May 2018)