Difference: UgradLabPolicy ( vs. 1)

Revision 12015-08-19 - DaveCostello

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="AcceptableUseGuidelines"

Undergraduate Lab Policies

Computer Science Department
University of Rochester
September 2015

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/twiki/bin/view/Main/UgradLabPolicy. 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.

Use of Accounts

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: such files 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.

The Undergraduate Labs

Physical access to the undergraduate labs is by electronic card reader. Swipe your UR id to get in. University IT (not CS department staff) manages the card readers and logs entries and exits through the doors. Access via the card reader must be requested from University IT. CS staff usually requests access for individuals at the time of their CS account creation or if their CS status changes. If your card stops working you should report it to labstaff.. 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 labstaff@cs.rochester.edu). 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.

Printers

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 PDF, use evince or okular. 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.

Disk Space

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 and (especially) video 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 a version control system (rcs, cvs, svn, hg, git, ...). These maintain a record of only the changes in your files, and use much less space.

Other Issues

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.

The Research Labs

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, visit your advisor fill out the on-line form together (https://www.cs.rochester.edu/urguest/login.php). 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 renew your account explicitly each 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.

Grievance Procedures

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.

-- {updated - 2015-08-19}

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.

Use of Accounts

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: such files 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.

The Undergraduate Labs

Physical access to the undergraduate labs is by electronic card reader. Swipe your UR id to get in. University IT (not CS department staff) manages the card readers and logs entries and exits through the doors. Access via the card reader must be requested from University IT. CS staff usually requests access for individuals at the time of their CS account creation or if their CS status changes. If your card stops working you should report it to labstaff.. 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 labstaff@cs.rochester.edu). 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.

Printers

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 PDF, use evince or okular. 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.

Disk Space

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 and (especially) video 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 a version control system (rcs, cvs, svn, hg, git, ...). These maintain a record of only the changes in your files, and use much less space.

Other Issues

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.

The Research Labs

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, visit your advisor fill out the on-line form together (https://www.cs.rochester.edu/urguest/login.php). 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 renew your account explicitly each 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.

Grievance Procedures

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.

-- {updated - 2015-08-19}

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback