Getting support

You can get commercial support for versions of Puppet Enterprise (PE) in the leading-edge release stream (also known as STS), long-term support (LTS), and overlap support (extended support for prior LTS streams until EOL). You can also get support from our user community.

Puppet Enterprise support life cycle

Puppet Enterprise (PE) release streams are considered short-term support (STS), long-term support (LTS), overlap support (extended support until EOL), and end of life (EOL).

Note: STS is the leading-edge release stream, also called the Puppet Enterprise (PE) release track.

For full information about release types, support phases and dates for each release, release frequency, and upgrade recommendations, go to the Puppet Enterprise lifecycle policy page.

If the latest release with the most up-to-date features is right for you, download or try the latest PE release, or download an older supported release from the Previous Releases page. We recommend following our Installing guide and understanding the System requirements before downloading the installation package.

Open source tools and libraries

PE uses open source tools and libraries. We use both externally maintained components, such as Ruby, PostgreSQL, and JVM, and projects we own and maintain, such as Facter, Puppet agent, Puppet Server, and PuppetDB.

Projects we own and maintain are "upstream" of our commercial releases. Our open source projects move faster and have shorter support life cycles than PE. We might discontinue updates to our open source platform components before their commercial EOL dates. We vet upstream security and feature releases and update supported versions according to customer demand and our Security policy.

Support portal

We provide responsive, dependable, quality support to resolve any issues regarding the installation, operation, and use of Puppet Enterprise (PE).

PE has two commercial support plans: Standard and Premium. Both allow you to report your support issues to our confidential customer support portal. When you purchase PE, you receive an account and login details for the portal, which includes access to our knowledge base.

Note: The term standard installation refers to a PE installation with up to 4,000 nodes. The Standard Support Plan is not limited to this installation type. In the support context, Standard refers to the support level, not the PE installation size.

Puppet metrics collector

The Puppet metrics collector can help troubleshoot performance issues with Puppet Enterprise (PE) components.

Puppet Professional Services and Support use and recommend the tool to help optimize PE installations.

The Puppet metrics collector is packaged in a module that is installed with PE. By default, the module is disabled. You can enable and disable metrics collection by setting Boolean values for these parameters:
  • puppet_enterprise::enable_metrics_collection (for Puppet services metrics)
  • puppet_enterprise::enable_system_metrics_collection (for system metrics)
For for information and instructions, refer to Puppet Enterprise metrics.
Important: If you have a version of the puppetlabs-puppet_metrics_collector module, from the Forge or other sources, specified in the code, you must remove this version before upgrading to allow the version bundled with PE to be asserted.

PE support script

When seeking support, you might be asked to run an information-gathering support script. This script collects a large amount of system information and Puppet Enterprise (PE) diagnostics, compresses the data, and prints the location of the zipped tarball when it finishes running.

The pe_support_script module, bundled with the installer, provides the script.

Running the support script

Run the support script on the command line of your primary server or any agent node running Red Hat Enterprise Linux, Ubuntu, or SUSE Linux Enterprise Server operating systems with the command: /opt/puppetlabs/bin/puppet enterprise support

PE version 2019.8.9 includes version 3 of the support script. Version 3 has more options that can be used to modify the support script behavior. As such, some options in version 3 are not available in combination with the --v1 option. This is because the --v1 option activates the legacy (version 1) support script. Options not compatible with version 1 are designated in the table below as Not compatible with the --v1 parameter.

