• Choose a category
• All
• Classic-Fiction

The apache::virtual_host definition is included in the apache module and allows us to define one or more virtuals hosts. So how would we use this definition? Well, we'd invoke it in each node and for each virtual host we'd like to create. You can see this in Listing 422.

Listing 4-22 shows the definition of the web.testing.com node. We invoke the apache::virtual_host definition twice. Each time the definition creates a configuration file in the /etc/httpd/conf. d/ directory that is based on the virtual_host. erb template. You can see this template here:

The template is populated with the document root, the IP address, and the server name variables from the definition. The resulting file for the first invokation of the apache::virtual_host definition would look like this:

Next, a directory is created for each virtual host to hold the site's files. Lastly, the definition triggers a reload of the httpd service with the use of the notify metaparameter.

If we wanted to remove a virtual host, we would set the ensure attribute to disabled in the definition like so:

This would remove the testi.testing. com configuration files and the associated directory. The httpd service would then be restarted to update Apache with the new configuration.

And again in Listing 4-4, you'll see that we have included the apache module in our templates. pp file as part of the webserver template node.

Resources

There are a lot of examples of Puppet configurations, especially modules. Listed here are some of these examples:

• Reductive Labs Puppet module page, which includes modules for xen, git, and ntp, among others:

• Reductive Labs wiki page, which details module organization:

• Puppet Show-a Ruby on Rails tool for managing Puppet including nodes and configuration:

• A CPAN-like way of distributing Puppet modules:

• A collection of Puppet recipes for configuring a variety of resources, applications, and daemons:

• A Git repository containing a collection of modules:

• David Schmitt's collection of Puppet configuration and modules:

• Modules for managing daemontools and djbdns:

• Suggested template for documenting manifests:

• David Letter's sample Puppet deployment:

CHAPTER 5

Reporting on Puppet

One of the key aspects of any configuration management system is reporting. Reporting on a configuration management system can provide information on performance and compliance to policy and standards, and provide graphical representations of the overall state of your configuration. Puppet's reporting engine is limited at this stage but still allows some useful, albeit basic, reporting that can be graphed and displayed.

In this chapter, I'll explain what reports are available and how to work with them, look at graphing our reporting data, and briefly discuss how to build custom reports.

Getting Started

Puppet clients can be configured to return data at the end of each configuration run. Puppet calls this data a transaction report. The transaction reports are sent to the master server, where a number of report processors exist that can utilize this data and present it in a variety of forms. You can also develop your own report processors to customize the reporting output.

Each transaction report comes in the form of the YAML file. YAML, which is a recursive acronym for "YAML Ain't Markup Language," is a human-readable data serialization format that draws heavily from concepts in XML and the Python and C programming languages.

The transaction reports contain all log messages generated by the transaction and some additional metrics. The metrics fall into three general types: time, resource, and change metrics. Within each of these metrics are one or more values. They include the following:

• Transaction metric showing the time taken by the transaction

• Resource metrics including

• Total: Total number of resources being managed

0 Skipped: Total resources that were skipped

• Scheduled: Total resources that were scheduled

• Out of Sync: Total resources that were out of