The GPG key bundled with PE versions prior to 2019.8.4 expired on 17 August 2021. If you’re installing version 2019.8.9 or earlier of PE on Debian, Ubuntu, or SUSE Linux Enterprise Server (SLES) nodes, the expired key might cause a failure when PE packages are being added to the system.

To fix the issue, do one of the following:

On Debian or Ubuntu, do the workaround described in Expired GPG Key causes node installation to fail.

On SLES, on the signature verification failure message, select yes when asked if you want to continue with the installation. Here is an example of the message:

Signature verification failed for file 'repomd.xml' from repository 'puppet-enterprise'.

    Note: Signing data enables the recipient to verify that no modifications occurred after the data
    were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
    and in extreme cases even to a system compromise.

    Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the
    whole repo.

    Warning: This file was modified after it has been signed. This may have been a malicious change,
    so it might not be trustworthy anymore! You should not continue unless you know it's safe.

Signature verification failed for file 'repomd.xml' from repository 'puppet-enterprise'. Continue? [yes/no] (no): yesCopied!

Initial agent run after upgrade can fail with many environments

In installations with many environments, where file sync can take several minutes, the orchestration service fails to reload during the first post-upgrade Puppet run. As a workaround, re-run the Puppet agent until the orchestration service loads properly. To prevent encountering this error, you can clean up unused environments before upgrading, and wait several minutes after the installer completes to run the agent.

Converting legacy compilers fails with an external certificate authority

If you use an external certificate authority (CA), the

puppet infrastructure
                    run convert_legacy_compiler

command fails with an error during the certificate-signing step.

Agent_cert_regen: ERROR: Failed to regenerate agent certificate on node <compiler-node.domain.com>
Agent_cert_regen: bolt/run-failure:Plan aborted: run_task 'enterprise_tasks::sign' failed on 1 target
Agent_cert_regen: puppetlabs.sign/sign-cert-failed Could not sign request for host with certname <compiler-node.domain.com> using caserver <master-host.domain.com>

To work around this issue when it appears:

Log on to the CA server and manually sign certificates for the compiler.
On the compiler, run Puppet: puppet agent -t
Unpin the compiler from PE Master group, either from the console, or from the CLI using the command: /opt/puppetlabs/bin/puppet resource pe_node_group "PE Master" unpinned="<COMPILER_FQDN>"
On your primary server, in the pe.conf file, remove the entry puppet_enterprise::profile::database::private_temp_puppetdb_host
If you have an external PE-PostgreSQL node, run Puppet on that node: puppet agent -t
Run Puppet on your primary server: puppet agent -t
Run Puppet on all compilers: puppet agent -t

Converted compilers can slow PuppetDB in multi-region installations

In configurations that rely on high-latency connections between your primary servers and compilers – for example, in multi-region installations – converted compilers running the PuppetDB service might experience significant slowdowns. If your primary server and compilers are distributed among multiple data centers connected by high-latency links or congested network segments, reach out to Support for guidance before converting legacy compilers.

Ruby gem installation failures

In 2019.8.7, installing ruby gems with native extensions, like digest-crc, can result in failures.

Disaster recovery known issues

These are the known issues for disaster recovery in this release.

An unreachable replica runs the primary server out of disk space

If a provisioned replica becomes unreachable, the associated primary server can quickly run out of disk space, causing a complete interruption to PE services. In larger installations, an outage can occur in under an hour. The disk usage issue is caused by the PE-PostgreSQL service on the primary server retaining change logs that the replica hasn't acknowledged.

To avoid an outage, resolve any replica issues immediately, or forget the replica: from your primary server, run

puppet infrastructure forget
                    <REPLICA NODE NAME>

FIPS known issues

These are the known issues with FIPS-enabled PE in this release.

`c_rehash` binary vulnerability

While CVE-2022-1292 and CVE-2022-2068 were resolved for non-FIPS installations in PE 2019.8.12, these vulnerabilities are still present for FIPS installations. To mitigate this vulnerability, use this command to make the c_rehash binary non-executable:

chmod -x /opt/puppetlabs/puppet/bin/c_rehashCopied!

Puppet Server FIPS installations don’t support Ruby’s OpenSSL module

FIPS-enabled PE installations don't support extensions or modules that use the standard Ruby Open SSL library, such as hiera-eyaml. As a workaround, you can use a non-FIPS-enabled primary server with FIPS-enabled agents, which limits the issue to situations where only the primary uses the Ruby library. This limitation does not apply to versions 1.1.0 and later of the splunk_hec module, which supports FIPS-enabled servers. The FIPS Mode section of the module's Forge page explains the limitations of running this module in a FIPS environment.

Configuration and maintenance known issues

