Configuration Reference -
This page is autogenerated; any changes will get overwritten (last generated on Wed Dec 30 19:31:12 -0500 2009)
Specifying Configuration Parameters
On The Command-Line
Every Puppet executable (with the exception of puppetdoc) accepts all of
the parameters below, but not all of the arguments make sense for every executable.
I have tried to be as thorough as possible in the descriptions of the
arguments, so it should be obvious whether an argument is appropriate or not.
These parameters can be supplied to the executables either as command-line
options or in the configuration file. For instance, the command-line
invocation below would set the configuration directory to /private/puppet:
$ puppetd --confdir=/private/puppet
Note that boolean options are turned on and off with a slightly different
syntax on the command line:
The invocations above will enable and disable, respectively, the storage of
the client configuration.
As mentioned above, the configuration parameters can also be stored in a
configuration file, located in the configuration directory. As root, the
default configuration directory is /etc/puppet, and as a regular user, the
default configuration directory is ~user/.puppet. As of 0.23.0, all
executables look for puppet.conf in their configuration directory
(although they previously looked for separate files). For example,
puppet.conf is located at /etc/puppet/puppet.conf as root and
~user/.puppet/puppet.conf as a regular user by default.
All executables will set any parameters set within the main section,
while each executable will also look for a section named for the executable
and load those parameters. For example, puppetd will look for a
section named puppetd, and puppetmasterd looks for a section
named puppetmasterd. This allows you to use a single configuration file
to customize the settings for all of your executables.
The file follows INI-style formatting. Here is an example of a very simple
If you're starting out with a fresh configuration, you may wish to let
the executable generate a template configuration file for you by invoking
the executable in question with the --genconfig command. The executable
will print a template configuration to standard output, which can be
redirected to a file like so:
$ puppetd --genconfig > /etc/puppet/puppet.conf
Note that this invocation will replace the contents of any pre-existing
puppet.conf file, so make a backup of your present config if it contains
Like the --genconfig argument, the executables also accept a --genmanifest
argument, which will generate a manifest that can be used to manage all of
Puppet's directories and files and prints it to standard output. This can
likewise be redirected to a file:
Puppet can also create user and group accounts for itself (one puppet group
and one puppet user) if it is invoked as root with the --mkusers argument:
$ puppetd --mkusers
The puppetd and puppetmasterd executables catch some signals for special
handling. Both daemons catch (SIGHUP), which forces the server to restart
tself. Predictably, interrupt and terminate (SIGINT and SIGTERM) will shut
down the server, whether it be an instance of puppetd or puppetmasterd.
Sending the SIGUSR1 signal to an instance of puppetd will cause it to
immediately begin a new configuration transaction with the server. This
signal has no effect on puppetmasterd.
Configuration Parameter Reference
Below is a list of all documented parameters. Not all of them are valid with all
Puppet executables, but the executables will ignore any inappropriate values.
Whether to use a queueing system to provide asynchronous database integration. Requires that puppetqd be running and that 'PSON' support for ruby be installed.
The configuration file that defines the rights to the different namespaces and methods. This can be used as a coarse-grained authorization system for both puppetd and puppetmasterd.
Whether log files should always flush to disk.
Whether to enable autosign. Valid values are true (which autosigns any key request, and is a very bad idea), false (which never autosigns any key request), and the path to a file, which uses that configuration file to determine which keys to sign.
The address a listening server should bind to. Mongrel servers default to 127.0.0.1 and WEBrick defaults to 0.0.0.0.
Where FileBucket files are stored.
Wether the master should function as a certificate authority.
How long a certificate should be valid. This parameter is deprecated, use ca_ttl instead
The type of hash used in certificates.
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; valid values must be an integer, optionally followed by one of the units 'y' (years of 365 days), 'd' (days), 'h' (hours), or 's' (seconds). The unit defaults to seconds. If this parameter is set, ca_days is ignored. Examples are '3600' (one hour) and '1825d', which is the same as '5y' (5 years)
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.
Whether matching in case statements and selectors should be case-sensitive. Case insensitivity is handled by downcasing all values before comparison.
(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.
A Complete listing of all certificates
The certificate directory.
The DNS names on the Server certificate as a colon-separated list. If it's anything other than an empty string, it will be used as an alias in the created certificate. By default, only the server gets an alias set up, and only for 'puppet'.
The name to use when handling certificates. Defaults to the fully qualified domain name.
The file in which puppetd stores a list of the classes associated with the retrieved configuration. Can be loaded in the separate puppet executable using the --loadclasses option.
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 (mostly used during testing with TextMate), and false, which produces no color.
The main Puppet configuration directory. The default for this parameter is calculated based on the user. If the process is runnig as root or the user that puppetmasterd 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 configuration file for puppetdoc.
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.
Print the value of a specific configuration parameter. If a parameter 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 feature is only available in Puppet versions higher than 0.18.4.
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.
Where the CA stores certificate requests
Send the process into the background. This is the default.
The type of database to use.
The database cache for client configurations. Used for querying within the language.
Whether to automatically migrate the database.
The name of the database to use.
The database password for Client caching. Only used when networked databases are used.
The database server for Client 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.
The database user for Client caching. Only used when networked databases are used.
Which diff command to use when printing differences between files.
Which arguments to pass to the diff command when printing differences between files.
Whether facts should be made all lowercase when sent to the server.
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., puppetd) this determines the environment itself, which is used to find modules and much more. For servers (i.e., puppetmasterd) this provides the default environment for nodes we know nothing about.
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 output must be a YAML dump of a hash, and that hash must have one or both of classes and parameters, where classes is an array and parameters is a hash. For unknown nodes, the commands 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 store facts that it pulls down from the central server.
Where Puppet should look for facts. Multiple directories should be colon-separated, like normal PATH variables.
What files to ignore when pulling down facts.
Default: .svn CVS
From where to retrieve facts. The standard Puppet file type is used for retrieval, so anything that is a valid file source can be used here.
Whether facts should be synced with the central server.
Where the fileserver configuration is stored.
The minimum time to wait (in seconds) 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.
Whether to just print a configuration to stdout and exit. Only makes sense when used interactively. Takes into account arguments specified on the CLI.
Whether to just print a manifest to stdout and exit. Only makes sense when used interactively. 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 puppetmasterd should run as.
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.
Boolean; wheter or not puppetd should validate the server SSL certificate against the request hostname.
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.
The HTTP proxy port to use for outgoing connections
Where the puppetd 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.
A parameter that can be used in commit hooks, since it enables you to parse-check a single file rather than requiring that all files exist.
Boolean; whether puppetd should ignore schedules. This is useful for initial puppetd runs.
The bit length of keys.
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 LDAP server. Only used if ldapnodes is enabled.
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.
Whether to use lexical scoping (vs. dynamic).
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 puppetd should listen for connections. If this is true, then by default only the runner server is started, which allows remote authorized and authenticated nodes to connect and trigger puppetd runs.
Where each client stores the CA certificate.
Where puppetd caches the local configuration. An extension indicating the cache format is added automatically.
The Puppet log directory.
Whether Puppet should manage the owner, group, and mode of files it uses internally
The entry-point manifest for puppetmasterd.
Where puppetmasterd looks for its manifests.
Where the puppetmasterd web server logs.
Where puppetmasterd logs. This is generally not used, since syslog is the default log destination.
Which port puppetmasterd listens on.
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 puppetd will run as.
The search path for modules as a colon-separated list of directories.
The name of the service, if we are running as one. The default is essentially $0 without the path or .rb.
How the puppetmaster 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)
Where to find information about nodes.
Whether puppetd should be run in noop mode.
Whether to validate parameters during parsing.
Just check the syntax of the manifests.
Where puppetd stores the password for its private key. Generally unused.
The shell search path. Defaults to whatever is inherited from the parent process.
The pid file
Where Puppet should store plugins that it pulls down from the central server.
What files to ignore when pulling down plugins.
Default: .svn CVS .git
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.
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.
Where the client stores private certificate information.
The private key directory.
The public key directory.
A lock file to temporarily stop puppetd from doing anything.
The log file for puppetd. This is generally not used.
Which port puppetd 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
The list of reports to generate. All reports are looked for in puppet/reports/<name>.rb, and multiple report names should be comma-separated (whitespace is okay).
(Deprecated for 'report_server') The server to which to send transaction reports.
The bit length of the certificates.
Where host certificate requests are stored.
The configuration file that defines the rights to the different rest indirections. This can be used as a fine-grained authorization system for puppetmasterd.
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.
Where Puppet PID files are kept.
How often puppetd applies the client configuration; in seconds.
Where to find the sendmail binary with which to send email.
Where the serial number for certificates is stored.
The server to which server puppetd should connect
The type of server to use. Currently supported options are webrick and mongrel. If you use mongrel, you will need a proxy in front of the process or processes, since Mongrel cannot speak SSL.
Whether to print a contextual diff when files are being replaced. The diff is printed on stdout, so this option is meaningless unless you are running Puppet interactively. This feature currently requires the diff/lcs Ruby library.
Where the CA stores signed certificates.
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.
The header containing an authenticated client's SSL DN. Only used with Mongrel. This header must be set by the proxy to the authenticated client's SSL DN (e.g., /CN=puppet.reductivelabs.com). See http://reductivelabs.com/puppet/trac/wiki/UsingMongrel for more information.
The header containing the status message of the client verification. Only used with Mongrel. This header must be set by the proxy to 'SUCCESS' if the client successfully authenticated, and anything else otherwise. See http://reductivelabs.com/puppet/trac/wiki/UsingMongrel for more information.
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 puppetd and puppetmasterd store state associated with the running configuration. In the case of puppetmasterd, this file reflects the state discovered through interacting with clients.
Whether to store each client's configuration. This requires ActiveRecord from Ruby on Rails.
Whether to only search for the complete hostname as it is in the certificate when searching for node information in the catalogs.
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-seperated directories.
Boolean; wether storeconfigs store in the database only the facts and exported resources. If true, then storeconfigs performance will be higher and still allow exported/collected resources, but other usage external to Puppet might not work
Whether to print stack traces on some errors
Whether to validate types during parsing.
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 puppetmasterd should run as.
Where Puppet stores dynamic and growing data. The default for this parameter is calculated specially, like confdir.
The directory in which YAML data is stored, usually in a subdirectory.
Boolean; whether to use the zlib library
This page autogenerated on Wed Dec 30 19:31:12 -0500 2009