PE known issues
Sections
These are the known issues in PE 2019.8.
Installation and upgrade known issues
These are the known issues for installation and upgrade in this release.
Expired GPG key causing install failures
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.
- 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): yes
Copied!
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
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>
- 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 entrypuppet_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.
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
c_rehash
binary
non-executable:chmod -x /opt/puppetlabs/puppet/bin/c_rehash
Copied!
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.
- 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>.conf
Copied! - Restart
pe-puppetserver
:systemctl restart pe-puppetserver
Copied!
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.