What's new since PE 2021.7

Feature highlights

Experience the full value of Puppet Enterprise

If you have installed Puppet Enterprise, you can separately install and use Security Compliance Management (formerly Puppet Comply®) and Continuous Delivery, which are both now covered by your Puppet Enterprise license. Additionally, by purchasing the Puppet Enterprise Advanced license, you can unlock the following premium features:

• Security Compliance Enforcement (formerly CEM)
• Advanced Impact Analysis capabilities within Continuous Delivery

For more information about the Puppet Enterprise license, see Getting a license.

Launch Security Compliance Management and Continuous Delivery consoles from the PE console

Starting in PE 2023.7, if you've installed Security Compliance Management and Continuous Delivery, you can launch their respective consoles by clicking quick links in the PE console.

Identify operational issues affecting infrastructure nodes

The console now includes an Operational status page showing the result of the latest checks performed by the pe_status_check module. Issues requiring your attention are listed under the affected infrastructure nodes. For more information, see Identify operational issues affecting infrastructure nodes.

Important: If you previously installed the pe_status_check module from the Forge or specified a version in your Puppetfile, ensure that you remove the previously installed version. This allows the latest version bundled with PE to be asserted.

PE certificate authority supports auto-renewal of agent certificates

If your installation includes puppet-agent 8.2.0 or a later version, PE is preconfigured to allow the certificate authority service to generate new agent certificates ahead of certificate expiration dates. This default functionality helps prevent disruption associated with certificate expirations. Optionally, you can turn off auto-renewal of agent certificates and customize your PE certificate authority settings.

Default timeout limits for deploy jobs

Timeout limits forcibly stop deploy jobs that run too long. This feature is useful for stopping jobs that are stuck, without requiring you to manually monitor the progress of jobs.

CAUTION: The feature for forcibly stopping deploy jobs can result in incomplete Puppet runs, partial configuration changes, and other issues. When setting timeout limits, consider the job scope, typical runtime, and your infrastructure's capacity (such as concurrency limits).

The default timeout limit is 30 minutes per node. You can change the global default limit by modifying the default_deploy_node_timeout setting in your Orchestrator and pe-orchestration-services parameters.

View and edit scheduled plans in the console

You can now view and edit scheduled plan details in the console.

View and edit scheduled jobs in the console

You can now view and edit scheduled job details in the console.

Authenticate users in multiple LDAP domains

You can now connect multiple Lightweight Directory Access Protocol (LDAP) domains to PE. This new feature brings many changes to the role-based access control (RBAC) API and LDAP-related pages in the PE console.

In the PE console, view and manage all of your LDAP external directory service connections on the LDAP tab of the Access control page.

The Test connection button is removed. When you Connect to external directory services, the Connect button now automatically tests the connection before saving the configuration.

Use the Certificate chain field (or cert_chain API key) to define unique certificate chains across servers.

The following new endpoints replace deprecated or removed endpoints. For a list of deprecated and removed endpoints, refer to the Deprecations and removals section of these release notes.

• POST /command/groups/create
• POST /command/ldap/create
• POST /command/ldap/update
• POST /command/ldap/test
• POST /command/ldap/delete
• GET /ldap
• GET /ldap/<id>

Responses from these endpoints now include the identity_provider_id:

• GET /v1/groups
• GET /v1/groups/<sid>
• GET /v1/users
• GET /v1/users/<sid>
• GET /v2/users

Default timeout limits for tasks and plans

Timeout limits forcibly stop tasks and plans that run too long. This feature is useful for stopping tasks and plans that are stuck without requiring you to manually monitor task or plan progress.

CAUTION: The feature for forcibly stopping tasks and plans can result in incomplete Puppet runs, partial configuration changes, and other issues. When setting timeout limits, consider the task or plan scope, typical runtime, and your infrastructure's capacity (such as concurrency limits).

The default timeout limits are 40 minutes for tasks (per node) and 60 minutes for plans (for the entire plan run). You can change the global default limits by modifying the default_task_node_timeout and default_plan_timeout settings in your Orchestrator and pe-orchestration-services parameters.

Alternatively, you can set timeout limits for an individual task or plan when Running tasks from the console, Running plans from the console, or running tasks and plans with the Orchestrator API.

You can use the timeout option with the following Orchestrator API endpoints:

