5.5. USER SUPPORT SERVICES

161

This keeps a record of who is root at any time, and is more secure in the sense of having fewer points of attack.

The privileged user should have a minimal environment, should not read or reply to its own E-mail (this should be sent to a system administration group), and should never log in over an unencrypted channel.

5.5 User support services

All users require help at some time or another. The fact that normal users are not privileged users means that they must occasionally rely on a superuser to clean up a mess, or fix a problem which is beyond their control. If we are to distinguish between privileged and non-privileged users, we cannot deny users this service.

5.5.1Support policy

The amount of support that one offers users is a matter of policy. One has the choice between supporting users directly, and investing time in making them self-sufficient. Which of these two strategies pays most dividends depends on the nature of the problem. In almost all cases both strategies are needed. Thus one looks for a mixture of the following:

•Training users.

•Helping users.

•Documenting and providing the answers to frequently asked questions.

The proportion of time spent on each must be chosen as policy.

System administrators’ time is usually in short supply, though increased automation is steadily freeing us to concentrate on higher level problems, like support. The ability to support a system depends on its size in relation to the available resource personnel. Supporting hardware and software means fixing errors, upgrading and perhaps providing tuition or telephone help-desks. E-mail help-desks such as Rust, Gnats, Nearnet, Netlog, PTS, QueueMH can assist in the organization of support services, but they are mainly task-tracking tools. Sometimes hosts and software packages are labelled unsupported in order to emphasize to users that they are on their own if they insist on using those facilities.

One of the challenges system administrators sometimes have to endure on coming to a new site, where chaos reigns, is the transition from anarchy to a smaller set of supported platforms and software. See for instance, refs. [226, 182]. This can be a tough problem, since users always prefer freedom to restriction. Support services need to be carefully considered and tailored to each local environment.

A recent development in user assistance is the Virtual Network Computing model from AT&T [24]. This is a way to allow a remote user duplicate access to a graphical user interface. Thus an administrator can log onto an existing

162	CHAPTER 5. USER MANAGEMENT

user session and have dual controls, allowing users to be nurse-maided through difficulties online.

5.5.2Checklist

The provision of a service to users suggests the need for quality controls. This goes back to the central principle of predictability in management: a controlled and verified result allows one to have confidence in the effectiveness of the procedure and thus the long-term stability of the human–computer system. We shall return to the issue of quality control in a more formal setting in section 8.12.1.

Checklists are a useful algorithmic aid to securing predictable results. The basic checklist for user services is this:

1.Read the user request properly.

2.Do you understand the request?

3.Is the request in line with policy?

4.Are you competent to deal with the request?

5.Schedule the request (rapid response mitigates frustration).

Limoncelli has defined a model to promote standardization of user assistance, in what he calls the Nine Step Model [197]. This is a way of regularizing the interaction between user and help-desk in order to promote predictability in the process and quality control of the result (see table 5.1).

Greeting

1. Greeting ‘How may I help you?’

Problem identification

2.Identify problem

3.Refine and express the problem

4.Verify the problem

Correction

5.Propose solutions

6.Select solution

7.Execution

Verification

8.Self-check

9.User-check

Table 5.1: The nine steps in Limoncelli’s model of user assistance. The all-important greeting should not be forgotten as one launches into a technical procedure.

5.6. CONTROLLING USER RESOURCES

163

The Nine Step Model is actually a straightforward example of a development cycle: problem identification, solution, verification. It is not unlike procedures one might use in software engineering to create a computer program. The main difference is an attention to the social graces: users appreciate being noticed and taken seriously (hence the greeting), and they also appreciate an explanation of what is going on during the assistance. Some administrators are good at talking users through their logical analysis, while others tend to keep their thoughts to themselves. Human users generally appreciate being included in the procedures.

5.6 Controlling user resources

Every system has a mixture of passive and active users.

Passive users utilize the system often minimally, quietly accepting the choices which have been made for them. They seldom place great demands on the system. They do not follow the development of the system with any zeal and they are often not even aware of what files they have. They seldom make demands other than when things go wrong. Passive users can be a security risk, because they are not aware of their actions.

Active users, on the other hand, follow every detail of system development. They frequently find every error in the system and contact system administrators frequently, demanding upgrades of their favorite programs. Active users can be of great help to a system administrator, because they test out problems and report them actively. They are an important part of the system administration team, or community, and can also go a long way to helping the passive users. An important point about active users, however, is that they are not authorized staff.

