Chapter 1: Responsibilities and
Who Does What?
This discussion applies to the relationship between
iTSS and those who have contracted for our support services on a yearly
or case-by-case basis - the phrase 'local staff' means loosely those who
used to be Local Support in the days of NCS, or anyone at a site acting
in a similar role.
As a general rule, we believe it makes sense for
local staff to take care of regular requirements on their site and call
on Systems Group for unusual tasks.
Here 'Systems Group' means the UNIX support staff
in iTSS - at present this consists of the authors of this Guide.
"Regular requirements" certainly includes setting
up new userids and updating the various NIS
maps. Also if a site is planning to buy 12 workstations of the same
type in a year, the local staff should probably be doing the workstation
installations ( following the iTSS WorkInstructions
). On the other hand, if a site buys one or two workstations per year,
experience gained at one installation will probably have been forgotten
(and be out-of-date !) by the next one so the local staff should call in
Systems Group and spend their time more profitably elsewhere. By the same
token, we will almost always set up the various site servers as they can
leverage experience of these machines across many sites. Unique hardware
and software (such as computer-controlled instruments) probably has to
be looked after locally though the systems groups are willing to advise
and assist if they can.
Local teams are likely to retain formal responsibility
in certain areas and, in everybody's interest, we have attempted to list
All disk areas containing user
data should be regularly backed up. In general, full backups should be
done weekly and incremental backups nightly. Many sites are now using
Legato Networker. Systems group will advise on how to do this and will
normally set up the server and help get the system going. However, if the
site has only one or two systems Networker may be unnecessary and here
Systems Group can set up scripts instead. They will also help resolve any
problems. However, responsibility for seeing that adequate backup procedures
exist, are tested and are followed, rests with the local staff. No system
programmer should agree to work on a machine if he does not believe it
is adequately backed up.
Back to contents
All changes to the user service
should be written up in advance and approved by all concerned. "Emergency"
changes should be written up retrospectively. The mechanics of how this
is done are pretty variable but local staff are responsible for seeing
it is done on their site. In particular, they must issue appropriate warnings
to their users and negotiate about down time.
As far as changes to be carried out by Systems Group
are concerned, we have found that it generally works better if local staff
write a "product"-oriented description of the desired change (i.e. what
they want) and leave the details of the work to those who will be doing
Systems Group generally write a short report describing
the work carried out and, in particular, detailing any further actions.
The local representative should agree this and thereby sign-off the work
or else raise raise further change requests.
It should be clear that successful change control
is very much a "to and fro" process between those requesting the change
and those doing the work. The intention is to improve communications and
reduce misunderstandings. Many applications are now interdependent, and
upgrades to one system can cause another to be stressed beyond its present
capabilities and need patches. Ideally an operating system upgrade or applications
upgrade needs to be talked over with several supporters and local people
to be sure all the implications have been addressed.
Back to contents
We should all be aware of the
provisions of the NERC Code of Conduct - poor security procedures are liable
to be treated very seriously by NERC management. The Zenith
package has been installed to assist in checking system security
and a new password program made available (chpasswd ) which checks passwords
as they are created. A more formal approach to computer security is now
being taken during the preparations for Firewall installations.
UIDs and GIDs
Each site has authority to allocate
these to its resident users within the ranges shown in Appendix
1. UIDs should be notified to the CURD administrator (email@example.com).
Back to contents
IP Nos and hostnames
NSG allocate IP network numbers
to sites when they are connected to the Internet. Local staff are responsible
for allocating host numbers and host names. They should keep records of
these and, where appropriate, mail firstname.lastname@example.org to ask NSG to
add them to the DNS database.
Details of all UNIX workstations
looked after by iTSS are currently held centrally for purposes of maintenance
agreements, licences etc.. Whenever local staff install a workstation they
should ensure that the system details are entered into the Configuration
Database, either using Microsoft Access or by asking Systems Group to do
it for them, and should check that they are licenced for any chargeable
products they plan to load.
Maintenance arrangements should be agreed with the
workstation owners and the appropriate group in Swindon asked to organise
the contract. Some manufacturers assume workstations are to go on maintenance,
others do not.
Back to contents
This page last updated February 13th 1998 by