pe-puppet-server.conf settings

enable-file-sync-locking or file_sync::file_sync_locking_enabled

Controls whether the file sync client locks the JRuby pool (and, by extension, most requests to Puppet Server) while deploying Puppet code.

Default: true

We do not recommend changing the enable-file-sync-locking setting. Instead, enable Lockless code deploys, which allow the file sync client to update code into versioned code directories without blocking Puppet Server requests or overwriting the live code directory.

gem-home

Determines where JRuby looks for gems. This is also used by the puppetserver gem command line tool.

Default: '/opt/puppetlabs/puppet/cache/jruby-gems'

jruby_max_active_instances

Controls the maximum number of JRuby instances to allow on the Puppet Server.

Default: 4

For more information, refer to JRuby max active instances.

max_requests_per_instance

Sets the maximum number of requests allowed for each JRuby interpretor instance before it is killed.

Default: 100000

For more information, refer to JRuby max requests per instance.

max-queued-requests

Sets the maximum number of requests allowed to be queued waiting to borrow from the JRuby pool.

This setting is optional and defaults to 0 (unlimited). If changed, you must specify a positive integer.

After reaching the limit, all new requests receive a 503 Service Unavailable response until the queue drops below the limit. If the max-retry-delay setting is also set to a positive integer, then the 503 response includes a random sleep time after which the client can retry the request.

Don't use this setting if your managed infrastructure includes multiple agents older than Puppet 5.3. Because older agents treat 503 responses as failures, a thundering herd problem occurs when the agents schedule their next runs at the same time.

max-retry-delay

Sets the maximum number of seconds allowed for the random sleep time set when the max-queued-requests limit is exceeded. The random sleep time is returned as a Retry-After header on the 503 response for each rejected request.

Default: 1800 seconds

If max-queued-requests is 0, there is no limit to the number of queued requests and, therefore, the max-retry-delay is irrelevant.

pre-commit-hook-commands or puppetserver::pre_commit_hook_commands

Specify scripts, as an array of strings, that you want the file sync storage server to execute against a repo after receiving a change but before committing and syncing the change across compilers. This is similar to Configuring post-deployment commands for r10k or Configuring post-environment hooks for Code Manager.

The pe-puppetserver process, acting as the pe-puppet user, executes the scripts in the order supplied. You must supply scripts as absolute paths. Additionally, the pe-puppet user must be able to execute the scripts, and the scripts must be able to consume stdin (even if the script doesn't do anything with it).

Default: ["/opt/puppetlabs/server/bin/generate-puppet-types.rb"]

Removing the default value disables the generate-puppet-types.rb script. Unless you intentionally want to disable this type generation method, make sure to keep the default path in the array.

The output, error, and exit code for these scripts are logged at the trace level of pe-puppetserver logs when the exit code is 0. If the exit code is not 0, the codes are logged at the error level.

This setting is managed in PE modules, and you can override it by setting the puppet_enterprise::master::puppetserver::pre_commit_hook_commands parameter in Hiera. Make sure to include the default path (for generate-puppet-types.rb) to ensure custom type are correctly cached. If you want to disable all pre-commit commands, supply an empty array in Hiera.

puppet-code-repo

Identifies, as a string, the internal name for the Puppet code repo (the codedir) that contains all code to sync across compilers (including user-supplied code repos).

Do not change this setting.

Default: 'puppet-code'

puppet_enterprise::master::puppetserver::jruby_puppet_instance_creation_concurrency

Following the first instance of a JRuby, this setting controls how many JRuby instances are concurrently created. This number should be between 1 and jruby_max_active_instances - 1.

Default: 3

The default value of jruby_max_active_instances is determined dynamically but is typically 4, so after the first JRuby instance is initialized, the default value of 3 for this setting allows all of the remaining JRuby instances to be loaded concurrently. Users may be able to raise this value to speed up Puppet Server start up, however too many JRuby instances trying to initialize concurrently may cause an unacceptable drop in performance on some systems. Users are recommended to experiment with this setting to find the value that works best for them.

puppet_enterprise::master::puppetserver::settings_catalog

Valid values are true or false. If set to true, the JRuby instances will not validate that the file settings exist, for example, codedir. These should be managed by packages or in Puppet Enterprise’s Puppet code, and if this setting is enabled and it causes an issue please file a bug report. Issues such as a missing required directory, file or misconfigured permissions on said directory or file might appear. Once this setting is enabled, to disable it users must explicitly set the value to false. Disabling this parameter value removes it from Puppet management and the last explicit configuration value is the value that Puppet sees.

ruby-load-path or puppetserver_jruby_puppet_ruby_load_path

Determines where Puppet Server finds components such as Puppet and Facter. The agent's libdir path is included by default.

Default: ['/opt/puppetlabs/puppet/lib/ruby/vendor_ruby', '/opt/puppetlabs/puppet/cache/lib']

For more information, refer to Set the Ruby load path.

server-conf-dir

Sets the Puppet configuration directory path.

Default: '/etc/puppetlabs/puppet'

server-var-dir

Sets the Puppet Server variable directory path.

Default: '/opt/puppetlabs/server/data/puppetserver'