Principle 21 (Active users). Active users need to understand that, while their skills are appreciated, they do not decide system policy: they must obey it. Even in a democracy, rules are determined by process and then obeyed by everyone.

Skilled administrators need to be social engineers, placating active user wishes and keeping them in the loop, without bowing to their every whim. Individual skill amongst users does not necessarily carry with it responsibility to the whole system. System administrators have a responsibility to find a balance which addresses users’ needs but which keeps the system stable and functional. If we upgrade software too often, users will be annoyed. New versions of software function differently and this can hinder people in their work. If we do not upgrade often enough, we can also hinder work by restricting possibilities.

5.6.1Resource consumption

Disks fill up at an alarming rate. Users almost never throw away files unless they have to. If one is lucky enough to have only very experienced and extremely friendly users on the system, then one can try asking them nicely to tidy up their files. Most administrators do not have this luxury however. Most users never think about the trouble they might cause others by keeping lots of junk around. After all, multi-user systems and network servers are designed to give every user the

164	CHAPTER 5. USER MANAGEMENT

impression that they have their own private machine. Of course, some users are problematical by nature.

Suggestion 6 (Problem users). Keep a separate partition for problem users’ home directories, or enforce strict quotas on them.

No matter what we do to fight the fire, users still keep feeding the flames. To keep hosts working it is necessary to remove files, not just add them. Quotas limit the amount of disk space users can have access to, but this does not solve the real problem. The real problem is that in the course of using a computer many files are created as temporary data but are never deleted afterwards. The solution is to delete them.

•Some files are temporary by definition. For example, the byproducts of compilation, *.o files, files which can easily be regenerated from source like TeX *.dvi files, cache files in .netscape/ loaded in by Netscape’s browser program etc.

•Some files can be defined as temporary as a matter of policy. For example, files which users collect for personal pleasure like *.mp3, video formats and pornography.

When a Unix program crashes, the kernel dumps its image to disk in a file called core. These files crop up all over the place and have no useful purpose for most users.1 To most users they are just fluff on the upholstery and should be removed. A lot of free disk space can be reclaimed by deleting these files. Many users will not delete them themselves, however, because they do not even understand why they are there.

Disk quotas mean that users have a hard limit to the number of bytes they are allowed to use on the disk. They are an example of a more general concept known as system accounting whereby you can control the resources used by any user, whether they be the number of printed pages sent to the printer or the number of bytes written to the disk. Disk quotas have advantages and disadvantages.

•The advantage is that users really cannot exceed their limits. There is no way around this.

•Disk quotas are very restrictive and when a user exceeds their limit they often do not understand what has happened. Usually users do not even get a message unless they are logging in. Quotas also prevent users from creating large temporary files which can be a problem when compiling programs. They carry with them a system overhead, which makes everything run a little slower.

In some environments, the idea of deleting a user’s files is too much to contemplate. In a company or research laboratory, one might want to be extremely careful in

1In some instances, core files have been used by malicious users to obtain secret information about the system that was held in memory prior to the crash.

5.6. CONTROLLING USER RESOURCES

165

such a practice. In other cases, like schools and universities, this is pure necessity. Deciding whether to delete files automatically must be a policy decision. It might be deemed totalitarian to delete files without asking. On the other hand, this is often the only way to ever clear anything up. Many users will be happy if they do not have to think about the problem themselves. A tidy policy, rather than a quota policy, gives users a greater illusion of freedom, which is good for system morale. We must naturally be careful never to delete files which cannot be regenerated or re-acquired if necessary. File tidying was first suggested by Zwicky in ref. [336], within a framework of quotas. See also refs. [134, 55].

Example 2. A useful strategy is to delete files one is not sure about only if they have not been accessed for a certain period of time, say a week. This allows users to use files freely as long as they need to, but prevents them from keeping the files around for ever. Cfengine can be used to perform this task.

For example a simple cfengine program would look like:

control:

actionsequence = ( tidy )

mountpattern = ( /site/host ) homepattern = ( home? )

#

# 3 days minimum, remember weekends

#

tidy:
home	pattern=core	recurse=inf age=0
home	pattern=a.out	recurse=inf age=3
home	pattern=*%	recurse=inf age=3
home	pattern=*~	recurse=inf age=3
home	pattern=*.o	recurse=inf age=1
home	pattern=*.aux	recurse=inf age=3
home	pattern=*.mp3	recurse=inf age=14
home/Desktop/Trash	pattern=*	recurse=inf age=14
home/.netscape/cache	pattern=*	recurse=inf age=0