These options can modify the support script output:
Option Description
--verbose Logs verbosely.
--debug Logs debug information.
--classifier Collects classification data.
--dir <DIRECTORY> Specifies where to save the support script's resulting tarball.
--ticket <NUMBER> Specifies a support ticket number for record-keeping purposes.
--encrypt Encrypts the support script's resulting tarball with GnuPG encryption.
Note: You must have GPG or GPG2 available in your PATH in order to encrypt the tarball.
--log_age Specifies how many days' worth of logs the support script collects. Valid values are positive integers or all to collect all logs, up to 1 GB per log. Default is 7 (seven days).
--v1 Activate version 1 of the support script. This option is not compatible with options designated as Not compatible with the --v1 parameter.
--v3 Activate version 3 of the support script. This is a default but can be overridden with --v1.
--list List diagnostics that may be enabled or disabled. Diagnostics labeled "opt-in" must be explicitly enabled. All others are enabled by default. Not compatible with the --v1 parameter.
--enable <LIST> A comma-separated list of diagnostic names to enable. Use the --list option to print available names. The --enable option must be used to activate diagnostics marked as "opt-in." Not compatible with the --v1 parameter.
--disable <LIST> A comma-separated list of diagnostic names to disable. Use the --list option to print available names. Not compatible with the --v1 parameter.
--only <LIST> A comma-separated list of diagnostic names to enable. All other diagnostics are disabled. Use the --list option to print available names. Not compatible with the --v1 parameter.
--upload Upload the output tarball to Puppet Support via SFTP. Requires the --ticket <NUMBER> option to be used. Not compatible with the --v1 parameter.
--upload_disable_host_key_check Disable SFTP host key checking. Go to Use SFTP to upload files to Puppet Support for a list of current host key values. Not compatible with the --v1 parameter.
--upload_user <USER> Specify a SFTP user to use when uploading. If not specified, a shared write-only account is used. Not compatible with the --v1 parameter.
--upload_key <FILE> Specify a SFTP key to use with --upload_user. Not compatible with the --v1 parameter.
These code examples show how to use options when running the support script:
# Collect diagnostics for just Puppet agent and Puppet Server /opt/puppetlabs/bin/puppet enterprise support --only puppet-agent,puppetserver # Enable collection of PE classification /opt/puppetlabs/bin/puppet enterprise support --enable pe.console.classifier-groups # Disable collection of system logs, upload result to Puppet Support via SFTP /opt/puppetlabs/bin/puppet enterprise support --disable system.logs --upload --ticket 12345

Descriptions of diagnostics you can select with the --enable, --disable, and --only flags are in the next section.

Information collected by the support script

This information is collected by the support script.

base-status
The base-status check collects basic diagnostics about the PE installation. This check is enabled and is not affected by the --disable or --only flags.
Specifically, the base-status check collects the support script version, the Puppet ticket number (if supplied), and the time the script ran.
system
The checks in the system scope gather diagnostics, logs, and configuration related to the operating system.
The system.config check collects:
  • A copy of /etc/hosts
  • A copy of /etc/nsswitch.conf
  • A copy of /etc/resolv.conf
  • Configuration for the APT, YUM, and dnf package managers
  • The operating system version
  • The umask in effect
  • The status of SELinux
  • A list of configured network interfaces
  • A list of configured firewall rules
  • A list of loaded firewall kernel modules
The system.logs check collects copies of the system log (syslog) and kernel log (dmesg).
The system.status check collects:
  • Values of variables set in the environment
  • A list of running processes
  • A list of enabled services
  • A list of systemd timers
  • The uptime of the system
  • A list of established network connections
  • NTP status
  • The IP address and hostname of the node running the script, according to DNS
  • Disk usage
  • RAM usage
puppet-agent
The checks in the puppet-agent scope gather diagnostics, logs, and configuration related to the Puppet agent services.
The puppet.config check collects:
  • Facter configuration files from /etc/puppetlabs/facter/facter.conf
  • Puppet configuration files from /etc/puppetlabs/puppet/device.conf, /etc/puppetlabs/puppet/hiera.yaml, and /etc/puppetlabs/puppet/puppet.conf
  • PXP agent configuration files from /etc/puppetlabs/pxp-agent/modules/ and /etc/puppetlabs/pxp-agent/pxp-agent.conf
The puppet-agent.logs check collects:
  • Puppet log files from /var/log/puppetlabs/puppet
  • JournalD logs for the puppet service and pxp-agent service
  • PXP agent log files from /var/log/puppetlabs/puppet
The puppet-agent.status check collects:
  • facter -p output and debug-level messages
  • A list of Ruby gems installed for use by Puppet
  • Ping output for the Puppet Server the agent is configured to use
  • A copy of the graphs/ directory and the classes.txt and last_run_summary.yaml files from the Puppet statedir
  • A listing of metadata (name, size, etc.) of files present in the /etc/puppetlabs, /var/log/puppetlabs, and /opt/puppetlabs directories.
  • A listing of Puppet and PE packages installed on the system along with verification output for each
