Chapter 1: Responsibilities and Management Issues
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 Responsibilities

Local teams are likely to retain formal responsibility in certain areas and, in everybody's interest, we have attempted to list these here

Backups

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

Change Control

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 it.

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

Security

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 (admin@itss.nerc).
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 dnsadmin@ua.nsw.ac.uk to ask NSG to add them to the DNS database.

Configuration 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 rfcr@itss.nerc.ac.uk