Policies governing the use of
Open Computing Facility resources

These policies can also be found on OCF machines in the directory /opt/local/share/OCF/Official_Documents/Policies

1) Policies governing all users

• 1.1) Eligibility for using OCF resources
  The Open Computing Facility provides accounts and services only to people who meet at least one of the following eligibility criteria as verified by presentation of the specified documentation:

  1) UC Berkeley Students

  Student Picture ID or Current Registration Card plus photo id. (If the student does not have either of the above IDs, they may get a temporary Student ID at the Cashiers' Office. This ID has an expiration date and must be accompanied by a secondary photo ID.)

  The student's current registration status will be checked electronically.

  2) Faculty and Staff--Any Faculty or Staff Member who is directly associated with UC Berkeley

  Current UC Berkeley Staff or Faculty ID Card

  3) Post Doctoral, Visiting Scholars, Research Assistant, etc.

  Must have letter from their department on departmental letterhead stating(*):

  • Name
  • Appointment Length
  • Departmental Support for the Computer Account

  4) Lawrence Berkeley Laboratory (LBL) Staff

  LBL Staff ID Card

  5) Graduate Theological Union Students (GTU)--Current Doctoral Students ONLY! Masters program not eligible.

  Must show student ID card.

  6) ASUC Employees

  ASUC employees must show their emplyee ID card

  7) Math Science Research Institute (MSRI)--Postdoc Researchers or Research Professors.

  Must have letter from the department on departmental letterhead, stating(*):

  • They hold a valid appointment with the University
  • Departmental Support for the Computer Account

  8) UC Extension Faculty (Faculty Extension Faculty are usually instructors, and not titled "Faculty", primarily due to the part-time role)

  An appointment letter marked as independent contractor by agreement for a term.

  9) UC Berkeley Extension Students--Students enrolled in certificate programs (Note: A large number of Extension Courses do not lead towards Certificate programs) or concurrently enrolled in courses offered by UC Berkeley.

  Qualified UC Extension Students must show the following:

  • Enrolled in a credit course (confirmed by copy of enrollment confirmation) for classes numbered 1 through 499,
    OR
  • Enrolled in a certificate program (confirmed by documents and/or receipts for the certificate program),
    OR
  • Enrolled in a UC Berkeley class concurrently (confirmed by a copy of paid and signed concurrent enrollment form).

  10) Employees of other University-affiliated organizations who work on the UC Berkeley campus (i.e. California Alumni Association, International House, Howard Hughes Medical Institute) or are closely associated with the Berkeley campus (i.e. Richmond Field Station).

  Must have letter from their organization/unit on letterhead, stating(*):

  • Currently an employee of the organization
  • Organizational Support for obtaining the Computer Account

  11) Volunteers, contractors, and other individuals who work on campus supporting the University.

  Must have a letter from the sponsoring department on departmental letterhead stating(*):

  • Individual is affiliated with the department.
  • Department supports the individual's request for a Computer Account

  12) Student groups, staff groups, or campus support organizations.
  (Additional restrictions apply, see the Group Account Policy)

  • Copy of a completed SAS form for student groups,
    OR
  • Letter on departmental letterhead(*) verifying departmental recognition of the group and supporting their request for a group account,
    OR
  • Sufficient documentation to establish that the group has been recognized by the Chancellor as a support organization and that the person making the request for the group account is authorized to make that request.

  * All letters supporting an account should be on appropriate letterhead, must signed by someone other than the account applicant, and should include contact information for the person signing the letter for verification purposes.

  [per OCF Board decision, 3/10/97]

• 1.2) Obtaining access to the OCF resources
  
  • 1.2.1) All OCF account-holders must sign a form agreeing to abide by OCF policies [per OCF Board decision, 2/23/89], and agreeing not to hold the University responsible for lost files or other misfortunes which may result from their use of OCF services [per Memorandum of Understanding].
  • 1.2.2) No user may be forced to pay any fees for use of the OCF services. [per Memorandum of Understanding]
  • 1.2.3) Membership in the OCF is not required for use of the OCF services, nor does it provide any special privileges or entitlement to OCF services. [per Memorandum of Understanding]
  • 1.2.4) Each OCF user may have one and only one account on the OCF computers at any time. Each OCF user must use their own account and may not allow anyone else to use their account. Each OCF user will be held responsible for actions committed with their account. [per OCF Board decision, 2/16/89]
  • 1.2.5) OCF users may choose their own account names, but they must be reasonably based on the user's real name. [per OCF Board decision, 10/10/91]
• 1.3) Acceptable Uses of OCF resources
  • 1.3.1) Possession of password-cracking programs on the OCF is legitimate. Cracking passwords on the OCF is not a legitimate use of the OCF or of the aforementioned programs, and can/will be sufficient cause for staff to turn an account off. If staff sees somebody running a password-cracking program, staff may ask that person to explain his actions. He will have one week to explain them, and will not use the mentioned programs during that one week under pain of account termination. [per OCF Board decision, 10/24/91]
  • 1.3.2) Use of the OCF for an ongoing business is prohibited. Notice of such use will result in such use being stopped.