puppetserver
The checks in the puppetserver scope gather diagnostics, logs, and configuration related to the Puppet Server service.
The puppetserver.config check collects these Puppet Server configuration files:
  • /etc/puppetlabs/code/hiera.yaml
  • /etc/puppetlabs/puppet/auth.conf
  • /etc/puppetlabs/puppet/autosign.conf
  • /etc/puppetlabs/puppet/classfier.yaml
  • /etc/puppetlabs/puppet/fileserver.conf
  • /etc/puppetlabs/puppet/hiera.yaml
  • /etc/puppetlabs/puppet/puppet.conf
  • /etc/puppetlabs/puppet/puppetdb.conf
  • /etc/puppetlabs/puppet/routes.yaml
  • /etc/puppetlabs/puppetserver/bootstrap.cfg
  • /etc/puppetlabs/puppetserver/code-manager-request-logging.xml
  • /etc/puppetlabs/puppetserver/conf.d/
  • /etc/puppetlabs/puppetserver/logback.xml
  • /etc/puppetlabs/puppetserver/request-logging.xml
  • /etc/puppetlabs/r10k/r10k.yaml
  • /opt/puppetlabs/server/data/code-manager/r10k.yaml
The puppetserver.logs check collects:
  • Puppet Server log files from /var/log/puppetlabs/puppetserver/
  • JournalD logs for the pe-puppetserver service
  • r10k log files from /var/log/puppetlabs/r10k/
The puppetserver.metrics check collects data stored in /opt/puppetlabs/puppet-metrics-collector/puppetserver
The puppetserver.status check collects:
  • A list of certificates issued by the Puppet CA
  • A list of Ruby gems installed for use by Puppet Server
  • Output from the status/v1/services API
  • Output from the puppet/v3/environment_modules API
  • Output from the analytics/v1/collections/snapshots API
  • Output from the puppet/v3/environments API
  • environment.conf and hiera.yaml files from each Puppet code environment
  • The disk space used by Code Manager cache, storage, client, and staging directories
  • The disk space used by the server's File Bucket
  • The output of r10k deploy display
puppetdb
The checks in the puppetdb scope gather diagnostics, logs, and configuration related to the PuppetDB service.
The puppetdb.config check collects these configuration files:
  • /etc/puppetlabs/puppetdb/bootstrap.cfg
  • /etc/puppetlabs/puppetdb/certificate-whitelist
  • /etc/puppetlabs/puppetdb/conf.d/
  • /etc/puppetlabs/puppetdb/logback.xml
  • /etc/puppetlabs/puppetdb/request-logging.xml
The puppetdb.logs check collects PuppetDB log files (/var/log/puppetlabs/puppetdb) and JournalD logs for the pe-puppetdb service.
The puppetdb.metrics check collects data stored in /opt/puppetlabs/puppet-metrics-collector/puppetdb.
The puppetdb.status check collects:
  • Output from the status/v1/services API
  • Output from the pdb/admin/v1/summary-stats API
  • A list of active certnames from the PQL query nodes[certname] {deactivated is null and expired is null}
pe
The checks in the pe scope gather diagnostics, logs, and configuration related to Puppet Enterprise services.
The pe.config check collects:
  • Installer configuration files:
    • /etc/puppetlabs/enterprise/conf.d/
    • /etc/puppetlabs/enterprise/hiera.yaml
    • /etc/puppetlabs/installer/answers.install
  • PE client tools configuration files:
    • /etc/puppetlabs/client-tools/orchestrator.conf
    • /etc/puppetlabs/client-tools/puppet-access.conf
    • /etc/puppetlabs/client-tools/puppet-code.conf
    • /etc/puppetlabs/client-tools/puppetdb.conf
    • /etc/puppetlabs/client-tools/services.conf
The pe.logs check collects:
  • PE installer log files from /var/log/puppetlabs/installer/
  • PE backup and restore log files from /var/log/puppetlabs/pe-backup-tools/ and /var/log/puppetlabs/puppet_infra_recover_config_cron.log
