This page is autogenerated; any changes will get overwritten
puppet.conf
or on the
command line.disable18n
, environment_timeout
, always_retry_plugins
,
and the Puppet Server JRuby max-active-instances
setting. To verify PE
configuration defaults, check the puppet.conf
file after installation.--setting
and
--no-setting
instead of --setting (true|false)
. (Using --setting false
results in “Error: Could not parse application options: needless argument”.)$variables
in other settings; $environment
is special, in that puppet master will interpolate each agent node’s
environment instead of its own.splay
setting, note that the period that it waits changes
each time the Puppet agent is restarted.rundir = $vardir/run { owner = puppet,
group = puppet, mode = 644 }
See the configuration guide for more details.
A lock file to indicate that a puppet agent catalog run is currently in progress. The file contains the pid of the process that holds the lock on the catalog run.
A lock file to indicate that puppet agent runs have been administratively disabled. File contains a JSON object with state information.
Whether to allow a new certificate request to overwrite an existing
certificate request. If true, then the old certificate must be cleaned using
puppetserver ca clean
, and the new request signed using puppetserver ca sign
.
Affects how we cache attempts to load Puppet resource types and features. If
true, then calls to Puppet.type.<type>?
Puppet.feature.<feature>?
will always attempt to load the type or feature (which can be an
expensive operation) unless it has already been loaded successfully.
This makes it possible for a single agent run to, e.g., install a
package that provides the underlying capabilities for a type or feature,
and then later load that type or feature during the same run (even if
the type or feature had been tested earlier and had not been available).
If this setting is set to false, then types and features will only be checked once, and if they are not available, the negative result is cached and returned for all subsequent attempts to load the type or feature. This behavior is almost always appropriate for the server, and can result in a significant performance improvement for types and features that are checked frequently.
Whether log files should always flush to disk.
Whether (and how) to autosign certificate requests. This setting is only relevant on a puppet master acting as a certificate authority (CA).
Valid values are true (autosigns all certificate requests; not recommended), false (disables autosigning certificates), or the absolute path to a file.
The file specified in this setting may be either a configuration file
or a custom policy executable. Puppet will automatically determine
what it is: If the Puppet user (see the user
setting) can execute the
file, it will be treated as a policy executable; otherwise, it will be
treated as a config file.
If a custom policy executable is configured, the CA puppet master will run it every time it receives a CSR. The executable will be passed the subject CN of the request as a command line argument, and the contents of the CSR in PEM format on stdin. It should exit with a status of 0 if the cert should be autosigned and non-zero if the cert should not be autosigned.
If a certificate request is not autosigned, it will persist for review. An admin
user can use the puppetserver ca sign
command to manually sign it, or can delete
the request.
For info on autosign configuration files, see the guide to Puppet’s config files.
The search path for global modules. Should be specified as a list of directories separated by the system path separator character. (The POSIX path separator is ‘:’, and the Windows path separator is ‘;’.)
These are the modules that will be used by all environments. Note that
the modules
directory of the active environment will have priority over
any global directories. For more info, see
https://puppet.com/docs/puppet/latest/environments_about.html
The binder configuration file. Puppet reads this file on each request to configure the bindings system. If set to nil (the default), a $confdir/binder_config.yaml is optionally loaded. If it does not exists, a default configuration is used. If the setting :binding_config is specified, it must reference a valid and existing yaml file.
Where FileBucket files are stored.
The expected fingerprint of the CA certificate. If specified, the agent will compare the CA certificate fingerprint that it downloads against this value and reject the CA certificate if the values do not match. This only applies during the first download of the CA certificate.
The name to use the Certificate Authority certificate.
The port to use for the certificate authority.
The server to use for certificate authority requests. It’s a separate server because it cannot and does not need to horizontally scale.
The default TTL for new certificates. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The CA certificate.
The certificate revocation list (CRL) for the CA.
The root directory for the certificate authority.
The CA private key.
The CA public key.
How to store cached catalogs. Valid values are ‘json’, ‘msgpack’ and ‘yaml’. The agent application defaults to ‘json’.
Where to get node catalogs. This is useful to change if, for instance, you’d like to pre-compile catalogs and store them in memcached or some other easily-accessed store.
The inventory file. This is a text file to which the CA writes a complete listing of all certificates.
The certificate directory.
Whether certificate revocation checking should be enabled, and what level of checking should be performed.
When certificate revocation is enabled, Puppet expects the contents of its CRL to be one or more PEM-encoded CRLs concatenated together. When using a cert bundle, CRLs for all CAs in the chain of trust must be included in the crl file. The chain should be ordered from least to most authoritative, with the first CRL listed being for the root of the chain and the last being for the leaf CA.
When certificate_revocation is set to ‘true’ or ‘chain’, Puppet ensures that each CA in the chain of trust has not been revoked by its issuing CA.
When certificate_revocation is set to ‘leaf’, Puppet verifies certs against the issuing CA’s revocation list, but it does not verify the revocation status of the issuing CA or any CA above it within the chain of trust.
When certificate_revocation is set to ‘false’, Puppet disables all certificate revocation checking and does not attempt to download the CRL.
The name to use when handling certificates. When a node
requests a certificate from the CA puppet master, it uses the value of the
certname
setting as its requested Subject CN.
This is the name used when managing a node’s permissions in
auth.conf.
In most cases, it is also used as the node’s name when matching
node definitions
and requesting data from an ENC. (This can be changed with the node_name_value
and node_name_fact
settings, although you should only do so if you have
a compelling reason.)
A node’s certname is available in Puppet manifests as $trusted['certname']
. (See
Facts and Built-In Variables
for more details.)
certname
to
only use lowercase letters, numbers, periods, underscores, and dashes. (That is,
it should match /A[a-z0-9._-]+Z/
.)ca
is reserved, and can’t be used as the certname
for a normal node.Defaults to the node’s fully qualified domain name.
The file in which puppet agent stores a list of the classes
associated with the retrieved configuration. Can be loaded in
the separate puppet
executable using the --loadclasses
option.
The directory in which serialized data is stored on the client.
Where FileBucket files are stored locally.
The directory in which client-side YAML data is stored.
Code to parse directly. This is essentially only used
by puppet
, and should only be set if you’re writing your own Puppet
executable.
The main Puppet code directory. The default for this setting is calculated based on the user. If the process is running as root or the user that Puppet is supposed to run as, it defaults to a system directory, but if it’s running as any other user, it defaults to being in the user’s home directory.
Whether to use colors when logging to the console. Valid values are
ansi
(equivalent to true
), html
, and false
, which produces no color.
Defaults to false on Windows, as its console does not support ansi colors.
The main Puppet configuration directory. The default for this setting is calculated based on the user. If the process is running as root or the user that Puppet is supposed to run as, it defaults to a system directory, but if it’s running as any other user, it defaults to being in the user’s home directory.
The configuration file for the current puppet application.
The name of the puppet config file.
How to determine the configuration version. By default, it will be the time that the configuration is parsed, but you can provide a shell script to override how the version is determined. The output of this script will be added to every log message in the reports, allowing you to correlate changes on your hosts to the source version on the server.
Setting a global value for config_version in puppet.conf is not allowed (but it can be overridden from the commandline). Please set a per-environment value in environment.conf instead. For more info, see https://puppet.com/docs/puppet/latest/environments_about.html
Prints the value of a specific configuration setting. If the name of a setting is provided for this, then the value is printed and puppet exits. Comma-separate multiple values. For a list of all values, specify ‘all’. This setting is deprecated, the ‘puppet config’ command replaces this functionality.
How often the Puppet agent refreshes its local CRL. By default the CRL is only downloaded once, and never refreshed. If a duration is specified, then the agent will refresh its CRL whenever it next runs and the elapsed time since the CRL was last refreshed exceeds the duration.
In general, the duration should be greater than the runinterval
.
Setting it to an equal or lesser value will cause the CRL to be
refreshed on every run.
If the agent downloads a new CRL, the agent will use it for subsequent network requests. If the refresh request fails or if the CRL is unchanged on the server, then the agent run will continue using the local CRL it already has.This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
An optional file containing custom attributes to add to certificate signing
requests (CSRs). You should ensure that this file does not exist on your CA
puppet master; if it does, unwanted certificate extensions may leak into
certificates created with the puppetserver ca generate
command.
If present, this file must be a YAML hash containing a custom_attributes
key
and/or an extension_requests
key. The value of each key must be a hash, where
each key is a valid OID and each value is an object that can be cast to a string.
Custom attributes can be used by the CA when deciding whether to sign the
certificate, but are then discarded. Attribute OIDs can be any OID value except
the standard CSR attributes (i.e. attributes described in RFC 2985 section 5.4).
This is useful for embedding a pre-shared key for autosigning policy executables
(see the autosign
setting), often by using the 1.2.840.113549.1.9.7
(“challenge password”) OID.
Extension requests will be permanently embedded in the final certificate.
Extension OIDs must be in the “ppRegCertExt” (1.3.6.1.4.1.34380.1.1
),
“ppPrivCertExt” (1.3.6.1.4.1.34380.1.2
), or
“ppAuthCertExt” (1.3.6.1.4.1.34380.1.3
) OID arcs. The ppRegCertExt arc is
reserved for four of the most common pieces of data to embed: pp_uuid
(.1
),
pp_instance_id
(.2
), pp_image_name
(.3
), and pp_preshared_key
(.4
)
— in the YAML file, these can be referred to by their short descriptive names
instead of their full OID. The ppPrivCertExt arc is unregulated, and can be used
for site-specific extensions. The ppAuthCert arc is reserved for two pieces of
data to embed: pp_authorization
(.1
) and pp_auth_role
(.13
). As with
ppRegCertExt, in the YAML file, these can be referred to by their short
descriptive name instead of their full OID.
Where the CA stores certificate requests.
Whether to send the process into the background. This defaults to true on POSIX systems, and to false on Windows (where Puppet currently cannot daemonize).
This setting has been deprecated. Use of any value other than ‘hiera’ should instead be configured in a version 5 hiera.yaml. Until this setting is removed, it controls which data binding terminus to use for global automatic data binding (across all environments). By default this value is ‘hiera’. A value of ‘none’ turns off the global binding.
The default source for files if no server is given in a
uri, e.g. puppet:///file. The default of rest
causes the file to be
retrieved using the server
setting. When running apply
the default
is file_server
, causing requests to be filled locally.
The default main manifest for directory environments. Any environment that
doesn’t set the manifest
setting in its environment.conf
file will use
this manifest.
This setting’s value can be an absolute or relative path. An absolute path will make all environments default to the same main manifest; a relative path will allow each environment to use its own manifest, and Puppet will resolve the path relative to each environment’s main directory.
In either case, the path can point to a single file or to a directory of manifests to be evaluated in alphabetical order.
Boolean; whether to generate the default schedule resources. Setting this to false is useful for keeping external report processors clean of skipped schedule resources.
The root directory of devices’ $confdir.
Path to the device config file for puppet device.
The root directory of devices’ $vardir.
Which diff command to use when printing differences between files. This setting
has no default value on Windows, as standard diff
is not available, but Puppet can use many
third-party diff tools.
Which arguments to pass to the diff command when printing differences between
files. The command to use can be chosen with the diff
setting.
Which digest algorithm to use for file resources and the filebucket. Valid values are md5, sha256, sha384, sha512, sha224. Default is md5.
If true, turns off all translations of Puppet and module log messages, which affects error, warning, and info log messages, as well as any translations in the report and CLI.
Whether to disallow an environment-specific main manifest. When set
to true
, Puppet will use the manifest specified in the default_manifest
setting
for all environments. If an environment specifies a different main manifest in its
environment.conf
file, catalog requests for that environment will fail with an error.
This setting requires default_manifest
to be set to an absolute path.
A comma-separated list of warning types to suppress. If large numbers of warnings are making Puppet’s logs too large or difficult to use, you can temporarily silence them with this setting.
If you are preparing to upgrade Puppet to a new major version, you should re-enable all warnings for a while.
Valid values for this setting are:
deprecations
— disables deprecation warnings.undefined_variables
— disables warnings about non existing variables.undefined_resources
— disables warnings about non existing resources.
A comma-separated list of alternate DNS names for Puppet Server. These are extra
hostnames (in addition to its certname
) that the server is allowed to use when
serving agents. Puppet checks this setting when automatically creating a
certificate for Puppet agent or Puppet Server. These can be either IP or DNS, and the type
should be specified and followed with a colon. Untyped inputs will default to DNS.
In order to handle agent requests at a given hostname (like “puppet.example.com”), Puppet Server needs a certificate that proves it’s allowed to use that name; if a server shows a certificate that doesn’t include its hostname, Puppet agents will refuse to trust it. If you use a single hostname for Puppet traffic but load-balance it to multiple Puppet Servers, each of those servers needs to include the official hostname in its list of extra names.
Note: The list of alternate names is locked in when the server’s certificate is signed. If you need to change the list later, you can’t just change this setting; you also need to regenerate the certificate. For more information on that process, see the [cert regen docs] (https://puppet.com/docs/puppet/latest/ssl_regenerate_certificates.html).
To see all the alternate names your servers are using, log into your CA server
and run puppetserver ca list --all
, then check the output for (alt names: ...)
.
Most agent nodes should NOT have alternate names; the only certs that should
have them are Puppet Server nodes that you want other agents to trust.
Whether to document all resources when using puppet doc
to
generate manifest documentation.
The environment in which Puppet is running. For clients,
such as puppet agent
, this determines the environment itself, which
Puppet uses to find modules and much more. For servers, such as puppet master
,
this provides the default environment for nodes that Puppet knows nothing about.
When defining an environment in the [agent]
section, this refers to the
environment that the agent requests from the master. The environment doesn’t
have to exist on the local filesystem because the agent fetches it from the
master. This definition is used when running puppet agent
.
When defined in the [user]
section, the environment refers to the path that
Puppet uses to search for code and modules related to its execution. This
requires the environment to exist locally on the filesystem where puppet is
being executed. Puppet subcommands, including puppet module
and
puppet apply
, use this definition.
Given that the context and effects vary depending on the
config section
in which the environment
setting is defined, do not set it globally.
The name of a registered environment data provider used when obtaining environment specific data. The three built in and registered providers are ‘none’ (no data), ‘function’ (data obtained by calling the function ‘environment::data()’) and ‘hiera’ (data obtained using a data provider configured using a hiera.yaml file in root of the environment). Other environment data providers may be registered in modules on the module path. For such custom data providers see the respective module documentation. This setting is deprecated.
How long the Puppet master should cache data it loads from an environment.
A value of 0
will disable caching. This setting can also be set to
unlimited
, which will cache environments until the master is restarted
or told to refresh the cache.
You should change this setting once your Puppet deployment is doing
non-trivial work. We chose the default value of 0
because it lets new
users update their code without any extra steps, but it lowers the
performance of your Puppet master.
We recommend setting this to unlimited
and explicitly refreshing your
Puppet master as part of your code deployment process.
environment-cache
API endpoint. See the docs for the Puppet Server
administrative API.Any value other than 0
or unlimited
is deprecated, since most Puppet
servers use a pool of Ruby interpreters which all have their own cache
timers. When these timers drift out of sync, agents can be served
inconsistent catalogs.
A search path for directory environments, as a list of directories separated by the system path separator character. (The POSIX path separator is ‘:’, and the Windows path separator is ‘;’.)
This setting must have a value set to enable directory environments. The
recommended value is $codedir/environments
. For more details, see
https://puppet.com/docs/puppet/latest/environments_about.html
Whether each resource should log when it is being evaluated. This allows you to interactively see exactly what is being done.
The external node classifier (ENC) script to use for node data. Puppet combines this data with the main manifest to produce node catalogs.
To enable this setting, set the node_terminus
setting to exec
.
This setting’s value must be the path to an executable command that can produce node information. The command must:
classes
— A list of classes, as an array or hash.environment
— A string.parameters
— A list of top-scope variables to set, as a hash.Generally, an ENC script makes requests to an external data source.
For more info, see the ENC documentation.
Whether to enable a pre-Facter 4.0 release of Facter (distributed as the “facter-ng” gem). This is not necessary if Facter 3.x or later is installed. This setting is still experimental.
Where Puppet should look for facts. Multiple directories should be separated by the system path separator character. (The POSIX path separator is ‘:’, and the Windows path separator is ‘;’.)
The node facts terminus.
Where the fileserver configuration is stored.
The minimum time to wait between checking for updates in configuration files. This timeout determines how quickly Puppet checks whether a file (such as manifests or puppet.conf) has changed on disk. The default will change in a future release to be ‘unlimited’, requiring a reload of the Puppet service to pick up changes to its internal configuration. Currently we do not accept a value of ‘unlimited’. To reparse files within an environment in Puppet Server please use the environment_cache endpoint
The authorization key to connect to the Puppet Forge. Leave blank for unauthorized or license based connections
Freezes the ‘main’ class, disallowing any code to be added to it. This essentially means that you can’t have any code outside of a node, class, or definition other than in the site manifest.
Causes validation of loaded legacy Ruby functions (3x API) to raise errors about illegal constructs that could cause harm or that simply does not work. This flag is on by default. This flag is made available so that the validation can be turned off in case the method of validation is faulty - if encountered, please file a bug report.
Whether or not to enable all features currently being developed for future major releases of Puppet. Should be used with caution, as in development features are experimental and can have unexpected effects.
When true, causes Puppet applications to print an example config file
to stdout and exit. The example will include descriptions of each
setting, and the current (or default) value of each setting,
incorporating any settings overridden on the CLI (with the exception
of genconfig
itself). This setting only makes sense when specified
on the command line as --genconfig
.
Whether to just print a manifest to stdout and exit. Only makes
sense when specified on the command line as --genmanifest
. Takes into account arguments specified
on the CLI.
Whether to create .dot graph files, which let you visualize the dependency and containment relationships in Puppet’s catalog. You can load and view these files with tools like OmniGraffle (OS X) or graphviz (multi-platform).
Graph files are created when applying a catalog, so this setting
should be used on nodes running puppet agent
or puppet apply
.
The graphdir
setting determines where Puppet will save graphs. Note
that we don’t save graphs for historical runs; Puppet will replace the
previous .dot files with new ones every time it applies a catalog.
See your graphing software’s documentation for details on opening .dot
files. If you’re using GraphViz’s dot
command, you can do a quick PNG
render with dot -Tpng <DOT FILE> -o <OUTPUT FILE>
.
Where to save .dot-format graphs (when the graph
setting is enabled).
The group Puppet Server will run as. Used to ensure the agent side processes (agent, apply, etc) create files and directories readable by Puppet Server when necessary.
The hiera configuration file. Puppet only reads this file on startup, so you must restart the puppet master every time you edit it.
Where individual hosts store and look for their certificates.
Where the host’s certificate revocation list can be found. This is distinct from the certificate authority’s CRL.
This setting is deprecated.
Where individual hosts store and look for their private key.
Where individual hosts store and look for their public key.
The maximum amount of time to wait when establishing an HTTP connection. The default value is 2 minutes. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
Whether to write HTTP request and responses to stderr. This should never be used in a production environment.
The list of extra headers that will be sent with http requests to the master. The header definition consists of a name and a value separated by a colon.
The maximum amount of time a persistent HTTP connection can remain idle in the connection pool, before it is closed. This timeout should be shorter than the keepalive timeout used on the HTTP server, e.g. Apache KeepAliveTimeout directive. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The HTTP proxy host to use for outgoing connections. The proxy will be bypassed if
the server’s hostname matches the NO_PROXY environment variable or no_proxy
setting. Note: You
may need to use a FQDN for the server hostname when using a proxy. Environment variable
http_proxy or HTTP_PROXY will override this value.
The password for the user of an authenticated HTTP proxy.
Requires the http_proxy_user
setting.
Note that passwords must be valid when used as part of a URL. If a password
contains any characters with special meanings in URLs (as specified by RFC 3986
section 2.2), they must be URL-encoded. (For example, #
would become %23
.)
The HTTP proxy port to use for outgoing connections
The user name for an authenticated HTTP proxy. Requires the http_proxy_host
setting.
The time to wait for data to be read from an HTTP connection. If nothing is read after the elapsed interval then the connection will be closed. The default value is 10 minutes. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The HTTP User-Agent string to send when making network requests.
Skip searching for classes and definitions that were missing during a prior compilation. The list of missing objects is maintained per-environment and persists until the environment is cleared or the master is restarted.
Boolean; whether puppet agent should ignore schedules. This is useful for initial puppet agent runs.
The type of private key. Valid values are rsa
and ec
. Default is rsa
.
The bit length of keys.
Where puppet agent stores the last run report summary in yaml format.
Where puppet agent stores the last run report in yaml format.
The LDAP attributes to include when querying LDAP for nodes. All returned attributes are set as variables in the top-level scope. Multiple values should be comma-separated. The value ‘all’ returns all attributes.
The search base for LDAP searches. It’s impossible to provide a meaningful default here, although the LDAP libraries might have one already set. Generally, it should be the ‘ou=Hosts’ branch under your main directory.
The LDAP attributes to use to define Puppet classes. Values should be comma-separated.
The attribute to use to define the parent node.
The password to use to connect to LDAP.
The LDAP port.
The LDAP server.
Whether SSL should be used when searching for nodes. Defaults to false because SSL usually requires certificates to be set up on the client side.
The LDAP attributes that should be stacked to arrays by adding the values in all hierarchy elements of the tree. Values should be comma-separated.
The search string used to find an LDAP node.
Whether TLS should be used when searching for nodes. Defaults to false because TLS usually requires certificates to be set up on the client side.
The user to use to connect to LDAP. Must be specified as a full DN.
An extra search path for Puppet. This is only useful for those files that Puppet will load on demand, and is only guaranteed to work for those cases. In fact, the autoload mechanism is responsible for making sure this directory is in Ruby’s search path
Where each client stores the CA certificate.
Where Puppet should store translation files that it pulls down from the central server.
From where to retrieve translation files. The standard Puppet file
type
is used for retrieval, so anything that is a valid file source can
be used here.
Default logging level for messages from Puppet. Allowed values are:
crit
Where to send log messages. Choose between ‘syslog’ (the POSIX syslog service), ‘eventlog’ (the Windows Event Log), ‘console’, or the path to a log file.
The directory in which to store log files
Whether Puppet should manage the owner, group, and mode of files it uses internally.
Note: For Windows agents, the default is false
for versions 4.10.13 and greater, versions 5.5.6 and greater, and versions 6.0 and greater.
The entry-point manifest for puppet master. This can be one file or a directory of manifests to be evaluated in alphabetical order. Puppet manages this path as a directory if one exists or if the path ends with a / or .
Setting a global value for manifest
in puppet.conf is not allowed
(but it can be overridden from the commandline). Please use
directory environments instead. If you need to use something other than the
environment’s manifests
directory as the main manifest, you can set
manifest
in environment.conf. For more info, see
https://puppet.com/docs/puppet/latest/environments_about.html
The default port puppet subcommands use to communicate
with Puppet Server. (eg puppet facts upload
, puppet agent
). May be
overridden by more specific settings (see ca_port
, report_port
).
Sets the max number of logged/displayed parser validation deprecation warnings in case multiple deprecation warnings have been detected. A value of 0 blocks the logging of deprecation warnings. The count is per manifest.
Sets the max number of logged/displayed parser validation errors in case multiple errors have been detected. A value of 0 is the same as a value of 1; a minimum of one error is always raised. The count is per manifest.
Sets the max number of logged/displayed parser validation warnings in case multiple warnings have been detected. A value of 0 blocks logging of warnings. The count is per manifest.
The maximum allowed UID. Some platforms use negative UIDs but then ship with tools that do not know how to handle signed ints, so the UIDs show up as huge numbers that can then not be fed back into the system. This is a hackish way to fail in a slightly more useful way when that happens.
The maximum amount of time the Puppet agent should wait for its
certificate request to be signed. A value of unlimited
will cause puppet agent
to ask for a signed certificate indefinitely.
This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The maximum amount of time the puppet agent should wait for an
already running puppet agent to finish before starting a new one. This is set by default to 1 minute.
A value of unlimited
will cause puppet agent to wait indefinitely.
This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
Whether to merge class-level dependency failure warnings.
When a class has a failed dependency, every resource in the class generates a notice level message about the dependency failure, and a warning level message about skipping the resource.
If true, all messages caused by a class dependency failure are merged into one message associated with the class.
Whether to create the necessary user and group that puppet agent will run as.
Extra module groups to request from the Puppet Forge. This is an internal setting, and users should never change it.
The module repository
The directory into which module tool data is stored
The search path for modules, as a list of directories separated by the system path separator character. (The POSIX path separator is ‘:’, and the Windows path separator is ‘;’.)
Setting a global value for modulepath
in puppet.conf is not allowed
(but it can be overridden from the commandline). Please use
directory environments instead. If you need to use something other than the
default modulepath of <ACTIVE ENVIRONMENT'S MODULES DIR>:$basemodulepath
,
you can set modulepath
in environment.conf. For more info, see
https://puppet.com/docs/puppet/latest/environments_about.html
The name of the application, if we are running as one. The
default is essentially $0 without the path or .rb
.
The short name for the EC curve used to generate the EC private key. Valid
values must be one of the curves in OpenSSL::PKey::EC.builtin_curves
.
Default is prime256v1
.
List of host or domain names that should not go through http_proxy_host
. Environment variable no_proxy or NO_PROXY will override this value. Names can be specified as an FQDN host.example.com
, wildcard *.example.com
, dotted domain .example.com
, or suffix example.com
.
How to store cached nodes. Valid values are (none), ‘json’, ‘msgpack’, or ‘yaml’.
How the puppet master determines the client’s identity and sets the ‘hostname’, ‘fqdn’ and ‘domain’ facts for use in the manifest, in particular for determining which ‘node’ statement applies to the client. Possible values are ‘cert’ (use the subject’s CN in the client’s certificate) and ‘facter’ (use the hostname that the client reported in its facts).
This setting is deprecated, please use explicit fact matching for classification.
The fact name used to determine the node name used for all requests the agent makes to the master. WARNING: This setting is mutually exclusive with node_name_value. Changing this setting also requires changes to the default auth.conf configuration on the Puppet Master. Please see http://links.puppet.com/node_name_fact for more information.
The explicit value used for the node name for all requests the agent makes to the master. WARNING: This setting is mutually exclusive with node_name_fact. Changing this setting also requires changes to the default auth.conf configuration on the Puppet Master. Please see http://links.puppet.com/node_name_value for more information.
Which node data plugin to use when compiling node catalogs.
When Puppet compiles a catalog, it combines two primary sources of info: the main manifest, and a node data plugin (often called a “node terminus,” for historical reasons). Node data plugins provide three things for a given node name:
The three main node data plugins are:
plain
— Returns no data, so that the main manifest controls all node configuration.exec
— Uses an
external node classifier (ENC),
configured by the external_nodes
setting. This lets you pull a list of Puppet classes
from any external system, using a small glue script to perform the request and format the
result as YAML.classifier
(formerly console
) — Specific to Puppet Enterprise. Uses the PE console
for node data.”
Whether to apply catalogs in noop mode, which allows Puppet to partially simulate a normal run. This setting affects puppet agent and puppet apply.
When running in noop mode, Puppet will check whether each resource is in sync, like it does when running normally. However, if a resource attribute is not in the desired state (as declared in the catalog), Puppet will take no action, and will instead report the changes it would have made. These simulated changes will appear in the report sent to the puppet master, or be shown on the console if running puppet agent or puppet apply in the foreground. The simulated changes will not send refresh events to any subscribing or notified resources, although Puppet will log that a refresh event would have been sent.
Important note:
The noop
metaparameter
allows you to apply individual resources in noop mode, and will override
the global value of the noop
setting. This means a resource with
noop => false
will be changed if necessary, even when running puppet
agent with noop = true
or --noop
. (Conversely, a resource with
noop => true
will only be simulated, even when noop mode is globally disabled.)
Perform one configuration run and exit, rather than spawning a long-running daemon. This is useful for interactively running puppet agent, or running puppet agent from cron.
Where puppet agent stores the password for its private key. Generally unused.
The shell search path. Defaults to whatever is inherited from the parent process.
This setting can only be set in the [main]
section of puppet.conf; it cannot
be set in [master]
, [agent]
, or an environment config section.
The file containing the PID of a running process. This file is intended to be used by service management frameworks and monitoring systems to determine if a puppet process is still in the process table.
Where Puppet should store plugins that it pulls down from the central server.
Where Puppet should store external facts that are being handled by pluginsync
Where to retrieve external facts for pluginsync
What files to ignore when pulling down plugins.
From where to retrieve plugins. The standard Puppet file
type
is used for retrieval, so anything that is a valid file source can
be used here.
A command to run after every agent run. If this command returns a non-zero return code, the entire Puppet run will be considered to have failed, even though it might have performed work during the normal run.
The preferred means of serializing ruby instances for passing over the wire. This won’t guarantee that all instances will be serialized using this method, since not all classes can be guaranteed to support this format, but it will be used for all classes that support it.
A command to run before every agent run. If this command returns a non-zero return code, the entire Puppet run will fail.
The directory where catalog previews per node are generated.
The scheduling priority of the process. Valid values are ‘high’, ‘normal’, ‘low’, or ‘idle’, which are mapped to platform-specific values. The priority can also be specified as an integer value and will be passed as is, e.g. -5. Puppet must be running as a privileged user in order to increase scheduling priority.
Where the client stores private certificate information.
The private key directory.
Whether to enable experimental performance profiling
The public key directory.
Whether to print the Puppet stack trace on some errors.
This is a noop if trace
is also set.
The fallback log file. This is only used when the --logdest
option
is not specified AND Puppet is running on an operating system where both
the POSIX syslog service and the Windows Event Log are unavailable. (Currently,
no supported operating systems match that description.)
Despite the name, both puppet agent and puppet master will use this file as the fallback logging destination.
For control over logging destinations, see the --logdest
command line
option in the manual pages for puppet master, puppet agent, and puppet
apply. You can see man pages by running puppet <SUBCOMMAND> --help
,
or read them online at https://puppet.com/docs/puppet/latest/man/.
Whether to send reports after every transaction.
Whether the ‘http’ report processor should include the system certificate store when submitting reports to HTTPS URLs. If false, then the ‘http’ processor will only trust HTTPS report servers whose certificates are issued by the puppet CA or one of its intermediate CAs. If true, the processor will additionally trust CA certificates in the system’s certificate store.
The port to communicate with the report_server.
The server to send transaction reports to.
The directory in which to store reports. Each node gets
a separate subdirectory in this directory. This setting is only
used when the store
report processor is enabled (see the
reports
setting).
The list of report handlers to use. When using multiple report handlers,
their names should be comma-separated, with whitespace allowed. (For example,
reports = http, store
.)
This setting is relevant to puppet master and puppet apply. The puppet
master will call these report handlers with the reports it receives from
agent nodes, and puppet apply will call them with its own report. (In
all cases, the node applying the catalog must have report = true
.)
See the report reference for information on the built-in report
handlers; custom report handlers can also be loaded from modules.
(Report handlers are loaded from the lib directory, at
puppet/reports/NAME.rb
.)
The URL that reports should be forwarded to. This setting
is only used when the http
report processor is enabled (see the
reports
setting).
Where host certificate requests are stored.
The file in which puppet agent stores a list of the resources associated with the retrieved configuration.
The configuration file that defines the rights to the different
rest indirections. This can be used as a fine-grained authorization system for
puppet master
. The puppet master
command is deprecated and Puppet Server
uses its own auth.conf that must be placed within its configuration directory.
Whether to send updated facts after every transaction. By default puppet only submits facts at the beginning of the transaction before applying a catalog. Since puppet can modify the state of the system, the value of the facts may change after puppet finishes. Therefore, any facts stored in puppetdb may not be consistent until the agent next runs, typically in 30 minutes. If this feature is enabled, puppet will resubmit facts after applying its catalog, ensuring facts for the node stored in puppetdb are current. However, this will double the fact submission load on puppetdb, so it is disabled by default.
Enables having extended data in the catalog by storing them as a hash with the special key
__ptype
. When enabled, resource containing values of the data types Binary
, Regexp
,
SemVer
, SemVerRange
, Timespan
and Timestamp
, as well as instances of types derived
from Object
retain their data type.
The YAML file containing indirector route configuration.
Where Puppet PID files are kept.
How often puppet agent applies the catalog. Note that a runinterval of 0 means “run continuously” rather than “never run.” This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The maximum amount of time an agent run is allowed to take. A Puppet agent run that exceeds this timeout will be aborted. A value of 0 disables the timeout. Defaults to 1 hour. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
Where the serial number for certificates is stored.
The puppet master server to which the puppet agent should connect.
The directory in which serialized data is stored, usually in a subdirectory.
The list of puppet master servers to which the puppet agent should connect, in the order that they will be tried.
Whether to log and report a contextual diff when files are being replaced.
This causes partial file contents to pass through Puppet’s normal
logging and reporting system, so this setting should be used with
caution if you are sending Puppet’s reports to an insecure
destination. This feature currently requires the diff/lcs
Ruby
library.
Where the CA stores signed certificates.
Tags to use to filter resources. If this is set, then only resources not tagged with the specified tags will be applied. Values must be comma-separated.
The address the agent should use to initiate requests.
Whether to sleep for a random amount of time, ranging from
immediately up to its $splaylimit
, before performing its first agent run
after a service restart. After this period, the agent runs periodically
on its $runinterval
.
For example, assume a default 30-minute $runinterval
, splay
set to its
default of false
, and an agent starting at :00 past the hour. The agent
would check in every 30 minutes at :01 and :31 past the hour.
With splay
enabled, it waits any amount of time up to its $splaylimit
before its first run. For example, it might randomly wait 8 minutes,
then start its first run at :08 past the hour. With the $runinterval
at its default 30 minutes, its next run will be at :38 past the hour.
If you restart an agent’s puppet service with splay
enabled, it
recalculates its splay period and delays its first agent run after
restarting for this new period. If you simultaneously restart a group of
puppet agents with splay
enabled, their checkins to your puppet masters
can be distributed more evenly.
The maximum time to delay before an agent’s first run when
splay
is enabled. Defaults to the agent’s $runinterval
. The
splay
interval is random and recalculated each time the agent is started or
restarted. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The domain which will be queried to find the SRV records of servers to use.
Certificate authorities who issue server certificates. SSL servers will not be considered authentic unless they possess a certificate issued by an authority listed in this file. If this setting has no value then the Puppet master’s CA certificate (localcacert) will be used.
The header containing an authenticated client’s SSL DN.
This header must be set by the proxy to the authenticated client’s SSL
DN (e.g., /CN=puppet.puppetlabs.com
). Puppet will parse out the Common
Name (CN) from the Distinguished Name (DN) and use the value of the CN
field for authorization.
Note that the name of the HTTP header gets munged by the web server
common gateway interface: an HTTP_
prefix is added, dashes are converted
to underscores, and all letters are uppercased. Thus, to use the
X-Client-DN
header, this setting should be HTTP_X_CLIENT_DN
.
The header containing the status message of the client verification. This header must be set by the proxy to ‘SUCCESS’ if the client successfully authenticated, and anything else otherwise.
Note that the name of the HTTP header gets munged by the web server
common gateway interface: an HTTP_
prefix is added, dashes are converted
to underscores, and all letters are uppercased. Thus, to use the
X-Client-Verify
header, this setting should be
HTTP_X_CLIENT_VERIFY
.
A lock file to indicate that the ssl bootstrap process is currently in progress.
The setting is deprecated and has no effect. Ensure all root and
intermediate certificate authorities used to issue client certificates are
contained in the server’s cacert
file on the server.
Where SSL certificates are kept.
The directory where Puppet state is stored. Generally, this directory can be removed without causing harm (although it might result in spurious service restarts).
Where puppet agent and puppet master store state associated with the running configuration. In the case of puppet master, this file reflects the state discovered through interacting with clients.
How long the Puppet agent should cache when a resource was last checked or synced.
This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
A value of 0
or unlimited
will disable cache pruning.
This setting affects the usage of schedule
resources, as the information
about when a resource was last checked (and therefore when it needs to be
checked again) is stored in the statefile
. The statettl
needs to be
large enough to ensure that a resource will not trigger multiple times
during a schedule due to its entry expiring from the cache.
Whether to compile a static catalog,
which occurs only on a Puppet Server master when the code-id-command
and
code-content-command
settings are configured in its puppetserver.conf
file.
Whether to store each client’s configuration, including catalogs, facts, and related data. This also enables the import and export of resources in the Puppet language - a mechanism for exchange resources between nodes.
By default this uses the ‘puppetdb’ backend.
You can adjust the backend using the storeconfigs_backend setting.
Configure the backend terminus used for StoreConfigs. By default, this uses the PuppetDB store, which must be installed and configured before turning on StoreConfigs.
The strictness level of puppet. Allowed values are:
The strictness level is for both language semantics and runtime evaluation validation. In addition to controlling the behavior with this master switch some individual warnings may also be controlled by the disable_warnings setting.
No new validations will be added to a micro (x.y.z) release, but may be added in minor releases (x.y.0). In major releases it expected that most (if not all) strictness validation become standard behavior.
Whether the agent specified environment should be considered authoritative, causing the run to fail if the retrieved catalog does not match it.
Whether to only search for the complete hostname as it is in the certificate when searching for node information in the catalogs or to match dot delimited segments of the cert’s certname and the hostname, fqdn, and/or domain facts.
This setting is deprecated and will be removed in a future release.
Causes an evaluation error when referencing unknown variables. (This does not affect referencing variables that are explicitly set to undef).
Whether to print a transaction summary.
Checksum types supported by this agent for use in file resources of a static catalog. Values must be comma-separated. Valid types are md5, md5lite, sha256, sha256lite, sha384, sha512, sha224, sha1, sha1lite, mtime, ctime. Default is md5, sha256, sha384, sha512, sha224.
What syslog facility to use when logging to syslog. Syslog has a fixed list of valid facilities, and you must choose one of those; you cannot just make one up.
Tags to use to find resources. If this is set, then only resources tagged with the specified tags will be applied. Values must be comma-separated.
Turns on experimental support for tasks and plans in the puppet language. This is for internal API use only. Do not change this setting.
Whether to print stack traces on some errors. Will print internal Ruby stack trace interleaved with Puppet function frames.
Transactional storage file for persisting data between transactions for the purposes of infering information (such as corrective_change) on new data received.
The external trusted facts script to use. This setting’s value can be set to the path to an executable command that can produce external trusted facts. The command must:
For unknown or invalid nodes, exit with a non-zero exit code.
File that provides mapping between custom SSL oids and user-friendly names
Whether to only use the cached catalog rather than compiling a new catalog on every run. Puppet can be run with this enabled by default and then selectively disabled when a recompile is desired. Because a Puppet agent using cached catalogs does not contact the master for a new catalog, it also does not upload facts at the beginning of the Puppet run.
Whether the server will search for SRV records in DNS for the current domain.
Whether to use the cached configuration when the remote configuration will not compile. This option is useful for testing new configurations, where you want to fix the broken configuration rather than reverting to a known-good one.
The user Puppet Server will run as. Used to ensure the agent side processes (agent, apply, etc) create files and directories readable by Puppet Server when necessary.
Where Puppet stores dynamic and growing data. The default for this
setting is calculated specially, like confdir
_.
The directory containing vendored modules. These modules will
be used by all environments like those in the basemodulepath
. The only
difference is that modules in the basemodulepath
are pluginsynced, while
vendored modules are not
Whether or not to look for versioned environment directories,
symlinked from $environmentpath/<environment>
. This is an experimental
feature and should be used with caution.
How frequently puppet agent should ask for a signed certificate.
When starting for the first time, puppet agent will submit a certificate
signing request (CSR) to the server named in the ca_server
setting
(usually the puppet master); this may be autosigned, or may need to be
approved by a human, depending on the CA server’s configuration.
Puppet agent cannot apply configurations until its approved certificate is
available. Since the certificate may or may not be available immediately,
puppet agent will repeatedly try to fetch it at this interval. You can
turn off waiting for certificates by specifying a time of 0, or a maximum
amount of time to wait in the maxwaitforcert
setting, in which case
puppet agent will exit if it cannot get a cert.
This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
How frequently puppet agent should try running when there is an already ongoing puppet agent instance.
This argument is by default disabled (value set to 0). In this case puppet agent will
immediatly exit if it cannot run at that moment. When a value other than 0 is set, this
can also be used in combination with the maxwaitforlock
argument.
This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The directory in which YAML data is stored, usually in a subdirectory.