UNIX system administration handbook
UNIX system administration handbook
How to Upgrade 1500 Workstations on Saturday, and Still Have Time to Mow the Yard on Sunday
LISA '95 Proceedings of the 9th USENIX conference on System administration
Tracking Hardware Configurations in a Heterogeneous Network with syslogd
LISA '95 Proceedings of the 9th USENIX conference on System administration
Automating the Administration of Heterogeneous LANs
LISA '96 Proceedings of the 10th USENIX conference on System administration
Automation of Site Configuration Management
LISA '97 Proceedings of the 11th USENIX conference on System administration
An Analysis of UNIX System Configuration
LISA '97 Proceedings of the 11th USENIX conference on System administration
A Configuration Distribution System for Heterogeneous Networks
LISA '98 Proceedings of the 12th USENIX conference on System administration
An NFS Configuration Management System and its Underlying Object-Oriented Model
LISA '98 Proceedings of the 12th USENIX conference on System administration
LISA '98 Proceedings of the 12th USENIX conference on System administration
A Retrospective on Twelve Years of LISA Proceedings
LISA '99 Proceedings of the 13th USENIX conference on System administration
Pan: A High-Level Configuration Language
LISA '02 Proceedings of the 16th USENIX conference on System administration
Hi-index | 0.00 |
One problem that faces system administrators is how to install and maintain local configuration information on a large number of machines. Some previous approaches such as cloning [2] help, but they only provide a baseline, not ongoing configuration control. Other mechanisms such as Typecast [7], Hobgoblin [5], Scrape [3] or Mkserv [6] assist in the configuration process, and provide some support for ongoing maintenance. However supporting multiple system configurations is still troublesome. Also it can be very difficult to delegate system administration tasks. Insufficient logging of file changes can create a nightmare when attempting to find the cause of a problem. The method we present uses rdist and integrates it with make(1) and the CVS version control system to provide the ability to delegate and log changes. End node users can make changes to their workstations, however all changes are logged, so that it is possible to see what has changed on a given machine when problems occur. When making changes that affect a large number of machines (e.g., amd automount maps, rc files) previous versions of the file are available in the CVS tree and can be retrieved and distributed in case of unforeseen problems.