The pe.status check collects output from puppet infra status, current tuning settings from puppet infra tune, and recommended tuning settings from puppet infra tune.
The pe.file-sync check is disabled by default. When activated by the --enable option, this check collects:
  • Puppet manifests and other content from /etc/puppetlabs/code-staging/
  • Puppet manifests and other content stored in Git repos under /opt/puppetlabs/server/data/puppetserver/filesync
pe.console
The checks in the pe.console scope gather diagnostics, logs, and configuration related to the Puppet Enterprise console service.
The pe.console.config check collects these configuration files:
  • /etc/puppetlabs/console-services/bootstrap.cfg
  • /etc/puppetlabs/console-services/conf.d/
  • /etc/puppetlabs/console-services/logback.xml
  • /etc/puppetlabs/console-services/rbac-certificate-whitelist
  • /etc/puppetlabs/console-services/request-logging.xml
  • /etc/puppetlabs/nginx/conf.d/
  • /etc/puppetlabs/nginx/nginx.conf
The pe.console.logs check collects:
  • Console log files from /var/log/puppetlabs/console-services/ and /var/log/puppetlabs/nginx/
  • JournalD logs for the pe-puppetdb and pe-nginx services
The pe.console.status check collects:
  • Output from the /status/v1/services API
  • Directory service connection configuration, with passwords removed
The pe.console.classifier-groups check is disabled by default. When activated by the --enable option, this check collects all classification data provided by the /v1/groups API endpoint.
pe.orchestration
The checks in the pe.orchestration scope gather diagnostics, logs, and configuration related to the Puppet Enterprise orchestration services.
The pe.orchestration.config check collects:
  • ACE server configuration files from /etc/puppetlabs/puppet/ace-server/conf.d/
  • Bolt server configuration files from /etc/puppetlabs/puppet/bolt-server/conf.d/
  • Orchestration service configuration files:
    • /etc/puppetlabs/puppet/orchestration-services/bootstrap.cfg
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/analytics.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/auth.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/global.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/inventory.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/metrics.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/orchestrator.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/pcp-broker.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/web-routes.conf
    • /etc/puppetlabs/puppet/orchestration-services/conf.d/webserver.conf
    • /etc/puppetlabs/puppet/orchestration-services/logback.xml
    • /etc/puppetlabs/puppet/orchestration-services/request-logging.xml
The pe.orchestration.logs check collects:
  • ACE server log files from /var/log/puppetlabs/ace-server/
  • Bolt server log files from /var/log/puppetlabs/bolt-server/
  • Orchestrator log files from /var/log/puppetlabs/orchestration-services/
  • JournalD logs for the pe-ace-server service, pe-bolt-server service, and pe-orchestration-services service
The pe.orchestration.metrics check collects data stored in /opt/puppetlabs/puppet-metrics-collector/orchestrator/.
The pe.orchestration.status check collects output from the /status/v1/services API.
pe.postgres
The checks in the pe.postgres scope gather diagnostics, logs, and configuration related to the Puppet Enterprise PostgreSQL database.
The pe.postgres.config check collects these configuration files:
  • /opt/puppetlabs/server/data/postgresql/*/data/postgresql.conf
  • /opt/puppetlabs/server/data/postgresql/*/data/postmaster.opts
  • /opt/puppetlabs/server/data/postgresql/*/data/pg_ident.conf
  • /opt/puppetlabs/server/data/postgresql/*/data/pg_hba.conf
The pe.postgres.logs check collects JournalD logs for the pe-postgresql service and these PostgreSQL log files:
  • /var/log/puppetlabs/postgresql/*/
  • /opt/puppetlabs/server/data/postgresql/pg_upgrade_internal.log
  • /opt/puppetlabs/server/data/postgresql/pg_upgrade_server.log
  • /opt/puppetlabs/server/data/postgresql/pg_upgrade_utility.log
The pe.postgres.status check collects:
  • A list of setting values that the database is using while running
  • A list of currently established database connections and the queries being executed
  • A distribution of Puppet run start times for thundering herd detection
  • The status of any configured replication slots
  • The status of any active replication connections
  • The size of database directories on disk
  • The size of databases as reported by the database service
  • The size of tables and indices within databases

Community support

As a Puppet Enterprise (PE) customer, you are welcome to participate in our large and helpful open source community as well as report issues against the open source project.