About Puppet Collections and packages

Repository organization
About Puppet versions
1. Pinning Puppet package versions
Puppet collection contents
Using Puppet collections
Verifying Puppet packages
1. Automatic verification
2. Manual verification
Nightly repositories

Note: This document covers the Puppet Collection repository of open source Puppet 4-compatible software packages.

For Puppet 3.8 open source packages, see its repository documentation.

For Puppet Enterprise installation tarballs, see its installation documentation.

Puppet maintains official package repositories for several operating systems and distributions. To make the repositories more predictable, we version them as “Puppet Collections” — each collection has all of the software you need to run a functional Puppet deployment, in versions that are known to work well with each other. Each collection is opt-in, and you must choose one (and on some operating systems, install a package on Puppet-managed systems) to install software and receive updates.

Repository organization

Collection repositories are organized into two tiers that correspond to Puppet Enterprise releases, which are downstream from the collection’s open-source components:

Numbered collections, such as Puppet Collection 1 (PC1), are long-lived, stable repositories from which long term support (LTS) Puppet Enterprise releases are built. Numbered collections maintain the same major version of each component package during its lifetime, which delivers bug fixes and minimizes breaking changes, but also introduces fewer new features.
The “latest” collection follows every release of Puppet Enterprise, including versions not considered LTS releases, and is updated with new major-version releases that might introduce breaking changes.

Puppet publishes updates for operating systems starting from the time a package is first published for that operating system to a collection repository, and stops updating those packages 30 days after the end of the operating system’s vendor-determined lifespan.

See The Puppet Enterprise Lifecycle for information about phases of the Puppet Support Lifecycle.

About Puppet versions

Puppet’s version numbers use the format X.Y.Z, where:

X must increase for major backwards-incompatible changes
Y can increase for backwards-compatible new functionality
Z can increase for bug fixes

Pinning Puppet package versions

To receive the most up-to-date Puppet software without introducing breaking changes, use the latest collection, pin your infrastructure to known versions, and update the pinned version manually when you’re ready to update. For example, if you’re using the puppetlabs-puppet_agent module to manage the installed puppet-agent package, use this resource to pin it to version 1.7.0:

class { '::puppet_agent':
  collection      => 'latest',
  package_version => '1.7.0',
}

When puppet-agent 2.0.0 is released, update package_version when you’re ready to upgrade to that version:

class { '::puppet_agent':
  collection      => 'latest',
  package_version => '2.0.0',
}

Puppet collection contents

Puppet Collection 1 contains the following components:

Package	Contents
`puppet-agent`	Puppet, Facter, Hiera, MCollective, `pxp-agent`, root certificates, and prerequisites like Ruby and Augeas
`puppetserver`	Puppet Server; depends on `puppet-agent`
`puppetdb`	PuppetDB
`puppetdb-termini`	Plugins to let Puppet Server talk to PuppetDB

Using Puppet collections

A Puppet Collection (PC) is numbered with an integer, beginning with Puppet Collection 1 (PC1). The larger the integer, the newer the collection.

The way you access a Puppet Collection depends on your operating system, and its distribution, version, and installation methods. If you use a *nix operating system with a package manager, for example, you access a Puppet Collection by adding it as a package repository.

Note: OS X and Windows support the Puppet agent software only, via the puppet-agent package. OS X puppet-agent packages are organized by Puppet Collection; for more information, see the OS X installation instructions.

Yum-based systems

To enable the Puppet Collection 1 repository, first choose the package based on your operating system and version. The packages are located in the yum.puppetlabs.com repository and named using the following convention:

puppetlabs-release-<COLLECTION>-<OS ABBREVIATION>-<OS VERSION>.noarch.rpm

For instance, the package for Puppet Collection 1 on Red Hat Enterprise Linux 7 (RHEL 7) is puppetlabs-release-pc1-el-7.noarch.rpm.

Next, use the rpm tool as root with the upgrade (-U) flag, and optionally the verbose (-v), and hash (-h) flags:

sudo rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

The rpm tool outputs its progress:

Retrieving https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
1:puppetlabs-release-pc1-0.9.2-1.el################################# [100%]

