|
Service Policies
This file is a collection of documents that describe the policies
and services provided by the Computer Science Department's Unix
support group, called "csops". Each document is separated by a
line like -=-=-=-=. Many are in the process of being developed and
are either incomplete or un-polished, but still might be useful as
guidelines. Formats vary and are marked in comments at the beginning
of each document. A quick index follows:
filename format contents
------------------------------------------------------------------
backups.nr roff -ms backup and recovery policy
authority.policy text who's in charge
csops.requests text who can ask for what
house.calls text support for home machines
pager text when to page
supported.disk.tape tbl, roff supported peripherals
supported.printers tbl, roff supported printers
supported.software text beginnings of software list
supported.systems tbl, roff supported operating systems
autonomous.machines text policy for errant machines
autonomy roff -ms policy for external sysadmins
downtime text downtime policy, notice required
policy.grouplogins text rules for group logins
policy.non.user.logins text rules for special logins
policy.nsfnet roff nsfnet acceptable use
power.outages text policy/procedures for power outages
backups.nr =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.\" Format with -ms
.\"
.ds LH \fIRFC BU001\fP
.ds CH \fIBackup/Recovery Policy\fP
.ds RH \fICSOps\fP
.ds CF \fIPage %\fP
.ds RF \\*(DY
.TL
RFC BU001 -- Backup/Recovery Policy
.AU
CSOps Committee
.AI
University of Colorado
Computer Science Department
Computer Science Operations
.AB no
This document will detail a backup/recovery policy for which CSOps will
be responsible and will provide the Computer Science Department user
community with information related to their responsibilities as well.
.AE
.\" .2C
.SH
.SH
Backup Schedule
.LP
Any backup policy will entail tradeoffs either in labor, materials
(tapes,drives,etc), recovery or backup times. It is important to arrive
at a schedule which will provide sufficient recovery capabilities
without being prohibitively expensive in other areas and one which
is satisfactory to the user community.
.LP
The CSops Commitee has determined that the following schedule is
generally sufficient for the large number of possible recovery
situations:
.IP [1]
.nr PS \n(PS-2
\fBA Full backup (Level 0) will be performed every month on each system.\fP
.nr PS \n(PS+2
.IP
This backup will be retained for a period of 2 years. Any file that
was present for at least 35 days over the course of a year will be
recoverable from this backup series.
.IP [2]
.nr PS \n(PS-2
\fBIncremental backups will be performed nightly.\fP
.nr PS \n(PS+2
.IP
Such backups are guaranteed only semi-nightly (every other day). This is
to ensure that our backups complete properly. If a backup failure occurs
on a given night, we will reserve the right to preempt the next nights
regular run in order to run the failed backup again to ensure we have
consistent backups.
.IP
These backups will be retained for 2 months and will allow any file that
existed for 24 hours (60 guaranteed) to be recovered from the night
previous to its loss.
.IP [3]
.nr PS \n(PS-2
\fBSpecial Backups\fP
.nr PS \n(PS+2
.IP
For data that requires a special consideration, backups will be
performed as requested. This includes filesystems that have just come
into existence (incrementals on such filesystems will of course be
full backups and would inappropriately skew the incremental backups),
and data that is deemed highly critical which might need to be saved
indefinitely or archived elsewhere.
.IP [4]
.nr PS \n(PS-2
\fBPersonal Backups\fP
.nr PS \n(PS+2
.IP
For those who wish to perform backups of their own data, a publicly
available tape backup device (Exabyte 8mm @ 2GB) will be available in the
Engineering Office Tower Copy Room (ECOT-7-26).
.IP
CSOps will provide the media necessary to perform your backups as well
as technical assistance and documentation. (This applies only to
faculty and staff)
.SH
Recovery Policy
.LP
Recoveries may be requested by users by sending electronic mail to the
address:
.IP
\fIoperations@cs\fP
.LP
Such mail will be forwarded into the CSops trouble-mail system. The
following checklist (found in /csops/forms/File-Restore) \fImust\fP be
supplied, otherwise the request will be removed from the trouble queue
and the user will be notified to resubmit the request with the proper
information.
.B1
.nr PS \n(PS-4
.nr VS \n(VS-4
.nf
.so /csops/forms/File-Restore
.fi
.nr PS \n(PS+4
.nr VS \n(VS+4
.B2
.LP
In the following criteria \fI"fully specified"\fP refers to complete
information specified by the user on the file(s) being recovered per
the request form above.
.LP
Recoveries will be performed according to the following criteria:
.IP [1]
.nr PS \n(PS-2
\fBSingle File within 2 months of request date\fP (\fIfully specified\fP)
.nr PS \n(PS+2
.IP
Such files will be recovered within 2 working days to the destination requested
by the user.
.IP [2]
.nr PS \n(PS-2
\fBMultiple Files or Directories of files\fP (\fIfully specified\fP)
.nr PS \n(PS+2
.IP
Such files will be recovered within 7 working days to the destination
requested by the user. It is anticipated that in general, recoveries
of this nature will take much less time than this, however large
restores may necessitate reading more tapes and possibly require
freeing up existing disk resources.
.IP [3]
.nr PS \n(PS-2
\fBNon-Fully specified restores\fP
.nr PS \n(PS+2
.IP
Any recovery requests which are not fully specified according to
the recovery form above will be returned to the user asking for the
incomplete information to be supplied and no further processing will
be done. However, if the user is absolutely unable to provide the
complete details, the recovery will be re-entered at very low priority
(as time permits).
.LP
*** Additional Notes ***
.PP
CSOps will be installing a "safe" removal program that can be used as
an alias for 'rm' (The Unix remove command) that will allow you to
recover files that you accidentally delete without having to contact
CSOps. The mechanism to use this will be described later.
authority.policy =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Authority Structure Concerning Requests of CSOps
CSOps is charged with providing systems administration support for the research
and administrative needs of the Computer Science Department. Faculty, staff and
graduate students are permitted to initiate requests for service to CSOps.
While CSOps will attempt to meet most requests, because of limited resources
CSOps may establish policy with regards to the priority with which requests are
handled, and may further determine that some requests will not be handled.
The manager of CSOps has final authority about priorities, and whether requests
will or will not be serviced. If a member of the community is not satisfied
with a CSOps determination about a request, then s/he may take the matter to the
chairperson of the CS Department.
The CSOPS-committee, that is composed of faculty, students and CSOps personnel,
has an advisory role. If a member of the user community is not satisfied with
a CSOps determination, s/he may discuss the situation with the CSOps committee,
which may offer suggestions to the manager of CSOps or the chairman of the CS
Department.
The primary mission of the CSOps-committee is to facilitate communication
between CSOps, the faculty and the larger user community. In addition to
understanding the many issues surrounding CSOps, the committee works to
articulate reasonable policies so that CSOps can most effectively serve the
needs of the Computer Science department.
csops.requests =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Revised policy on making requests to CSOPS
A new policy for the operation of csops, detailed in this note, is now being
phased in. It was developed by CSOPS and the CSOPS committee. There are two
elements to the policy:
a) Establishment of csops "POINTS OF CONTACT" for research groups: Each
research group in the department has been assigned a "point of contact"
(POC) in CSOPS. The three current POCs are all full-time staff members of
CSOPS. The assignment of groups to CSOPS staff members is given below.
b) Clarification of how requests to csops are to be made (see below).
It is hoped that this policy will allow for more efficient and knowledgeable
responses to your requests.
Please inform your post-docs and PhD students of this new policy. Thanks.
(The following page, suitable for framing, gives the details of the new policy,
and can be used for future reference:)
ASSIGNMENT OF RESEARCH GROUPS TO POCs
groups and sysadmin's names removed.
INITIATING REQUESTS TO CSOPS
Interaction with CSOPS can be broken into three categories:
CALL trouble at x2-5720 -- Use this approach to
* report things that need immediate attention
* ask short questions about systems
* get verbal interaction to solve some problem
EMAIL to trouble@cs -- Use this approach to
* initiate a request for repairs that are not critical (i.e., you will
survive if the problem isn't fixed in the next 2 hours)
* initiate a request for longer term tasks (e.g., installs,
reconfigurations,...)
CALL your POINT OF CONTACT -- Use this approach to
* follow up on a previous request, e.g., to ask status
* give verbal description of implementation details or considerations
about some request
* plan reconfigurations, purchases of new equipment or s/w, etc.
CSOPS ACKNOWLEDGEMENT OF TROUBLE QUEUE REQUESTS
The TROUBLE QUEUE is used as the main tracking mechanism of requests to CSOPS,
to ensure that requests are not lost. CSOPS normally looks at new trouble queue
entries within 2 business hours, and either solves the problem or gives it a
priority and possibly assigns it to a staff member. As part of the new policy,
CSOPS will send mail to the requester, describing what happened at this stage.
(A listing of the full trouble queue is obtained by the command "status".)
HOURS OF CSOPS OPERATION
The normal business hours of CSOPS is 8-12 and 1-5 on weekdays. The phone
x2-5720 will be answered during these times, except for very unusual
circumstances.
house.calls =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
March 16, 1994
CSOps Policy on House-Calls by CSOps Personnel
CSOps has many duties and scarce resources. House-calls (i.e., service requests
requiring a CSOps person to be physically off-campus) are costly in terms of
both staff time and transportation costs. A major difficulty in connection with
house-calls is that it is not feasible for CSOps to bring all of the needed
diagnostic equipment with them to someone's house. In general, house-calls are
only available for faculty and professional staff, and even in such cases are
discouraged.
Whenever a house-call is requested, the caller must provide transportation for
the CSOps personnel (at a mutually convenient time that is scheduled in advance)
from the Engineering Center to the off-campus location and back again.
In order to significantly reduce the need for house-calls, CSOps strongly
encourages the faculty and professional staff to
** use Xterminals with Xremote or a workstation with slip **
** for their home machine **
In that case, many repairs can be done over the phone line. In general, CSOps
can provide everything you need to set up slip or Xremote by yourself at home.
However, faculty and professional staff who need help in setting up slip or
Xremote at their home site will be allowed one "free" house-call for this
purpose. (However, as with all house-calls, you must provide transportation.)
Three categories of problems involving home machines can be distinguished:
(a) Problems that can only be diagnosed and fixed in the CSOps lab (e.g., if
the communication between your cpu and external disk is flaky)
(b) Problems that can be diagnosed and fixed, either at your home or in the
CSOps lab
(c) Problems that can only be diagnosed and fixed at your home (e.g., if it
involves a home network configuration, or specific wires or phone lines in
your home)
In cases (a) and (b), the equipment should be brought into the CSOps lab. In
many cases you will only need to bring in specific components of your home
system (e.g., the cpu and an external disk, but not the monitor). If you have
physical limitations, then CSOps personnel will help you bring the equipment
into the lab. However, you must provide transportation.
In case (c), CSOps will make a house-call to fix the problem.
pager =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CSOPS Policy on Non-Business-Hour Paging of CSOPS Personnel
The normal business hours of CSOps are 8AM-5PM (including lunch) on university
working days.
During non-business hours CSOps personnel can be contacted using a pager.
The primary purpose of the pager is so that CSOps personnel can respond to
emergencies where equipment is threatened. Due to the limited funding for
CSOps, this pager should be used only in very extra-ordinary cases. In
particular,
a) if there is a "community emergency" that threatens equipment (e.g., if an
air-conditioner is malfunctioning, if you smell smoke), then the pager
should be notified as soon as possible. (In fact, we also ask that you try
calling CSOps at x2-5720 and sending email, and that you take any necessary
immediate action, such as turning a machine off.)
b) if there is a "community emergency" because a very major system that
services a broad audience is down, then the pager should be notified. The
"very major systems" are anchor, piper, faserver, mroe or tigger. CSOps
will attempt to fix the problem as soon as possible.
c) if there is a "community emergency" because a major system is down, then
the pager may be notified. A "major system" is defined to be a system that
can serve 10 or more persons at the same time, and for which there is no
short-term alternative. CSOps will attempt to respond to such emergencies
during non-business hours, but may not be able to in some cases.
Important note: the pager should *not* be notified about this
kind of emergency between midnight and 7AM.
d) if a faculty or professional staff person has a "personal emergency" (e.g.,
they are trying to meet a deadline and their computer crashed), then that
person may notify the pager. There is no guarantee that CSOps will respond
to such personal emergencies.
e) in general, graduate students and post-docs should not use the pager for
"personal emergencies". However, a faculty or professional staff
person may designate one or two key members of their research team as
"pager-authorized researchers" (PARs).
-- A PAR may contact the pager in the case of a "personal emergency"
related to the team's research objectives.
-- Each request to assign PAR status must be submitted to the manager
of CSOps for approval. CSOps will provide an electronic form for
making such requests.
-- Each request must be made for a specific duration (e.g., 1 week, 1
month, or 1 year)
-- The manager of CSOps has the authority to deny/remove PAR status
from any individual who has abused the privilege of pager notification.
f) if a graduate student uses the pager inappropriately, CSOps has the
authority to suspend that person's computing privileges and to inform
his/her advisor of the offense.
The pager can be contacted in the following ways:
a) dialing 441-8005 and leaving a voice mail message
b) send email to csops-pager@cs.colorado.edu (There is currently a
200-character limit per message, including the lines specifying the sender
and the subject.)
supported.disk.tape =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.\" tbl | nroff | col
.\" tbl | psroff -t > foo.ps
.nh
.ll 7i
.sp 0.35i
.po 0.75i
.ps 10
.vs 11
.TS
box, expand;
cfB s s s s s.
CSOps Supported Disk & Tape List (DRAFT)
_
.T&
cp9fB | cp9fB | cp9fB | cp9fB | cp9fB | cp9fB .
Vendor Model Interface Present Purchase Notes
\^ \^ \^Protocol \^Support \^Recommendation \^
.T&
ltp9fB | ltp8 | lp8 | lp8 | lp8 | lp8I .
.vs10
_
DEC ? ? ? ?
_
Micropolis 221x SCSI-2 A 0
_
Seagate ? ? ? ?
_
.TE
.ps -2
\(dg CSOps is presently ramping up in this area
.ps +2
.ll 7i
.in 0.25i
.ft B
.ps 9
Notes:
.br
.ft R
.ps 8
.in 0.25i
Support Levels are defined as:
.ps 7.5
.ft I
.br
.in 0.5i
A) Fully Supported
.br
B) Partially Supported
.br
C) Limited Support
.br
D) No Support
.br
.in -0.25i
.ps 8
.ft R
Purchase Recommendations are defined as:
.ps 7.5
.ft I
.br
.in 0.5i
1) Purchases of this peripheral are highly recommended
.br
0) Purchases are neither recommended nor discouraged
.br
-1) Purchases are highly discouraged
.br
This list is dynamic and peripherals may be added, deleted, or modified by
CSOps at any time. Several architectures are included in this list for
which little or no support is provided nor implied. They are simply
included to provide completeness with respect to the current CS network
environment. Please check the date mark on this document to ensure it
is not more than 6 months old.
.br
One-time exceptions and long-term changes to this list may be added at
the discretion of the CSOps manager, or may be contested to the CSOps
committee.
.br
.sp 0.5i
Date: \n(mo/\n(dy/\n(yr
supported.printers =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.\" tbl | nroff | col
.\" tbl | psroff -t > foo.ps
.nh
.ll 7i
.sp 0.35i
.po 0.75i
.ps 10
.vs 11
.TS
box, expand;
cfB s s s s s.
CSOps Supported Printers List (DRAFT)
_
.T&
cp9fB | cp9fB | cp9fB | cp9fB | cp9fB | cp9fB .
Vendor Model Processor Present Purchase Notes
\^ \^ \^Software \^Support \^Recommendation \^
.T&
ltp9fB | ltp8 | lp8 | lp8 | lp8 | lp8I .
.vs10
_
Apple LaserWriter Plus PostScript A -1
\^ LaserWriter IINT PostScript A -1
\^ LaserWriter Pro 6xx PostScript A 1
_
Canon BJ800C (?) NeXT PostScript RIP A -1
_
Hewlett LaserJet II, IIP, IID PostScript A 0
\^Packard LaserJet IV PostScript A 1
\^ * PCL C -1
_
.TE
.ps -2
\(dg CSOps is presently ramping up in this area
.ps +2
.ll 7i
.in 0.25i
.ft B
.ps 9
Notes:
.br
.ft R
.ps 8
.in 0.25i
Support Levels are defined as:
.ps 7.5
.ft I
.br
.in 0.5i
A) Fully Supported
.br
B) Partially Supported
.br
C) Limited Support
.br
D) No Support
.br
.in -0.25i
.ps 8
.ft R
Purchase Recommendations are defined as:
.ps 7.5
.ft I
.br
.in 0.5i
1) Purchases of this system are highly recommended
.br
0) Purchases are neither recommended nor discouraged
.br
-1) Purchases are highly discouraged
.br
This list is dynamic and systems may be added, deleted, or modified by
CSOps at any time. Several architectures are included in this list for
which little or no support is provided nor implied. They are simply
included to provide completeness with respect to the current CS network
environment. Please check the date mark on this document to ensure it
is not more than 6 months old.
.br
One-time exceptions and long-term changes to this list may be added at
the discretion of the CSOps manager, or may be contested to the CSOps
committee.
.br
.sp 0.5i
Date: \n(mo/\n(dy/\n(yr
supported.software =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[ CSOps Supported Software Applications ]
Mail User Agents
Elm, MH, XMH, Eudora (Mac), UCBMail,
Graphical User Interfaces
X11R5, X11R4, Sunview (-)
supported.systems =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.\" tbl | nroff | col
.\" tbl | psroff -t > foo.ps
.ps 7
.vs 7
.sp
EQUIPMENT CURRENTLY SUPPORTED BY CSOPS
.sp
CSOps currently supports a variety of hardware and software platforms. Such
diversity is inherent in the activities of a research oriented department such
as ours. However, increased diversity is costly, because it requires more
effort from CSOps, both in terms of the learning curve to become familiar with
new systems, because of the variety of paradigms that they must be familiar
with, and because of continued improvements of the various platforms.
.sp
The attached chart shows the hardware platforms in the department, the level of
support that CSOps currently provides for them, and whether CSOps recommends
them. We hope that this chart will be useful to you, as you plan new equipment
acquisitions.
.sp
Be aware that the equipment on this list can only be supported if it meets
minimum requirements for configuration. This includes having sufficient memory
and disk to support the environment running on the system. Requirements differ
for each architecture and operating system so please contact CSops to verify any
configuration that you have a question about.
.sp
CURRENT LEVELS OF SUPPORT
.sp
In the chart, the level of support support level is indicated using 4 loose
categories:
.sp
A) Fully Supported: CSOps provides full support for installation and
maintenance of the platform and associated generic software [CSOps reserves
the right to negotiate with regards to maintenance of certain software
packages], and for network connectivity. CSOps considers itself to be
expert with regards to this equipment.
.sp
B) Partially Supported: CSOps is striving to provide level (A) support, but is
on a learning curve, and does not consider itself to be expert.
.sp
C) Limited Support: CSOps currently provides an IP address and supports TCP/IP
network services connectivity (including, e.g., telnet, rlogin, lpd).
.sp
D) Network Connectivity: CSOps currently provides an IP address and a network
tap, but otherwise users are "on their own".
.sp
CSOPS REVIEW OF PLANNED EQUIPMENT ACQUISITIONS
.sp
If you are planning to acquire new equipment, you should complete the "Request
to Initiate Service" form (/csops/forms/Request-For-Service). This will inform
CSOps about new equipment coming into the department, and provides the vehicle
whereby CSOps commits to a level of support for the equipment.
.sp
REACTING TO CHANGE
.sp
The computer industry and the equipment needs of the department are highly
dynamic. CSOps attempts to stay abreast of new developments. In particular,
CSOps will learn new systems that are determined by the faculty to be widely
relevant. (If you have suggestions in this regard, please contact CSOps and/or
the CSOps committee.)
.sp
On the chart, the dagger symbol indicates that CSOps is ramping up for some of
this new technology.
.sp
HELPING CSOPS LEARN ABOUT NEW PLATFORMS
.sp
In order for CSOps to effectively learn about, install, and maintain new
platforms, it is expeted that CSOps have a dedicated machine of the same type
in the CSOps lab. (This can be a scaled down, less expensive version of the
research machine(s).) In particular, CSOps can learn a system faster and
provide quicker turn-around on maintenance if it has a dedicated machine. Thus,
we recommend that when new platforms are brought into the department, CSOps be
provided with a dedicated machine of that type. Funding might come from the CER
grant, or from pooling of research grants that are using the equipment.
.sp
CSOPS RECOMMENDATIONS
.sp
The chart also shows recommendations from CSOps (and the CSOps-committee) about
what platforms people in the department should acquire. These recommendations
are based primarily on how the technology is changing, and how departmental
research needs are changing. There are three loose categories:
.sp
1) Acquisition of this equipment is highly recommended
0) Acquisition is neither recommended nor discouraged
-1) Acquisition is strongly discouraged
.sp
UPDATING THE CHART
.sp
The levels of equipment support provided by CSOps are highly dynamic, and this
chart will be updated about twice a year. In general, you should discuss all
planned equipment acquisitions with CSOps, in order to clearly understand
the level of support they are expected to provide, and that they can in fact
provide.
.sp
FINAL NOTE
.sp
CSOps is currently developing analogous charts concerning supported peripherals
(i.e., disks, printers, modems, etc.)
.ps 10
.\" page-eject
.nh
.ll 7i
.sp 0.35i
.po 0.5i
.ps 10
.vs 11
.TS
box, expand;
cfB s s s s s.
CSOps Supported Systems List
_
.T&
cp9fB | cp9fB | cp9fB | cp9fB | cp9fB | cp9fB .
Vendor Model Operating Present Purchase Notes
\^ \^ \^ \^Support \^Recommendation \^
\^ \^ \^System \^Level \^ \^
.T&
ltp9fB | ltp8 | lp8 | lp8 | lp8 | lp8I .
.vs10
_
Apple Macintosh II,Quadra,PowerBook System 7.x B\(dg 1
\^ PowerPC Series System 7.x ? ?
_
Convex C-3220 ? D -1
_
DEC Alpha/AXP (DS3000/xxx) OSF 1.3/2.0 A 1 OSF1 source license
\^ DECstation 5000 Ultrix 4.x A 1 expected soon
\^ DECstation 3100 Ultrix 4.x A 0
\^ VAXstation 3100, 3200 Ultrix 4.x B 0
_
HP 9000/7xx HP-UX 9.01 A 1 CU now has site
\^ \^ NeXTStep A\(dg 0 license package for
\^ 9000/3xx HP-UX 9.x A -1 unbundled SW via CNS
\^ \^ HP-BSD 4.3 C -1
_
INTEL HyperCube iPSC ? D -1
_
KSR KSR-1 OSF1 D -1 KSR funds RA for support
_
MIPS Mips-1000 U-MIPS ? C -1 soon as alumni dies...
_
NCD NCD Xterminals X A 1
\^ \^ XRemote A 1 \^
_
Network FA Server ? A 1
\^Appliances \^
_
NeXT NeXTCube / Station NeXTStep ? A 0
_
SGI IRIS Indigo IRIX 4.0+ A 1
\^ IRIS Extreme IRIX 4.0+ A 1 \^
_
Solbourne Series 4/xxx OS/MP 4.1 A -1
\^ Series 5/xxx OS/MP 4.1C A 0 \^
_
Sun SPARCstation 1,1+,2,10,ELC,SLC,IPX SunOS 4.x A 1
\^ SPARCsystem 4/6xx (Sun4 VME/SBus) SunOS 4.x A 1 \^
\^ SPARCsystem 4/xxx (Sun4 VME) SunOS 4.x A 0 \^
\^ Sun 3/xx SunOS 4.x A -1 \^
\^ \^ Xkernel (as xterminal) A -1 \^
\^ Sun 3/xxx (VME) SunOS 4.x A -1 \^
\^ SPARCstation, SPARCsystem Solaris 2.x D\(dg -1 \^No equipment available
\^within CSOps to support
\^at present
\^ SPARC NeXTStep A\(dg 0 \^Not Presently Available
_
Symbolics ? ? D -1 AI systems
\^ \^(Hal Eden)
_
PC & Compatibles 386, 486, Pentium BSD-I A\(dg 0 CSOps has no resources to
\^support at present
.TE
.ps -2
\(dg CSOps is presently ramping up experience in this area
.ps +2
.ll 7i
.in 0.25i
.ft B
.ps 9
\fBNotes:\fP
.br
.ft R
.ps 9
.in 0.25i
Support Levels are defined as:
.ps 8
.ft I
.in 0.5i
.pp
A) Fully Supported: CSOps provides full support for installation and
maintenance of the platform and associated generic software [CSOps
reserves the right to negotiate with regards to maintenance of
certain software packages], and for network connectivity. CSOps
considers itself to be expert with regards to this equipment.
.br
B) Partially Supported: CSOps is striving to provide level (A) support,
but is on a learning curve, and does not consider itself to be
expert.
.br
C) Limited Support: CSOps currently provides an IP address and supports
TCP/IP network services connectivity (including, e.g., telnet,
rlogin, lpd).
.br
D) No Support: CSOps currently provides an IP address and a network tip,
but otherwise users are "on their own".
.br
.in -0.25i
.ps 9
.ft R
Acquisition Recommendations are defined as:
.ps 8
.ft I
.br
.in 0.5i
1) Acquisition of this equipment is highly recommended
.br
0) Acquisition is neither recommended nor discouraged
.br
-1) Acquisition is strongly discouraged
.br
.ps 8.5
.in -0.25i
This list is dynamic and systems may be added, deleted, or modified by
CSOps at any time. Several architectures are included in this list for
which little or no support is provided nor implied. They are simply
included to provide completeness with respect to the current CS network
environment. Please check the date mark on this document to ensure it
is not more than 6 months old.
.br
One-time exceptions and long-term changes to this list may be added at
the discretion of the CSOps manager, or may be contested to the CSOps
committee.
.br
.sp 0.5i
Date: \n(mo/\n(dy/\n(yr
autonomous.machines =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Fully autonomous machines on the CS networks
This level of autonomy is intended for purely research/experimental
situations.
Any faculty or staff may connect a machine to the CS networks that
is not to be supported by CS Ops. In order to maintain security
and not adversely affect other network users, the following guidlines
must be enforced by the responsible faculty/staff. One faculty or
staff member must be given full responsibility for the use of the
system.
Access to a physical network must be controlled to maintain as
secure an environment as practical. The Superuser on any Unix
machine has the ability to read every bit that travels by on the
network, so Superuser access needs to be controlled. All of the
items below are intended to reasonably protect the security of
the network and other users on it. Other measures should be taken
to protect the users of the system and their data.
Connection
- The IP address and the physical network tap used must be
provided by CS Ops. The hostname used must correspond to
the hostname given to CS Ops and in the campus hosts file
for that IP address, ie. no imposters.
- The machine must be connected to a subnet of the CS network,
not the CS backbone.
Security
- The root password must be changed at least once/semester
and be known by no more than three people who are judged to
be responsible. One of those people must be the responsible
faculty/staff.
- We suggest that sudo be installed and used for any other
users that require various root privileges. Other mechanisms
may be used, but they should log activities.
- Only the root account can have a UID=0.
- CS Ops full-time staff have accounts and sudo access for
emergencies (power outages, things run amuck) and to verify
these guidlines are followed. The sudo access may be
limited, but no less than kill and halt.
- NFS and YP must not be installed or used.
- The machine must not run any electronic mail system.
- The machine cannot be in /.rhosts or /etc/hosts.equiv of
any other machines.
Access/Use
- The machine must not broadcast: routing packets (RIP, EGP,
HELLO) rwho or other passive information.
- The machine must not answer requests for standard services:
tftp, bootp, rarp, bootparams, etc.
- The machine must not transmit data excessively such that
other machines on the network are noticably affected, ie.
flood the net.
autonomy =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.\" To print this document, 'tbl filename | psroff -ms'
.\" dyker Wed Oct 16 09:37:15 MDT 1991
.sp 2
.ce 2
Computer Science Department Computing Operations
Guidlines for Computer Systems and Networking
.sp 2
.LP
These guidlines have been developed in response to requests for more
autonomy in operations of specific machines within the CS Department.
The CS Ops staff follow these guidlines in support of department machines.
These guidlines represent the minimum level necessary to ensure secure
and reliable network interoperation. These guidlines also include
information and recommendations for operations with in the department and
the University.
.LP
As a user and system administrator, you are required to:
.in
.nf
- Work withing these guildlines.
.br
- Stay aware of changes and developments to the network and these
guidlines by monitoring the "cs-guide" mailing list.
downtime =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Any downtime more than a fastboot should be announced via motd a
minimum of 24 hours ahead of time... unless it is an emergency.
Exceptions to this rule are research class machines:
encore
cubie/bud/budlite
ksr
eclipse
Any downtime more than 2 hours or including more than one server
should be posted with one week notice.
When it is time to shutdown for scheduled or un-scheduled downtime,
execute the shutdown (rwall) with at least 30 minutes notice (whenever
possible). Always include in the rwall message the expected time
the machine will be back on-line.
Bringing a machine down, one should always consider the following:
is anyone currently logged in?
wall 'em
are there any jobs running in the background?
attempt to contact the user before nuking
are there any local files open via nfs
this is virtually impossible to detect -
use judgement and knowledge about nfs dependencies
policy.grouplogins =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
A "group" login is one which is not the primary account of an
individual user or one where more than one person knows the password
or is allowed access to the account. Such logins are not allowed
in the CS dept. Accounts with a specific purpose program in place
of a shell are allowed provided the login program is sufficiently
secure to prevent shell access. Such accounts should have uids
less than 1000. To maintain security and integrity of our systems,
we MUST maintain accountability of each login account. With group
accounts, it is difficult to hold someone responsible for the use
of the account.
If a group account is required for a special purpose, it will be
granted ONLY under the following circumstances:
- A CS faculty or staff agrees to be be solely responsible for all
activity on the account, and
- The responsible person MUST change the password for the account
a minimum of once per semester.
Information on who is responsible for the group account and an
agreement to change the password as indicated and abide by all other
user policies must be provided to CSops IN WRITING and signed by the
person responsible for the account.
policy.non.user.logins =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Any account which is not the primary account for a specific individual
requires the approval of csops. The account will only be approved if
the function required cannot be reasonably provided by another more
acceptable (secure) means.
If the account is for sole use by a user who already has an account:
- the cuid of the account should be the same as the main
user with an extra digit, and
- the uid should be above 1000, ie. assigned by uniquid,
- the account is subject to the same terms and conditions
as a primary account and a new t&c agreement must be
signed for that account.
If the account is for use by a program (eg. ingres):
- csops must review the security of the required account
configuration, and
- uid should be less than 1000, ie. not managed by uniquid,
- either the password should be disabled or the login program
should prevent shell access; both are preferred, one is
required.
If the account is for use by any user to provide a service (eg, netfind):
- csops must review the security of the required account
configuration - the login program *must* be secure, and
- uid should be less than 1000, ie. not managed by uniquid,
policy.nsfnet =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
\" no macros
.sz 12
.sp 7
.ce
\fBNEW ACCEPTABLE USE POLICY FROM NSFNET\fR
.sp
The following is a new acceptable use policy for the NSFNET backbone
service. Copies are available via anonymous FTP from nis.nsf.net. The file
to retrieve is: acceptable.use.policies/nsfnet.txt or nsfnet.ps for the
PostScript version.
.sp 3
\fBThe NSFNET Backbone Service Acceptable Use Policy\fR
.sp
\fBGENERAL PRINCIPLE:\fR
.sp
(1) NSFNET Backbone services are provided to support open research and
education in and among US research and instructional institutions, plus
research arms of for-profit firms when engaged in open scholarly
communication and research. Use for other purposes is not acceptable.
.sp
\fBSPECIFICALLY ACCEPTABLE USES:\fR
.sp
(2) Communication with foreign researchers and educators in connection
with
research or instruction, as long as any network that the foreign user
employs for such communication provides reciprocal access to US
researchers
and educators.
.sp
(3) Communication and exchange for professional development, to maintain
currency, or to debate issues in a field or subfield of knowledge.
.sp
(4) Use for disciplinary-society, university-association,
government-advisory, or standards activities related to the user's
research
and instructional activities.
.sp
(5) Use in applying for or administering grants or contracts for research
or instruction, but not for other fundraising or public relations
activities.
.sp
(6) Any other administrative communications or activities in direct
support
of research and instruction.
.sp
(7) Announcements of new products or services for use in research or
instruction, but not advertising of any kind.
.sp
(8) Any traffic originating from a network of another member agency of the
Federal Networking Council if the traffic meets the acceptable use policy
of that agency.
.sp
(9) Communication incidental to otherwise acceptable use, except for
illegal or specifically unacceptable use.
.sp
\fBUNACCEPTABLE USES\fR
.sp
(10) Use for for-profit activities (consulting for pay, sales or
administration of campus stores, sale of tickets to sports events, and so
on) or use by for-profit institutions unless covered by the General
Principle or as a specifically acceptable use.
.sp
(11) Extensive use for private or personal business. This statement
applies
to use of the the NSFNET Backbone only. NSF expects that connecting
networks will formulate their own use policies. The NSF Division of
Networking and Communications Research and Infrastructure will resolve any
questions about this Policy or its interpretation.
|
|
