This page lists known issues for PuppetDB in Puppet Enterprise.
This version of PE includes PuppetDB version 4.2.5. Refer to the PuppetDB release notes for more information.
After upgrading to 2016.5.1 or 2016.5.2, PostgreSQL CPU usage increases by 50 percent. To workaround this issue, we’ve created the pdb_3323_workaround module.
After you install this module, it’s safe to ignore. The index will be removed when you upgrade in the future.
Adding the sensitive datatype to the parameters of an existing resource, or enabling the experimental rich_data feature, causes catalog storage failures in PuppetDB. You must remove the sensitive data type from resource parameters and disable rich_data if you want PuppetDB to store new catalogs for affected nodes.
If, during installation or upgrade, you supply an incorrect password for one of the PE databases users (RBAC, console, PuppetDB), the install/upgrade will fail. However, in some cases it might appear that the install/upgrade was successful. For example, if the incorrect password is supplied for the console database user, the install/upgrade continues—and appears to succeed—but the console will not be functional.
If for any reason the
pe-postgresql service is stopped, agents receive several different error messages, for example:
Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 400 on SERVER: (<unknown>): mapping values are not allowed in this context at line 7 column 28
or, when attempting to request a catalog:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: (<unknown>): mapping values are not allowed in this context at line 7 column 28 Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run
If you encounter these errors, simply re-start the
Puppet Server handles outgoing HTTPS connections differently from the older MRI Ruby Puppet master, and has a new restriction on the server certificates it will accept. This affects all Puppet Enterprise versions in the 2015.2 series.
If Puppet Server makes client connections to another HTTPS service, that service must use only one certificate. If that service is behind a load balancer, and the back-end servers use individual certificates, Puppet Server will frequently abort its client connections. For more details, see this note from the Puppet Server docs.
Therefore, if you are running multiple PuppetDB servers behind a load balancer, you must configure all of them to use the same certificate. You can do this by following the instructions below.
Warning: This is a non-standard configuration that may or may not be supported, depending on what your organization has negotiated with Puppet.
Also note that if you use this workaround, you will not be able to use
/opt/puppetlabs/sbin/puppetdb ssl-setupto repair certificate issues with PuppetDB.
On the Puppet master that serves as the CA, generate a certificate for your PuppetDB nodes with the load balancer hostname as one of the DNS alt names. In this example, we use
puppet cert generate <pe-internal-puppetdb> --dns_alt_names=<LOAD BALANCER HOSTNAME>
/etc/puppetlabs/puppet/ssl/certs/pe-internal-puppetdb.pem) to the same path on each PuppetDB node (
/etc/puppetlabs/puppet/ssl/private_keys/pe-internal-puppetdb.pem) to the same path on each PuppetDB node (
/etc/puppetlabs/puppet/ssl/public_keys/pe-internal-puppetdb.pem) to the same path on each PuppetDB node (
In the PE console, configure the
puppet_enterprise::profile::puppetdb class to use the new
a. Click Nodes > Classification, and in the PE Infrastructure node group, select the PE PuppetDB group.
b. On the Classes tab, find the
c. From the Parameter drop-down list, select
d. In the Value field, enter
5e. Click Add parameter, and commit changes.
Add the hostname of the load balancer to the PE Infrastructure class.
a. Click Nodes > Classification, and select the PE Infrastructure group.
b. On the Classes tab, find the
c. For the
puppetdb_host entry, edit the value to reflect the hostname of your load balancer.
d. Commit changes.