7.2. METHODS: CONTROLLING CAUSES AND SYMPTOMS |
237 |
default configuration. A response to software piracy. A response to anti-social behavior and harassment of others (spamming, obnoxious news postings etc.). Are users allowed to play games, if so when? Are users allowed to chat online? Are users allowed to download files such as MP3 or pornography? Policy on sharing of accounts (i.e. preferably not). Policy on use of IRC robots and other automatic processes which collect large amounts of data off-line. Policy on garbage collection when disks become full: what files can legitimately be deleted?
•Network: Will the network be segmented, with different access policies on different subnets? Will a firewall be used? What ports will be open on which subnets, and which will be blocked at the router? What services will be run?
•Mail: Limit the size of incoming and outgoing mail. Spam filtering. Virus controls.
•WWW: Allowing or forbidding user CGI scripts. Guidelines for allowed content of web pages. Policy regarding advertising on web pages. Load restrictions: what to do if certain pages generate too much traffic. Policy on plagiarism and illegal use of imagery.
•Printing: How many pages can be printed? Is printing of personal documents allowed? Should there be a limit to the number of pages which can be printed at one time (large documents hold up the print queue)?
•Security: Physical security of hosts. Backup schedule. Who is allowed to be master of their own hosts? Can arbitrary users mount other users’ home directories or mailboxes with NFS on their private PCs (this means that they have automatic access to everyone’s personal files)? What access controls should be used on files? Password policy (aging, how often should passwords change) and policy on closing accounts which have been compromised.
•Privacy: Is encryption allowed? What tools will be provided for private communication?
See also the discussion of policy as a system administration tool in refs. [341, 140].
7.2 Methods: controlling causes and symptoms
Component-based software development is a central theme in modern design, and it has almost exclusively followed the path of trading control over algorithmic detail for limited freedoms through configurable parameters to standardized ‘methods’. Sun Microsystems’ Java technology and Microsoft’s .NET are two recent developments that exemplify this trend. The need for configuration is thus a feature of all modern software systems, and what was previously an issue of programming a sequence of imperative logic, is now an issue of administrating a few basic choices. Thus programming is increasingly turning into system administration.
238 |
CHAPTER 7. CONFIGURATION AND MAINTENANCE |
As we move ever more towards standardized methods and algorithms, the process of programming becomes increasingly one of administering the few remaining choices, as configuration options.
Example 4. In Java-related technologies, there is a vast library of standardized methods for performing every kind of operation, from basic algorithms for hashing or encryption, to graphics, to database access. Low-level details are withheld from programmers, e.g. explicit database queries in SQL are replaced by standardized methods that hide the implementation details, and offer parameters for customizing usage. The issue is no longer one of creativity with basic imperative logic, but one of combining standardized blocks and materials into a usable scheme, more like an interior designer.
Software engineers seldom think of the process of configuring components as a system administration issue, because ‘system administration’ is commonly assumed to apply only to the low-level infrastructure such as hardware and software installation. Nevertheless, it is important to understand the equivalence of these issues, because many flaws in software systems are provoked and exploited because software engineers make naive assumptions about infrastructure. Similarly, software engineers seldom think carefully about how software will be configured in practice across large installation bases. System administrators are thus left to improvise the best from a bad lot.
Clearly, there is a trade-off between detailed control and increasing standardization.
Principle 40 (Standardized methods offer predictability). Replacing direct low-level control with configurable high-level interfaces increases standardization and thus predictability. If the methods are implemented correctly, this improves quality control; if they are flawed, it becomes a systematic error, but with only a single point of failure and repair.
This trade-off is always a dilemma in the policy-making and government of both man and machine. There are ethical issues here also. By adopting standardized methods, one removes freedom of choice from the end user, or programmer; it is an authoritarian strategy that some users find disturbing, because it assumes that a high-level, standard authority knows better than a low-level technician, which is seldom true in a knowledge-based society; but it also has clear benefits of simplification to offer. There is economy in standardization, and – correctly implemented – a standard can find great leverage in the experiences of experts. Great power requires great responsibility, however, and should not be wielded in an inflexible way.
Example 5. The control of basic infrastructure can be a huge responsibility. We have seen examples of this in the dominance of the Windows operating systems. The ease with which viruses propagate, for instance, is a direct result of the permissiveness of the operating system infrastructure. The lack of control administrators have over the basic methods prevents them from effectively solving the problem of viruses, except by installing counter-virus software.
7.3. CHANGE MANAGEMENT |
239 |
In this case, standardization to an unsatisfactory state leads to strategies for relieving symptoms rather than curing them at source. We can elevate this to a principle.
Principle 41 (Symptoms and cause). Inadequate control over infrastructure demands a strategy of short-term symptom relief in lieu of a more permanent reparation at source.
Although it is preferable to fix problems at source, it is not always possible to do so. There will always be a need to distinguish between short-term patches and long-term patches, since the rate of software correction is much less than the rate at which errors are discovered.
7.3 Change management
The opposite side of the coin in configuration and maintenance is the management of significant changes, e.g. upgrades, redesign and replacement. Can such things be done without disruption to service? Does this idea contradict the idea of convergence referred to in section 6.7? Planning changes of infrastructure can be dealt with using two general strategies:
•Deconstruction followed by reconstruction.
•Change of policy description followed by convergence to a new state.
We might call these ‘change’ and ‘organic growth’ respectively. Traugott and Huddleston introduced the idea of infrastructure management in ref. [305] to describe the construction of systems from the bottom up. Traugott has later argued that this infrastructure needs to be maintained in much the same way as building it in the first place. Change management then becomes a reconstruction of infrastructure. An ideologically ‘convergent’ approach (typified by cfengine) would be to try to gradually change aspects of policy and allow the system to converge towards the state associated with the change.
To date, no study has been performed to compare these two approaches for major changes. Clearly, the larger the magnitude of a change, the closer these two approaches must become. The amount of work required to perform large changes through differential adjustment grows significantly with the magnitude of the change. At some point, the benefit of adjustment rather than reconstruction becomes ambiguous. Many system administrators will doubtless feel more comfortable with starting from scratch when large changes need to be made as a matter of convenience.
Why would people go over to the new, if the old still works? When making changes, one must not forget the issue of service provision and reliability. Temporary redundancy of service is a sensible precaution in a mission-critical environment. If something should go wrong during a change, service must continue. Securing predictability during a change is a tricky business, because the conditions under which a system is performing its function are changing. Change management can thus be viewed as a problem in risk or fault management. We return to this viewpoint in section 8.8.
240 |
CHAPTER 7. CONFIGURATION AND MAINTENANCE |
7.4 Declarative languages
The idea that standardization can be achieved by providing only configuration parameters to predefined methods naturally leads us into the area of declarative languages, such as make or Prolog.
An imperative programming language, such as C or Perl, is a traditional specification of the steps required to build an algorithm that alters the state of the system from some initial state to a final one. The key feature is that the programmer must specify the route taken to get from initial to final state. With a declarative language, one does not say how to get from initial to final state, but rather what the final state should be. The language itself uses its battery of standard methods then to evaluate a solution to the problem. The result is an extremely economical form of expression, stripped of details that are usually irrelevant to the language user.
Cfengine is one specialized language for the purpose of configuration management [38, 41, 55] that has features in common with Prolog [79]. A declaration takes the form:
circumstances:
declarative actions new resulting circumstances
Thus when a certain set of circumstances arises, the declared actions are evaluated, leading possibly to new follow-up circumstances, with other rules to be evaluated. Rules are evaluated in an unspecified order, using an unspecified schedule.
The Unix tool make is similar to this, but it evaluates its dependencies both imperatively and recursively:
circumstances: prior dependent circumstances
imperative actions
With make, users have to specify the details of how to get from the initial to the final state using a secondary language; make is only a host framework for other language interpreters. Cfengine, on the other hand, has expert knowledge in the form of standard methods with special properties (see section 7.11).
7.5 Policy configuration and its ethical usage
The move towards systems built from standard configurable methods has another aspect that is somewhat darker. Although we shall not exaggerate its importance, it has long-term implications that are worthy of consideration by all system designers.
The removal of control from end users can mean a removal of the detailed knowledge required to run a system. This is a ‘dumbing down’ of the task of system administration. Such a prolonged dumbing down can result in a loss of the expertise required to diagnose and run the system. In turn this implies a