Enterprise Linux 7

sudo rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

Enterprise Linux 6

sudo rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-6.noarch.rpm

Enterprise Linux 5

wget https://yum.puppetlabs.com/puppetlabs-release-pc1-el-5.noarch.rpm
sudo rpm -Uvh puppetlabs-release-pc1-el-5.noarch.rpm

Note: For recent versions of Puppet, we no longer ship Puppet master components for RHEL 5. However, we continue to ship new versions of the puppet-agent package for RHEL 5 agents.

Fedora 23

sudo rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-fedora-23.noarch.rpm

Note: We ship only puppet-agent packages for Fedora 23.

Apt-based systems

To enable the Puppet Collection 1 repository, first choose the package based on your operating system and version. The packages are located in the apt.puppetlabs.com repository and named using the following convention:

puppetlabs-release-<COLLECTION>-<VERSION CODE NAME>.deb

For instance, the release package for Puppet Collection 1 on Debian 7 “Wheezy” is puppetlabs-release-pc1-wheezy.deb. For Ubuntu releases, the code name is the adjective, not the animal.

Next, download the release package and install it as root using the dpkg tool and the install flag (-i):

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-wheezy.deb
sudo dpkg -i puppetlabs-release-pc1-wheezy.deb

Finally, run apt-get update after installing the release package to update the apt package lists.

Ubuntu 16.04 Xenial Xerus

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-xenial.deb
sudo dpkg -i puppetlabs-release-pc1-xenial.deb
sudo apt update

Ubuntu 14.04 Trusty Tahr

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-trusty.deb
sudo dpkg -i puppetlabs-release-pc1-trusty.deb
sudo apt-get update

Ubuntu 12.04 Precise Pangolin

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-precise.deb
sudo dpkg -i puppetlabs-release-pc1-precise.deb
sudo apt-get update

Debian 9 Stretch

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-stretch.deb
sudo dpkg -i puppetlabs-release-pc1-stretch.deb
sudo apt-get update

Debian 8 Jessie

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-jessie.deb
sudo dpkg -i puppetlabs-release-pc1-jessie.deb
sudo apt-get update

Debian 7 Wheezy

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-wheezy.deb
sudo dpkg -i puppetlabs-release-pc1-wheezy.deb
sudo apt-get update

OS X systems

While the puppet-agent package is the only component of a Puppet Collection available on OS X, you can still use Puppet Collections to ensure the version of package-agent you install is compatible with the Puppet Collection powering your infrastructure.

To download puppet-agent for Puppet Collection 1:

Verifying Puppet packages

We sign most of our packages, Ruby gems, and release tarballs with GNU Privacy Guard (GPG). This helps prove that the packages originate from Puppet and have not been compromised.

Security-conscious users can use GPG to verify signatures on our packages.

Automatic verification

Certain operating system and installation methods automatically verify our package signatures.

If you install Puppet packages via our Yum and Apt repositories, the Puppet Collection release package that enables the repository also installs our release signing key. The Yum and Apt tools automatically verify the integrity of our packages as you install them.
Our Microsoft Installer (MSI) packages for Windows are signed with a different key, and the Windows installer automatically verifies the signature before installing the package.

In these cases, you don’t need to do anything to verify the package signature.

Manual verification

If you’re using Puppet source tarballs or Ruby gems, or installing RPM packages without Yum, you can manually verify the signatures.

Import the public key

Before you can verify signatures, you must import the Puppet public key and verify its fingerprint. This key is certified by several Puppet developers and should be available from the public keyservers.

To import the public key, run:

gpg --keyserver pgp.mit.edu --recv-key 7F438280EF8D349F

The gpg tool then requests and imports the key:

	gpg: requesting key EF8D349F from hkp server pgp.mit.edu
	gpg: /home/username/.gnupg/trustdb.gpg: trustdb created
	gpg: key EF8D349F: public key "Puppet, Inc. Release Key (Puppet, Inc. Release Key) <[email protected]>" imported
	gpg: no ultimately trusted keys found
	gpg: Total number processed: 1
	gpg:               imported: 1  (RSA: 1)

