For release notes on versions of Puppet Server prior to Puppet Server 2.5, see docs.puppet.com.
Released September 8, 2016.
This is a feature and bug-fix release of Puppet Server. This release also adds an official Puppet Server package for SuSE Enterprise Linux (SLES) 12.
Warning: If you’re upgrading from Puppet Server 2.4 or earlier and have modified
/etc/default/puppetserver, see the Puppet Server 2.5 release notes first before upgrading for instructions on avoiding potential failures.
Puppet Server provides a new endpoint,
/status/v1/services, which can provide basic Java Virtual Machine-level metrics related to the current Puppet Server process’s memory usage.
To request this data, make an HTTP GET request to Puppet Server with a query string of
level=debug. For details on the endpoint and its response, see the Services endpoint documentation.
Experimental feature note: These metrics are experimental. The names and values of the metrics may change in future releases.
Previous versions of Puppet Server would rotate and compress logs daily using logrotate. Puppet Server 2.6 uses Logback, the logging library used by Puppet Server’s Java Virtual Machine (JVM).
Under logrotate, certain pathological error states — such as running out of file handles — could cause previous versions of Puppet Server to fill up disk partitions with logs of stack traces.
In Puppet Server 2.6, Logback compresses Server-related logs into archives when their size exceeds 10MB. Also, when the total size of all Puppet Server logs exceeds 1GB, Logback deletes the oldest logs. These improvements should limit the space that Puppet Server’s logs consume and prevent them from filling partitions.
Debian upgrade note: On Debian-based Linux distributions, logrotate will continue to attempt to manage your Puppet Server log files until
/etc/logrotate.d/puppetserveris removed. These logrotate attempts are harmless, but will generate a duplicate archive of logs. As a best practice, delete
logrotate.dafter upgrading to Puppet Server 2.6.
This doesn’t affect clean installations of Puppet Server on Debian, or any upgrade or clean installation on other Linux distributions.
This release resolves two issues by updating the version of JRuby used by Puppet Server to 1.7.26.
In previous versions of Puppet Server 2.x, when a variable lookup is performed from Ruby code or an ERB template and the variable is not defined, catalog compilation could periodically fail with an error message similar to:
Puppet Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, integer 2181729414 too big to convert to `int` at <PUPPET FILE>
The error message is inaccurate; the lookup should return nil. The error is a bug in JRuby, which Puppet Server uses to run Ruby code. Puppet Server 2.6 resolves this by updating JRuby.
Also, when Puppet Server uses a large JVM memory heap and large number of JRuby instances, Puppet Server could fail to start and produce error messages in the
puppetserver.log file similar to:
java.lang.IllegalStateException: There was a problem adding a JRubyPuppet instance to the pool. Caused by: org.jruby.embed.EvalFailedException: (LoadError) load error: jopenssl/load -- java.lang.NoClassDefFoundError: org/jruby/ext/openssl/NetscapeSPKI
We fixed the underlying issue in JRuby, and this fix is included in Puppet Server 2.6.
Puppet Server 2.6 adds the ability to specify a whitelist of environment variables made available to Ruby code. To whitelist variables, add them to the
environment-vars section under the
jruby-puppet configuration section in
Released August 11, 2016.
This is a feature and bug-fix release of Puppet Server.
Potential breaking issues when upgrading with a modified
If you disabled the certificate authority (CA) on Puppet Server by editing the
bootstrap.cfgfile on older versions of Puppet Server — for instance, because you have a multi-master configuration with the default CA disabled on some masters, or use an external CA — be aware that Puppet Server as of version 2.5.0 no longer uses the
Puppet Server 2.5.0 and newer instead create a new configuration file,
/etc/puppetlabs/puppetserver/services.d/ca.cfg, if it doesn’t already exist, and this new file enables CA services by default.
To ensure that CA services remain disabled after upgrading, create the
/etc/puppetlabs/puppetserver/services.d/ca.cfgfile with contents that disable the CA services before you upgrade to Server 2.5.0 or newer. The
puppetserverservice restarts after the upgrade if the service is running before the upgrade, and the service restart also reloads the new
Also, back up your masters’
ssldir(or at least your
crl.pemfile) before you upgrade to ensure that you can restore your previous certificates and certificate revocation list, so you can restore them in case any mistakes or failures to disable the CA services in
ca.cfglead to a master unexpectedly enabling CA services and overwriting them.
For more details, including a sample
ca.cfgfile that disables CA services, see the bootstrap upgrade notes.
Potential service failures when upgrading with a modified init configuration
If you modified the init configuration file — for instance, to configure Puppet Server’s JVM memory allocation or maximum heap size — and upgrade Puppet Server 2.5.0 or newer with a package manager, you might see a warning during the upgrade that the updated package will overwrite the file (
/etc/sysconfig/puppetserverin Red Hat and derivatives, or
/etc/default/puppetserverin Debian-based systems).
The changes to the file support the new service bootstrapping behaviors. If you don’t accept changes to the file during the upgrade, the puppetserver service fails and you might see a
Service ':PoolManagerService' not foundor similar warning. To resolve the issue, set the
BOOTSTRAP_CONFIGsetting in the init configuration file to:
If you modified other settings in the file before upgrading, and then overwrite the file during the upgrade, you might need to reapply those modifications after the upgrade.
To disable the Puppet CA service in previous versions of Puppet Server 2.x, users edited the
bootstrap.cfg file, usually located at
This workflow could cause problems for users performing package upgrades of Puppet Server where
bootstrap.cfg was modified, because the package might overwrite the modified
bootstrap.cfg and undo their changes.
To improve the upgrade experience for these users, Puppet Server 2.5.0 can load the service bootstrapping settings from multiple files. This in turn allows us to provide user-modifiable settings in a separate file and avoid overwriting any changes during an upgrade.
Puppet Server 2.5.0 can sign certificate signing requests (CSRs) from Puppet 4.6 agents that contain a new custom object identifier (OID) arc to represent secured extensions for use with
Aside: Trapperkeeper powers the HOCON
auth.confand authorization methods introduced in Puppet Server 2.2.0. This new CSR-signing functionality in Server 2.5.0 builds on features added to Puppet 4.6 and the addition of X.509 extension-based authorization rules added to Trapperkeeper alongside Puppet Server 2.4.
To sign CSRs wth the new OID arc via the Puppet 4.6 command-line tools, use the
puppet cert sign --allow-authorization-extensions command. See the
puppet cert man page for details. This workflow is similar to signing DNS alt names.
The new OID arc is “puppetlabs.1.3”, with a long name of “Puppet Authorization Certificate Extension” and short name of
ppAuthCertExt (where “puppetlabs” is our registered OID arc 126.96.36.199.4.1.34380). Set the extension “puppetlabs.1.3.1” (
pp_authorization) on CSRs that need to be authenticated via the new workflow. We’ve also included an default alias of
pp_auth_role at extension “puppetlabs.1.3.13” for common workflows. See the Puppet CSR attributes and certificate extensions documentation for more information.
We’ve also improved the CLI output of
puppet cert list and
puppet cert sign to work better with the
--machine-readable flags, and we allow administrators to force a prompt when signing certificates with the
This allows for easier automated failover to authorized nodes within a Puppet infrastructure and provides tools for creating new, securely automated workflows, such as automated component promotions within Puppet-managed infrastructure.
Puppet Server 2.4.x used a deprecated API for a Clojure CLI option-parsing library. As a result, calls to
puppetserver gem (either directly, or indirectly by using a
puppetserver_gem package resource) generated unexpected warning messages:
Warning: Could not match Warning: The following options to parse-opts are unrecognized: :flag
Puppet Server 2.5.0 updates this library, which prevents this error message from appearing.
When installed on CentOS 6, Puppet Server 2.4.x included an empty PID file. When running
service puppetserver status, Puppet Server returned an unexpected error message:
puppetserver dead but pid file exists.
When performing a clean installation of Puppet Server 2.5.0, no PID file is created, and
service puppetserver status should return the expected
not running message.