Adding the Package Repository

Now we’ll install and enable a Puppet Labs Puppet Collection repository on your fresh new system. Our first step is to check what the latest Puppet Collection is. You can find this at “Using Puppet Collections” in the Puppet Labs online documents.

Get the URL for the Enterprise Linux 7 Collection and install that package as described in the documentation.

[vagrant@client ~]$ sudo yum install -y \
 http://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

This installs and enables a Puppet Collection package repository, which contains the Puppet 4 package. After it has finished installing, you can confirm it is enabled with the following command:

[vagrant@client ~]$ sudo yum repolist
Loaded plugins: fastestmirror
...snip repository checks...
repo id                      repo name                                   status
base/7/x86_64                CentOS-7 - Base                             9,363
extras/7/x86_64              CentOS-7 - Extras                             451
puppetlabs-pc1/x86_64        Puppet Labs PC1 Repository el 7 - x86_64      128
updates/7/x86_64             CentOS-7 - Updates                          2,146
repolist: 12,088

This shows you that there were 128 packages in the puppetlabs-pc1 repository (when this book was last updated).

Installing the Puppet Agent

Now let’s go ahead and install the Puppet agent:

[vagrant@client ~]$ sudo yum install -y puppet-agent
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.sonn.com
 * extras: mirrors.loosefoot.com
 * updates: mirrors.sonic.net
Resolving Dependencies
--> Running transaction check
---> Package puppet-agent.x86_64 0:1.10.9-1.el7 will be installed
--> Finished Dependency Resolution

...snip lots of output...

Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : puppet-agent-1.10.9-1.el7.x86_64             1/1
  Verifying  : puppet-agent-1.10.9-1.el7.x86_64             1/1

Installed:
  puppet-agent.x86_64 0:1.10.9-1.el7

Complete!

Guides for installing Puppet on other platforms can be found in Appendix A.

Reviewing Dependencies

If you have installed previous versions of Puppet, you’re accustomed to seeing dependency packages installed along with Puppet. Puppet 4 uses an All In One (AIO) installer, where all dependencies are installed together with Puppet. You can view these in the new installation directory:

[vagrant@client ~]$ ls -la /opt/puppetlabs/bin/
total 0
drwxr-xr-x 2 root root 68 Apr 6 4:41 .
drwxr-xr-x 4 root root 29 Apr 6 4:41 ..
lrwxrwxrwx 1 root root 33 Apr 6 4:41 facter -> /opt/puppetlabs/puppet/bin/facter
lrwxrwxrwx 1 root root 32 Apr 6 4:41 hiera -> /opt/puppetlabs/puppet/bin/hiera
lrwxrwxrwx 1 root root 30 Apr 6 4:41 mco -> /opt/puppetlabs/puppet/bin/mco
lrwxrwxrwx 1 root root 33 Apr 6 4:41 puppet -> /opt/puppetlabs/puppet/bin/puppet

Unlike previous versions, the Puppet commands are not installed in /usr/bin, and won’t be available in your default path. This puppet-agent package adds the file /etc/profile.d/puppet-agent.sh, which will add /opt/puppetlabs/bin to your path. This file is automatically included by the Bash shell during initialization. Let’s use that now:

[vagrant@client ~]$ which puppet
/usr/bin/which: no puppet in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
[vagrant@client ~]$ source /etc/profile.d/puppet-agent.sh
[vagrant@client ~]$ which puppet
/opt/puppetlabs/bin/puppet

Let’s review the other programs you see in this directory besides Puppet:

Facter

Facter is a program that evaluates a system and provides a number of facts about it. These facts include node-specific information (e.g., architecture, hostname, and IP address), in addition to custom information from plugins provided by Puppet modules. For a sneak preview, run the command facter right now and look at all the information it has.

We’ll be covering how to make use of Facter facts in Chapter 5, and how to create custom facts in Part II.

Hiera

Hiera is a component we’ll use to load in the data used by Puppet manifests and modules. Hiera allows you to provide default values and then override or expand them through a customizable hierarchy. This may sound complex, but Hiera’s beauty and elegance comes from its simplicity.

You’ll learn how to use Hiera in Part II, and after its introduction, you will see Hiera used in every subsequent example in the book.

Marionette Collective

Marionette Collective, or MCollective, is an orchestration framework tightly integrated with Puppet.

You’ll learn how to use it in Part IV, where we’ll use the mco client to manipulate the Puppet agent.

Reviewing Puppet 4 Changes

If you have installed previous versions of Puppet, you’ll notice that the installation packages and the configuration file paths have all changed.

Making Tests Convenient

Throughout this book, you’ll edit files and make changes within the Puppet configuration directory. Normally, this would require you to type sudo every time you want to change a file.

