These are the new features, enhancements, resolved issues, and deprecations in this version of PE.
PE 2019.8.4
This version updates the PostgreSQL version to address critical security vulnerabilities.
PE 2019.8.3
New features
Value report
A new Value report page in the Admin section of the console estimates the amount of time reclaimed by using PE automation. The report is configurable based on your environment. See Access the value report for more information.
Enhancements
Spend less time waiting on puppet infrastructure
commands
The puppet infrastructure
commands that use plans,
for example for upgrading, provisioning compilers, and regenerating certificates,
are now noticeably faster due to improvements in how target nodes are verified.
Provision a replica without manually pinning the target node
You're no longer required to manually pin the target replica node to the
PE Infrastructure Agent group before running puppet infrastructure provision replica
. This action —
which ensures that the correct catalog and PXP
settings are applied to the replica node in load balanced installations — is now
handled automatically by the command.
Configure environment caching
Using new environment timeout settings, you can improve Puppet Server performance by caching long-lived
environments and purging short-lived environments. For example, in the PE
Master node group, in the puppet_enterprise::master
class, set environment_timeout_mode
= from_last_used
and environment_timeout
= 30m
to clear short-lived environments 30 minutes
from when they were last used. By default, when you enable Code Manager, environment_timeout
is set to unlimited, which caches
all environments.
Configure the number of threads used to download modules
A new configuration parameter, download_pool_size
,
lets you specify the number of threads r10k uses to download modules. The default is
4
, which improves deploy performance in most
environments.
Configure PE-PostgreSQL autovacuum cost limit
The cost limit value used in PE-PostgreSQL autovacuum operations is now set at a more
reasonable default that scales with the number of CPUs and autovacuum workers
available. The setting is also now configurable using the
puppet_enterprise::profile::database::autovacuum_vacuum_cost_limit
parameter.
Previously, the setting was not configurable, and it used the PostgreSQL default, which could result in database tables and indexes growing continuously.
Rerun Puppet or tasks on failed nodes only
You can choose to rerun Puppet or a task only on the nodes that failed during the initial run by selecting Failed nodes on the Run again drop down.
Run plans only when required parameters are supplied
In the console, the option to commit a plan appears after you supply all required parameters. This is to prevent plan failures by accidentally running plans without required parameters.
Schedule plans in the console and API
You can use the console to schedule one time or recurring plans and view currently
scheduled plans. Additionally, you can use the schedule_plan
command for scheduling one-time plan runs using the
POST /command/schedule_plan endpoint.
Use sensitive parameters in plans
You can use the Sensitive
type for parameters in
plans. Parameters marked as Sensitive
aren't stored
in the orchestrator's database, aren't returned via API calls, and don't appear in
the orchestrator's log. Sensitive parameters are also not visible from the
console.
View more details about plans
The environment a plan was run from is now displayed in the console on the
Job details page. The environment is returned from the
/plan_jobs
endpoint using the new environment
key. See GET /plan_jobs for more information.
Additionally, the parameters supplied to tasks that are run as part of a plan are displayed in the console on the Plan details page. Sensitive parameters are masked and are never stored for a task run.
Differentiate between software and driver patch types for Windows
PE now ignores Driver
update types in Windows Updates by default and only
includes the Software
type, cutting down on
unnecessary patch updates. To change this default, configure the new windows_update_criteria
parameter in the pe_patch
class by removing or changing the Type
argument. See Patch management parameters for more information about the parameter.
Serve patching module files more efficiently
Certain pe_patch
module files are now delivered to
target nodes using methods that improve scalability and result in fewer file
metadata checks during Puppet runs.
Receive a notification when CA certs are about to expire
The console now notifies you if a CA certificate is expiring soon. The Certificates page in the sidebar displays a yellow ! badge if a certificate expires in less than 60 days, and a red ! badge if a certificate expires in less than 30 days. If there are certificates that need signing in addition to the certificates expiring, the number of certificates that need to be signed is displayed in the badge but the color stays the same.
View details about a particular code deployment
The Code Manager
/deploys/status
endpoint now includes the deployment
ID in the "deploys-status"
section for incomplete
deploys so you can correlate status output to a particular deployment
request.
Additionally, you can query the Code Manager
/deploys/status
endpoint with a deployment ID to see
details about a particular deployment. The response contains information about both
the Code Manager deploy and the sync to compilers for the
resulting commit.
Troubleshoot code deployments
File sync now uses the public git SHA recorded in the signature field of the .r10k-deploy.json
file instead of an internal SHA that
file sync created. Additionally, versioned directories used for lockless deploys now
use an underscore instead of a hyphen so that paths are valid environment names.
With these changes, you can now map versioned directories directly to SHAs in your
control repository.
When upgrading to 2019.3 or later with versioned deploys enabled, versioned
directories are recreated with underscores. You can safely remove orphaned
directories with hyphens located at
/opt/puppetlabs/server/data/puppetserver/filesync/client/versioned-dirs
.
Report on user activities
A new GET /v2/events API that tracks more user activities, like date, time, remote IP address, user ID, and action. You can use the console to generate a report of activities on the User details page.
Platform support
This version adds support for these platforms.
- Red Hat Enterprise Linux 8 aarch64
Deprecations and removals
Master removed from docs
Documentation for this release replaces the term master with primary server. This change is part of a company-wide effort to remove harmful terminology from our products.
For the immediate future, you’ll continue to encounter master
within the product, for example in parameters, commands, and
preconfigured node groups. Where documentation references these codified product
elements, we’ve left the term as-is.
As a result of this update, if you’ve bookmarked or linked to specific sections of a docs page that include master in the URL, you’ll need to update your link.
Whitelist and blacklist deprecated
In the interest of removing racially insensitive terminology, the terms
whitelist and blacklist are deprecated in favor of
allowlist and blocklist. Classes, parameters, and file
names that use these terms continue to work, but we recommend updating your
classification, Hiera data, and pe.conf
files as soon as possible in preparation for
their removal in a future release.
These are the classes, parameters, task parameters, and file names that are affected.
- puppet_enterprise::pg::cert_whitelist_entry
- puppet_enterprise::certs::puppetdb_whitelist
- puppet_enterprise::certs::whitelist_entry
- puppet_enterprise::master::code_manager::purge_whitelist
- puppet_enterprise::master::file_sync::whitelisted_certnames
- puppet_enterprise::orchestrator::ruby_service::whitelist
- puppet_enterprise::profile::ace_server::whitelist
- puppet_enterprise::profile::bolt_server::whitelist
- puppet_enterprise::profile::certificate_authority::client_whitelist
- puppet_enterprise::profile::console::cache::cache_whitelist
- puppet_enterprise::profile::console::whitelisted_certnames
- puppet_enterprise::profile::puppetdb::sync_whitelist
- puppet_enterprise::profile::puppetdb::whitelisted_certnames
- puppet_enterprise::puppetdb::cert_whitelist_path
- puppet_enterprise::puppetdb::database_ini::facts_blacklist
- puppet_enterprise::puppetdb::database_ini::facts_blacklist_type
- puppet_enterprise::puppetdb::jetty_ini::cert_whitelist_path
- /etc/puppetlabs/console-services/rbac-certificate-whitelist
Split-to-mono migration removed
The puppet infrastructure run migrate_split_to_mono
command has been removed. The command migrated a split installation to a standard
installation with the console and PuppetDB on the
primary server. Upgrades to PE 2019.2 and later
required migrating as a prerequisite to upgrade, so this command is no longer used.
If you're upgrading from an earlier version of PE
with a split installation, see Migrate from a split to a standard
installation in the documentation for your current version.
Resolved issues
Upgrade and puppet infrastructure
commands failed if your
primary server was not in the production
environment
Upgrades and puppet infrastructure
commands — including replica
upgrade and compiler provisioning, conversion, and upgrade — failed with a
Bolt::RunFailure if your primary server was not in the production
environment.
This release fixes both issues, and upgrades to this version are unaffected.
- Verify that you've specified your non-
production
infrastructure environment for these parameters:pe_install::install::classification::pe_node_group_environment
puppet_enterprise::master::recover_configuration::pe_environment
- Run
puppet infra recover_configuration --pe-environment <PRIMARY_ENVIRONMENT>
- When upgrading, run the installer with the
--pe_environment
flag:sudo ./puppet-enterprise-installer –- --pe_environment <PRIMARY_ENVIRONMENT>
Upgrade failed if a PostgreSQL repack was in progress
If a PostgreSQL repack operation was in progress when you attempted to upgrade PE, the upgrade could fail with the error cannot drop extension pg_repack because other objects depend on it.
Upgrade failed with an unenabled replica
PE upgrade failed if you had a provisioned, but not enabled, replica.
Compiler provisioning failed if a single compiler was unresponsive
Thepuppet infrastructure provision
compiler
command failed if any compiler in your pool failed a
pre-provisioning health check. puppet infrastructure
commands failed with an
external node classifier
With an external node classifier, puppet
infrastructure
commands, such as puppet
infrastructure compiler upgrade
and puppet
infrastructure provision compiler
, failed.
Automated Puppet runs could fail after running compiler or certificate regeneration commands
After provisioning compilers, converting compilers, or regenerating certificates with
puppet infrastructure
commands, automated Puppet runs could fail because the Puppet service hadn't restarted.
puppet infrastructure recover_configuration
misreported success
if specified environment didn't exist
If you specified an invalid environment when running puppet infrastructure
recover_configuration
, the system erroneously reported that the
environment's configuration was saved.
Runs, plans, and tasks failed after promoting a replica
After promoting a replica, infrastructure nodes couldn't connect to the newly
promoted primary server because the master_uris
value still pointed to the old primary server.
This release fixes the issue for newly-provisioned replicas, however if you have an
enabled replica, in both the PE Agent and PE
Infrastructure Agent node groups, in the puppet_enterprise::profile::agent
class, verify that the setting for
master_uris
matches the setting for server_list
. Both values must include both your primary
server and replica, for example ["PRIMARY.EXAMPLE.COM",
"REPLICA.EXAMPLE.COM"]
. Setting these values ensures that agents can
continue to communicate with the promoted replica in the event of a failover.
Replica commands could leave the Puppet service disabled
The reinitialize replica command as well as the provision replica command, which includes reinitializing, left the Puppet service disabled on the replica.
Skipping agent configuration when enabling a replica deleted settings for the PE Agent group
If you used the --skip-agent-config
flag with puppet infra enable replica
or puppet infra provision replica --enable
, any custom settings that you
specified for server_list
and pcp_broker_list
in the PE Agent node group were
deleted.
Provisioning a replica failed after regenerating the primary server certificate
If you previously regenerated the certificate for your primary server, provisioning a replica can failed due to permission issues with backed up directories.
Console was inaccessible with PE set to IPv6
If you specified IPv6, PE Java services still listened to the IPv4 localhost. This mismatch could prevent access to the console as Nginx proxied traffic to the wrong localhost.
Apply blocks failed to compile
Puppet Server might have failed to compile apply blocks for plans when there were more than eight variables, or when variables had names that conflict with key names for hashes or target settings in plans.
Yaml plans displayed all parameters as optional in the console
Yaml plans listed all parameters as having default values, regardless of whether there is a default value set in the code or not. This caused all parameters to display defaults in orchestrator APIs and show as optional in the console. Yaml plans no longer display all parameters as optional.
Running puppet query
produced a cryptic error
puppet query
with insufficient permissions
produced an error similar to
this:ERROR - &{<nil> } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
Primary server reported HTTP error after Qualys scan
When running a Qualys scan, the primary server no longer reports the error "HTTP Security Header Not Detected. Issue at Port 443".
Nodes CSV export failed with PQL query
The csv export functionality no longer produces an error when you specified nodes using a PQL query.
The wait_until_available
function didn’t work
with multiple transports
When a target included in the TargetSpec
argument to
the wait_until_available
plan function used the ACE
(remote) transport, the function failed immediately and wouldn't wait for any of the
targets in the TargetSpec
argument.
Unnecessary logs and failed connections in bolt-server
and ace-server
When requests were made with unsupported ciphers, bolt-server
and ace-server
would log
stack traces. Stack traces might lead to unusual growth in the logs for those
services when, for example, they are scanned by security scanning products. The Puma
Server library in those services has been updated to prevent emitting the stack
traces into the bolt-server.log
and ace-server.log
.
Patch task could misreport success for Windows nodes
When patching Windows nodes, running the pe_patch::patch_server
task always reported success,
even if there were problems installing one or more updates. With this fix, the task
now fails with an error message about which updates couldn't be installed
successfully.
The pe_patch
fact didn't consider classifier
environment group
When pe_patch
scheduled scripts that uploaded facts,
the facts didn't consider the current environment the node was compiling catalogs
in. If the local agent environment didn’t match the environment specified by the
server, the facts endpoint included tags for an unexpected environment.
Reenabling lockless code deploys could fail
Reenabling lockless code deploys could fail due to the persistence of the versioned code directory. With this release, any existing versioned code directory is deleted – and recreated – when you reenable lockless code deploys.
File-sync client repo grew after frequent commits
The file-sync client repo no longer grows rapidly when there are frequent commits to it. For example, when syncing the CA dir for DR, and many new certificates are signed are revoked quickly.
PE 2019.8.1
Enhancements
Value reporting
A new values API reports details about automated changes that PE makes to nodes, and provides an estimate of time freed by each type of change based on intelligent defaults or values you provide. You can also specify an average hourly salary and see an estimate of cost savings for all automated changes.
Console navigation and workflow improvements
- The Classification page was renamed Node groups.
- The setup page was renamed Admin.
- There is a new Inventory section in the sidebar, which contains the Nodes, Node groups, and Packages pages.
- The Inventory page was removed. To add nodes to inventory, click Add nodes in the upper right corner of the Nodes page.
- There is a new Access control page, which contains tabs for Users, User roles, User groups, and External directory.
- The Configuration tab was broken out into two tabs: Classes and Configuration data. The Classes tab is for declaring classes and setting parameters while the Configuration data tab is for setting parameters without declaring classes.
- There is a New in 2019.8 page in the sidenav, which lists console-related release notes. It will be updated after each z release and is visible for the first two weeks after a release.
Compiler conversion runs in parallel
When you convert all compilers at one time with puppet
infrastructure run convert_legacy_compiler all=true
, the process is now
noticeably faster due to streamlining in when Puppet
runs occur on target hosts.
Console displays enum and boolean plan parameter values in select menu
You can select plan parameters that are boolean or enum types from a drop down menu in the Value field.
Updates to metrics endpoints
Access to endpoints under /metrics are now controlled by
trapperkeeper-authorization and configured in the Puppet Serverauth.conf
file. The default rule allows remote access with a valid Puppet certificate.
Setting the v2 metrics endpoint to debug no longer displays debug messages from Jolokia. In order to see debugging messages, set a configuration value in addition to the usual logback changes.
Deprecations and removals
Application orchestration features in the Puppet language
- Keywords:
site
,application
,consumes
, andproduces
- Metaparameters:
export
andconsume
- Resource kinds:
application
,site
,capability_mapping
Puppet::Parser::EnvironmentCompiler
Puppet::Parser::Compiler::CatalogValidator::SiteValidator
Puppet::Parser::Compiler::CatalogValidator::EnvironmentRelationshipValidator
Puppet::Type#is_capability?
Puppet::Type#application?
- Environment catalog REST API
Resolved issues
Upgrading Windows agents using the puppet_agent module could restart non-Puppet services
If you're using a log aggregator, upgrading Windows agents using the puppet_agent module could cause non-Puppet services to restart.
Upgrading agents using the puppet_agent module could produce non-breaking errors
Upgrading agents from versions 6.14 or 6.15 using the puppet-agent module could
produce errors about an unavailable file resource or unknown HTTP resource. These
errors occurred only during the initial Puppet agent
run, when the agent was still using versions 6.14 or 6.15 with an updated primary
server. The error resolved after the puppet-agent
service restarted.
Pre-upgrade check produced inaccurate errors on standalone PE-PostgreSQL nodes
## Pre-Upgrade Checks Warning: Puppet agent is not running. Error: No configuration file found at /etc/puppetlabs/client-tools/services.conf. This file is installed automatically on Puppet Server nodes. Make sure you are running the command on a primary master, primary master replica, or compile master. Error: Try 'puppet infrastructure help status' for usage
The error occurred because the pre-upgrade check verified services running on the primary server which were not present on standalone PE-PostgreSQL nodes.
Upgrade could fail with custom structured facts
If you use custom facts that use structured facts, upgrade could fail with an error related to your custom fact, for example: undefined method '[]' for nil:NilClass (Puppet::Error).
Upgrade commands failed if PXP agents were configured to connect to load balancers
In installations with load balancers, the puppet infrastructure
upgrade
commands could fail if the PXP
agent on infrastructure nodes connected to load balancers instead of to the primary
server. The upgrade plan now verifies configuration and prompts you to fix any
issues before continuing with the upgrade.
Compiler upgrade could fail to upgrade Puppet Server
The puppet infrastructure upgrade compiler
command
could fail to upgrade Puppet Server depending on how the
catalog was built for performing the upgrade.
Converting all
legacy compilers failed in
disaster recovery installations
With disaster recovery enabled, the command to convert legacy compilers with the
option all=true
failed.
Converting legacy compilers failed with autosigning enabled
Running puppet infrastructure run convert_legacy_compiler
with autosigning enabled caused the conversion to fail during certificate
regeneration.
Converting legacy compilers could fail with DNS alternative names
If dns_alt_names
were specified in the [agent]
section of puppet.conf
, the puppet infrastructure run
convert_legacy_compiler
command failed because it didn't recognize the
alternative names. As a temporary workaround, we recommended moving dns_alt_names
to the [main]
section of puppet.conf
on the
compilers to be converted, however [agent]
is the
preferred section to specify this parameter. The compiler conversion command now
recognizes DNS alternative in either the [agent]
or
[main]
section of puppet.conf
.
Missing package dependencies for SUSE Linux Enterprise Server agent nodes
On agent nodes running SUSE Linux Enterprise Server 15, the libyaml-cpp
package and operating system packages
prefixed with libboost_
were no longer bundled with
Puppet agent, and also might not have been
included in the operating system.
Command to regenerate agent certificates didn't work with nodes behind a load balancer
In large and extra-large installations with load balancers, the command puppet infrastructure run regenerate_agent_certificate
failed because compilers didn't have the tasks needed to run the command, and agent
nodes don't communicate directly with the primary
server.
With lockless code deploy enabled, deleted branches could increase disk use
If you deleted a branch from your control repository with lockless deploys enabled, some artifacts could remain on disk and increase your disk use.
With lockless code deploy enabled, deploying with --wait
could produce an erroneous timeout
Deploying code from the command line or API with the --wait
flag produced a timeout error, even though the code deploy
completed.
The blackout_windows
parameter in pe_patch
class couldn't handle time zones with negative
UTC offset
If you used a negative value to offset the timezone when setting the blackout_windows
parameter for patching node groups, the
pe_patch
fact would return an error.
The pe_patch
fact wouldn't generate if there was
a parsing error
The pe_patch
fact couldn't be generated if there was
an error when parsing the latest cached catalog for the node. Additionally, if you
did not have puppetlabs-stdlib
installed, packages
that were fixed to a particular version in the node's catalog were not recognized by
pe_patch
.
Node search input didn't respond to Enter key
The node name search bar on the Nodes page in the console didn't respond to the Enter key to search for a node and you had to select Submit manually. You can now use Enter to search for nodes.
Console radiator bars had a width of zero
In the console, the colored bars in the radiator were broken and didn't show the correct layout. The radiator has been fixed.
PE 2019.8
New features
Patch management
You can now manage patches on *nix and Windows nodes in the Patch Management section of the console. After setting up patching node groups, you can view the patch status for your nodes, filter available patches by type and operating system, and run a pre-filled task to apply patches to selected nodes from the Patches page. For information on configuring patch management and applying patches, see Managing patches.
Lockless code deploys
Using Code Manager, you can now optionally deploy code to versioned code directories rather than the live code directory. This change enables Puppet Server to continue serving catalog requests even as you deploy code.
You can enable lockless code deploys by setting
puppet_enterprise::profile::master::versioned_deploys
to
true
. For more information about lockless code deploys, see
Deploy code without blocking requests.
Enhancements
Improvements to puppet infrastructure upgrade
commands
When you specify more than one compiler to upgrade, the puppet infrastructure
upgrade compiler
command now upgrades all compilers at the same time,
rather than sequentially. Additionally, with both the compiler and replica upgrade
commands, you can now specify the location of an authentication token other than the
default. For example: puppet infrastructure upgrade compiler
--token-file=<PATH_TO_TOKEN>
.
More secure code deploys
Permissions for the Puppet code directory are now managed by file sync directly, instead of relying on symlinks. This change improves security during code deployment.
Logging for puppet infrastructure
commands that
use the orchestrator
A new log file located at /var/log/puppetlabs/installer/orchestrator_info.log
contains run
details about puppet infrastructure
commands that
use the orchestrator, including the commands to provision and upgrade compilers,
convert legacy compilers, and regenerate agent and compiler
certificates.
Improved error handling for plans
Before running plans, the built-in check for node connectivity now provides more descriptive error messages, such as host key verification failures.
Unspecified default values for tasks and plans are supplied automatically
optional
in the
console. New scheduling options in the console
You can now specify scheduled tasks and Puppet jobs to run every two weeks or every four weeks.
Plan support for apply()
on pcp
transports
Plans now support using the apply_prep()
function and
blocks of Puppet code within calls to apply()
. The feature is only available on targets
connected to PE using the PCP transport and does not
work on nodes connected over SSH or WinRM.
Support for new options in the command/deploy endpoint
filetimeout
http_connect_timeout
http_keepalive_timeout
http_read_timeout
ordering
skip_tags
tags
use_cached_catalog
usecacheonfailure
Platform support
This version adds support for these platforms
- macOS 10.15
Deprecations and removals
Razor removed
Razor has been removed from PE in this release. If you want to continue using Razor, you can use the open source version of the tool.Support for bolt.yaml
settings in plans
removed
Settings from bolt.yaml
are no longer read from the
environment directory. The modulepath
setting is
only configurable from environment.conf
.
Platforms removed
Support for these platforms is removed in this release:
- Enterprise Linux 6
- Ubuntu 16.04
Resolved issues
Upgrade removed custom classification rules from PE Master node group
Custom rules that you used to classify compilers in the PE Master
node group were removed upon upgrade, or when you ran puppet
infrastructure configure
.
Upgrade failed with a Could not retrieve facts error
Could not retrieve facts ... undefined method `split' for nil:NilClass (Puppet::Error)from /opt/puppetlabs/installer/lib/ruby/gems/2.5.0/gems/facter-4.0.20/lib/custom_facts/util/loader.rb:125:in `load'
Upgrading a replica could temporarily lock the agent on the primary server
If you tried to run Puppet on your primary server
before the puppet infrastructure upgrade replica
command completed, you could encounter an error that a Puppet run was already in progress.
FIPS installs didn't fully support cert chain validation
In FIPS environments, RBAC could not connect to LDAP using a pem
or jks
file.
Command to remove old PostgreSQL versions failed on Ubuntu
When run on Ubuntu nodes, the puppet infrastructure run remove_old_postgresql_versions
command
failed, erroneously reporting that PostgreSQL wasn't
installed.
Enabling a replica could fail immediately after provisioning
When running puppet infrastructure provision replica --enable
, the
command could fail after the replica was provisioned but before it was enabled if
services on the replica were still starting up. The command now waits for services
to start and verifies that replication has completed before enabling the
replica.
Ubuntu 20.04 couldn't be installed with PE package management
Ubuntu 20.04 wasn't available for installation as a
pe_repo
class, even though it was a supported
agent platform.
Loading plan lists crashed console services
When plan run results were large, the console crashed due to high memory usage on the
Plan details page. An optional results query parameter
has been added to the GET/plan_jobs
endpoint. This
parameter keeps you from experiencing high memory usage in the console when loading
results for large plan runs.
Default value for tasks and plans dropped in middleware
When a task had a default value of false
or null
, the console metadata panel did not display the
default value.
Event inspector displayed wrong table types
Browsing the event inspector sometimes created inconsistencies in tables and errors in table links.