• Choose a category
• All
• Classic-Fiction

First, we need to ensure we have a user and group for the master daemon to run as. If you've installed Puppet from a package, generally a user and group, usually both called puppet, will already have been created for you. You can check for this user by using the id command like so:

You could also check the /etc/passwd and /etc/group files directly:

If the puppet user and group does not exist, you need to create them. I recommend naming both user and group puppet as this is the default Puppet expects. So on a Red Hat host you would create them like so:

Starting the Puppet Master

If we've got a user and group to run the Puppet master server, we can start it using the puppetmasterd binary.

You can see that trying to start puppetmasterd has resulted in an error message stating that the manifest, /etc/puppet/manifests/site.pp, must exist. A manifest is Puppet's term for a text document that defines a particular configuration or configurations. These manifests are then compiled and applied to a Puppet node to set the desired configuration on the node.

Puppet requires a central manifest file, called the site manifest, before the master daemon can be started. By default, this site manifest file is called site. pp and is located in the /etc/puppet/manifests directory (you'll learn how to reconfigure this location later in this chapter). This central manifest will ultimately contain all the configuration information required to configure all your nodes, either directly in the file or by including and importing other files.

But we'll discuss your manifest configuration and how to structure it in Chapter 4. For now, we just want to create a simple site. pp file so we can get Puppet started. First, let's create the directory:

Now, in Listing 2-1 you can see an example site.pp file.

This site.pp file is very simple: it sets the user and group ownership of the /etc/passwd file as well as its permissions. Indeed, our first site. pp file could do anything, we just need a syntactically correct file so we can start the daemon; we will add to it further and look at its syntax in Chapter 3.

Now in Listing 2-2, with our newly created site manifest, let's try to start the master daemon again.

This time we've started puppetmasterd with the --verbose and --no-daemonize options. The --verbose option turns on verbose logging, and the --no-daemonize option forces the master daemon to run in the foreground. This mode is ideal for troubleshooting your master daemon.

Puppet expects to find each node defined in a manifest, either directly in the site. pp file or in another file and imported into the site manifest. The node definitions tell Puppet about each host to be configured and exactly what configuration applies to them; for example, you might have configuration specific to Debian hosts, or to web servers or hosts in a specific location. When you are using node definitions, only the configuration defined to a particular node will be applied to that node.

Puppet detects if you have any nodes defined. If you don't have any defined, as we have here, Puppet turns off node designation. With node designation turned off, all configuration resources (excluding configuration in classes and definitions, which we'll talk about in Chapter 3) defined will be applied to all nodes that connect to the master. As we don't have any nodes, nor any substantive configuration, it's easiest to turn off nodes until we're ready to define our first node. We'll look at node definition in Chapter 3.

From Listing 2-2, you can see the master daemon has started and is listening on TCP port 8140. You'll need to open this port in any firewall you have running on the local host. If the port is open and the master daemon has started without any error messages, you're now ready to connect your first node.

Starting the Puppet Client

Unlike the Puppet master daemon, the Puppet client daemon runs as the root user, allowing it to