The key is also available via HTTP.

Note: If this is your first time running the gpg tool, it might fail to import the key after creating its configuration file and keyring. This is normal, and you can run the command a second time to import the key into your newly created keyring.

Verify the fingerprint

The fingerprint of the Puppet release signing key is 6F6B 1550 9CF8 E59E 6E46 9F32 7F43 8280 EF8D 349F.

To check the key’s fingerprint, run the following:

gpg --list-key --fingerprint 7F438280EF8D349F

Then, ensure the fingerprint listed in the output matches the above value:

	pub   4096R/EF8D349F 2016-08-18 [expires: 2021-08-17]
				Key fingerprint = 6F6B 1550 9CF8 E59E 6E46  9F32 7F43 8280 EF8D 349F
	uid                  Puppet, Inc. Release Key (Puppet, Inc. Release Key) <[email protected]>
	sub   4096R/656674AE 2016-08-18 [expires: 2021-08-17]

Verify a source tarball or gem

To verify a source tarball or Ruby gem, you must download both it and its corresponding .asc file. These files are available from https://downloads.puppetlabs.com/puppet/.

Next, verify the tarball or gem by running the following, replacing <VERSION> with the Puppet version number, and <FILE TYPE> with tar.gz for a tarball or gem for a Ruby gem:

gpg --verify puppet-<VERSION>.<FILE TYPE>.asc puppet-<VERSION>.<FILE TYPE>

The output should confirm that the signature matches:

gpg: Signature made Mon 19 Sep 2016 04:58:29 PM UTC using RSA key ID EF8D349F
gpg: Good signature from "Puppet, Inc. Release Key (Puppet, Inc. Release Key) <[email protected]>"

If you have not taken the necessary steps to build a trust path, through the web of trust, to one of the signatures on the release key, gpg produces a warning similar to the following when you verify the signature:

Could not find a valid trust path to the key.
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6F6B 1550 9CF8 E59E 6E46  9F32 7F43 8280 EF8D 349F

This is normal if you do not have a trust path to the key. If you’ve verified the fingerprint of the key as described above, GPG has verified the archive’s integrity; the warning only means that GPG can’t automatically prove the key’s ownership.

Verify an RPM package

Puppet RPM packages include an embedded signature. To verify it, you must import the Puppet public key to rpm, then use rpm to check the signature.

First, retrieve the Puppet public key and place it in a file on your node.

Next, run the following, replacing <PUBLIC KEY FILE> with the path to the file containing the Puppet public key:

sudo rpm --import PUBKEY <PUBLIC KEY FILE>

The rpm tool won’t output anything if successful.

Then to verify an RPM you’ve downloaded, run the rpm tool with the checksig flag (-K):

sudo rpm -vK <RPM FILE NAME>

This verifies the embedded signature, as signified by the OK results in the rpm output:

puppet-agent-1.5.1-1.el6.x86_64.rpm:
    Header V4 RSA/SHA512 Signature, key ID ef8d349f: OK
    Header SHA1 digest: OK (95b492a1fff452d029aaeb59598f1c78dbfee0c5)
    V4 RSA/SHA512 Signature, key ID ef8d349f: OK
    MD5 digest: OK (4878909ccdd0af24fa9909790dd63a12)

If you don’t import the Puppet public key, you can still verify the package’s integrity using rpm -vK. However, you won’t be able to validate the package’s origin:

puppet-agent-1.5.1-1.el6.x86_64.rpm:
    Header V4 RSA/SHA512 Signature, key ID ef8d349f: NOKEY
    Header SHA1 digest: OK (95b492a1fff452d029aaeb59598f1c78dbfee0c5)
    V4 RSA/SHA512 Signature, key ID ef8d349f: NOKEY
    MD5 digest: OK (4878909ccdd0af24fa9909790dd63a12)

Verify an OS X `puppet-agent` package

Puppet signs puppet-agent packages for OS X with a developer ID and certificate. To verify the signature, download and mount the puppet-agent disk image, then use the pkgutil tool with the --check-signature flag:

pkgutil --check-signature /Volumes/puppet-agent-<AGENT-VERSION>-1.osx10.10/puppet-agent-<AGENT-VERSION>-1-installer.pkg