I have found that most people prefer the following change to create an easier-to-use environment for learning (this command will make the vagrant user the owner of all files in that directory):

[vagrant@client ~]$ sudo chown -R vagrant /etc/puppetlabs

The remainder of this book assumes you have made this change. If you decide to continue using sudo, you’ll need to add it to any command involving files in /etc/puppetlabs.

[vagrant@client ~]$ sudo chown -R vagrant /etc/puppetlabs
[vagrant@client ~]$ sudo puppet apply -e ''
Notice: Compiled catalog for client.example.com in environment production
Notice: Applied catalog in 0.01 seconds

Obviously you won’t be using the vagrant user in a production environment. However, it is not uncommon to see something like the following done to give write access to all members of a certain group:

[vagrant@client ~]$ sudo chgrp -R sysadmin /etc/puppetlabs
[vagrant@client ~]$ sudo chmod -R g+w /etc/puppetlabs

One reason you may not want to change the ownership of this directory would be if your Puppet deployment was managed by continuous integration tools, and you want to ensure that everybody uses the tools. That won’t be a problem when using this book, and chown -R vagrant /etc/puppetlabs is highly recommended for the lessons here.

Running Puppet Without sudo

When you run Puppet with sudo, it uses the system-level configuration files, like so:

[vagrant@client ~]$ sudo puppet config print |grep dir
confdir = /etc/puppetlabs/puppet
codedir = /etc/puppetlabs/code
vardir = /opt/puppetlabs/puppet/cache
logdir = /var/log/puppetlabs/puppet
...etc...

When you run Puppet without sudo, it will use paths in your home directory for configuration files. This can be useful when you are writing and testing small manifests:

[vagrant@client ~]$ puppet config print |grep dir
confdir = /home/vagrant/.puppetlabs/etc/puppet
codedir = /home/vagrant/.puppetlabs/etc/code
vardir = /home/vagrant/.puppetlabs/opt/puppet/cache
logdir = /home/vagrant/.puppetlabs/var/log
...etc...

Most people don’t want to be constantly migrating changes back and forth between two different directory structures. There are two ways to resolve this dilemma:

Use sudo every time you run Puppet

While this is an easy-to-remember way of working, I find myself less comfortable with this option. There are many manifests that can be tested without root access, and many Puppet commands that perform simple lookups for which root access is not required.

Set up a configuration file to use the system-level paths

Modify your personal Puppet configuration to use the system-level paths. This allows you to run Puppet commands that read the same modules and configuration data without invoking root-level access.

I much prefer the second approach, and I recommend it for daily use. For this reason, we have preinstalled the ~/.puppetlabs/etc/puppet/puppet.conf configuration file on all Vagrant configurations, which enables this for you. Check it out:

[vagrant@client ~]$ cat ~/.puppetlabs/etc/puppet/puppet.conf
# Allow "puppet hiera" and "puppet module" commands without sudo
[main]
    logdest = console
    confdir = /etc/puppetlabs/puppet
    codedir = /etc/puppetlabs/code

If you don’t like this setup, you are welcome to remove this file. Just remember to use sudo with every Puppet command, or it will use a different configuration file than you expect.

Running Puppet with sudo

On most systems, the sudo command resets the user search path to a list of known safe directories. Unfortunately, this does not include the Puppet directory. You can see the effect of this change with the following command:

[vagrant@client vagrant]$ env |grep PATH
PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/puppetlabs/bin:
  /home/vagrant/.local/bin:/home/vagrant/bin

[vagrant@client vagrant]$ sudo env |grep PATH
PATH=/bin:/sbin:/bin:/usr/sbin:/usr/bin

If you want to run Puppet with sudo, you’ll need to add the /opt/puppetlabs/bin directory to sudo’s secure_path default. The following command will get the current secure_path from the sudoers file, and create a sudoers.d/ config extension that appends /opt/puppetlabs/bin:

$ sudo grep secure_path /etc/sudoers \
    | sed -e 's#$#:/opt/puppetlabs/bin#' \
    | sudo tee /etc/sudoers.d/puppet-securepath
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/opt/puppetlabs/bin

$ sudo env |grep PATH
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/opt/puppetlabs/bin

Reviewing Puppet Installation

During the course of this chapter, you did the following:

• Enabled the Puppet Yum repository on your system.
• Installed Puppet and its dependencies from this repository.
• Learned the dependencies that support Puppet.
• Reviewed the changed paths used by Puppet 4 on Unix/Linux systems.

Best of all, none of this was done with magic helper scripts that hid the details from you. You can repeat these exact steps on any test or production node to install or upgrade Puppet.