This script iterates automatically over all users’ home directories, and recurses into them, deleting files if the time since they were last accessed exceeds the time limits specified.

Care should always be taken in searching for and deleting patterns containing ‘core’. Some operating systems keep directories called core, while others have files called core.h. As long as the files are plain files with an exact name match, one is usually safe.

166	CHAPTER 5. USER MANAGEMENT

5.6.2Quotas and limits in general

In a shared environment, all users share the same machine resources. If one user is selfish that affects all of the other users. Given the opportunity, users will consume all of the disk space and all of the memory and CPU cycles somehow, whether through greed or simply through inexperience. Thus it is in the interests of the user community to limit the ability of users to spoil things for other users.

One way of protecting operating systems from users and from faulty software is to place quotas on the amount of system resources which they are allowed.

•Disk quotas: Place fixed limits on the amount of disk space which can be used per user. The advantage of this is that the user cannot use more storage than this limit; the disadvantage is that many software systems need to generate/cache large temporary files (e.g. compilers, or web browsers) and a fixed limit means that these systems will fail to work as a user approaches his/her quota.

•CPU time limit: Some faulty software packages leave processes running which consume valuable CPU cycles to no purpose. Users of multiuser computer systems occasionally steal CPU time by running huge programs which make the system unusable for others. The C-shell limit cputime function can be globally configured to help prevent accidents.

•Policy decisions: Users collect garbage. To limit the amount of it, one can specify a system policy which includes items of the form: ‘Users may not have mp3, wav, mpeg etc. files on the system for more than one day’.

Quotas have an unpleasant effect on system morale, since they restrict personal freedom. They should probably only be used as a last resort. There are other ways of controlling the build-up of garbage.

Principle 22 (Freedom). Quotas, limits and restrictions tend to antagonize users. Users place a high value on personal freedom. Restrictions should be minimized or made inconspicuous to avoid a backlash. Workaround solutions which avoid rigid limits are preferable, if possible.

5.6.3Killing old processes

Processes sometimes do not get terminated when they should. There are several reasons for this. Sometimes users forget to log out, sometimes poorly written terminal software does not properly kill its processes when a user logs out. Sometimes background programs simply crash or go into loops from which they never return. One way to clean up processes in a work environment is to look for user processes which have run for more than a day. (Note that the assumption here is that everyone is supposed to log out each day and then log in again the next day – that is not always the case.) Cfengine can also be used to clean up old processes. Cfengine’s processes commands are used to match processes in the process table (which can be seen by running ps ax on Unix).

5.6. CONTROLLING USER RESOURCES

167

5.6.4Moving users

When disk partitions become full, it is necessary to move users from old partitions to new ones.2 Moving users is a straightforward operation, but it should be done with some caution. A user who is being moved should not be logged in while the move is taking place, or files could be copied incorrectly. We begin by looking for an appropriate user, perhaps one who has used a particularly large amount of disk space.

Example 3. On Unix-like systems we have all the tools we require:

cd /site/host/home-old du -s *

Having chosen a user, with username user, we copy the directory to its new location,

tar cf - user | (cd /site/host/home-new; tar xpvf - )

edit the new location in the password file,

emacs /etc/passwd

and finally remove the old data:

rm -r user

Users need to be informed about the move: we have to remember that they might hard-code the names of their home directories in scripts and programs, e.g. CGIscripts. Also, the user’s account must be closed by altering their login shell, for instance, before the files are moved.

5.6.5Deleting old users

Users who leave an organization eventually need to be deleted from the system. For the sake of certainty, it is often advisable to keep old accounts for a time in case the user actually returns, or wishes to transfer data to a new location. Whether or not this is acceptable must be a question of policy. Clearly it would be unacceptable for company secrets to be transferred to a new location. Before deleting a user completely, a backup of the data can be made for safe-keeping. Then we have to remove the following:

•Account entry from the password database.

•Personal files.

•E-mail and voice mail and mailing lists.

•Removal from groups and lists (e.g. mailing lists).

•Removal of cron and batch tasks.

•Revocation of smartcards and electronic ID codes.

2Some systems might be equipped with virtual volume managers which provide the illusion of infinitely large partitions, but not everyone can afford this luxury.