The tool confirms the signature and outputs fingerprints for each certificate in the chain:

Package "puppet-agent-<AGENT-VERSION>-1-installer.pkg":
   Status: signed by a certificate trusted by Mac OS X
   Certificate Chain:
    1. Developer ID Installer: PUPPET LABS, INC. (VKGLGN2B6Y)
       SHA1 fingerprint: AF 91 BF B7 7E CF 87 9F A8 0A 06 C3 03 5A B4 C7 11 34 0A 6F
       -----------------------------------------------------------------------------
    2. Developer ID Certification Authority
       SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
       -----------------------------------------------------------------------------
    3. Apple Root CA
       SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

You can also confirm the certificate when installing the package by clicking the lock icon in the top-right corner of the installer:

Locate and click the lock icon in the OS X package installer window's top-right corner.

This displays details about the puppet-agent package’s certificate:

Details about the puppet-agent package's certificate displayed by the OS X package installer.

Nightly repositories

We provide automatically built nightly repositories for *nix operating systems containing packages of pre-release software not intended for production use. The nightly repositories require that you also have the standard Puppet Collection repository enabled.

Nightly?

Our automated systems create new “nightly” repositories for builds that pass our acceptance testing on the most popular platforms. This means we might not technically release builds nightly. However, they still represent bleeding-edge Puppet builds that are not intended for production use.

Nightly repository contents

Each nightly repo contains a single product. We make nightly repositories for Puppet Server, Puppet Agent (including its related tools), and PuppetDB.

Latest vs. specific commit

There are two kinds of nightly repository for each product:

The “-latest” repository stays around forever and always contains the latest build. We publish new packages to this repository every day or two, and are good for persistent canary systems.
The other repositories are all named after a specific git commit. They contain a single build, so you can reliably install the same version on many systems. These repositories are useful when testing a specific build, such to help Puppet test an impending release announced on the puppet-users mailing list.

We delete single-commit repositories a week or two after we create them, so if you want to keep the packages available, import them into your local repository.

Enabling nightly repositories on Yum-based systems

Enable the main Puppet Collection repository, as described above.
In a web browser, go to https://nightlies.puppetlabs.com/. Choose the repository you want; this will be either <PRODUCT>-latest, or <PRODUCT>/<COMMIT>.
Click through to your repository’s repo_configs/rpm directory, and identify the .repo file that applies to your operating system. This looks like pl-puppet-agent-<COMMIT>-el-7-x86_64.repo.

Download the .repo file into the system’s /etc/yum.repos.d/ directory. For example, to install the RHEL 7 puppet-agent nightly repository for commit 732e883, run:

cd /etc/yum.repos.d
sudo wget https://nightlies.puppetlabs.com/puppet-agent/732e883733fe5e5989afe330e3c5cea00b678d1e/repo_configs/rpm/pl-puppet-agent-732e883733fe5e5989afe330e3c5cea00b678d1e-el-7-x86_64.repo

Upgrade or install the product.

Enabling nightly repositories on Apt-based systems

Enable the main Puppet Collection repository, as described above.
In a web browser, go to https://nightlies.puppetlabs.com/. Choose the repository you want; this will be either <PRODUCT>-latest, or <PRODUCT>/<COMMIT>.
Click through to your repository’s repo_configs/deb directory, and identify the .list file that applies to your operating system. This looks like pl-puppet-agent-<COMMIT>-xenial.list.
Download the .list file into the system’s /etc/apt/sources.list.d/ directory. For example, to install the Ubuntu 16.04 (Xenial) puppet-agent nightly repository for commit 732e883, run:
```
cd /etc/apt/sources.list.d
sudo wget https://nightlies.puppetlabs.com/puppet-agent/732e883733fe5e5989afe330e3c5cea00b678d1e/repo_configs/deb/pl-puppet-agent-732e883733fe5e5989afe330e3c5cea00b678d1e-xenial.list
```
Nightly packages are signed, but with a different key than official releases.
Run sudo apt-get update.
Upgrade or install the product.

Puppet 4.10 reference manual