Exploring the Puppet configuration file

Let's take a look at the default configuration that ships with Puppet Open Source. By default, you can find the config file in the /etc/puppet/puppet.conf directory. The configuration file is as follows:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates

[master]
# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

The first interesting thing to note about this configuration file is that it can be used for the Puppet agent, Puppet master, and Puppet apply commands. Many items of the configuration file tend to be common items such as log directories, run directories, and so on, so there is no real need to keep a separate version of these files for each role. Again, this is an example of the common way that Puppet has been designed, when it comes to configuration.

The puppet.conf file is split up using the standard ini notation of using configuration blocks to separate roles and the common configuration. The most common blocks that you will encounter are [main], [agent], and [master], although sites that have implemented either Puppet faces or Puppet environments may have more. Generally speaking, as these additional configuration blocks are not used to set up reporting, we shall ignore them for the purposes of this book.

The [main] configuration block is used for any configuration that is applied regardless of the mode that Puppet is run in. As you can see from the preceding configuration file, this includes locations of SSL certificates, logs, and other fundamental configuration items. These are generally things that you should keep the same on every host, regardless of it being a Puppet master or agent. However, it's worth noting that you can override the settings in a configuration block by setting them in a more specific block elsewhere in the file. Any setting in the [main] configuration block is available to be overridden by any subsequent block further down the configuration file.

The [master] block is used for all configuration items that are specific to the role of the Puppet master. As you can see in the default configuration file, this includes items for Phusion Passenger configurations, but more importantly for us, this is also where you would set items such as the report processor and its options. For our initial setup, we're going to use the master configuration to set where our reports will be stored and ensure that we are using the store report processor.

The [agent] configuration block is utilized when you run Puppet as an agent. It is here that we can set the fairly simple configuration required to make the Puppet agent communicate reports with the Puppet master. We won't be spending much time in this configuration block; the majority of the configuration and processing of the Puppet reports takes place on the Puppet master rather than on the client side. There are some exceptions to this rule; for instance, you may have to amend a client-side setting to make the Puppet agent report to a different Puppet master.

Alternatively, if you are using the HTTP report process, you may wish to set a different URL. So, it's worth having an understanding of the options that are available.

Tip

Why use a separate Puppet report server?

As with all good enterprise solutions, Puppet has been designed to allow certain roles to be decomposed into separate components to ease scaling. Reporting fits into this, and you may find that if you are using report processors that are resource intensive, then you may want to separate the reporting function onto a separate server and leave as many resources as possible for the Puppet master to deal with client requests.

You can find a complete list of all configuration options for Puppet at http://docs.puppetlabs.com/references/latest/configuration.html, including the options for directing reports to a separate Puppet master.