This page is autogenerated; any changes will get overwritten (last generated on 2016-01-15 16:31:41 +0100)
puppet.conf or on the
command line.--setting and
--no-setting instead of --setting (true|false).$variables in other settings; $environment
is special, in that puppet master will interpolate each agent node’s
environment instead of its own.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.
Permit hyphens (-) in variable names and issue deprecation warnings about
them. This setting should always be false; setting it to true
will cause subtle and wide-ranging bugs. It will be removed in a future version.
Hyphenated variables caused major problems in the language, but were allowed
between Puppet 2.7.3 and 2.7.14. If you used them during this window, we
apologize for the inconvenience — you can temporarily set this to true
in order to upgrade, and can rename your variables at your leisure. Please
revert it to false after you have renamed all affected variables.
Affects how we cache attempts to load Puppet ‘features’. If false, then
calls to Puppet.features.<feature>? will always attempt to load the
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 feature, and then later load that feature during the same run (even if
the feature had been tested earlier and had not been available).
If this setting is set to true, then 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 feature. This behavior is almost always appropriate for the server, and can result in a significant performance improvement for features that are checked frequently.
During an inspect run, the file bucket server to archive files to if archive_files is set.
During an inspect run, whether to archive files whose contents are audited to a file bucket.
Whether to use a queueing system to provide asynchronous database integration.
Requires that puppet queue be running.
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 puppet cert 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 ‘;’.)
If you are using directory environments, 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
http://docs.puppetlabs.com/puppet/latest/reference/environments.html
This setting also provides the default value for the deprecated modulepath
setting, which is used when directory environments are disabled.
The address a listening server should bind to.
Turns the binding system on or off. This includes bindings in modules. The binding system aggregates data from modules and other locations and makes them available for lookup. The binding system is experimental and any or all of it may change.
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.
Whether the master should function as a certificate authority.
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. Will be used if present but otherwise ignored.
The root directory for the certificate authority.
The CA private key.
Where the CA stores the password for the private key.
Where the CA stores private certificate information.
The CA public key.
How to store cached catalogs. Valid values are ‘json’, ‘msgpack’ and ‘yaml’. The agent application defaults to ‘json’.
(Deprecated for ‘preferred_serialization_format’) What format to use to dump the catalog. Only supports ‘marshal’ and ‘yaml’. Only matters on the client, since it asks the server for a specific format.
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.
The certdnsnames setting is no longer functional,
after CVE-2011-3872. We ignore the value completely.
For your own certificate request you can set dns_alt_names in the
configuration and it will apply locally. There is no configuration option to
set DNS alt names, or any other subjectAltName value, for another nodes
certificate.
Alternately you can use the --dns_alt_names command line option to set the
labels added while generating your own CSR.
The window of time leading up to a certificate’s expiration that a notification will be logged. This applies to CA, master, and agent certificates. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
Whether certificate revocation should be supported by downloading a Certificate Revocation List (CRL) to all clients. If enabled, CA chaining will almost definitely not work.
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 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.
Whether or not to use the native facter (cfacter) implementation instead of the Ruby one (facter). Defaults to false.
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.
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 deprecated. Please set a per-environment value in environment.conf instead. For more info, see http://docs.puppetlabs.com/puppet/latest/reference/environments.html
Print 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’.
How long the client should wait for the configuration to be retrieved before considering it a failure. This can help reduce flapping if too many clients contact the server at one time. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
The url where the puppet couchdb database will be created.
Only used when facts_terminus is set to couch.
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 puppet cert 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) or
“ppPrivCertExt” (1.3.6.1.4.1.34380.1.2) 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.
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).
Where to retrive information about data.
The type of database to use. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The number of database connections for networked databases. Will be ignored unless the value is a positive integer. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The sqlite database file. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
Whether to automatically migrate the database. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The name of the database to use. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The database password for caching. Only used when networked databases are used. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The database password for caching. Only used when networked databases are used. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The database server for caching. Only used when networked databases are used.
The database socket location. Only used when networked databases are used. Will be ignored if the value is an empty string. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
The database user for caching. Only used when networked databases are used. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
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.
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. Default is md5.
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.
Default: []
The comma-separated list of alternative DNS names to use for the local host.
When the node generates a CSR for itself, these are added to the request
as the desired subjectAltName in the certificate: additional DNS labels
that the certificate is also valid answering as.
This is generally required if you use a non-hostname certname, or if you
want to use puppet kick or puppet resource -H and the primary certname
does not match the DNS name you use to communicate with the host.
This is unnecessary for agents, unless you intend to use them as a server for
puppet kick or remote puppet resource management.
It is rarely necessary for servers; it is usually helpful only if you need to have a pool of multiple load balanced masters, or for the same master to respond on two physically separate networks under different names.
Whether to document all resources when using puppet doc to
generate manifest documentation.
(Deprecated) Facts that are dynamic; these facts will be ignored when deciding whether changed facts should result in a recompile. Multiple facts should be comma-separated.
The environment Puppet is running in. For clients
(e.g., puppet agent) this determines the environment itself, which
is used to find modules and much more. For servers (i.e., puppet master)
this provides the default environment for nodes we know nothing about.
How long the Puppet master should cache data it loads from an
environment.
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 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.restart.txt file to
refresh an application without restarting Apache; see the Passenger docs
for details.We don’t recommend using any value other than 0 or unlimited, since
most Puppet masters 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 $confdir/environments. For more details, see
http://docs.puppetlabs.com/puppet/latest/reference/environments.html
Whether each resource should log when it is being evaluated. This allows you to interactively see exactly what is being done.
An external command that can produce node information. The command’s output
must be a YAML dump of a hash, and that hash must have a classes key and/or
a parameters key, where classes is an array or hash and
parameters is a hash. For unknown nodes, the command should
exit with a non-zero exit code.
This command makes it straightforward to store your node mapping information in other data sources like databases.
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 templates) has changed on disk. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
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.
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 for the different configuration graphs. These dot files can be interpreted by tools like OmniGraffle or dot (which is part of ImageMagick).
Where to store dot-outputted graphs.
The group puppet master should run as.
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.
Where individual hosts store and look for their certificate requests.
Where individual hosts store and look for their private key.
Where individual hosts store and look for their public key.
Allow http compression in REST communication with the master. This setting might improve performance for agent -> master communications over slow WANs. Your puppet master needs to support compression (usually by activating some settings in a reverse-proxy in front of the puppet master, which rules out webrick). It is harmless to activate this settings if your master doesn’t support compression, but if it supports it, this setting might reduce performance on high-speed LANs.
Whether to write HTTP request and responses to stderr. This should never be used in a production environment.
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. 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.
Where the puppet agent web server logs.
Ignore cache and always recompile the configuration. This is useful for testing new configurations, where the local cache may in fact be stale even if the timestamps are up to date - if the facts change or if the server changes.
If true, allows the parser to continue without requiring
all files referenced with import statements to exist. This setting was primarily
designed for use with commit hooks for parse-checking.
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.
When true, also prevents $trusted and $facts from being overridden in any scope
The port to communicate with the inventory_server.
The server to send facts to.
Should usually be the same as the facts terminus
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. Only used if node_terminus is set to ldap.
The LDAP server. Only used if node_terminus is set to ldap.
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.
The serialization format to use when sending file_metadata query parameters. Older versions of puppet master expect certain query parameters to be serialized as yaml, which is deprecated.
This should almost always be false. It can be temporarily set to true to let agents using this Puppet version connect to a puppet master running Puppet 3.0.0 through 3.2.x.
Note that this is set to true automatically if the agent detects an older master, so should never need to be set explicitly.
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
Whether puppet agent should listen for
connections. If this is true, then puppet agent will accept incoming
REST API requests, subject to the default ACLs and the ACLs set in
the rest_authconfig file. Puppet agent can respond usefully to
requests on the run, facts, certificate, and resource endpoints.
Where each client stores the CA certificate.
Where puppet agent caches the local configuration. An extension indicating the cache format is added automatically.
Default logging level for messages from Puppet. Allowed values are:
crit
The directory in which to store log files
Whether Puppet should manage the owner, group, and mode of files it uses internally
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 deprecated. 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
http://docs.puppetlabs.com/puppet/latest/reference/environments.html
Used to build the default value of the manifest setting. Has no other purpose.
This setting is deprecated.
Where the puppet master web server saves its access log. This is only used when running a WEBrick puppet master. When puppet master is running under a Rack server like Passenger, that web server will have its own logging behavior.
This file is literally never used, although Puppet may create it
as an empty file. For more context, see the puppetdlog setting and
puppet master’s --logdest command line option.
This setting is deprecated and will be removed in a future version of Puppet.
The port for puppet master traffic. For puppet master, this is the port to listen on; for puppet agent, this is the port to make requests on. Both applications use this setting to get the 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.
Whether to create the necessary user and group that puppet agent will run as.
Extra module groups to request from the Puppet Forge
The module repository
The directory which the skeleton for module tool generate is stored.
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 deprecated. 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
http://docs.puppetlabs.com/puppet/latest/reference/environments.html
The name of the application, if we are running as one. The
default is essentially $0 without the path or .rb.
How to store cached nodes. Valid values are (none), ‘json’, ‘msgpack’, ‘yaml’ or write only yaml (‘write_only_yaml’). The master application defaults to ‘write_only_yaml’, all others to none.
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)
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.puppetlabs.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.puppetlabs.com/node_name_value for more information.
Where to find information about nodes.
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.
How unrelated resources should be ordered when applying a catalog.
Allowed values are title-hash, manifest, and random. This
setting affects puppet agent and puppet apply, but not puppet master.
title-hash (the default) will order resources randomly, but will use
the same order across runs and across nodes.manifest will use the order in which the resources were declared in
their manifest files.random will order resources randomly and change their order with each
run. This can work like a fuzzer for shaking out undeclared dependencies.Regardless of this setting’s value, Puppet will always obey explicit
dependencies set with the before/require/notify/subscribe metaparameters
and the ->/~> chaining arrows; this setting only affects the relative
ordering of unrelated resources.
Selects the parser to use for parsing puppet manifests (in puppet DSL
language/’.pp’ files). Available choices are current (the default)
and future.
The current parser means that the released version of the parser should
be used.
The future parser is a “time travel to the future” allowing early
exposure to new language features. What these features are will vary from
release to release and they may be invididually configurable.
Available Since Puppet 3.2.
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.
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.
Whether plugins should be synced with the central server.
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.
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 http://docs.puppetlabs.com/puppet/latest/reference/man/.
Which port puppet agent listens on.
Which type of queue to use for asynchronous processing. If your stomp server requires authentication, you can include it in the URI as long as your stomp client library is at least 1.1.1
Which type of queue to use for asynchronous processing.
The log level for Rails connections. The value must be
a valid log level within Rails. Production environments normally use info
and other environments normally use debug. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
Where Rails-specific logs are sent. This setting is only used by the ActiveRecord storeconfigs and inventory backends, which are deprecated.
Whether to send reports after every transaction.
The port to communicate with the report_server.
The serialization format to use when sending reports to the
report_server. Possible values are pson and yaml. This setting
affects puppet agent, but not puppet apply (which processes its own
reports).
This should almost always be set to pson. It can be temporarily set to
yaml to let agents using this Puppet version connect to a puppet master
running Puppet 3.0.0 through 3.2.x.
Note that this is set to ‘yaml’ automatically if the agent detects an older master, so should never need to be set explicitly.
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 ‘from’ email address for the reports.
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, tagmail.)
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).
The bit length of the certificates.
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 YAML file containing indirector route configuration.
The directory where RRD database files are stored. Directories for each reporting host will be created under this directory.
How often RRD should expect data. This should match how often the hosts report back to the server. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
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.” If you want puppet agent to never run, you should start
it with the --no-client option. This setting can be a time interval in seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).
Where to find the sendmail binary with which to send email.
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.
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.
The name by which we identify ourselves in SMTP HELO for reports.
If you send to a smtpserver which does strict HELO checking (as with Postfix’s
smtpd_helo_restrictions access controls), you may need to ensure this resolves.
The TCP port through which to send email reports.
The server through which to send email reports.
Whether to sleep for a pseudo-random (but consistent) amount of time before a run.
The maximum time to delay before runs. Defaults to being the same as the run interval. 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 inteface: 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 inteface: 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.
Certificate authorities who issue client certificates. SSL clients 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.
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.
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 ActiveRecord and an SQL database to store and query the data; this, in turn, will depend on Rails being available.
You can adjust the backend using the storeconfigs_backend setting.
Configure the backend terminus used for StoreConfigs. By default, this uses the ActiveRecord store, which directly talks to the database from within the Puppet Master process.
Whether to only search for the complete hostname as it is in the certificate when searching for node information in the catalogs.
Makes the parser raise errors when referencing unknown variables. (This does not affect referencing variables that are explicitly set to undef).
Flatten fact values to strings using #to_s. Means you can’t have arrays or hashes as fact values. (DEPRECATED) This option will be removed in Puppet 4.0.
Whether to print a transaction summary.
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.
The mapping between reporting tags and email addresses.
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.
Where Puppet looks for template files. Can be a list of colon-separated directories.
This setting is deprecated. Please put your templates in modules instead.
Boolean; whether Puppet should store only facts and exported resources in the storeconfigs
database. This will improve the performance of exported resources with the older
active_record backend, but will disable external tools that search the storeconfigs database.
Thinning catalogs is generally unnecessary when using PuppetDB to store catalogs.
Whether to print stack traces on some errors
Stores trusted node data in a hash called $trusted. When true also prevents $trusted from being overridden in any scope.
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.
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 master should run as.
Where Puppet stores dynamic and growing data. The default for this
setting is calculated specially, like confdir_.
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, 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).
The directory in which YAML data is stored, usually in a subdirectory.
Boolean; whether to use the zlib library
This page autogenerated on 2016-01-15 16:31:41 +0100