Puppet has about 200 settings, all of which are listed in the configuration reference. Most users can ignore about 170 of those.
This page lists the most important ones. (We assume here that you’re okay with default values for things like the port Puppet uses for network traffic.) The link for each setting will go to the long description in the configuration reference.
Why so many settings? There are a lot of settings that are rarely useful but still make sense, but there are also at least a hundred that shouldn’t be configurable at all.
This is basically a historical accident. Due to the way Puppet’s code is arranged, the settings system was always the easiest way to publish global constants that are dynamically initialized on startup. This means a lot of things have crept in there regardless of whether they needed to be configurable.
We’ve added improved behavior to Puppet, but some of it can’t be enabled by default until a major version boundary, since it changes things that some users might be relying on. But if you know your site won’t be affected, you can enable some of it today.
trusted_server_facts(Puppet master/apply only) — Set this setting to
trueto take advantage of the
$server_factsvariable, which contains a hash of server-side facts that cannot be overwritten by client-side facts.
strict_variables = true(Puppet master/apply only) — This makes uninitialized variables cause parse errors, which can help squash difficult bugs by failing early instead of carrying undef values into places that don’t expect them. This one has a strong chance of causing problems when you turn it on, so be wary, but it will eventually improve the general quality of Puppet code. This will be enabled by default in Puppet 5.0.
Roughly in order of importance. Most of these can go in either
[agent], or be specified on the command line.
server— The Puppet master server to request configurations from. Defaults to
puppet; change it if that’s not your server’s name.
report_server— If you’re using multiple masters, you’ll need to centralize the CA; one of the ways to do this is by configuring
ca_serveron all agents. See the multiple masters guide for more details. The
report_serversetting works about the same way, although whether you need to use it depends on how you’re processing reports.
certname— The node’s certificate name, and the unique identifier it uses when requesting catalogs; defaults to the fully qualified domain name.
certnameto only use letters, numbers, periods, underscores, and dashes. (That is, it should match
cais reserved, and can’t be used as the certname for a normal node.
environment— The environment to request when contacting the Puppet master. It’s only a request, though; the master’s ENC can override this if it chooses. Defaults to
Note on Non-Certname Node Names
Although it’s possible to set something other than the certname as the node name (using either the
node_name_valuesetting), we don’t generally recommend it. It allows you to re-use one node certificate for many nodes, but it reduces security, makes it harder to reliably identify nodes, and can interfere with other features.
Setting a non-certname node name is not officially supported in Puppet Enterprise.
These settings affect the way Puppet applies catalogs.
noop— If enabled, the agent won’t do any work; instead, it will look for changes that should be made, then report to the master about what it would have done. This can be overridden per-resource with the
priority— Allows you to “nice” Puppet agent so it won’t starve other applications of CPU resources while it’s applying a catalog.
report— Whether to send reports. Defaults to true; usually shouldn’t be disabled, but you might have a reason.
tags— Lets you limit the Puppet run to only include resources with certain tags.
show_diff— Tools for debugging or learning more about an agent run. Extra-useful when combined with the
usecacheonfailure— Whether to fall back to the last known good catalog if the master fails to return a good catalog. The default behavior is good, but you might have a reason to disable it.
ignoreschedules— If you use schedules, this can be useful when doing an initial Puppet run to set up new nodes.
postrun_command— Commands to run on either side of a Puppet run.
These settings affect the way Puppet agent acts when running as a long-lived service.
runinterval— How often to do a Puppet run, when running as a service.
waitforcert— Whether to keep trying back if the agent can’t initially get a certificate. The default behavior is good, but you might have a reason to disable it.
splaylimit— Together, these allow you to spread out agent runs. When running the agent as a daemon, the services will usually have been started far enough out of sync to make this a non-issue, but it’s useful with cron agents. For example, if your agent cron job happens on the hour, you could set
splay = trueand
splaylimit = 60mto keep the master from getting briefly hammered and then left idle for the next 50 minutes.
daemonize— Whether to daemonize. Set this to false when running the agent from cron.
onetime— Whether to exit after finishing the current Puppet run. Set this to true when running the agent from cron.
Many of these settings are also important for standalone Puppet apply nodes, since they act as their own Puppet master.
These settings should usually go in
[master]. However, if you’re using Puppet apply in production, put them in
dns_alt_names— A list of hostnames the server is allowed to use when acting as a Puppet master. The hostname your agents use in their
serversetting must be included in either this setting or the master’s
certnamesetting. Note that this setting is only used when initially generating the Puppet master’s certificate — if you need to change the DNS names, you must:
sudo puppet cert clean <MASTER'S CERTNAME>.
sudo puppet cert generate <MASTER'S CERTNAME> --dns_alt_names <ALT NAME 1>,<ALT NAME 2>,....
environment_timeout— For better performance, you can set this to
unlimitedand make refreshing the Puppet master a part of your standard code deployment process. See the timeout section of the Configuring Environments page for more details.
environmentpath— Controls where Puppet finds directory environments. See the page on directory environments for details.
basemodulepath— A list of directories containing Puppet modules that can be used in all environments. See the modulepath page for details.
reports— Which report handlers to use. For a list of available report handlers, see the report reference. You can also write your own report handlers. Note that the report handlers might require settings of their own.
Puppet Server has its own configuration files; consequently, there are several settings in
puppet.conf that Puppet Server ignores.
puppet-admin— Settings to control which authorized clients can use the admin interface.
jruby-puppet— Provides details on tuning JRuby for better performance.
JAVA_ARGS— Instructions on tuning the Puppet Server memory allocation.
ssl_client_verify_header— These are used when running Puppet master as a Rack application (e.g. under Passenger), which you should definitely be doing. See the Passenger setup guide for more context about how these settings work; depending on how you configure your Rack server, you can usually leave these settings with their default values.
always_cache_features— You should always set this to
[master]for better performance. (Don’t change the default value in
[main], because Puppet apply and Puppet agent both need this set to
config.rufile should forcibly set this, as done in the default
These features configure add-ons and optional features.
external_nodes— The ENC settings. If you’re using an ENC, set these to
execand the path to your ENC script, respectively.
storeconfigs_backend— Used for setting up PuppetDB. See the PuppetDB docs for details.
catalog_terminus— This can enable the optional static compiler. If you have lots of
fileresources in your manifests, the static compiler lets you sacrifice some extra CPU work on your Puppet master to gain faster configuration and reduced HTTPS traffic on your agents. See the “static compiler” section of the indirection reference for details.
ca_ttl— How long newly signed certificates should be valid for.
autosign— Whether (and how) to autosign certificates. See the autosigning page for details.