Pro Puppet (33 page)

Listing 6-7.
Verifying stored configuration tables

Listing 6-8.
Adding an index on the resources table

This command creates an index on the
exported
,
restype
and
title
fields in the
resources
table.

With stored configurations enabled in the Puppet master, we can now export resources from a node's catalog. These exported resources may then be collected on another node, allowing nodes to exchange configuration information dynamically and automatically. In this section we'll examine a number of common use cases for exported resources.

The first example will export the public SSH host identification key from each Puppet-managed node and store the resources centrally in the stored configuration database. Every node may then collect all of the public host keys from all other nodes. This configuration increases security and eliminates the “unknown host” warning commonly shown when logging in via SSH for the first time.

The second example we provide uses exported resources to dynamically re-configure a load balancer when additional Puppet master worker processes come online.

Finally, you'll see how to dynamically and automatically reconfigure the Nagios monitoring system to check the availability to new Puppet managed systems.

When new systems are brought online in a large network, the
known_hosts
files of all other systems become stale and out of date, causing “unknown host” warnings when logging in using SSH. Puppet provides a simple and elegant solution to this problem using stored configurations and exported resources. When new systems are brought online, Puppet updates the known_hosts file on all other systems by adding the public host key of the new system. This automated management of the known_hosts file also increases security, by reducing the likelihood of a “man-in-the-middle” attack remaining unnoticed.

We learned in this chapter any resource may be declared virtually using the @ symbol before the resource declaration. A similar syntax,
@@
, is used when resources should be declared virtually and exported to all other nodes using stored configurations. The use of
@@
allows any node's catalog to collect the resource.
Listing 6-9
shows how this looks for SSH public keys.

This Puppet code snippet looks a little strange compared to what we've worked with so far.

The class
ssh::hostkeys
should be included in the catalog of all nodes in the network for their SSH public host keys to be exported and collectible. All of the resources and parameters are set to variables coming from Facter fact values. In
Listing 6-10
, two
sshkey
resources have been declared as virtual resources and exported to the central stored configuration database, as indicated by the
@@
symbols. The titles of each resource contain the suffixes
_dsa
or
_rsa
, preventing these two resources from conflicting
with each other. To make sure each resource has a unique title for the entire network, the title also contains the fully qualified domain name of the node exporting the public host keys.

The
host_aliases
parameter provides additional names and addresses the node may be reached by. This information is important to prevent the “unknown host” warnings when connecting to the node from another system. In this example, we're providing the fully qualified domain name, short hostname, and IP address of the system. Each of these values comes from
facter
and is automatically provided.

They
type
and
key
parameters provide the public key information itself. The values of
$sshdsakey
and
$sshrsakey
also come from Facter and are automatically available on each host.

Exporting these two
sshkey
resources is not sufficient to configure the
known_hosts
file on each node. We must also collect all exported sshkey resources for Puppet to fully manage and keep updated the
known_hosts
file shown in
Listing 6-10
.

The
ssh::knownhosts
class should be included in the catalog for all nodes where Puppet should manage the SSH
known_hosts
file. Notice that we've used double angle braces to collect resources from the stored configuration database. This is similar to collecting virtual resources, however virtual resources only use a
single
pair of angle braces. We're also specifying that the
ensure
parameter should take on the value “present” when collecting the exported
sshkey
resources.

With the two classes configured and added to the node classification for every host in the network, the operator verifies host keys are collected on every node in the network.

First, our operator runs the Puppet agent on the
mail.example.com
host. Since this is the first host to run the Puppet agent, he expects only two SSH keys to be collected: the keys exported by the mail host itself, as you can see in
Listing 6-11
.

Note the two sshkey resources being collected from the stored configuration database, the ssh dsa and rsa public key exported from the
mail.example.com
host.

In
Listing 6-12
, the operator runs Puppet on the web server, expecting the public keys for both the web host and the mail host to be collected.

The Puppet agent on
web.example.com
manages a total of four ssh host key resources, as shown in
Listing 6-12
. The rsa and dsa keys from both the mail host and the web host are now being exported and stored in the configuration database.

Finally, running the Puppet agent once more on the
mail.example.com
host should result in the two public keys exported by the web host being collected and managed.
Listing 6-13
shows how the operator verifies this.

As expected, the two SSH public key resources exported by the web host are correctly being collected on the mail host. By exporting and collecting two sshkey resources, the staff of Example.com can rely on all hosts automatically knowing the identity of all other hosts, even as new hosts are added to the network. So long as Puppet runs frequently, every system will have a
known_hosts
file containing the public key of every other system in the network.

In the next example, you'll see how this feature also allows the automatic addition of worker nodes to a load balancer pool.

In the previous example, SSH public key resources were exported and stored in the configuration database so that every host in the network is able to collect the public identification keys of every other host in the network. Along the same lines, but on a much smaller scale, you can also export resources to a single node on the network, such as a load balancer.

In this example, HTTP worker nodes will export configuration resources that only the load balancer will collect. This combination eliminates the need to manually reconfigure the load balancer every time a new worker node is added to the network.

Each load balancer worker will export a defined resource type representing the load balancer configuration. Let's see how the Example.com operator configures this system now. The load balancer software being used in this example is Apache. The Example.com operator models the configuration of a
HTTP worker using a file fragment placed into the directory
/etc/httpd/conf.d.members/
. Let's first take a look at the defined resource type, shown in
Listing 6-14
.

This configuration file fragment contains a single line, the URL to a member of the load balancer pool. Using a defined resource type is recommended since all resources declared within will be exported when the defined type itself is exported.

The load balancer configuration is similar to the Apache configuration presented in the Scaling Puppet chapter. Without using exported resources, the Example.com operator might define his load balancer configuration statically, as shown in
Listing 6-15
.

In this example, three Puppet master workers have been statically defined. If the Example.com operator would like to add additional capacity, he would have to add a fourth line to this Apache configuration block. Exported resources allow him to save this manual step and automatically add the configuration once a new worker node comes online and is configured by Puppet. To accomplish this, the Example.com operator replaces all of the
BalancerMember
statements with an Include statement to read in all of the file fragments. In the Puppet manifest, these configuration statements are modeled using the balancermember defined type, shown in
Listing 6-16
.