• POST /command/task
• POST /command/plan_run
• POST /command/environment_plan_run
• POST /scheduled_jobs/environment_jobs

Unique status for queued jobs

To better differentiate queued-but-unstarted jobs from jobs that are running, a new pending state was introduced for queued jobs.

The pending state is visible in the console and in responses from GET /plan_jobs and GET /plan_jobs/<job-id>.

View and edit scheduled tasks in the console

You can now view and edit scheduled task details in the console.

Enhancements

Puppet Server automatically regenerates CRLs that are nearing expiry

Starting in PE 2023.6, Puppet Server performs daily checks on Certificate Revocation Lists (CRLs) and if a CRL is due to expire within 30 days, Puppet Server automatically regenerates it. This enhancement significantly reduces the risk of failed Puppet runs and service outages caused by expired CRLs.

Improved plan concurrency with new pe-plan-runner service

PE 2023.6 introduces the pe-plan-runner service, which improves scalability and performance compared to the existing orchestrator service. Disabled by default, the new service runs on the primary server, allowing concurrent execution of up to 100 plans, with potential for further scaling based on available primary server memory.

With pe-plan-runner enabled, you can continue scheduling and running plans using existing PE console workflows or Orchestrator APIs, and any previously scheduled plans are automatically executed by pe-plan-runner.

To start running plans over pe-plan-runner instead of the orchestrator service:

1. Click Node groups > PE Infrastructure > PE Orchestrator.
2. Select the Classes tab and locate the puppet_enterprise::profile::orchestrator class.
3. From the Parameter name dropdown, select plan_runner_active and enter true as the value.
4. Click Add to node group and commit your changes.

Tip: After enabling pe-plan-runner, monitor memory usage on the primary server, as poorly optimized plans may adversely affect performance.

Enhanced workflow for configuring and running task jobs in the console

The process of configuring and running task jobs has been divided into three clear steps in the Tasks section of the console. You can now configure the task job, use one of the three node-targeting methods, and review your setup before scheduling or running the task.

Include or exclude catalog resource edges in catalogs sent to PuppetDB

By default, catalogs submitted to PuppetDB include resource edges, providing data that is useful if you want to identify or analyze the relationships between catalog resources. Starting in PE 2023.6, you can modify the submit_catalog_edges parameter in the puppet_enterprise::profile::master::puppetdb class to exclude resource edges from catalogs. This setting is beneficial if you do not require resource edge data and want to reduce the amount of data stored by PuppetDB.

Specify ciphers to use for connections between PE console and LDAP servers

PE 2023.6 includes a new ldap_cipher_suites parameter in the puppet_enterprise::profile::console class. This parameter allows console users to specify an array of ciphers to use when establishing connections to configured LDAP servers. By default, the value is set to $puppet_enterprise::ssl_cipher_suites, which captures the array of ciphers specified by the puppet_enterprise::ssl_cipher_suites parameter.

Upgraded logback

To address CVE-2023-6378, logback is upgraded to version 1.3.14. If you want to use a customized setting for the logappender variable, see Upgrade cautions for information about avoiding disruptions in logging.

By default, the puppet_enterprise::profile::agent class manages some puppet.conf settings

Starting in PE 2023.6, the manage_puppet_conf parameter in puppet_enterprise::profile::agent class is set to true by default, meaning that all settings configured in the puppet_enterprise::profile::agent class are applied to the puppet.conf file.

If you do not want to use the puppet_enterprise::profile::agent class to manage the puppet.conf file, ensure you set manage_puppet_conf to false.

Enhanced options for creating fact-based node group rules

When creating fact-based node group rules, you can now include or exclude nodes based on whether a fact, expressed as an array of values, contains a specific value.

For information about creating fact-based rules in the console, see Writing node group rules.

For information on using rules when forming requests to the node classifier API, see Rule condition grammar.

Updated common PQL queries in console

When configuring Puppet runs in the console, you can choose from a range of common Puppet Query Language (PQL) queries to target nodes for jobs and tasks. With the removal of legacy facts in Puppet 8, common queries that used legacy facts have been updated to use equivalent structured facts.

Puppet 8 is installed with PE 2023.4

When you install PE 2023.4, an upgraded version of Puppet is installed automatically. Puppet 8 includes several changes that can enhance PE performance capability. For example:

• Starting in Puppet 8, legacy facts are replaced by structured facts.
• Strict validation is enabled by default.
• Ruby is upgraded to version 3.2.

