Managing Server Configuration Files

Any server configuration file that is not 'boilerplate' should live in the serverfiles project in the lab's file system. When you want to change a configuration file, check first to see if the configuration file is part of the serverfiles project for the server in question. If no (or adding a new system to an Ahatlab server), please add the file to the appropriate project and update the LabData topic.

When altering configuration files, for each change, comment out the line with the default value, make a copy of the line with the default value immediately below the commented out line and make changes to the copy. Initial and date the change. This process helps a lot with retaining and sharing knowledge - as researchers, we tend to delve into a server or OS topic related to our interests, eventually developing a lot of expertise in an area, then not needing that expertise for weeks, months, or even years. It's frustrating to have to relocate and/or relearn information later. So document things at the moment you do them. The specific process described also optimizes tracking changes with diff reports when doing version upgrades, whether of a specific subsystem or an entire OS (see UpgradingFedoraWithYum.)

Puppet and Cft combine to form a much more agile approach to configuration management.

Using Puppet Configuration Recipes

Puppet is a declarative language designed to

• automate systems administration (duh...)
• expose the relationships between systems emphasizing stable configuration data, not the transient fine details involved in each build
• document both the stable data and the transient fine details, rendering the outcome reliable and repeatable.

As such, Puppet offers a general protocol layer that can be used to radically stabilize managing the ever changing set of clients and servers used in a pocket research lab. Specialized deployment tools such as Capistrano may be used in combination with Puppet .

A particular set of relationships and files designed to accomplish a particular task is called a recipe. A recipe may contain supporting files as well as describing sets of changes appropriate for various types of servers. Very clever. Puppet is written in RuBy, btw.

Puppet uses Facter to profile each host. Facter is also written in Ruby, and can be extended to include custom 'facts', which Puppet can then take into account in the design of recipes.

A central server called the PuppetMaster stores and serves templates called manifests.

[back to top]

see also ServerAdminGuidelines

• Just testing -- ScottBieser - 28 Oct 2008