The lives of system administrators and operations staff often revolve around a series of repetitive tasks: configuring hosts, creating users, and managing applications, daemons, and services. Often these tasks are repeated many times in the life cycle of one host, from building to decommissioning, and as new configuration is added or corrected for error or entropy.
The usual response to these repetitive tasks is to try to automate them with scripts and tools. This leads to the development of custom-built scripts and applications. In my first role as a systems administrator, I remember creating a collection of Control Language (CL) and Rexx scripts that I subsequently used to manage and operate a variety of infrastructure. The scripts were complex, poorly documented and completely customized to my environment.
My experience is not unique, and this sort of development is a common response to the desire to make life easier, automate boring, manual tasks and give you a few more minutes in the day for the more interesting projects and tasks (or to get to the pub earlier).
Very few of the scripts developed in this ad hoc manner are ever published, documented, or reused. Indeed, copyright for most custom material rests with the operator or system administrator’s organization and is usually left behind when they move on. This leads to the same tool being developed over and over again. Sometimes they are even developed over and over again in the same company if previous incarnations don’t suit a new incumbent (or occasionally, if they are indecipherable to a new incumbent!).
These custom scripts and applications rarely scale to suit large environments, and they often have issues of stability, flexibility, and functionality. In multi-platform environments, such scripts also tend to suit only one target platform, resulting in situations such as the need to create a user creation script for BSD, another one for Linux, and still another for Solaris. This increases the time and effort required to develop and maintain the very tools you are hoping to use to reduce administrative efforts.
Other approaches include the purchase of operations and configuration management tools like HP’s Opsware, BMC’s CONTROL-M, IBM’s Tivoli suite, and CA’s Unicenter products. But commercial tools generally suffer from two key issues: price and flexibility. Price, especially, can quickly become an issue: The more platforms and hosts that you are managing, the greater the price. In large environments, licensing for such tools can run to millions of dollars.
Flexibility is also a key concern. Commercial tools are usually closed source and are limited to the features available to them, meaning that if you want to extend them to do something custom or specific to your environment, you need to request a new feature, potentially with a waiting period and associated cost. Given the huge varieties of deployments, platforms, configurations and applications in organizations, it is rare to discover any tool that provides the ability to completely customize to suit your environment.