Important: For information about these and other key changes in Puppet 8 that might affect your PE upgrade, see Puppet upgrade in 2023.4 and later.

r10k upgrade

PE includes r10k version 4.0, which has been updated to enhance scalability, reduce dependency risks, and align with Git security best practices.

Important: To review information about changes introduced in r10k 4.0 that might affect your PE upgrade, see Upgrade cautions.

Task concurrency limit now pertains to individual tasks or plans

The task_concurrency setting defines the maximum number of task or plan actions that can be executed simultaneously.

Previously, the concurrency limit pertained globally to actions on any nodes in your installation that were targeted by any current task or plan jobs. Now, the concurrency limit is specific to the nodes targeted by individual task or plan jobs. This improvement significantly reduces latency when multiple task or plan jobs are run simultaneously.

For example, in a company that uses PE, four users each run a task job targeting 10 nodes. The four task jobs are similar in scope and the users initiate their jobs simultaneously. The task_concurrency parameter is set to 10. Previously, with a concurrency limit of 10, task actions would begin executing for one of the jobs and the three remaining jobs would be queued. Now in this scenario, the concurrency limit pertains to each job, so all 40 task actions are executed concurrently. Because the four task jobs are similar in scope, they can be expected to be completed in roughly the same timeframe.

The global default concurrency limit is 1000 actions per job. You can change the global default limit by modifying the task_concurrency parameter value in your Orchestrator and pe-orchestration-services parameters.

Enhanced workflow for configuring and running jobs in the console

The process of configuring and running jobs has been divided into three clear steps in the Jobs section of the console. You can now configure the job, use one of the three node-targeting methods, and review your setup before scheduling or running the job.

Classifier service automatically replaces legacy facts in node group rules

With the removal of legacy facts in Puppet 8, the PE classifier service now analyzes your node group rules and automatically replaces legacy facts with corresponding structured facts. If any of your node group rules contain legacy facts that cannot be directly mapped to structured facts, the classifier service generates warning messages in the logs, prompting you to manually remove or replace the unmappable legacy facts. For more information about the removal of legacy facts in Puppet 8, see Puppet upgrade in 2023.4 and later.

PE installer flags unmappable legacy facts in node group rules

Because legacy facts are removed in Puppet 8, the PE installer now examines your existing node group rules and if any unmappable legacy facts are found, the installation process stops with a warning. To proceed with installation, you can replace or remove unmappable legacy facts and re-run the installer. For more information about the removal of legacy facts in Puppet 8, see Puppet upgrade in 2023.4 and later

Session timeout warning in the PE console

Previously, whenever a console session timed out due to inactivity, users were logged out automatically and returned to the console login screen without warning. Now, whenever a session is about to expire due to inactivity, the console displays a warning modal to inform users they'll be logged out soon. The warning modal includes an option to continue the session.

You can configure the behavior of the timeout modal using the following console service parameters:

• puppet_enterprise::profile::console::session_timeout_polling_frequency_seconds
• puppet_enterprise::profile::console::session_timeout_warning_seconds

Orchestrator HTTP-client limits can be configured to match infrastructure requirements

You can now specify HTTP-client connection limit parameters in the puppet_enterprise::profile::orchestrator class. You can set connection limits for authenticated and unauthenticated clients by specifying an integer value for the following parameters:

• max_connections_per_route_authenticated
• max_connections_total_authenticated
• max_connections_per_route_unauthenticated
• max_connections_total_unauthenticated

Orchestrator socket timeout is configurable

By default, whenever no data is available on the socket, the orchestrator waits for a maximum of 120,000 milliseconds before closing the HTTP connection. Now you can specify the maximum time before socket timeout by changing the default value of the socket_timeout parameter in the puppet_enterprise::profile::orchestrator class.

Enhanced logging of certificate authority actions

Previously, agent certificate requests were authorized using the ”pp_cli_auth”: “true” certificate extension. Now, when RBAC tokens are available, token-based authentication is used. This new default authorization method allows better auditability because user IDs that trigger certificate authority actions are reported to the audit log. If you want to configure the certificate authority service settings so that RBAC tokens are always required for authorization of agent certificate requests, you can set the value of allow_puppetlabs_certificate_authentication to false in your certificate_authority service parameters.

More efficient agent run reporting to conserve storage in PuppetDB