These are the known issues for configuration and maintenance in this release.

`regenerate_agent_certificate` can't verify node type if client tools were installed through a `package` resource

When running the puppet infra run regenerate_agent_certificate command, the plan can't verify that a node isn't an infrastructure node if the pe-client-tools package was installed on the node through a package resource. To make the plan succeed, you must pass in: force=true

Restarting or running Puppet on infrastructure nodes can trigger an `illegal reflective access operation` warning

When restarting PE services or performing agent runs on infrastructure nodes, you might see the warning Illegal reflective access operation ... All illegal access operations will be denied in a future release in the command-line output or logs. These warnings are internal to PE service components, have no impact on their functionality, and can be safely disregarded.

Orchestration services known issues

These are the known issues for the orchestration services in this release.

Orchestrator doesn't properly periodically prune jobs

A calculation error introduced in 2019.8.10 causes job records to be stored beyond the job_prune_threshold limit. Restarting pe-orchestration-services triggers pruning.

Running plans during code deployment can result in failures

If a plan is running during a code deployment, things like compiling apply block statements or downloading and running tasks that are part of a plan might fail. This is because plans run on a combination of PE services, like orchestrator and puppetserver, and the code each service is acting on might get temporarily out of sync during a code deployment.

Console and console services known issues

These are the known issues for the console and console services in this release.

Gateway timeout errors in the console

In versions 2019.8.0 through 2019.8.4, using facts to filter nodes might produce either a "502 Bad Gateway" or "Gateway Timeout" error instead of the expected results. This was resolved in 2019.8.5.

Patching known issues

These are the known issues for patching in this release.

Patching fails with excluded YUM packages

In the patching task or plan, using yum_params to pass the --exclude flag in order to exclude certain packages can result in task or plan failure if the only packages requiring updates are excluded. As a workaround, use the versionlock command (which requires installing the yum-plugin-versionlock package) to lock the packages you want to exclude at their current version. Alternatively, you can fix a package at a particular version by specifying the version with a package resource for a manifest that applies to the nodes to be patched.

Code management known issues

These are the known issues for Code Manager, r10k, and file sync in this release.

Can't configure `full_deploy` parameter

Configuring module deployment scope by adding the full_deploy parameter to your Code Manager configuration in Hiera does not correctly modify the parameter's setting.

Until this issue is fixed, you'll need to create a separate config file to manage this parameter. To do this:

In the same directory as your code-manager.conf file, create a .conf file with the following contents:
```
code-manager: {
   full-deploy: true
}Copied!
```

Set the same permissions on this file as code-manager.conf:

chown pe-puppet:pe-puppet /etc/puppetlabs/puppetserver/conf.d/<FILENAME>.conf
chmod 640 /etc/puppetlabs/puppetserver/conf.d/<FILENAME>.confCopied!

Restart pe-puppetserver:

systemctl restart pe-puppetserverCopied!

Important: PE doesn't manage this configuration file. The file can persist through upgrades, so you'll need to remove it once the issue is resolved, and then follow the steps in Configuring module deployment scope to reconfigure the parameter.

Changing a file type in a control repo produces a checkout conflict error

Changing a file type in a control repository – for example, deleting a file and replacing it with a directory of the same name – generates the error JGitInternalException: Checkout conflict with files accompanied by a stack trace in the Puppet Server log. As a workaround, deploy the control repo with the original file deleted, and then deploy again with the replacement file or directory.

Enabling Code Manager and multithreading in Puppet Server deadlocks JRuby

Setting the new environment_timeout parameter to any non-zero value – including the unlimited default when Code Manager is enabled – interferes with multithreading in Puppet Server and can result in JRuby deadlocking after several hours.

Code Manager and r10k do not identify the default branch for module repositories

When you use Code Manager or r10k to deploy modules from a Git source, the default branch of the source repository is always assumed to be main. If the module repository uses a default branch that is not main, an error occurs. To work around this issue, specify the default branch with the ref: key in your Puppetfile.

Was this page helpful?

We’re sorry to hear that!
Please tell us why so we can help. Enter your feedback and email. This form is sent to the Puppet docs team. We ask for your email as we might contact you regarding your feedback. If you need help with the product itself, visit Puppet Support or ask in Puppet Community on Slack. Feedback:

Email Address:

To learn about how Puppet uses your personal information, visit our privacy policy.

Please enter your feedback and contact email

If you leave us your email, we may contact you regarding your feedback. For more information on how Puppet uses your personal information, see our privacy policy.

See an issue? Please file a JIRA ticket in our [DOCUMENTATION] project.

PE known issues

Sections

Installation and upgrade known issues

Expired GPG key causing install failures