Pulling Strings With Puppet - James Turnbull [13]
Now you've got a simple Puppet master daemon running and have your first node connected. If you want you can now jump ahead to Chapter 3 to look at how to use Puppet to configure your hosts, or you can continue to read this chapter to learn more about how to run and configure Puppet.
Running the Puppet Daemons
Like most Unix and Linux applications, the Puppet daemons, puppetmasterd and puppetd, can be started and stopped using your platform's standard spawn process. Indeed, if you've installed Puppet from a package, you'll usually find that the package installation process has added the appropriate links and scripts to start the daemons when your host boots.
If you have manually installed Puppet from source, or your package installation has not provided a control script, you can find a variety of scripts you can use in the Puppet source package in the conf directory. Currently, there are scripts and configuration files for FreeBSD (which can be easily adjusted for other BSD platforms), Gentoo, Red Hat, Solaris, and SuSE. You can easily modify the files available to suit most platforms capable of running Puppet.
Tip - The Puppet daemons also do some signal handling. The Puppet master and client daemons both recognize the SIGHUP signal, which forces the daemons to restart themselves. The SIGINT signal will terminate both the master and client daemons. The Puppet client also processes the SIGUSRS signal, which causes the daemon to initiate a new connection to the server and check for new configuration.
Configuring Puppet
Your Puppet installation comes with a number of binaries that run the various Puppet functions and daemons. We've already touched on the puppetd, puppetmasterd, and puppetca binaries, but we'll go into more detail on them in the sections that follow. This is not a definitive guide to every configuration option but rather focuses on the key options. For a full reference to every command-line and configuration file option, you can find a guide at http://www.reductivelabs.com/trac/puppet/wiki/ConfigurationReference.
Each Puppet binary can be configured via the command line or via a configuration file or files. In Table 2-6, you can see a list of all the Puppet binaries and their purposes.
Each binary has a different set of command-line options you can use to run and configure it. The easiest way to see the configuration options used for each binary is by executing the binary with the --help option like so:
Note -► To get the --help text, you need to have the RDoc library installed as discussed earlier in this chapter.
Puppet configuration can also be managed via configuration file. Puppet's configuration file model is in the style of INI files. Each file is divided into namespace sections, and each section name is enclosed in parentheses and named for the Puppet function it configures; for example, the namespace used to configure the Puppet client daemon is called [puppetd]. The use of namespaces means options can be used in multiple namespaces, if the option is relevant to the binary being configured. For example, you can specify the same option twice, with different values, in the [puppetd] and [puppetmasterd] namespaces, and each binary will use only the configuration option contained in its own namespace.
In Table 2-7, I've listed the key namespaces in the configuration file.
You can see an example of a Puppet configuration file in Listing 2-4.
Listing 2-4. Puppet Configuration File
You can see we've defined two namespaces, [main] and [puppetd], in Listing 2-4 and specified some configuration options in each. Configuration options are structured as follows:
Boolean options are structured like so:
Or:
Each Boolean option is either defined as true or false.
When parsing a configuration file, all binaries will set options contained in the [main] namespace and will then set any options specified in the section named for