Previously, agent run reports submitted to PuppetDB contained significant amounts of data about unchanged managed resources. Now by default, to conserve storage space in PuppetDB, agent run reports only include data relating to changes enforced by the Puppet run. Data about the desired state of each managed resource is still available in agent catalogs. To revert to the previous behavior for agent run reporting, you can modify the puppet_enterprise::profile::agent::exclude_unchanged_resources parameter.

Improvements to error logging for the puppet backup command

Previously, error messages returned by the puppet backup command were generic in many cases. Now, descriptive error messages are displayed both in the terminal and in the log file, and you can use a --debug flag with puppet backup to extend error logging to all underlying Puppet commands.

Optimized translation of classifier rules in PuppetDB queries

Classifier rule translation has been optimized to produce better queries to PuppetDB when regular expressions are used in fact matching.

Restriction: This enhancement does not impact trusted facts, so suboptimal queries can still be produced when regular expressions are used against trusted facts.

Java 17 upgrade

This version upgrades Java from version 11 to 17 and changes the default garbage collector from Parallel to G1.

Thoroughly test PE 2023.0 in a non-production environment before upgrading if you customized PE Java services or you use plug-ins that include Java code.

Stop in-progress plans in the console

When Running plans in PE, you can click Stop plan on the plan's run details page to stop the plan. In this way, you can prevent new tasks from starting and allow in-progress tasks to finish. To forcibly stop in-progress tasks from a stopped plan, follow the instructions in Stop a task in progress.

Forcibly stop in-progress tasks in the console

To Stop a task in progress, you can now both stop and forcibly stop in-progress tasks from the console. Previously, you had to use the Orchestrator API to forcibly stop tasks.

CAUTION: A forcible stop is the last resort when a task is stuck. This type of stop can result in incomplete Puppet runs, partial configuration changes, and other issues.

Provisioning replicas requires matching agent versions

When provisioning a replica, the target node's agent version must match the primary server's agent version. If the versions don't match, the puppet infra provision replica command fails before initializing the provisioning process. Previously, the agent version wasn't checked, and mismatched agent versions caused provisioning to fail partway through.

Increased task_concurrency limit

The default value of the task_concurrency orchestrator parameter was increased from 250 to 1000.

recover_configuration command recreates nodes files

Previously, the puppet infrastructure recover_configuration command merged new values into the nodes files (at /etc/puppetlabs/enterprise/conf.d/nodes) instead of overwriting the files. This process caused problems if you deleted a value relevant to one or more nodes, because the deleted value would remain in these files and continue to be applied.

Now, the recover_configuration command fully rewrites the nodes files on each invocation. This process matches how the command handles changes to the user_data.conf file.

Notification when session expires due to inactivity

PE redirects users to the login page when a session expires due to inactivity. When this happens, the login page now includes a message that indicates why the user was logged out.

Improved performance when regenerating agent certificates for multiple agents

The puppet infrastructure run regenerate_agent_certificate action is now faster when you Regenerate agent certificates for multiple agents. You can also now use the agent_pdb_query parameter to use a PDB query to generate a list of agents for which you want to regenerate certificates.

This action now uses the Puppet Server CA API endpoints directly, rather than relying on the puppetserver ca CLI, as it did previously. This process is faster, but, if you encounter problems, you can revert to the previous behavior by including use_puppetserver_cli=true in the command.

Specify Code Manager worker cache cleanup interval

The deploy_pool_cleanup_interval specified how often workers pause to clean their on-disk caches. Learn more about this setting in Code Manager parameters.

CHACHA20 ciphers, compatible with non-FIPS PE installs

TLS_CHACHA20_POLY1305_SHA256 (TLSv1.3)

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (TLSv1.2)

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (TLSv1.2)

TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (TLSv1.2)

AES versions of two GCM ciphers, compatible with FIPS and non-FIPS installs

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (TLSv1.2)

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (TLSv1.2)

Removed restrictions

TLS_CHACHA20_POLY1305_SHA256 is no longer limited to Bolt server, ACE server, and NGINX.

ECDHE-ECDSA-CHACHA20-POLY1305 is no longer limited to NGINX.

ECDHE-RSA-CHACHA20-POLY1305 is no longer limited to NGINX.

Platform support

PE 2023.0 through 2023.7 added support for these platforms:

Deprecations and removals