Pulling Strings With Puppet - James Turnbull [3]
All of the source code, associated scripts, and configuration examples can be downloaded from the Apress web site. You can also submit any errata at the site.
If you have any questions and queries about the book, please do not hesitate to e-mail me at fames@hardening-linux.com.
CHAPTER 1
Introducing Puppet
The lives of system administrators and in general individuals employed in IT's operational sector 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 in order to add new configuration or remedy configuration that has changed through error, entropy, or development. These tasks can be an ineffective use of time and effort.
The usual first response to these tasks is to try to automate them. This leads to the development of custom-built scripts and applications. In my first role as an 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. Very little 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 administrator's organization and is usually left behind when they move on. This leads to the same tool being developed over and over again.
Custom scripts and applications rarely scale to suit large environments and often have issues of stability, flexibility, and functionality. 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, 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 configuration management applications like Opsware, BMC's CONTROL-M, and CA's Unicenter products. But commercial tools generally suffer from two key issues: price and flexibility. Cost can quickly become an issue because the more types of platform and number of hosts that you are managing, the greater the cost. Commercial tools are also usually closed source and are limited to the features available to them, meaning that if you want to extend them, do something custom or specific to your environment, you need to request a new feature, potentially with a waiting period and associated cost.
Free and Open Source Software (FOSS) systems and configuration management tools offer an alternative to both custom and commercial solutions, offering two key opportunities for organizations:
• They are open and extensible.
• They are free!
With FOSS products, the tool's source code is at your fingertips, allowing you to develop your own enhancements or adjustments. You are also part of a community of developers who share the vision for the development of that tool. And you and your organization can in turn contribute to that vision. This ability to shape the direction of the tools you are using can certainly result in a more flexible outcome for your organization.
The price tag is also obviously an important consideration for the purchase of any tool. While you sacrifice paid support for many tools, you do get the tool itself at no cost. Additionally, the active Puppet community can and does provide support. With the price of many commercial configuration management tools running into hundreds of thousands of dollars, the potential cost savings from the use of an open source tool can be substantial.
In the configuration management space, a variety of open source tools are available, in various stages of development and maturity. Some of the key products in this area are
• Puppet(http://puppet.reductivelabs.com/):
A configuration management tool written in Ruby with a client-server model that uses a declarative language to configure clients.
• cfengine (http://www.cfengine.org/):