• 1.4) Allocation of limited OCF resources
  • 1.4.1) Each user shall be allowed to use up to 5 megabytes of disk space, including storage for files in home directories, mail spools, and files available via OCF servers [per OCF Board decision, 9/18/96]. Waivers extending this limit may be requested from the OCF Disk Usage Management Board [per OCF General Meeting decision, 2/28/96].
  • 1.4.2) Each user shall be allowed to print up to 250 pages per semester. After this limit is reached, further printing privileges may be obtained via a procedure to be determined by the Site Manager. [per OCF Board Decision, 2/11/93]

2) Policies governing group accounts

• 2.1) Any group recognized by Student Activities and Services or sponsored by a university department may obtain a group account by contacting any OCF Staff Member. Other organizations require the approval of the Board of Directors.
  • 2.1.1) However, this policy shall not be interpreted as overriding the requirements of section 1.2.4. In particular, the OCF Decision Making Process retains the right to grant only one account to a student group, even to a group that has registered as several organizations with the Office of Student Life, if the purportedly separate groups are substantially similar in membership and purpose.
• 2.2) Group accounts will be subject to a disk quota equaling the same amount as the regular user disk quota.
• 2.3) Because group accounts create an opportunity for anonymous malicious hacking, OCF rule violations done with group accounts will be handled much more strictly than with user accounts.
• 2.4) Group account passwords may not be distributed to people who aren't members of that group or who are not eligible for a personal OCF account.
• 2.5) Group accounts must answer any mail they get from the system administration within a week.
• 2.6) Group accounts must at all times have one user who is responsible for that group account, and must provide a non-email contact for that person (e.g., a phone number).
• 2.7) Group accounts must be listed in a public file maintained by the Site Manager, currently /usr/local/OCF/Group_Accounts.
• 2.8) Group accounts are intended to build a sense of community. Therefore, we also require groups to make the following information available either in their .plan files or on their web pages:
  • Description of the organization.
  • Ways to get involved with the organization.
  • How to get in touch with the person responsible for the account.

3) Policies governing OCF Staff

3.1) Staff members shall be chosen by the OCF Decision Making Process. [per OCF Board decision on 4/13/89]

3.2) Flaming Policy

Staff members should NOT flame users within their capacity as staff members or as a result of staff actions. We've had cases when users who did not know what they were doing caused damage to the cluster. We've also had cases when users flamed staffers for staff actions. In both of these cases, while the temptation to flame back is high, the current site manager feels that it would be more beneficial to rationally address the user's concerns (or mistakes). This way, the user may actually understand why he was wrong, rather than be alienated by a flame.

Users should probably understand that this does NOT mean staff will never mail you and say "You REALLY screwed up." It does, however, mean, that if we say you screwed up, we'll also try to make sure you understand how you screwed up. We'll also refrain from using terms such as "Steaming Pile of Excrement. . ." :-)

Please understand, also, that while some staff guidelines are absolute (staff members who delete your directory because they don't personally like you WILL lose staff and superuser privileges, and probably get their accounts turned off), this guideline is a recommendation. In other words, if a staff member does flame a user, the site manager will probably remind of the staff member of the policy, and repeated flaming could possibly get him gently shoved off staff.

3.3) Privacy policy

Staff all have pretty similar ideas as to when to use root to look in a user's account and when not to. Generally speaking, if the user is a possibly serious threat to the cluster (if a staffer has seen them cracking passwords, logging in from various strange places WITHOUT explanation, etc. . .), staff can use limited root to give his account a cursory glance. Files, if possible, should NOT be read. Their mail box should NEVER be read (a possible exception to this is the postmaster, but dpassage knows better than me the confines of his job, and staffers who remove strange characters in the mail box so it can be read, in which case, they should NOT read what is in the mail box). If a user asks us a question which implies that he is granting staff permission to look in his files, fine -- we will look in his files. In this case, however, we will only look in the relevant files. I realize this policy is vague. It is intended to be vague, so staff can have the freedom of movement to execute the job efficiently. Having a vague policy also means that staff can get away with more, and means that if I think a staffer abused the policy, probably nothing will happen to him. The first time. But I WILL make sure that staffer understands the limits of it, and that he NEVER EVER abuses it again.

3.4) Erasing Files

There are only two possible reasons to erase files:

• A) The user has asked us to erase them (he may have had problems removing them himself, if they're called '-*&" for example)
• B) The user has been over his quota for the length of time dictated by the current disk-quotas policy. In this case, his files will be removed, starting from the biggest to the smallest, until he is under his quota.

There should be no other reasons to erase files.

3.5) Maliciousness.

The WORST thing a staffer could do is abuse root privileges. Examples of this are improperly removing files, maliciously harassing users, maliciously logging people out, etc. In cases like this, when the site manager decides that a staffer has acted maliciously, that staffer will be squished. HARD.

3.6) Authorization

Staff is generally authorized to act independently of the SM in most situations. This is so decisions do not have to be delayed by the bureaucracy of having to ask the SM for approval for all decisions, especially when sometimes staff needs to do something immediately, and the SM isn't around.

There are some things, however, that always require SM approval. They are:

• 1) Taking accounts off-line for more than the length of a reboot. That is, accounts should not be erased or backed up to tape and made unavailable to their owners without the authorization of the SM or the explicit request of the owner of the account.

4) Other policies

• Policy on Unattended Processes

References

• The Constitution of the Open Computing Facility. Ratified February 3, 1989, and amended March 21, 1990; May 14, 1991; and November 21, 1991.
• Memorandum of Understanding between Apollo Computer Inc., U.C.B. Information Systems and Technology, and the Open Computing Facility. Signed November 21, 1988.