1047 lines
257 KiB
XML
1047 lines
257 KiB
XML
<?xml version="1.0" encoding="ASCII"?>
|
|
<pptp:PuppetDistribution xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pptp="http://www.puppetlabs.com/geppetto/1.0.0/PPTP" description="Puppet Distribution" version="3.7.1" label="puppet">
|
|
<contents xsi:type="pptp:NameSpace" name="settings" reserved="true">
|
|
<contents xsi:type="pptp:TPVariable" name="*"/>
|
|
<contents xsi:type="pptp:TPVariable" name="allow_duplicate_certs" documentation="<p>Whether to allow a new certificate request to overwrite an existing certificate.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="archive_file_server" documentation="<p>During an inspect run, the file bucket server to archive files to if archive_files is set.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="archive_files" documentation="<p>During an inspect run, whether to archive files whose contents are audited to a file bucket.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="async_storeconfigs" documentation="<p>Whether to use a queueing system to provide asynchronous database integration. Requires that puppetqd be running and that ‘PSON’ support for ruby be installed.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="authconfig" documentation="<p>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 puppet agent and puppet master.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="autoflush" documentation="<p>Whether log files should always flush to disk.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="autosign" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="bindaddress" documentation="<p>The address a listening server should bind to.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="bucketdir" documentation="<p>Where FileBucket files are stored.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca" documentation="<p>Wether the master should function as a certificate authority.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca_days" documentation="<p>How long a certificate should be valid. This parameter is deprecated, use ca_ttl instead.</p>" deprecated="true"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca_md" documentation="<p>The type of hash used in certificates.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca_name" documentation="<p>The name to use the Certificate Authority certificate.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca_port" documentation="<p>The port to use for the certificate authority.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca_server" documentation="<p>The server to use for certificate authority requests. It’s a separate server because it cannot and does not need to horizontally scale.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ca_ttl" documentation="<p>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).</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="cacert" documentation="<p>The CA certificate.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="cacrl" documentation="<p>The certificate revocation list (CRL) for the CA. Will be used if present but otherwise ignored.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="cadir" documentation="<p>The root directory for the certificate authority.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="cakey" documentation="<p>The CA private key.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="capass" documentation="<p>Where the CA stores the password for the private key</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="caprivatedir" documentation="<p>Where the CA stores private certificate information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="capub" documentation="<p>The CA public key.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="catalog_format" documentation="<p>(Deprecated for ‘preferred<i>serialization</i>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.</p>" deprecated="true"/>
|
|
<contents xsi:type="pptp:TPVariable" name="catalog_terminus" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="cert_inventory" documentation="<p>A Complete listing of all certificates</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="certdir" documentation="<p>The certificate directory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="certdnsnames" documentation="<p>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’.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="certificate_revocation" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="certname" documentation="<p>The name to use when handling certificates. Defaults to the fully qualified domain name.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="classfile" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="client_datadir" documentation="<p>The directory in which serialized data is stored on the client.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="clientbucketdir" documentation="<p>Where FileBucket files are stored locally.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="clientyamldir" documentation="<p>The directory in which client-side YAML data is stored.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="code" documentation="<p>Code to parse directly. This is essentially only used by puppet, and should only be set if you’re writing your own Puppet executable.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="color" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="confdir" documentation="<p>The main Puppet configuration directory. The default for this parameter 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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="config" documentation="<p>The configuration file for doc.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="config_version" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="configprint" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="configtimeout" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="couchdb_url" documentation="<p>The url where the puppet couchdb database will be created</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="csrdir" documentation="<p>Where the CA stores certificate requests</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="daemonize" documentation="<p>Send the process into the background. This is the default.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbadapter" documentation="<p>The type of database to use.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbconnections" documentation="<p>The number of database connections for networked databases. Will be ignored unless the value is a positive integer.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dblocation" documentation="<p>The database cache for client configurations. Used for querying within the language.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbmigrate" documentation="<p>Whether to automatically migrate the database.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbname" documentation="<p>The name of the database to use.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbpassword" documentation="<p>The database password for caching. Only used when networked databases are used.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbport" documentation="<p>The database password for caching. Only used when networked databases are used.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbserver" documentation="<p>The database server for caching. Only used when networked databases are used.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbsocket" documentation="<p>The database socket location. Only used when networked databases are used. Will be ignored if the value is an empty string.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dbuser" documentation="<p>The database user for caching. Only used when networked databases are used.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="deviceconfig" documentation="<p>Path to the device config file for puppet device</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="devicedir" documentation="<p>The root directory of devices’ $vardir</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="diff" documentation="<p>Which diff command to use when printing differences between files.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="diff_args" documentation="<p>Which arguments to pass to the diff command when printing differences between files.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="document_all" documentation="<p>Document all resources</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="downcasefacts" documentation="<p>Whether facts should be made all lowercase when sent to the server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="dynamicfacts" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="environment" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="evaltrace" documentation="<p>Whether each resource should log when it is being evaluated. This allows you to interactively see exactly what is being done.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="external_nodes" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="factdest" documentation="<p>Where Puppet should store facts that it pulls down from the central server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="factpath" documentation="<p>Where Puppet should look for facts. Multiple directories should be colon-separated, like normal PATH variables.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="facts_terminus" documentation="<p>The node facts terminus.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="factsignore" documentation="<p>What files to ignore when pulling down facts.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="factsource" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="factsync" documentation="<p>Whether facts should be synced with the central server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="fileserverconfig" documentation="<p>Where the fileserver configuration is stored.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="filetimeout" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="freeze_main" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="genconfig" documentation="<p>Whether to just print a configuration to stdout and exit. Only makes sense when used interactively. Takes into account arguments specified on the CLI.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="genmanifest" documentation="<p>Whether to just print a manifest to stdout and exit. Only makes sense when used interactively. Takes into account arguments specified on the CLI.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="graph" documentation="<p>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).</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="graphdir" documentation="<p>Where to store dot-outputted graphs.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="group" documentation="<p>The group puppet master should run as.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="hostcert" documentation="<p>Where individual hosts store and look for their certificates.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="hostcrl" documentation="<p>Where the host’s certificate revocation list can be found. This is distinct from the certificate authority’s CRL.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="hostcsr" documentation="<p>Where individual hosts store and look for their certificate requests.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="hostprivkey" documentation="<p>Where individual hosts store and look for their private key.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="hostpubkey" documentation="<p>Where individual hosts store and look for their public key.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="http_compression" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="http_proxy_host" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="http_proxy_port" documentation="<p>The HTTP proxy port to use for outgoing connections</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="httplog" documentation="<p>Where the puppet agent web server logs.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ignorecache" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ignoreimport" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ignoreschedules" documentation="<p>Boolean; whether puppet agent should ignore schedules. This is useful for initial puppet agent runs.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="inventory_port" documentation="<p>The port to communicate with the inventory_server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="inventory_server" documentation="<p>The server to send facts to.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="inventory_terminus" documentation="<p>Should usually be the same as the facts terminus</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="keylength" documentation="<p>The bit length of keys.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="lastrunfile" documentation="<p>Where puppet agent stores the last run report summary in yaml format.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="lastrunreport" documentation="<p>Where puppet agent stores the last run report in yaml format.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapattrs" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapbase" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapclassattrs" documentation="<p>The LDAP attributes to use to define Puppet classes. Values should be comma-separated.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapnodes" documentation="<p>Whether to search for node configurations in LDAP. See http://projects.puppetlabs.com/projects/puppet/wiki/LDAP_Nodes for more information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapparentattr" documentation="<p>The attribute to use to define the parent node.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldappassword" documentation="<p>The password to use to connect to LDAP.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapport" documentation="<p>The LDAP port. Only used if ldapnodes is enabled.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapserver" documentation="<p>The LDAP server. Only used if ldapnodes is enabled.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapssl" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapstackedattrs" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapstring" documentation="<p>The search string used to find an LDAP node.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldaptls" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ldapuser" documentation="<p>The user to use to connect to LDAP. Must be specified as a full DN.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="lexical" documentation="<p>Whether to use lexical scoping (vs. dynamic).</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="libdir" documentation="<p>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</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="listen" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="localcacert" documentation="<p>Where each client stores the CA certificate.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="localconfig" documentation="<p>Where puppet agent caches the local configuration. An extension indicating the cache format is added automatically.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="logdir" documentation="<p>The Puppet log directory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="manage_internal_file_permissions" documentation="<p>Whether Puppet should manage the owner, group, and mode of files it uses internally</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="manifest" documentation="<p>The entry-point manifest for puppet master.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="manifestdir" documentation="<p>Where puppet master looks for its manifests.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="masterhttplog" documentation="<p>Where the puppet master web server logs.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="masterlog" documentation="<p>Where puppet master logs. This is generally not used, since syslog is the default log destination.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="masterport" documentation="<p>Which port puppet master listens on.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="maximum_uid" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="mkusers" documentation="<p>Whether to create the necessary user and group that puppet agent will run as.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="modulepath" documentation="<p>The search path for modules as a list of directories separated by the ‘:’ character.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="name" documentation="<p>The name of the application, if we are running as one. The default is essentially $0 without the path or .rb.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="node_name" documentation="<p>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)</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="node_name_fact" documentation="<p>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<i>name</i>value. Changing this setting also requires changes to the default auth.conf configuration on the Puppet Master. Please see http://links.puppetlabs.com/node<i>name</i>fact for more information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="node_name_value" documentation="<p>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<i>name</i>fact. Changing this setting also requires changes to the default auth.conf configuration on the Puppet Master. Please see http://links.puppetlabs.com/node<i>name</i>value for more information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="node_terminus" documentation="<p>Where to find information about nodes.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="noop" documentation="<p>Whether puppet agent should be run in noop mode.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="onetime" documentation="<p>Run the configuration once, rather than as a long-running daemon. This is useful for interactively running puppetd.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="passfile" documentation="<p>Where puppet agent stores the password for its private key. Generally unused.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="path" documentation="<p>The shell search path. Defaults to whatever is inherited from the parent process.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="pidfile" documentation="<p>The pid file</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="plugindest" documentation="<p>Where Puppet should store plugins that it pulls down from the central server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="pluginsignore" documentation="<p>What files to ignore when pulling down plugins.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="pluginsource" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="pluginsync" documentation="<p>Whether plugins should be synced with the central server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="postrun_command" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="preferred_serialization_format" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="prerun_command" documentation="<p>A command to run before every agent run. If this command returns a non-zero return code, the entire Puppet run will fail.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="privatedir" documentation="<p>Where the client stores private certificate information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="privatekeydir" documentation="<p>The private key directory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="publickeydir" documentation="<p>The public key directory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="puppetdlockfile" documentation="<p>A lock file to temporarily stop puppet agent from doing anything.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="puppetdlog" documentation="<p>The log file for puppet agent. This is generally not used.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="puppetport" documentation="<p>Which port puppet agent listens on.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="queue_source" documentation="<p>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</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="queue_type" documentation="<p>Which type of queue to use for asynchronous processing.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="rails_loglevel" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="railslog" documentation="<p>Where Rails-specific logs are sent</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="report" documentation="<p>Whether to send reports after every transaction.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="report_port" documentation="<p>The port to communicate with the report_server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="report_server" documentation="<p>The server to send transaction reports to.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="reportdir" documentation="<p>The directory in which to store reports received from the client. Each client gets a separate subdirectory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="reportfrom" documentation="<p>The ‘from’ email address for the reports.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="reports" documentation="<p>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).</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="reportserver" documentation="<p>(Deprecated for ‘report_server’) The server to which to send transaction reports.</p>" deprecated="true"/>
|
|
<contents xsi:type="pptp:TPVariable" name="reporturl" documentation="<p>The URL used by the http reports processor to send reports</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="req_bits" documentation="<p>The bit length of the certificates.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="requestdir" documentation="<p>Where host certificate requests are stored.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="resourcefile" documentation="<p>The file in which puppet agent stores a list of the resources associated with the retrieved configuration.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="rest_authconfig" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="route_file" documentation="<p>The YAML file containing indirector route configuration.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="rrddir" documentation="<p>The directory where RRD database files are stored. Directories for each reporting host will be created under this directory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="rrdinterval" documentation="<p>How often RRD should expect data. This should match how often the hosts report back to the server.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="run_mode" documentation="<p>The effective ‘run mode’ of the application: master, agent, or user.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="rundir" documentation="<p>Where Puppet PID files are kept.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="runinterval" documentation="<p>How often puppet agent applies the client configuration; in seconds. 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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="sendmail" documentation="<p>Where to find the sendmail binary with which to send email.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="serial" documentation="<p>Where the serial number for certificates is stored.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="server" documentation="<p>The server to which server puppet agent should connect</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="server_datadir" documentation="<p>The directory in which serialized data is stored, usually in a subdirectory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="servertype" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="show_diff" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="signeddir" documentation="<p>Where the CA stores signed certificates.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="smtpserver" documentation="<p>The server through which to send email reports.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="splay" documentation="<p>Whether to sleep for a pseudo-random (but consistent) amount of time before a run.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="splaylimit" documentation="<p>The maximum time to delay before runs. Defaults to being the same as the run interval.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ssl_client_header" documentation="<p>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.puppetlabs.com). See http://projects.puppetlabs.com/projects/puppet/wiki/Using_Mongrel for more information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ssl_client_verify_header" documentation="<p>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://projects.puppetlabs.com/projects/puppet/wiki/Using_Mongrel for more information.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="ssldir" documentation="<p>Where SSL certificates are kept.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="statedir" documentation="<p>The directory where Puppet state is stored. Generally, this directory can be removed without causing harm (although it might result in spurious service restarts).</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="statefile" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="storeconfigs" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="storeconfigs_backend" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="strict_hostname_checking" documentation="<p>Whether to only search for the complete hostname as it is in the certificate when searching for node information in the catalogs.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="summarize" documentation="<p>Whether to print a transaction summary.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="syslogfacility" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="tagmap" documentation="<p>The mapping between reporting tags and email addresses.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="tags" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="templatedir" documentation="<p>Where Puppet looks for template files. Can be a list of colon-seperated directories.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="thin_storeconfigs" documentation="<p>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</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="trace" documentation="<p>Whether to print stack traces on some errors</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="use_cached_catalog" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="usecacheonfailure" documentation="<p>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.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="user" documentation="<p>The user puppet master should run as.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="vardir" documentation="<p>Where Puppet stores dynamic and growing data. The default for this parameter is calculated specially, like confdir_.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="yamldir" documentation="<p>The directory in which YAML data is stored, usually in a subdirectory.</p>"/>
|
|
<contents xsi:type="pptp:TPVariable" name="zlib" documentation="<p>Boolean; whether to use the zlib library</p>"/>
|
|
</contents>
|
|
<contents xsi:type="pptp:TPVariable" name="environment" documentation="The node's current environment. Available when compiling a catalog for a node."/>
|
|
<contents xsi:type="pptp:TPVariable" name="clientcert" documentation="The node's certname setting. Available when compiling a catalog for a node."/>
|
|
<contents xsi:type="pptp:TPVariable" name="clientversion" documentation="The current version of the puppet agent. Available when compiling a catalog for a node."/>
|
|
<contents xsi:type="pptp:TPVariable" name="servername" documentation="The puppet master’s fully-qualified domain name. (Note that this information is gathered from the puppet master by Facter, rather than read from the config files; even if the master’s certname is set to something other than its fully-qualified domain name, this variable will still contain the server’s fqdn.)"/>
|
|
<contents xsi:type="pptp:TPVariable" name="serverip" documentation="The puppet master's IP address"/>
|
|
<contents xsi:type="pptp:TPVariable" name="serverversion" documentation="The current version of puppet on the puppet master."/>
|
|
<contents xsi:type="pptp:TPVariable" name="trusted" documentation="$trusted will automatically contain trusted node data in future versions"/>
|
|
<functions documentation="<p>Returns all matches throughout the hierarchy --- not just the first match --- as a flattened array of unique values. If any of the matched values are arrays, they're flattened and included in the results.</p><p>In addition to the required <tt>key</tt> argument, <tt>hiera_array</tt> accepts two additional arguments:</p><ul><li><p>a <tt>default</tt> argument in the second position, providing a string or array to be returned in the absence of matches to the <tt>key</tt> argument</p></li><li><p>an <tt>override</tt> argument in the third position, providing a data source to consult for matching values, even if it would not ordinarily be part of the matched hierarchy. If Hiera doesn't find a matching key in the named override data source, it will continue to search through the rest of the hierarchy.</p></li></ul><p>If any matched value is a hash, puppet will raise a type mismatch error.</p><p>More thorough examples of <tt>hiera</tt> are available at: <http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions></p>" name="hiera_array" rValue="true"/>
|
|
<functions documentation="<p>A boolean function that tells you whether the current container is tagged with the specified tags. The tags are ANDed, so that all of the specified tags must be included for the function to return true.</p>" name="tagged" rValue="true"/>
|
|
<functions documentation="<p>Assigns classes to a node using an array merge lookup that retrieves the value for a user-specified key from a Hiera data source.</p><p>To use <tt>hiera_include</tt>, the following configuration is required:</p><ul><li><p>A key name to use for classes, e.g. <tt>classes</tt>.</p></li><li><p>A line in the puppet <tt>sites.pp</tt> file (e.g. <tt>/etc/puppet/manifests/sites.pp</tt>) reading <tt>hiera_include('classes')</tt>. Note that this line must be outside any node definition and below any top-scope variables in use for Hiera lookups.</p></li><li><p>Class keys in the appropriate data sources. In a data source keyed to a node's role, one might have:</p></li></ul><pre> ---
 classes:
 - apache
 - apache::passenger

</pre><p>In addition to the required <tt>key</tt> argument, <tt>hiera_include</tt> accepts two additional arguments:</p><ul><li><p>a <tt>default</tt> argument in the second position, providing an array to be returned in the absence of matches to the <tt>key</tt> argument</p></li><li><p>an <tt>override</tt> argument in the third position, providing a data source to consult for matching values, even if it would not ordinarily be part of the matched hierarchy. If Hiera doesn't find a matching key in the named override data source, it will continue to search through the rest of the hierarchy.</p></li></ul><p>More thorough examples of <tt>hiera_include</tt> are available at: <http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions></p>" name="hiera_include"/>
|
|
<functions documentation="<p>Call a lambda code block with the given arguments. Since the parameters of the lambda are local to the lambda's scope, this can be used to create private sections of logic in a class so that the variables are not visible outside of the class.</p><p>Example:</p><pre> # notices the array [1, 2, 'foo']
 with(1, 2, 'foo') |$x, $y, $z| { notice [$x, $y, $z] }

</pre><ul><li><p>since 3.7.0</p></li><li><p>note requires future parser</p></li></ul>" name="with" rValue="true"/>
|
|
<functions documentation="<p>Fail with a parse error.</p>" name="fail"/>
|
|
<functions documentation="<p>Loads an ERB template from a module, evaluates it, and returns the resulting value as a string.</p><p>The argument to this function should be a <tt><MODULE NAME>/<TEMPLATE FILE></tt> reference, which will load <tt><TEMPLATE FILE></tt> from a module's <tt>templates</tt> directory. (For example, the reference <tt>apache/vhost.conf.erb</tt> will load the file <tt><MODULES DIRECTORY>/apache/templates/vhost.conf.erb</tt>.)</p><p>This function can also accept:</p><ul><li><p>An absolute path, which can load a template file from anywhere on disk.</p></li><li><p>Multiple arguments, which will evaluate all of the specified templates and</p></li></ul><p>return their outputs concatenated into a single string.</p>" name="template" rValue="true"/>
|
|
<functions documentation="<p>Applies a parameterized block to each element in a sequence of entries from the first argument (<i>the enumerable</i>) and returns the last result of the invocation of the parameterized block.</p><p>This function takes two mandatory arguments: the first should be an Array, Hash, or something of enumerable type, and the last a parameterized block as produced by the puppet syntax:</p><pre> $a.reduce |$memo, $x| { ... }
 reduce($a) |$memo, $x| { ... }

</pre><p>When the first argument is an Array or someting of an enumerable type, the block is called with each entry in turn. When the first argument is a hash each entry is converted to an array with <tt>[key, value]</tt> before being fed to the block. An optional 'start memo' value may be supplied as an argument between the array/hash and mandatory block.</p><pre> $a.reduce(start) |$memo, $x| { ... }
 reduce($a, start) |$memo, $x| { ... }

</pre><p>If no 'start memo' is given, the first invocation of the parameterized block will be given the first and second elements of the enumeration, and if the enumerable has fewer than 2 elements, the first element is produced as the result of the reduction without invocation of the block.</p><p>On each subsequent invocation, the produced value of the invoked parameterized block is given as the memo in the next invocation.</p><p>Example Using reduce</p><pre> # Reduce an array
 $a = [1,2,3]
 $a.reduce |$memo, $entry| { $memo + $entry }
 #=> 6

 # Reduce hash values
 $a = {a => 1, b => 2, c => 3}
 $a.reduce |$memo, $entry| { [sum, $memo[1]+$entry[1]] }
 #=> [sum, 6]

 # reverse a string
 "abc".reduce |$memo, $char| { "$char$memo" }
 #=>"cbe"

</pre><p>It is possible to provide a starting 'memo' as an argument.</p><p>Example Using reduce with given start 'memo'</p><pre> # Reduce an array
 $a = [1,2,3]
 $a.reduce(4) |$memo, $entry| { $memo + $entry }
 #=> 10

 # Reduce hash values
 $a = {a => 1, b => 2, c => 3}
 $a.reduce([na, 4]) |$memo, $entry| { [sum, $memo[1]+$entry[1]] }
 #=> [sum, 10]

</pre><p>Example Using reduce with an Integer range</p><pre> Integer[1,4].reduce |$memo, $x| { $memo + $x }
 #=> 10

</pre><ul><li><p>since 3.2 for Array and Hash</p></li><li><p>since 3.5 for additional enumerable types</p></li><li><p>note requires <tt>parser = future</tt>.</p></li></ul>" name="reduce" rValue="true"/>
|
|
<functions documentation="<p>Evaluates an Embedded Puppet Template (EPP) file and returns the rendered text result as a String.</p><p>The first argument to this function should be a <tt><MODULE NAME>/<TEMPLATE FILE></tt> reference, which will load <tt><TEMPLATE FILE></tt> from a module's <tt>templates</tt> directory. (For example, the reference <tt>apache/vhost.conf.epp</tt> will load the file <tt><MODULES DIRECTORY>/apache/templates/vhost.conf.epp</tt>.)</p><p>The second argument is optional; if present, it should be a hash containing parameters for the template. (See below.)</p><p>EPP supports the following tags:</p><ul><li><p><tt><%= puppet expression %></tt> - This tag renders the value of the expression it contains.</p></li><li><p><tt><% puppet expression(s) %></tt> - This tag will execute the expression(s) it contains, but renders nothing.</p></li><li><p><tt><%# comment %></tt> - The tag and its content renders nothing.</p></li><li><p><tt><%%</tt> or <tt>%%></tt> - Renders a literal <tt><%</tt> or <tt>%></tt> respectively.</p></li><li><p><tt><%-</tt> - Same as <tt><%</tt> but suppresses any leading whitespace.</p></li><li><p><tt>-%></tt> - Same as <tt>%></tt> but suppresses any trailing whitespace on the same line (including line break).</p></li><li><p><tt><%- |parameters| -%></tt> - When placed as the first tag declares the template's parameters.</p></li></ul><p>File based EPP supports the following visibilities of variables in scope:</p><ul><li><p>Global scope (i.e. top + node scopes) - global scope is always visible</p></li><li><p>Global + all given arguments - if the EPP template does not declare parameters, and arguments are given</p></li><li><p>Global + declared parameters - if the EPP declares parameters, given argument names must match</p></li></ul><p>EPP supports parameters by placing an optional parameter list as the very first element in the EPP. As an example, <tt><%- |$x, $y, $z = 'unicorn'| -%></tt> when placed first in the EPP text declares that the parameters <tt>x</tt> and <tt>y</tt> must be given as template arguments when calling <tt>inline_epp</tt>, and that <tt>z</tt> if not given as a template argument defaults to <tt>'unicorn'</tt>. Template parameters are available as variables, e.g.arguments <tt>$x</tt>, <tt>$y</tt> and <tt>$z</tt> in the example. Note that <tt><%-</tt> must be used or any leading whitespace will be interpreted as text</p><p>Arguments are passed to the template by calling <tt>epp</tt> with a Hash as the last argument, where parameters are bound to values, e.g. <tt>epp('...', {'x'=>10, 'y'=>20})</tt>. Excess arguments may be given (i.e. undeclared parameters) only if the EPP templates does not declare any parameters at all. Template parameters shadow variables in outer scopes. File based epp does never have access to variables in the scope where the <tt>epp</tt> function is called from.</p><ul><li><p>See function inline_epp for examples of EPP</p></li><li><p>Since 3.5</p></li><li><p>Requires Future Parser</p></li></ul>" name="epp" rValue="true"/>
|
|
<functions documentation="<p>Evaluate a template string and return its value. See [the templating docs](http://docs.puppetlabs.com/guides/templating.html) for more information. Note that if multiple template strings are specified, their output is all concatenated and returned as the output of the function.</p>" name="inline_template" rValue="true"/>
|
|
<functions documentation="<p>Add the specified tags to the containing class or definition. All contained objects will then acquire that tag, also.</p>" name="tag"/>
|
|
<functions documentation="<p>Applies a parameterized block to each element in a sequence of selected entries from the first argument and returns the first argument.</p><p>This function takes two mandatory arguments: the first should be an Array or a Hash or something that is of enumerable type (integer, Integer range, or String), and the second a parameterized block as produced by the puppet syntax:</p><pre> $a.each |$x| { ... }
 each($a) |$x| { ... }

</pre><p>When the first argument is an Array (or of enumerable type other than Hash), the parameterized block should define one or two block parameters. For each application of the block, the next element from the array is selected, and it is passed to the block if the block has one parameter. If the block has two parameters, the first is the elements index, and the second the value. The index starts from 0.</p><pre> $a.each |$index, $value| { ... }
 each($a) |$index, $value| { ... }

</pre><p>When the first argument is a Hash, the parameterized block should define one or two parameters. When one parameter is defined, the iteration is performed with each entry as an array of <tt>[key, value]</tt>, and when two parameters are defined the iteration is performed with key and value.</p><pre> $a.each |$entry| { ..."key ${$entry[0]}, value ${$entry[1]}" }
 $a.each |$key, $value| { ..."key ${key}, value ${value}" }

</pre><p>Example using each:</p><pre> [1,2,3].each |$val| { ... } # 1, 2, 3
 [5,6,7].each |$index, $val| { ... } # (0, 5), (1, 6), (2, 7)
 {a=>1, b=>2, c=>3}].each |$val| { ... } # ['a', 1], ['b', 2], ['c', 3]
 {a=>1, b=>2, c=>3}.each |$key, $val| { ... } # ('a', 1), ('b', 2), ('c', 3)
 Integer[ 10, 20 ].each |$index, $value| { ... } # (0, 10), (1, 11) ...
 "hello".each |$char| { ... } # 'h', 'e', 'l', 'l', 'o'
 3.each |$number| { ... } # 0, 1, 2

</pre><ul><li><p>since 3.2 for Array and Hash</p></li><li><p>since 3.5 for other enumerables</p></li><li><p>note requires <tt>parser = future</tt></p></li></ul>" name="each" rValue="true"/>
|
|
<functions documentation="<p>Add another namespace for this class to search. This allows you to create classes with sets of definitions and add those classes to another class's search path.</p><p>Deprecated in Puppet 3.7.0, to be removed in Puppet 4.0.0.</p>" name="search"/>
|
|
<functions documentation="<p>Loads a file from a module and returns its contents as a string.</p><p>The argument to this function should be a <tt><MODULE NAME>/<FILE></tt> reference, which will load <tt><FILE></tt> from a module's <tt>files</tt> directory. (For example, the reference <tt>mysql/mysqltuner.pl</tt> will load the file <tt><MODULES DIRECTORY>/mysql/files/mysqltuner.pl</tt>.)</p><p>This function can also accept:</p><ul><li><p>An absolute path, which can load a file from anywhere on disk.</p></li><li><p>Multiple arguments, which will return the contents of the <strong>first</strong> file</p></li></ul><p>found, skipping any files that don't exist.</p>" name="file" rValue="true"/>
|
|
<functions documentation="<p>This is a parser function to read data from external files, this version uses CSV files but the concept can easily be adjust for databases, yaml or any other queryable data source.</p><p>The object of this is to make it obvious when it's being used, rather than magically loading data in when a module is loaded I prefer to look at the code and see statements like:</p><pre> $snmp_contact = extlookup("snmp_contact")

</pre><p>The above snippet will load the snmp_contact value from CSV files, this in its own is useful but a common construct in puppet manifests is something like this:</p><pre> case $domain {
 "myclient.com": { $snmp_contact = "John Doe <john@myclient.com>" }
 default: { $snmp_contact = "My Support <support@my.com>" }
 }

</pre><p>Over time there will be a lot of this kind of thing spread all over your manifests and adding an additional client involves grepping through manifests to find all the places where you have constructs like this.</p><p>This is a data problem and shouldn't be handled in code, and using this function you can do just that.</p><p>First you configure it in site.pp:</p><pre> $extlookup_datadir = "/etc/puppet/manifests/extdata"
 $extlookup_precedence = ["%{fqdn}", "domain_%{domain}", "common"]

</pre><p>The array tells the code how to resolve values, first it will try to find it in web1.myclient.com.csv then in domain_myclient.com.csv and finally in common.csv</p><p>Now create the following data files in /etc/puppet/manifests/extdata:</p><pre> domain_myclient.com.csv:
 snmp_contact,John Doe <john@myclient.com>
 root_contact,support@%{domain}
 client_trusted_ips,192.168.1.130,192.168.10.0/24

 common.csv:
 snmp_contact,My Support <support@my.com>
 root_contact,support@my.com

</pre><p>Now you can replace the case statement with the simple single line to achieve the exact same outcome:</p><pre> $snmp_contact = extlookup("snmp_contact")

</pre><p>The above code shows some other features, you can use any fact or variable that is in scope by simply using %{varname} in your data files, you can return arrays by just having multiple values in the csv after the initial variable name.</p><p>In the event that a variable is nowhere to be found a critical error will be raised that will prevent your manifest from compiling, this is to avoid accidentally putting in empty values etc. You can however specify a default value:</p><pre> $ntp_servers = extlookup("ntp_servers", "1.${country}.pool.ntp.org")

</pre><p>In this case it will default to "1.${country}.pool.ntp.org" if nothing is defined in any data file.</p><p>You can also specify an additional data file to search first before any others at use time, for example:</p><pre> $version = extlookup("rsyslog_version", "present", "packages")
 package{"rsyslog": ensure => $version }

</pre><p>This will look for a version configured in packages.csv and then in the rest as configured by $extlookup_precedence if it's not found anywhere it will default to <tt>present</tt>, this kind of use case makes puppet a lot nicer for managing large amounts of packages since you do not need to edit a load of manifests to do simple things like adjust a desired version number.</p><p>Precedence values can have variables embedded in them in the form %{fqdn}, you could for example do:</p><pre> $extlookup_precedence = ["hosts/%{fqdn}", "common"]

</pre><p>This will result in /path/to/extdata/hosts/your.box.com.csv being searched.</p><p>This is for back compatibility to interpolate variables with %. % interpolation is a workaround for a problem that has been fixed: Puppet variable interpolation at top scope used to only happen on each run.</p>" name="extlookup" rValue="true"/>
|
|
<functions documentation="<p>Perform regexp replacement on a string or array of strings.</p><ul><li><p><b>Parameters</b> (in order):<pre>* _target_ The string or array of strings to operate on. If an array, the replacement will be performed on each of the elements in the array, and the return value will be an array.
* _regexp_ The regular expression matching the target string. If you want it anchored at the start and or end of the string, you must do that with ^ and $ yourself.
* _replacement_ Replacement string. Can contain backreferences to what was matched using \0 (whole match), \1 (first set of parentheses), and so on.
* _flags_ Optional. String of single letter flags for how the regexp is interpreted:
 - *E* Extended regexps
 - *I* Ignore case in regexps
 - *M* Multiline regexps
 - *G* Global replacement; all occurrences of the regexp in each target string will be replaced. Without this, only the first occurrence will be replaced.
* _encoding_ Optional. How to handle multibyte characters. A single-character string with the following values:
 - *N* None
 - *E* EUC
 - *S* SJIS
 - *U* UTF-8

</pre></p></li><li><p><b>Examples</b></p></li></ul><p>Get the third octet from the node's IP address:</p><pre> $i3 = regsubst($ipaddress,'^(\d+)\.(\d+)\.(\d+)\.(\d+)$','\3')

</pre><p>Put angle brackets around each octet in the node's IP address:</p><pre> $x = regsubst($ipaddress, '([0-9]+)', '<\1>', 'G')
</pre>" name="regsubst" rValue="true"/>
|
|
<functions documentation="<p>Returns a SHA1 hash value from a provided string.</p>" name="sha1" rValue="true"/>
|
|
<functions documentation="<p>Contain one or more classes inside the current class. If any of these classes are undeclared, they will be declared as if called with the <tt>include</tt> function. Accepts a class name, an array of class names, or a comma-separated list of class names.</p><p>A contained class will not be applied before the containing class is begun, and will be finished before the containing class is finished.</p><p>When the future parser is used, you must use the class's full name; relative names are no longer allowed. In addition to names in string form, you may also directly use Class and Resource Type values that are produced by the future parser's resource and relationship expressions.</p>" name="contain"/>
|
|
<functions documentation="<p>Evaluate one or more classes, adding the required class as a dependency.</p><p>The relationship metaparameters work well for specifying relationships between individual resources, but they can be clumsy for specifying relationships between classes. This function is a superset of the 'include' function, adding a class relationship so that the requiring class depends on the required class.</p><p>Warning: using require in place of include can lead to unwanted dependency cycles.</p><p>For instance the following manifest, with 'require' instead of 'include' would produce a nasty dependence cycle, because notify imposes a before between File[/foo] and Service[foo]:</p><pre> class myservice {
 service { foo: ensure => running }
 }

 class otherstuff {
 include myservice
 file { '/foo': notify => Service[foo] }
 }

</pre><p>Note that this function only works with clients 0.25 and later, and it will fail if used with earlier clients.</p><p>When the future parser is used, you must use the class's full name; relative names are no longer allowed. In addition to names in string form, you may also directly use Class and Resource Type values that are produced by the future parser's resource and relationship expressions.</p>" name="require"/>
|
|
<functions documentation="<p>Make a virtual object real. This is useful when you want to know the name of the virtual object and don't want to bother with a full collection. It is slightly faster than a collection, and, of course, is a bit shorter. You must pass the object using a reference; e.g.: <tt>realize User[luke]</tt>.</p>" name="realize"/>
|
|
<functions documentation="<p>Converts a hash into a set of resources and adds them to the catalog.</p><p>This function takes two mandatory arguments: a resource type, and a hash describing a set of resources. The hash should be in the form <tt>{title => {parameters} }</tt>:</p><pre> # A hash of user resources:
 $myusers = {
 'nick' => { uid => '1330',
 gid => allstaff,
 groups => ['developers', 'operations', 'release'], },
 'dan' => { uid => '1308',
 gid => allstaff,
 groups => ['developers', 'prosvc', 'release'], },
 }

 create_resources(user, $myusers)

</pre><p>A third, optional parameter may be given, also as a hash:</p><pre> $defaults = {
 'ensure' => present,
 'provider' => 'ldap',
 }

 create_resources(user, $myusers, $defaults)

</pre><p>The values given on the third argument are added to the parameters of each resource present in the set given on the second argument. If a parameter is present on both the second and third arguments, the one on the second argument takes precedence.</p><p>This function can be used to create defined resources and classes, as well as native resources.</p><p>Virtual and Exported resources may be created by prefixing the type name with @ or @@ respectively. For example, the $myusers hash may be exported in the following manner:</p><pre> create_resources("@@user", $myusers)

</pre><p>The $myusers may be declared as virtual resources using:</p><pre> create_resources("@user", $myusers)
</pre>" name="create_resources"/>
|
|
<functions documentation="<p>Calls an external command on the Puppet master and returns the results of the command. Any arguments are passed to the external command as arguments. If the generator does not exit with return code of 0, the generator is considered to have failed and a parse error is thrown. Generators can only have file separators, alphanumerics, dashes, and periods in them. This function will attempt to protect you from malicious generator calls (e.g., those with '..' in them), but it can never be entirely safe. No subshell is used to execute generators, so all shell metacharacters are passed directly to the generator.</p>" name="generate" rValue="true"/>
|
|
<functions documentation="<p>Returns the match result of matching a String or Array[String] with one of:</p><ul><li><p>Regexp</p></li><li><p>String - transformed to a Regexp</p></li><li><p>Pattern type</p></li><li><p>Regexp type</p></li></ul><p>Returns An Array with the entire match at index 0, and each subsequent submatch at index 1-n. If there was no match <tt>undef</tt> is returned. If the value to match is an Array, a array with mapped match results is returned.</p><p>Example matching:</p><pre>"abc123".match(/([a-z]+)[1-9]+/) # => ["abc"]
"abc123".match(/([a-z]+)([1-9]+)/) # => ["abc", "123"]

</pre><p>See the documentation for "The Puppet Type System" for more information about types.</p><ul><li><p>since 3.7.0</p></li><li><p>note requires future parser</p></li></ul>" name="match"/>
|
|
<functions documentation="<p>Declares one or more classes, causing the resources in them to be evaluated and added to the catalog. Accepts a class name, an array of class names, or a comma-separated list of class names.</p><p>The <tt>include</tt> function can be used multiple times on the same class and will only declare a given class once. If a class declared with <tt>include</tt> has any parameters, Puppet will automatically look up values for them in Hiera, using <tt><class name>::<parameter name></tt> as the lookup key.</p><p>Contrast this behavior with resource-like class declarations (<tt>class {'name': parameter => 'value',}</tt>), which must be used in only one place per class and can directly set parameters. You should avoid using both <tt>include</tt> and resource-like declarations with the same class.</p><p>The <tt>include</tt> function does not cause classes to be contained in the class where they are declared. For that, see the <tt>contain</tt> function. It also does not create a dependency relationship between the declared class and the surrounding class; for that, see the <tt>require</tt> function.</p><p>When the future parser is used, you must use the class's full name; relative names are no longer allowed. In addition to names in string form, you may also directly use Class and Resource Type values that are produced by the future parser's resource and relationship expressions.</p>" name="include"/>
|
|
<functions documentation="<p>Applies a parameterized block to each element in a sequence of entries from the first argument and returns an array with the result of each invocation of the parameterized block.</p><p>This function takes two mandatory arguments: the first should be an Array, Hash, or of Enumerable type (integer, Integer range, or String), and the second a parameterized block as produced by the puppet syntax:</p><pre> $a.map |$x| { ... }
 map($a) |$x| { ... }

</pre><p>When the first argument <tt>$a</tt> is an Array or of enumerable type, the block is called with each entry in turn. When the first argument is a hash the entry is an array with <tt>[key, value]</tt>.</p><p>Example Using map with two arguments</p><pre> # Turns hash into array of values
 $a.map |$x|{ $x[1] }

 # Turns hash into array of keys
 $a.map |$x| { $x[0] }

</pre><p>When using a block with 2 parameters, the element's index (starting from 0) for an array, and the key for a hash is given to the block's first parameter, and the value is given to the block's second parameter.args.</p><p>Example Using map with two arguments</p><pre> # Turns hash into array of values
 $a.map |$key,$val|{ $val }

 # Turns hash into array of keys
 $a.map |$key,$val|{ $key }

</pre><ul><li><p>since 3.4 for Array and Hash</p></li><li><p>since 3.5 for other enumerables, and support for blocks with 2 parameters</p></li><li><p>note requires <tt>parser = future</tt></p></li></ul>" name="map" rValue="true"/>
|
|
<functions documentation="<p>Returns a MD5 hash value from a provided string.</p>" name="md5" rValue="true"/>
|
|
<functions documentation="<p>Quote and concatenate arguments for use in Bourne shell.</p><p>Each argument is quoted separately, and then all are concatenated with spaces. If an argument is an array, the elements of that array is interpolated within the rest of the arguments; this makes it possible to have an array of arguments and pass that array to shellquote instead of having to specify each argument individually in the call.</p>" name="shellquote" rValue="true"/>
|
|
<functions documentation="<p>Split a string variable into an array using the specified split regexp.</p><p><b>Example:</b></p><pre> $string = 'v1.v2:v3.v4'
 $array_var1 = split($string, ':')
 $array_var2 = split($string, '[.]')
 $array_var3 = split($string, '[.:]')

</pre><p><tt>$array<i>var1</tt> now holds the result <tt>['v1.v2', 'v3.v4']</tt>, while <tt>$array</i>var2</tt> holds <tt>['v1', 'v2:v3', 'v4']</tt>, and <tt>$array_var3</tt> holds <tt>['v1', 'v2', 'v3', 'v4']</tt>.</p><p>Note that in the second example, we split on a literal string that contains a regexp meta-character (.), which must be escaped. A simple way to do that for a single character is to enclose it in square brackets; a backslash will also escape a single character.</p>" name="split" rValue="true"/>
|
|
<functions documentation="<p>Evaluates an Embedded Puppet Template (EPP) string and returns the rendered text result as a String.</p><p>EPP support the following tags:</p><ul><li><p><tt><%= puppet expression %></tt> - This tag renders the value of the expression it contains.</p></li><li><p><tt><% puppet expression(s) %></tt> - This tag will execute the expression(s) it contains, but renders nothing.</p></li><li><p><tt><%# comment %></tt> - The tag and its content renders nothing.</p></li><li><p><tt><%%</tt> or <tt>%%></tt> - Renders a literal <tt><%</tt> or <tt>%></tt> respectively.</p></li><li><p><tt><%-</tt> - Same as <tt><%</tt> but suppresses any leading whitespace.</p></li><li><p><tt>-%></tt> - Same as <tt>%></tt> but suppresses any trailing whitespace on the same line (including line break).</p></li><li><p><tt><%- |parameters| -%></tt> - When placed as the first tag declares the template's parameters.</p></li></ul><p>Inline EPP supports the following visibilities of variables in scope which depends on how EPP parameters are used - see further below:</p><ul><li><p>Global scope (i.e. top + node scopes) - global scope is always visible</p></li><li><p>Global + Enclosing scope - if the EPP template does not declare parameters, and no arguments are given</p></li><li><p>Global + all given arguments - if the EPP template does not declare parameters, and arguments are given</p></li><li><p>Global + declared parameters - if the EPP declares parameters, given argument names must match</p></li></ul><p>EPP supports parameters by placing an optional parameter list as the very first element in the EPP. As an example, <tt><%- |$x, $y, $z='unicorn'| -%></tt> when placed first in the EPP text declares that the parameters <tt>x</tt> and <tt>y</tt> must be given as template arguments when calling <tt>inline_epp</tt>, and that <tt>z</tt> if not given as a template argument defaults to <tt>'unicorn'</tt>. Template parameters are available as variables, e.g.arguments <tt>$x</tt>, <tt>$y</tt> and <tt>$z</tt> in the example. Note that <tt><%-</tt> must be used or any leading whitespace will be interpreted as text</p><p>Arguments are passed to the template by calling <tt>inline<i>epp</tt> with a Hash as the last argument, where parameters are bound to values, e.g. <tt>inline</i>epp('...', {'x'=>10, 'y'=>20})</tt>. Excess arguments may be given (i.e. undeclared parameters) only if the EPP templates does not declare any parameters at all. Template parameters shadow variables in outer scopes.</p><p>Note: An inline template is best stated using a single-quoted string, or a heredoc since a double-quoted string is subject to expression interpolation before the string is parsed as an EPP template. Here are examples (using heredoc to define the EPP text):</p><pre> # produces 'Hello local variable world!'
 $x ='local variable'
 inline_epptemplate(@(END:epp))
 <%- |$x| -%>
 Hello <%= $x %> world!
 END

 # produces 'Hello given argument world!'
 $x ='local variable world'
 inline_epptemplate(@(END:epp), { x =>'given argument'})
 <%- |$x| -%>
 Hello <%= $x %> world!
 END

 # produces 'Hello given argument world!'
 $x ='local variable world'
 inline_epptemplate(@(END:epp), { x =>'given argument'})
 <%- |$x| -%>
 Hello <%= $x %>!
 END

 # results in error, missing value for y
 $x ='local variable world'
 inline_epptemplate(@(END:epp), { x =>'given argument'})
 <%- |$x, $y| -%>
 Hello <%= $x %>!
 END

 # Produces 'Hello given argument planet'
 $x ='local variable world'
 inline_epptemplate(@(END:epp), { x =>'given argument'})
 <%- |$x, $y=planet| -%>
 Hello <%= $x %> <%= $y %>!
 END

</pre><ul><li><p>Since 3.5</p></li><li><p>Requires Future Parser</p></li></ul>" name="inline_epp" rValue="true"/>
|
|
<functions documentation="<p>Returns a hash value from a provided string using the digest_algorithm setting from the Puppet config file.</p>" name="digest" rValue="true"/>
|
|
<functions documentation="<p>Returns a merged hash of matches from throughout the hierarchy. In cases where two or more hashes share keys, the hierarchy order determines which key/value pair will be used in the returned hash, with the pair in the highest priority data source winning.</p><p>In addition to the required <tt>key</tt> argument, <tt>hiera_hash</tt> accepts two additional arguments:</p><ul><li><p>a <tt>default</tt> argument in the second position, providing a hash to be returned in the</p></li></ul><p>absence of any matches for the <tt>key</tt> argument<ul><li><p>an <tt>override</tt> argument in the third position, providing a data source to insert at</p></li></ul>the top of the hierarchy, even if it would not ordinarily match during a Hiera data source lookup. If Hiera doesn't find a match in the named override data source, it will continue to search through the rest of the hierarchy.</p><p><tt>hiera_hash</tt> expects that all values returned will be hashes. If any of the values found in the data sources are strings or arrays, puppet will raise a type mismatch error.</p><p>More thorough examples of <tt>hiera_hash</tt> are available at: <http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions></p>" name="hiera_hash" rValue="true"/>
|
|
<functions documentation="<p>Performs a standard priority lookup and returns the most specific value for a given key. The returned value can be data of any type (strings, arrays, or hashes).</p><p>In addition to the required <tt>key</tt> argument, <tt>hiera</tt> accepts two additional arguments:</p><ul><li><p>a <tt>default</tt> argument in the second position, providing a value to be returned in the absence of matches to the <tt>key</tt> argument</p></li><li><p>an <tt>override</tt> argument in the third position, providing a data source to consult for matching values, even if it would not ordinarily be part of the matched hierarchy. If Hiera doesn't find a matching key in the named override data source, it will continue to search through the rest of the hierarchy.</p></li></ul><p>More thorough examples of <tt>hiera</tt> are available at: <http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions></p>" name="hiera" rValue="true"/>
|
|
<functions documentation="<p>Usage: <tt>fqdn_rand(MAX, [SEED])</tt>. MAX is required and must be a positive integer; SEED is optional and may be any number or string.</p><p>Generates a random whole number greater than or equal to 0 and less than MAX, combining the <tt>$fqdn</tt> fact and the value of SEED for repeatable randomness. (That is, each node will get a different random number from this function, but a given node's result will be the same every time unless its hostname changes.)</p><p>This function is usually used for spacing out runs of resource-intensive cron tasks that run on many nodes, which could cause a thundering herd or degrade other services if they all fire at once. Adding a SEED can be useful when you have more than one such task and need several unrelated random numbers per node. (For example, <tt>fqdn<i>rand(30)</tt>, <tt>fqdn</i>rand(30, 'expensive job 1')</tt>, and <tt>fqdn_rand(30, 'expensive job 2')</tt> will produce totally different numbers.)</p>" name="fqdn_rand" rValue="true"/>
|
|
<functions documentation="<p>Returns the given value if it is an instance of the given type, and raises an error otherwise. Optionally, if a block is given (accepting two parameters), it will be called instead of raising an error. This to enable giving the user richer feedback, or to supply a default value.</p><p>Example: assert that <tt>$b</tt> is a non empty <tt>String</tt> and assign to <tt>$a</tt>:</p><pre>$a = assert_type(String[1], $b)

</pre><p>Example using custom error message:</p><pre>$a = assert_type(String[1], $b) |$expected, $actual| {
 fail('The name cannot be empty')
}

</pre><p>Example, using a warning and a default:</p><pre>$a = assert_type(String[1], $b) |$expected, $actual| {
 warning('Name is empty, using default')
 'anonymous'
}

</pre><p>See the documentation for 'The Puppet Type System' for more information about types.<ul><li><p>since Puppet 3.7</p></li><li><p>requires future parser/evaluator</p></li></ul></p>" name="assert_type" rValue="true"/>
|
|
<functions documentation="<p>Determine whether a given class or resource type is defined. This function can also determine whether a specific resource has been declared, or whether a variable has been assigned a value (including undef...as opposed to never having been assigned anything). Returns true or false. Accepts class names, type names, resource references, and variable reference strings of the form '$name'. When more than one argument is supplied, defined() returns true if any are defined.</p><p> The <tt>defined</tt> function checks both native and defined types, including types provided as plugins via modules. Types and classes are both checked using their names:</p><pre> defined("file")
 defined("customtype")
 defined("foo")
 defined("foo::bar")
 defined('$name')

</pre><p> Resource declarations are checked using resource references, e.g. <tt>defined( File['/tmp/myfile'] )</tt>. Checking whether a given resource has been declared is, unfortunately, dependent on the parse order of the configuration, and the following code will not work:</p><pre> if defined(File['/tmp/foo']) {
 notify { "This configuration includes the /tmp/foo file.":}
 }
 file { "/tmp/foo":
 ensure => present,
 }

</pre><p> However, this order requirement refers to parse order only, and ordering of resources in the configuration graph (e.g. with <tt>before</tt> or <tt>require</tt>) does not affect the behavior of <tt>defined</tt>.</p><p> If the future parser is in effect, you may also search using types:</p><pre> defined(Resource['file','/some/file'])
 defined(File['/some/file'])
 defined(Class['foo'])

</pre><ul><li><p>Since 2.7.0</p></li><li><p>Since 3.6.0 variable reference and future parser types</p></li></ul>" name="defined" rValue="true"/>
|
|
<functions documentation="<p>Compares two version numbers.</p><p>Prototype:</p><pre> $result = versioncmp(a, b)

</pre><p>Where a and b are arbitrary version strings.</p><p>This function returns:</p><ul><li><p><tt>1</tt> if version a is greater than version b</p></li><li><p><tt>0</tt> if the versions are equal</p></li><li><p><tt>-1</tt> if version a is less than version b</p></li></ul><p>Example:</p><pre> if versioncmp('2.6-1', '2.4.5') > 0 {
 notice('2.6-1 is > than 2.4.5')
 }

</pre><p>This function uses the same version comparison algorithm used by Puppet's <tt>package</tt> type.</p>" name="versioncmp" rValue="true"/>
|
|
<functions documentation="<p>Looks up data defined using Puppet Bindings and Hiera. The function is callable with one to three arguments and optionally with a code block to further process the result.</p><p>The lookup function can be called in one of these ways:</p><pre> lookup(name)
 lookup(name, type)
 lookup(name, type, default)
 lookup(options_hash)
 lookup(name, options_hash)

</pre><p>The function may optionally be called with a code block / lambda with the following signatures:</p><pre> lookup(...) |$result| { ... }
 lookup(...) |$name, $result| { ... }
 lookup(...) |$name, $result, $default| { ... }

</pre><p>The longer signatures are useful when the block needs to raise an error (it can report the name), or if it needs to know if the given default value was selected.</p><p>The code block receives the following three arguments:</p><ul><li><p>The <tt>$name</tt> is the last name that was looked up (<b>the</b> name if only one name was looked up)</p></li><li><p>The <tt>$result</tt> is the looked up value (or the default value if not found).</p></li><li><p>The <tt>$default</tt> is the given default value (<tt>undef</tt> if not given).</p></li></ul><p>The block, if present, is called with the result from the lookup. The value produced by the block is also what is produced by the <tt>lookup</tt> function. When a block is used, it is the users responsibility to call <tt>error</tt> if the result does not meet additional criteria, or if an undef value is not acceptable. If a value is not found, and a default has been specified, the default value is given to the block.</p><p>The content of the options hash is:</p><ul><li><p><tt>name</tt> - The name or array of names to lookup (first found is returned)</p></li><li><p><tt>type</tt> - The type to assert (a Type or a type specification in string form)</p></li><li><p><tt>default</tt> - The default value if there was no value found (must comply with the data type)</p></li><li><p><tt>accept_undef</tt> - (default <tt>false</tt>) An <tt>undef</tt> result is accepted if this options is set to <tt>true</tt>.</p></li><li><p><tt>override</tt> - a hash with map from names to values that are used instead of the underlying bindings. If the name is found here it wins. Defaults to an empty hash.</p></li><li><p><tt>extra</tt> - a hash with map from names to values that are used as a last resort to obtain a value. Defaults to an empty hash.</p></li></ul><p>When the call is on the form <tt>lookup(name, options<i>hash)</tt>, or <tt>lookup(name, type, options</i>hash)</tt>, the given name argument wins over the <tt>options_hash['name']</tt>.</p><p>The search order is <tt>override</tt> (if given), then <tt>binder</tt>, then <tt>hiera</tt> and finally <tt>extra</tt> (if given). The first to produce a value other than undef for a given name wins.</p><p>The type specification is one of:</p><pre>* A type in the Puppet Type System, e.g.:
 * `Integer`, an integral value with optional range e.g.:
 * `Integer[0, default]` - 0 or positive
 * `Integer[default, -1]` - negative,
 * `Integer[1,100]` - value between 1 and 100 inclusive
 * `String`- any string
 * `Float` - floating point number (same signature as for Integer for `Integer` ranges)
 * `Boolean` - true of false (strict)
 * `Array` - an array (of Data by default), or parameterized as `Array[<element_type>]`, where
 `<element_type>` is the expected type of elements
 * `Hash`, - a hash (of default `Literal` keys and `Data` values), or parameterized as
 `Hash[<value_type>]`, `Hash[<key_type>, <value_type>]`, where `<key_type>`, and
 `<value_type>` are the types of the keys and values respectively
 (key is `Literal` by default).
 * `Data` - abstract type representing any `Literal`, `Array[Data]`, or `Hash[Literal, Data]`
 * `Pattern[<p1>, <p2>, ..., <pn>]` - an enumeration of valid patterns (one or more) where
 a pattern is a regular expression string or regular expression,
 e.g. `Pattern['.com$', '.net$']`, `Pattern[/[a-z]+[0-9]+/]`
 * `Enum[<s1>, <s2>, ..., <sn>]`, - an enumeration of exact string values (one or more)
 e.g. `Enum[blue, red, green]`.
 * `Variant[<t1>, <t2>,...<tn>]` - matches one of the listed types (at least one must be given)
 e.g. `Variant[Integer[8000,8999], Integer[20000, 99999]]` to accept a value in either range
 * `Regexp`- a regular expression (i.e. the result is a regular expression, not a string
 matching a regular expression).
* A string containing a type description - one of the types as shown above but in string form.

</pre><p>If the function is called without specifying a default value, and nothing is bound to the given name an error is raised unless the option <tt>accept_undef</tt> is true. If a block is given it must produce an acceptable value (or call <tt>error</tt>). If the block does not produce an acceptable value an error is raised.</p><p>Examples:</p><p>When called with one argument; <strong>the name</strong>, it returns the bound value with the given name after having asserted it has the default datatype <tt>Data</tt>:</p><pre> lookup('the_name')

</pre><p>When called with two arguments; <strong>the name</strong>, and <strong>the expected type</strong>, it returns the bound value with the given name after having asserted it has the given data type ('String' in the example):</p><pre> lookup('the_name', 'String') # 3.x
 lookup('the_name', String) # parser future

</pre><p>When called with three arguments, <strong>the name</strong>, the <strong>expected type</strong>, and a <strong>default</strong>, it returns the bound value with the given name, or the default after having asserted the value has the given data type (<tt>String</tt> in the example above):</p><pre> lookup('the_name', 'String', 'Fred') # 3x
 lookup('the_name', String, 'Fred') # parser future

</pre><p>Using a lambda to process the looked up result - asserting that it starts with an upper case letter:</p><pre> # only with parser future
 lookup('the_size', Integer[1,100]) |$result| {
 if $large_value_allowed and $result > 10
 { error 'Values larger than 10 are not allowed'}
 $result
 }

</pre><p>Including the name in the error</p><pre> # only with parser future
 lookup('the_size', Integer[1,100]) |$name, $result| {
 if $large_value_allowed and $result > 10
 { error 'The bound value for '${name}' can not be larger than 10 in this configuration'}
 $result
 }

</pre><p>When using a block, the value it produces is also asserted against the given type, and it may not be <tt>undef</tt> unless the option <tt>'accept_undef'</tt> is <tt>true</tt>.</p><p>All options work as the corresponding (direct) argument. The <tt>first<i>found</tt> option and <tt>accept</i>undef</tt> are however only available as options.</p><p>Using first_found semantics option to return the first name that has a bound value:</p><pre> lookup(['apache::port', 'nginx::port'], 'Integer', 80)

</pre><p>If you want to make lookup return undef when no value was found instead of raising an error:</p><pre> $are_you_there = lookup('peekaboo', { accept_undef => true} )
 $are_you_there = lookup('peekaboo', { accept_undef => true}) |$result| { $result }
</pre>" name="lookup" rValue="true"/>
|
|
<functions documentation="<p>Perform printf-style formatting of text.</p><p>The first parameter is format string describing how the rest of the parameters should be formatted. See the documentation for the <tt>Kernel::sprintf</tt> function in Ruby for all the details.</p>" name="sprintf" rValue="true"/>
|
|
<functions documentation="<p>Applies a parameterized block to each element in a sequence of entries from the first argument and returns an array or hash (same type as left operand for array/hash, and array for other enumerable types) with the entries for which the block evaluates to <tt>true</tt>.</p><p> This function takes two mandatory arguments: the first should be an Array, a Hash, or an Enumerable object (integer, Integer range, or String), and the second a parameterized block as produced by the puppet syntax:</p><pre> $a.filter |$x| { ... }
 filter($a) |$x| { ... }

</pre><p> When the first argument is something other than a Hash, the block is called with each entry in turn. When the first argument is a Hash the entry is an array with <tt>[key, value]</tt>.</p><p> Example Using filter with one parameter</p><pre> # selects all that end with berry
 $a = ["raspberry", "blueberry", "orange"]
 $a.filter |$x| { $x =~ /berry$/ } # rasberry, blueberry

</pre><p> If the block defines two parameters, they will be set to <tt>index, value</tt> (with index starting at 0) for all enumerables except Hash, and to <tt>key, value</tt> for a Hash.</p><p>Example Using filter with two parameters</p><pre> # selects all that end with 'berry' at an even numbered index
 $a = ["raspberry", "blueberry", "orange"]
 $a.filter |$index, $x| { $index % 2 == 0 and $x =~ /berry$/ } # raspberry

 # selects all that end with 'berry' and value >= 1
 $a = {"raspberry"=>0, "blueberry"=>1, "orange"=>1}
 $a.filter |$key, $x| { $x =~ /berry$/ and $x >= 1 } # blueberry

</pre><ul><li><p>since 3.4 for Array and Hash</p></li><li><p>since 3.5 for other enumerables</p></li><li><p>note requires <tt>parser = future</tt></p></li></ul>" name="filter"/>
|
|
<functions documentation="<p>Applies a parameterized block to each <i>slice</i> of elements in a sequence of selected entries from the first argument and returns the first argument, or if no block is given returns a new array with a concatenation of the slices.</p><p>This function takes two mandatory arguments: the first, <tt>$a</tt>, should be an Array, Hash, or something of enumerable type (integer, Integer range, or String), and the second, <tt>$n</tt>, the number of elements to include in each slice. The optional third argument should be a a parameterized block as produced by the puppet syntax:</p><pre> $a.slice($n) |$x| { ... }
 slice($a) |$x| { ... }

</pre><p>The parameterized block should have either one parameter (receiving an array with the slice), or the same number of parameters as specified by the slice size (each parameter receiving its part of the slice). In case there are fewer remaining elements than the slice size for the last slice it will contain the remaining elements. When the block has multiple parameters, excess parameters are set to undef for an array or enumerable type, and to empty arrays for a Hash.</p><pre> $a.slice(2) |$first, $second| { ... }

</pre><p>When the first argument is a Hash, each <tt>key,value</tt> entry is counted as one, e.g, a slice size of 2 will produce an array of two arrays with key, and value.</p><p>Example Using slice with Hash</p><pre> $a.slice(2) |$entry| { notice "first ${$entry[0]}, second ${$entry[1]}" }
 $a.slice(2) |$first, $second| { notice "first ${first}, second ${second}" }

</pre><p>When called without a block, the function produces a concatenated result of the slices.</p><p>Example Using slice without a block</p><pre> slice([1,2,3,4,5,6], 2) # produces [[1,2], [3,4], [5,6]]
 slice(Integer[1,6], 2) # produces [[1,2], [3,4], [5,6]]
 slice(4,2) # produces [[0,1], [2,3]]
 slice('hello',2) # produces [[h, e], [l, l], [o]]

</pre><ul><li><p>since 3.2 for Array and Hash</p></li><li><p>since 3.5 for additional enumerable types</p></li><li><p>note requires <tt>parser = future</tt>.</p></li></ul>" name="slice" rValue="true"/>
|
|
<functions documentation="<p>Log a message on the server at level debug.</p>" name="debug"/>
|
|
<functions documentation="<p>Log a message on the server at level info.</p>" name="info"/>
|
|
<functions documentation="<p>Log a message on the server at level notice.</p>" name="notice"/>
|
|
<functions documentation="<p>Log a message on the server at level warning.</p>" name="warning"/>
|
|
<functions documentation="<p>Log a message on the server at level err.</p>" name="err"/>
|
|
<functions documentation="<p>Log a message on the server at level alert.</p>" name="alert"/>
|
|
<functions documentation="<p>Log a message on the server at level emerg.</p>" name="emerg"/>
|
|
<functions documentation="<p>Log a message on the server at level crit.</p>" name="crit"/>
|
|
<types name="host" documentation="<p>Installs and manages host entries. For most systems, these entries will just be in <tt>/etc/hosts</tt>, but some systems (notably OS X) will have different solutions.</p>">
|
|
<properties name="target" documentation="<p>The file in which to store service information. Only used by those providers that write to disk. On most systems this defaults to <tt>/etc/hosts</tt>.</p>"/>
|
|
<properties name="comment" documentation="<p>A comment that will be attached to the line with a # character.</p>"/>
|
|
<properties name="host_aliases" documentation="<p>Any aliases the host might have. Multiple values must be specified as an array.</p>"/>
|
|
<properties name="ip" documentation="<p>The host's IP address, IPv4 or IPv6.</p>"/>
|
|
<parameters name="name" documentation="<p>The host name.</p>" namevar="true"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="ssh_authorized_key" documentation="<p>Manages SSH authorized keys. Currently only type 2 keys are supported.</p><p>In their native habitat, SSH keys usually appear as a single long line. This resource type requires you to split that line into several attributes. Thus, a key that appears in your <tt>~/.ssh/id_rsa.pub</tt> file like this...</p><pre> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAy5mtOAMHwA2ZAIfW6Ap70r+I4EclYHEec5xIN59ROUjss23Skb1OtjzYpVPaPH8mSdSmsN0JHaBLiRcu7stl4O8D8zA4mz/vw32yyQ/Kqaxw8l0K76k6t2hKOGqLTY4aFbFISV6GDh7MYLn8KU7cGp96J+caO5R5TqtsStytsUhSyqH+iIDh4e4+BrwTc6V4Y0hgFxaZV5d18mLA4EPYKeG5+zyBCVu+jueYwFqM55E0tHbfiaIN9IzdLV+7NEEfdLkp6w2baLKPqWUBmuvPF1Mn3FwaFLjVsMT3GQeMue6b3FtUdTDeyAYoTxrsRo/WnDkS6Pa3YhrFwjtUqXfdaQ== nick@magpie.puppetlabs.lan

</pre><p>...would translate to the following resource:</p><pre> ssh_authorized_key { 'nick@magpie.puppetlabs.lan':
 user => 'nick',
 type => 'ssh-rsa',
 key => 'AAAAB3NzaC1yc2EAAAABIwAAAQEAy5mtOAMHwA2ZAIfW6Ap70r+I4EclYHEec5xIN59ROUjss23Skb1OtjzYpVPaPH8mSdSmsN0JHaBLiRcu7stl4O8D8zA4mz/vw32yyQ/Kqaxw8l0K76k6t2hKOGqLTY4aFbFISV6GDh7MYLn8KU7cGp96J+caO5R5TqtsStytsUhSyqH+iIDh4e4+BrwTc6V4Y0hgFxaZV5d18mLA4EPYKeG5+zyBCVu+jueYwFqM55E0tHbfiaIN9IzdLV+7NEEfdLkp6w2baLKPqWUBmuvPF1Mn3FwaFLjVsMT3GQeMue6b3FtUdTDeyAYoTxrsRo/WnDkS6Pa3YhrFwjtUqXfdaQ==',
 }

</pre><p>To ensure that only the currently approved keys are present, you can purge unmanaged SSH keys on a per-user basis. Do this with the <tt>user</tt> resource type's <tt>purge<i>ssh</i>keys</tt> attribute:</p><pre> user { 'nick':
 ensure => present,
 purge_ssh_keys => true,
 }

</pre><p>This will remove any keys in <tt>~/.ssh/authorized<i>keys</tt> that aren't being managed with <tt>ssh</i>authorized_key</tt> resources. See the documentation of the <tt>user</tt> type for more details.</p><p><strong>Autorequires:</strong> If Puppet is managing the user account in which this SSH key should be installed, the <tt>ssh<i>authorized</i>key</tt> resource will autorequire that user.</p>">
|
|
<properties name="target" documentation="<p>The absolute filename in which to store the SSH key. This property is optional and should only be used in cases where keys are stored in a non-standard location (i.e.<tt> not in </tt>~user/.ssh/authorized_keys`).</p>"/>
|
|
<properties name="type" documentation="<p>The encryption type used.</p>"/>
|
|
<properties name="user" documentation="<p>The user account in which the SSH key should be installed. The resource will autorequire this user if it is being managed as a <tt>user</tt> resource.</p>"/>
|
|
<properties name="key" documentation="<p>The public key itself; generally a long string of hex characters. The <tt>key</tt> attribute may not contain whitespace.</p><p>Make sure to omit the following in this attribute (and specify them in other attributes):</p><ul><li><p>Key headers (e.g. 'ssh-rsa') --- put these in the <tt>type</tt> attribute.</p></li><li><p>Key identifiers / comments (e.g. 'joe@joescomputer.local') --- put these in the <tt>name</tt> attribute/resource title.</p></li></ul>"/>
|
|
<properties name="options" documentation="<p>Key options; see sshd(8) for possible values. Multiple values should be specified as an array.</p>"/>
|
|
<parameters name="name" documentation="<p>The SSH key comment. This attribute is currently used as a system-wide primary key and therefore has to be unique.</p>" namevar="true"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="zone" documentation="<p>Manages Solaris zones.</p><p><strong>Autorequires:</strong> If Puppet is managing the directory specified as the root of the zone's filesystem (with the <tt>path</tt> attribute), the zone resource will autorequire that directory.</p>">
|
|
<properties name="shares" documentation="<p>Number of FSS CPU shares allocated to the zone.</p>"/>
|
|
<properties name="dataset" documentation="<p>The list of datasets delegated to the non-global zone from the global zone. All datasets must be zfs filesystem names which are different from the mountpoint.</p>"/>
|
|
<properties name="pool" documentation="<p>The resource pool for this zone.</p>"/>
|
|
<properties name="autoboot" documentation="<p>Whether the zone should automatically boot.</p>"/>
|
|
<properties name="path" documentation="<p>The root of the zone's filesystem. Must be a fully qualified file name. If you include <tt>%s</tt> in the path, then it will be replaced with the zone's name. Currently, you cannot use Puppet to move a zone. Consequently this is a readonly property.</p>"/>
|
|
<properties name="inherit" documentation="<p>The list of directories that the zone inherits from the global zone. All directories must be fully qualified.</p>"/>
|
|
<properties name="iptype" documentation="<p>The IP stack type of the zone.</p>"/>
|
|
<properties name="ip" documentation="<p>The IP address of the zone. IP addresses <strong>must</strong> be specified with an interface, and may optionally be specified with a default router (sometimes called a defrouter). The interface, IP address, and default router should be separated by colons to form a complete IP address string. For example: <tt>bge0:192.168.178.200</tt> would be a valid IP address string without a default router, and <tt>bge0:192.168.178.200:192.168.178.1</tt> adds a default router to it.</p><p>For zones with multiple interfaces, the value of this attribute should be an array of IP address strings (each of which must include an interface and may include a default router).</p>"/>
|
|
<parameters name="id" documentation="<p>The numerical ID of the zone. This number is autogenerated and cannot be changed.</p>"/>
|
|
<parameters name="create_args" documentation="<p>Arguments to the <tt>zonecfg</tt> create command. This can be used to create branded zones.</p>"/>
|
|
<parameters name="clone" documentation="<p>Instead of installing the zone, clone it from another zone. If the zone root resides on a zfs file system, a snapshot will be used to create the clone; if it resides on a ufs filesystem, a copy of the zone will be used. The zone from which you clone must not be running.</p>"/>
|
|
<parameters name="install_args" documentation="<p>Arguments to the <tt>zoneadm</tt> install command. This can be used to create branded zones.</p>"/>
|
|
<parameters name="sysidcfg" documentation="<p>The text to go into the <tt>sysidcfg</tt> file when the zone is first booted. The best way is to use a template:</p><pre> # $confdir/modules/site/templates/sysidcfg.erb
 system_locale=en_US
 timezone=GMT
 terminal=xterms
 security_policy=NONE
 root_password=<%= password %>
 timeserver=localhost
 name_service=DNS {domain_name=<%= domain %> name_server=<%= nameserver %>}
 network_interface=primary {hostname=<%= realhostname %>
 ip_address=<%= ip %>
 netmask=<%= netmask %>
 protocol_ipv6=no
 default_route=<%= defaultroute %>}
 nfs4_domain=dynamic

</pre><p>And then call that:</p><pre> zone { myzone:
 ip => "bge0:192.168.0.23",
 sysidcfg => template("site/sysidcfg.erb"),
 path => "/opt/zones/myzone",
 realhostname => "fully.qualified.domain.name"
 }

</pre><p>The <tt>sysidcfg</tt> only matters on the first booting of the zone, so Puppet only checks for it at that time.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the zone.</p>" namevar="true"/>
|
|
<parameters name="realhostname" documentation="<p>The actual hostname of the zone.</p>"/>
|
|
<parameters name="ensure" documentation="<p>The running state of the zone. The valid states directly reflect the states that <tt>zoneadm</tt> provides. The states are linear, in that a zone must be <tt>configured</tt>, then <tt>installed</tt>, and only then can be <tt>running</tt>. Note also that <tt>halt</tt> is currently used to stop zones.</p>"/>
|
|
</types>
|
|
<types name="notify" documentation="<p>Sends an arbitrary message to the agent run-time log.</p>">
|
|
<properties name="message" documentation="<p>The message to be sent to the log.</p>"/>
|
|
<parameters name="name" documentation="<p>An arbitrary tag for your own reference; the name of the message.</p>" namevar="true"/>
|
|
<parameters name="withpath" documentation="<p>Whether to show the full object path. Defaults to false.</p>"/>
|
|
</types>
|
|
<types name="computer" documentation="<p>Computer object management using DirectoryService on OS X.</p><p>Note that these are distinctly different kinds of objects to 'hosts', as they require a MAC address and can have all sorts of policy attached to them.</p><p>This provider only manages Computer objects in the local directory service domain, not in remote directories.</p><p>If you wish to manage <tt>/etc/hosts</tt> file on Mac OS X, then simply use the host type as per other platforms.</p><p>This type primarily exists to create localhost Computer objects that MCX policy can then be attached to.</p><p><strong>Autorequires:</strong> If Puppet is managing the plist file representing a Computer object (located at <tt>/var/db/dslocal/nodes/Default/computers/{name}.plist</tt>), the Computer resource will autorequire it.</p>">
|
|
<properties name="ip_address" documentation="<p>The IP Address of the Computer object.</p>"/>
|
|
<properties name="en_address" documentation="<p>The MAC address of the primary network interface. Must match en0.</p>"/>
|
|
<properties name="ensure" documentation="<p>Control the existences of this computer record. Set this attribute to <tt>present</tt> to ensure the computer record exists. Set it to <tt>absent</tt> to delete any computer records with this name</p>"/>
|
|
<parameters name="name" documentation="<p>The authoritative 'short' name of the computer record.</p>" namevar="true"/>
|
|
<parameters name="realname" documentation="<p>The 'long' name of the computer record.</p>"/>
|
|
</types>
|
|
<types name="file" documentation="<p>Manages files, including their content, ownership, and permissions.</p><p>The <tt>file</tt> type can manage normal files, directories, and symlinks; the type should be specified in the <tt>ensure</tt> attribute.</p><p>File contents can be managed directly with the <tt>content</tt> attribute, or downloaded from a remote source using the <tt>source</tt> attribute; the latter can also be used to recursively serve directories (when the <tt>recurse</tt> attribute is set to <tt>true</tt> or <tt>local</tt>). On Windows, note that file contents are managed in binary mode; Puppet never automatically translates line endings.</p><p><strong>Autorequires:</strong> If Puppet is managing the user or group that owns a file, the file resource will autorequire them. If Puppet is managing any parent directories of a file, the file resource will autorequire them.</p>">
|
|
<parameters name="sourceselect" documentation="<p>Whether to copy all valid sources, or just the first one. This parameter only affects recursive directory copies; by default, the first valid source is the only one used, but if this parameter is set to <tt>all</tt>, then all valid sources will have all of their contents copied to the local system. If a given file exists in more than one source, the version from the earliest source in the list will be used.</p>"/>
|
|
<parameters name="replace" documentation="<p>Whether to replace a file or symlink that already exists on the local system but whose content doesn't match what the <tt>source</tt> or <tt>content</tt> attribute specifies. Setting this to false allows file resources to initialize files without overwriting future changes. Note that this only affects content; Puppet will still manage ownership and permissions. Defaults to <tt>true</tt>.</p>"/>
|
|
<parameters name="show_diff" documentation="<p>Whether to display differences when the file changes, defaulting to true. This parameter is useful for files that may contain passwords or other secret data, which might otherwise be included in Puppet reports or other insecure outputs. If the global <tt>show_diff</tt> setting is false, then no diffs will be shown even if this parameter is true.</p>"/>
|
|
<parameters name="validate_replacement" documentation="<p>The replacement string in a <tt>validate_cmd</tt> that will be replaced with an input file name. Defaults to: <tt>%</tt></p>"/>
|
|
<parameters name="validate_cmd" documentation="<p>A command for validating the file's syntax before replacing it. If Puppet would need to rewrite a file due to new <tt>source</tt> or <tt>content</tt>, it will check the new content's validity first. If validation fails, the file resource will fail.</p><p>This command must have a fully qualified path, and should contain a percent (<tt>%</tt>) token where it would expect an input file. It must exit <tt>0</tt> if the syntax is correct, and non-zero otherwise. The command will be run on the target system while applying the catalog, not on the puppet master.</p><p>Example:</p><pre> file { '/etc/apache2/apache2.conf':
 content => 'example',
 validate_cmd => '/usr/sbin/apache2 -t -f %',
 }

</pre><p>This would replace apache2.conf only if the test returned true.</p><p>Note that if a validation command requires a <tt>%</tt> as part of its text, you can specify a different placeholder token with the <tt>validate_replacement</tt> attribute.</p>"/>
|
|
<parameters name="path" documentation="<p>The path to the file to manage. Must be fully qualified.</p><p>On Windows, the path should include the drive letter and should use <tt>/</tt> as the separator character (rather than <tt>\\</tt>).</p>" namevar="true"/>
|
|
<parameters name="links" documentation="<p>How to handle links during file actions. During file copying, <tt>follow</tt> will copy the target file instead of the link, <tt>manage</tt> will copy the link itself, and <tt>ignore</tt> will just pass it by. When not copying, <tt>manage</tt> and <tt>ignore</tt> behave equivalently (because you cannot really ignore links entirely during local recursion), and <tt>follow</tt> will manage the file to which the link points.</p>"/>
|
|
<parameters name="recurselimit" documentation="<p>How far Puppet should descend into subdirectories, when using <tt>ensure => directory</tt> and either <tt>recurse => true</tt> or <tt>recurse => remote</tt>. The recursion limit affects which files will be copied from the <tt>source</tt> directory, as well as which files can be purged when <tt>purge => true</tt>.</p><p>Setting <tt>recurselimit => 0</tt> is the same as setting <tt>recurse => false</tt> --- Puppet will manage the directory, but all of its contents will be treated as unmanaged.</p><p>Setting <tt>recurselimit => 1</tt> will manage files and directories that are directly inside the directory, but will not manage the contents of any subdirectories.</p><p>Setting <tt>recurselimit => 2</tt> will manage the direct contents of the directory, as well as the contents of the <i>first</i> level of subdirectories.</p><p>And so on --- 3 will manage the contents of the second level of subdirectories, etc.</p>"/>
|
|
<parameters name="force" documentation="<p>Perform the file operation even if it will destroy one or more directories. You must use <tt>force</tt> in order to:</p><ul><li><p><tt>purge</tt> subdirectories</p></li><li><p>Replace directories with files or links</p></li><li><p>Remove a directory when <tt>ensure => absent</tt></p></li></ul>"/>
|
|
<parameters name="recurse" documentation="<p>Whether to recursively manage the <i>contents</i> of a directory. This attribute is only used when <tt>ensure => directory</tt> is set. The allowed values are:</p><ul><li><p><tt>false</tt> --- The default behavior. The contents of the directory will not be automatically managed.</p></li><li><p><tt>remote</tt> --- If the <tt>source</tt> attribute is set, Puppet will automatically manage the contents of the source directory (or directories), ensuring that equivalent files and directories exist on the target system and that their contents match.</p></li></ul><pre>Using `remote` will disable the `purge` attribute, but results in faster
catalog application than `recurse => true`.

The `source` attribute is mandatory when `recurse => remote`.
</pre><ul><li><p><tt>true</tt> --- If the <tt>source</tt> attribute is set, this behaves similarly to <tt>recurse => remote</tt>, automatically managing files from the source directory.</p></li></ul><pre>This also enables the `purge` attribute, which can delete unmanaged
files from a directory. See the description of `purge` for more details.

The `source` attribute is not mandatory when using `recurse => true`, so you
can enable purging in directories where all files are managed individually.

(Note: `inf` is a deprecated synonym for `true`.)

</pre><p>By default, setting recurse to <tt>remote</tt> or <tt>true</tt> will manage <i>all</i> subdirectories. You can use the <tt>recurselimit</tt> attribute to limit the recursion depth.</p>"/>
|
|
<parameters name="purge" documentation="<p>Whether unmanaged files should be purged. This option only makes sense when <tt>ensure => directory</tt> and <tt>recurse => true</tt>.</p><ul><li><p>When recursively duplicating an entire directory with the <tt>source</tt> attribute, <tt>purge => true</tt> will automatically purge any files that are not in the source directory.</p></li><li><p>When managing files in a directory as individual resources, setting <tt>purge => true</tt> will purge any files that aren't being specifically managed.</p></li></ul><p>If you have a filebucket configured, the purged files will be uploaded, but if you do not, this will destroy data.</p><p>Unless <tt>force => true</tt> is set, purging will <strong>not</strong> delete directories, although it will delete the files they contain.</p><p>If <tt>recurselimit</tt> is set and you aren't using <tt>force => true</tt>, purging will obey the recursion limit; files in any subdirectories deeper than the limit will be treated as unmanaged and left alone.</p>"/>
|
|
<parameters name="ignore" documentation="<p>A parameter which omits action on files matching specified patterns during recursion. Uses Ruby's builtin globbing engine, so shell metacharacters are fully supported, e.g. <tt>[a-z]<b></tt>. Matches that would descend into the directory structure are ignored, e.g., <tt></b>/*</tt>.</p>"/>
|
|
<parameters name="backup" documentation="<p>Whether (and how) file content should be backed up before being replaced. This attribute works best as a resource default in the site manifest (<tt>File { backup => main }</tt>), so it can affect all file resources.</p><ul><li><p>If set to <tt>false</tt>, file content won't be backed up.</p></li><li><p>If set to a string beginning with <tt>.</tt> (e.g., <tt>.puppet-bak</tt>), Puppet will use copy the file in the same directory with that value as the extension of the backup. (A value of <tt>true</tt> is a synonym for <tt>.puppet-bak</tt>.)</p></li><li><p>If set to any other string, Puppet will try to back up to a filebucket with that title. See the <tt>filebucket</tt> resource type for more details. (This is the preferred method for backup, since it can be centralized and queried.)</p></li></ul><p>Default value: <tt>puppet</tt>, which backs up to a filebucket of the same name. (Puppet automatically creates a <strong>local</strong> filebucket named <tt>puppet</tt> if one doesn't already exist.)</p><p>Backing up to a local filebucket isn't particularly useful. If you want to make organized use of backups, you will generally want to use the puppet master server's filebucket service. This requires declaring a filebucket resource and a resource default for the <tt>backup</tt> attribute in site.pp:</p><pre> # /etc/puppet/manifests/site.pp
 filebucket { 'main':
 path => false, # This is required for remote filebuckets.
 server => 'puppet.example.com', # Optional; defaults to the configured puppet master.
 }

 File { backup => main, }

</pre><p>If you are using multiple puppet master servers, you will want to centralize the contents of the filebucket. Either configure your load balancer to direct all filebucket traffic to a single master, or use something like an out-of-band rsync task to synchronize the content on all masters.</p>"/>
|
|
</types>
|
|
<types name="sshkey" documentation="<p>Installs and manages ssh host keys. At this point, this type only knows how to install keys into <tt>/etc/ssh/ssh<i>known</i>hosts</tt>. See the <tt>ssh<i>authorized</i>key</tt> type to manage authorized keys.</p>">
|
|
<properties name="target" documentation="<p>The file in which to store the ssh key. Only used by the <tt>parsed</tt> provider.</p>"/>
|
|
<properties name="type" documentation="<p>The encryption type used. Probably ssh-dss or ssh-rsa.</p>"/>
|
|
<properties name="key" documentation="<p>The key itself; generally a long string of uuencoded characters.</p>"/>
|
|
<properties name="host_aliases" documentation="<p>Any aliases the host might have. Multiple values must be specified as an array.</p>"/>
|
|
<parameters name="name" documentation="<p>The host name that the key is associated with.</p>" namevar="true"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="cron" documentation="<p>Installs and manages cron jobs. Every cron resource created by Puppet requires a command and at least one periodic attribute (hour, minute, month, monthday, weekday, or special). While the name of the cron job is not part of the actual job, the name is stored in a comment beginning with <tt># Puppet Name: </tt>. These comments are used to match crontab entries created by Puppet with cron resources.</p><p>If an existing crontab entry happens to match the scheduling and command of a cron resource that has never been synched, Puppet will defer to the existing crontab entry and will not create a new entry tagged with the <tt># Puppet Name: </tt> comment.</p><p>Example:</p><pre> cron { logrotate:
 command => "/usr/sbin/logrotate",
 user => root,
 hour => 2,
 minute => 0
 }

</pre><p>Note that all periodic attributes can be specified as an array of values:</p><pre> cron { logrotate:
 command => "/usr/sbin/logrotate",
 user => root,
 hour => [2, 4]
 }

</pre><p>...or using ranges or the step syntax <tt>*/2</tt> (although there's no guarantee that your <tt>cron</tt> daemon supports these):</p><pre> cron { logrotate:
 command => "/usr/sbin/logrotate",
 user => root,
 hour => ['2-4'],
 minute => '*/10'
 }

</pre><p>An important note: <i>the Cron type will not reset parameters that are removed from a manifest</i>. For example, removing a <tt>minute => 10</tt> parameter will not reset the minute component of the associated cronjob to <tt>*</tt>. These changes must be expressed by setting the parameter to <tt>minute => absent</tt> because Puppet only manages parameters that are out of sync with manifest entries.</p><p><strong>Autorequires:</strong> If Puppet is managing the user account specified by the <tt>user</tt> property of a cron resource, then the cron resource will autorequire that user.</p>">
|
|
<properties name="minute" documentation="<p>The minute at which to run the cron job. Optional; if specified, must be between 0 and 59, inclusive.</p>"/>
|
|
<properties name="environment" documentation="<p>Any environment settings associated with this cron job. They will be stored between the header and the job in the crontab. There can be no guarantees that other, earlier settings will not also affect a given cron job.</p><p>Also, Puppet cannot automatically determine whether an existing, unmanaged environment setting is associated with a given cron job. If you already have cron jobs with environment settings, then Puppet will keep those settings in the same place in the file, but will not associate them with a specific job.</p><p>Settings should be specified exactly as they should appear in the crontab, e.g., <tt>PATH=/bin:/usr/bin:/usr/sbin</tt>.</p>"/>
|
|
<properties name="weekday" documentation="<p>The weekday on which to run the command. Optional; if specified, must be between 0 and 7, inclusive, with 0 (or 7) being Sunday, or must be the name of the day (e.g., Tuesday).</p>"/>
|
|
<properties name="monthday" documentation="<p>The day of the month on which to run the command. Optional; if specified, must be between 1 and 31.</p>"/>
|
|
<properties name="target" documentation="<p>The name of the crontab file in which the cron job should be stored.</p><p>This property defaults to the value of the <tt>user</tt> property if set, the user running Puppet or <tt>root</tt>.</p><p>For the default crontab provider, this property is functionally equivalent to the <tt>user</tt> property and should be avoided. In particular, setting both <tt>user</tt> and <tt>target</tt> to different values will result in undefined behavior.</p>"/>
|
|
<properties name="month" documentation="<p>The month of the year. Optional; if specified must be between 1 and 12 or the month name (e.g., December).</p>"/>
|
|
<properties name="command" documentation="<p>The command to execute in the cron job. The environment provided to the command varies by local system rules, and it is best to always provide a fully qualified command. The user's profile is not sourced when the command is run, so if the user's environment is desired it should be sourced manually.</p><p>All cron parameters support <tt>absent</tt> as a value; this will remove any existing values for that field.</p>"/>
|
|
<properties name="special" documentation="<p>A special value such as 'reboot' or 'annually'. Only available on supported systems such as Vixie Cron. Overrides more specific time of day/week settings. Set to 'absent' to make puppet revert to a plain numeric schedule.</p>"/>
|
|
<properties name="hour" documentation="<p>The hour at which to run the cron job. Optional; if specified, must be between 0 and 23, inclusive.</p>"/>
|
|
<properties name="user" documentation="<p>The user who owns the cron job. This user must be allowed to run cron jobs, which is not currently checked by Puppet.</p><p>This property defaults to the user running Puppet or <tt>root</tt>.</p><p>The default crontab provider executes the system <tt>crontab</tt> using the user account specified by this property.</p>"/>
|
|
<parameters name="name" documentation="<p>The symbolic name of the cron job. This name is used for human reference only and is generated automatically for cron jobs found on the system. This generally won't matter, as Puppet will do its best to match existing cron jobs against specified jobs (and Puppet adds a comment to cron jobs it adds), but it is at least possible that converting from unmanaged jobs to managed jobs might require manual intervention.</p>" namevar="true"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="service" documentation="<p>Manage running services. Service support unfortunately varies widely by platform --- some platforms have very little if any concept of a running service, and some have a very codified and powerful concept. Puppet's service support is usually capable of doing the right thing, but the more information you can provide, the better behaviour you will get.</p><p>Puppet 2.7 and newer expect init scripts to have a working status command. If this isn't the case for any of your services' init scripts, you will need to set <tt>hasstatus</tt> to false and possibly specify a custom status command in the <tt>status</tt> attribute. As a last resort, Puppet will attempt to search the process table by calling whatever command is listed in the <tt>ps</tt> fact. The default search pattern is the name of the service, but you can specify it with the <tt>pattern</tt> attribute.</p><p><strong>Refresh:</strong> <tt>service</tt> resources can respond to refresh events (via <tt>notify</tt>, <tt>subscribe</tt>, or the <tt>~></tt> arrow). If a <tt>service</tt> receives an event from another resource, Puppet will restart the service it manages. The actual command used to restart the service depends on the platform and can be configured:</p><ul><li><p>If you set <tt>hasrestart</tt> to true, Puppet will use the init script's restart command.</p></li><li><p>You can provide an explicit command for restarting with the <tt>restart</tt> attribute.</p></li><li><p>If you do neither, the service's stop and start commands will be used.</p></li></ul>">
|
|
<properties name="flags" documentation="<p>Specify a string of flags to pass to the startup script.</p>"/>
|
|
<properties name="enable" documentation="<p>Whether a service should be enabled to start at boot. This property behaves quite differently depending on the platform; wherever possible, it relies on local tools to enable or disable a given service.</p>"/>
|
|
<properties name="ensure" documentation="<p>Whether a service should be running.</p>"/>
|
|
<parameters name="control" documentation="<p>The control variable used to manage services (originally for HP-UX). Defaults to the upcased service name plus <tt>START</tt> replacing dots with underscores, for those providers that support the <tt>controllable</tt> feature.</p>"/>
|
|
<parameters name="stop" documentation="<p>Specify a <b>stop</b> command manually.</p>"/>
|
|
<parameters name="restart" documentation="<p>Specify a <b>restart</b> command manually. If left unspecified, the service will be stopped and then started.</p>"/>
|
|
<parameters name="binary" documentation="<p>The path to the daemon. This is only used for systems that do not support init scripts. This binary will be used to start the service if no <tt>start</tt> parameter is provided.</p>"/>
|
|
<parameters name="pattern" documentation="<p>The pattern to search for in the process table. This is used for stopping services on platforms that do not support init scripts, and is also used for determining service status on those service whose init scripts do not include a status command.</p><p>Defaults to the name of the service. The pattern can be a simple string or any legal Ruby pattern, including regular expressions (which should be quoted without enclosing slashes).</p>"/>
|
|
<parameters name="status" documentation="<p>Specify a <b>status</b> command manually. This command must return 0 if the service is running and a nonzero value otherwise. Ideally, these exit codes should conform to [the LSB's specification][lsb-exit-codes] for init script status actions, but Puppet only considers the difference between 0 and nonzero to be relevant.</p><p>If left unspecified, the status of the service will be determined automatically, usually by looking for the service in the process table.</p><p>[lsb-exit-codes]: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html</p>"/>
|
|
<parameters name="start" documentation="<p>Specify a <b>start</b> command manually. Most service subsystems support a <tt>start</tt> command, so this will not need to be specified.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the service to run.</p><p>This name is used to find the service; on platforms where services have short system names and long display names, this should be the short name. (To take an example from Windows, you would use "wuauserv" rather than "Automatic Updates.")</p>" namevar="true"/>
|
|
<parameters name="manifest" documentation="<p>Specify a command to config a service, or a path to a manifest to do so.</p>"/>
|
|
<parameters name="path" documentation="<p>The search path for finding init scripts. Multiple values should be separated by colons or provided as an array.</p>"/>
|
|
<parameters name="hasrestart" documentation="<p>Specify that an init script has a <tt>restart</tt> command. If this is false and you do not specify a command in the <tt>restart</tt> attribute, the init script's <tt>stop</tt> and <tt>start</tt> commands will be used.</p><p>Defaults to false.</p>"/>
|
|
<parameters name="hasstatus" documentation="<p>Declare whether the service's init script has a functional status command; defaults to <tt>true</tt>. This attribute's default value changed in Puppet 2.7.0.</p><p>The init script's status command must return 0 if the service is running and a nonzero value otherwise. Ideally, these exit codes should conform to [the LSB's specification][lsb-exit-codes] for init script status actions, but Puppet only considers the difference between 0 and nonzero to be relevant.</p><p>If a service's init script does not support any kind of status command, you should set <tt>hasstatus</tt> to false and either provide a specific command using the <tt>status</tt> attribute or expect that Puppet will look for the service name in the process table. Be aware that 'virtual' init scripts (like 'network' under Red Hat systems) will respond poorly to refresh events from other resources if you override the default behavior without providing a status command.</p>"/>
|
|
</types>
|
|
<types name="zfs" documentation="<p>Manage zfs. Create destroy and set properties on zfs instances.</p><p><strong>Autorequires:</strong> If Puppet is managing the zpool at the root of this zfs instance, the zfs resource will autorequire it. If Puppet is managing any parent zfs instances, the zfs resource will autorequire them.</p>">
|
|
<properties name="sharenfs" documentation="<p>The sharenfs property. Valid values are <tt>on</tt>, <tt>off</tt>, share(1M) options</p>"/>
|
|
<properties name="volsize" documentation="<p>The volsize property. Valid values are <tt><size></tt></p>"/>
|
|
<properties name="atime" documentation="<p>The atime property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="aclmode" documentation="<p>The aclmode property. Valid values are <tt>discard</tt>, <tt>groupmask</tt>, <tt>passthrough</tt>.</p>"/>
|
|
<properties name="xattr" documentation="<p>The xattr property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="checksum" documentation="<p>The checksum property. Valid values are <tt>on</tt>, <tt>off</tt>, <tt>fletcher2</tt>, <tt>fletcher4</tt>, <tt>sha256</tt>.</p>"/>
|
|
<properties name="setuid" documentation="<p>The setuid property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="version" documentation="<p>The version property. Valid values are <tt>1</tt>, <tt>2</tt>, <tt>3</tt>, <tt>4</tt>, <tt>current</tt>.</p>"/>
|
|
<properties name="shareiscsi" documentation="<p>The shareiscsi property. Valid values are <tt>on</tt>, <tt>off</tt>, <tt>type=<type></tt>.</p>"/>
|
|
<properties name="recordsize" documentation="<p>The recordsize property. Valid values are powers of two between 512 and 128k.</p>"/>
|
|
<properties name="secondarycache" documentation="<p>The secondarycache property. Valid values are <tt>all</tt>, <tt>none</tt>, <tt>metadata</tt>.</p>"/>
|
|
<properties name="quota" documentation="<p>The quota property. Valid values are <tt><size></tt>, <tt>none</tt>.</p>"/>
|
|
<properties name="zoned" documentation="<p>The zoned property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="aclinherit" documentation="<p>The aclinherit property. Valid values are <tt>discard</tt>, <tt>noallow</tt>, <tt>restricted</tt>, <tt>passthrough</tt>, <tt>passthrough-x</tt>.</p>"/>
|
|
<properties name="sharesmb" documentation="<p>The sharesmb property. Valid values are <tt>on</tt>, <tt>off</tt>, sharemgr(1M) options</p>"/>
|
|
<properties name="canmount" documentation="<p>The canmount property. Valid values are <tt>on</tt>, <tt>off</tt>, <tt>noauto</tt>.</p>"/>
|
|
<properties name="compression" documentation="<p>The compression property. Valid values are <tt>on</tt>, <tt>off</tt>, <tt>lzjb</tt>, <tt>gzip</tt>, <tt>gzip-[1-9]</tt>, <tt>zle</tt>.</p>"/>
|
|
<properties name="primarycache" documentation="<p>The primarycache property. Valid values are <tt>all</tt>, <tt>none</tt>, <tt>metadata</tt>.</p>"/>
|
|
<properties name="dedup" documentation="<p>The dedup property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="nbmand" documentation="<p>The nbmand property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="snapdir" documentation="<p>The snapdir property. Valid values are <tt>hidden</tt>, <tt>visible</tt>.</p>"/>
|
|
<properties name="copies" documentation="<p>The copies property. Valid values are <tt>1</tt>, <tt>2</tt>, <tt>3</tt>.</p>"/>
|
|
<properties name="mountpoint" documentation="<p>The mountpoint property. Valid values are <tt><path></tt>, <tt>legacy</tt>, <tt>none</tt>.</p>"/>
|
|
<properties name="logbias" documentation="<p>The logbias property. Valid values are <tt>latency</tt>, <tt>throughput</tt>.</p>"/>
|
|
<properties name="reservation" documentation="<p>The reservation property. Valid values are <tt><size></tt>, <tt>none</tt>.</p>"/>
|
|
<properties name="refquota" documentation="<p>The refquota property. Valid values are <tt><size></tt>, <tt>none</tt>.</p>"/>
|
|
<properties name="refreservation" documentation="<p>The refreservation property. Valid values are <tt><size></tt>, <tt>none</tt>.</p>"/>
|
|
<properties name="exec" documentation="<p>The exec property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="devices" documentation="<p>The devices property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="vscan" documentation="<p>The vscan property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<properties name="readonly" documentation="<p>The readonly property. Valid values are <tt>on</tt>, <tt>off</tt>.</p>"/>
|
|
<parameters name="name" documentation="<p>The full name for this filesystem (including the zpool).</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="mcx" documentation="<p>MCX object management using DirectoryService on OS X.</p><p>The default provider of this type merely manages the XML plist as reported by the <tt>dscl -mcxexport</tt> command. This is similar to the content property of the file type in Puppet.</p><p>The recommended method of using this type is to use Work Group Manager to manage users and groups on the local computer, record the resulting puppet manifest using the command <tt>puppet resource mcx</tt>, then deploy it to other machines.</p><p><strong>Autorequires:</strong> If Puppet is managing the user, group, or computer that these MCX settings refer to, the MCX resource will autorequire that user, group, or computer.</p>">
|
|
<properties name="content" documentation="<p>The XML Plist used as the value of MCXSettings in DirectoryService. This is the standard output from the system command:</p><pre> dscl localhost -mcxexport /Local/Default/<ds_type>/ds_name

</pre><p>Note that <tt>ds_type</tt> is capitalized and plural in the dscl command.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the resource being managed. The default naming convention follows Directory Service paths:</p><pre> /Computers/localhost
 /Groups/admin
 /Users/localadmin

</pre><p>The <tt>ds<i>type</tt> and <tt>ds</i>name</tt> type parameters are not necessary if the default naming convention is followed.</p>" namevar="true"/>
|
|
<parameters name="ds_type" documentation="<p>The DirectoryService type this MCX setting attaches to.</p>"/>
|
|
<parameters name="ds_name" documentation="<p>The name to attach the MCX Setting to. (For example, <tt>localhost</tt> when <tt>ds_type => computer</tt>.) This setting is not required, as it can be automatically discovered when the resource name is parseable. (For example, in <tt>/Groups/admin</tt>, <tt>group</tt> will be used as the dstype.)</p>"/>
|
|
<parameters name="ensure" documentation="<p>Create or remove the MCX setting.</p>"/>
|
|
</types>
|
|
<types name="selboolean" documentation="<p>Manages SELinux booleans on systems with SELinux support. The supported booleans are any of the ones found in <tt>/selinux/booleans/</tt>.</p>">
|
|
<properties name="value" documentation="<p>Whether the SELinux boolean should be enabled or disabled.</p>"/>
|
|
<parameters name="persistent" documentation="<p>If set true, SELinux booleans will be written to disk and persist accross reboots. The default is <tt>false</tt>.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the SELinux boolean to be managed.</p>" namevar="true"/>
|
|
</types>
|
|
<types name="user" documentation="<p>Manage users. This type is mostly built to manage system users, so it is lacking some features useful for managing normal users.</p><p>This resource type uses the prescribed native tools for creating groups and generally uses POSIX APIs for retrieving information about them. It does not directly modify <tt>/etc/passwd</tt> or anything.</p><p><strong>Autorequires:</strong> If Puppet is managing the user's primary group (as provided in the <tt>gid</tt> attribute), the user resource will autorequire that group. If Puppet is managing any role accounts corresponding to the user's roles, the user resource will autorequire those role accounts.</p>">
|
|
<properties name="uid" documentation="<p>The user ID; must be specified numerically. If no user ID is specified when creating a new user, then one will be chosen automatically. This will likely result in the same user having different UIDs on different systems, which is not recommended. This is especially noteworthy when managing the same user on both Darwin and other platforms, since Puppet does UID generation on Darwin, but the underlying tools do so on other platforms.</p><p>On Windows, this property is read-only and will return the user's security identifier (SID).</p>"/>
|
|
<properties name="password_min_age" documentation="<p>The minimum number of days a password must be used before it may be changed.</p>"/>
|
|
<properties name="home" documentation="<p>The home directory of the user. The directory must be created separately and is not currently checked for existence.</p>"/>
|
|
<properties name="shell" documentation="<p>The user's login shell. The shell must exist and be executable.</p><p>This attribute cannot be managed on Windows systems.</p>"/>
|
|
<properties name="auths" documentation="<p>The auths the user has. Multiple auths should be specified as an array.</p>"/>
|
|
<properties name="keys" documentation="<p>Specify user attributes in an array of key = value pairs.</p>"/>
|
|
<properties name="iterations" documentation="<p>This is the number of iterations of a chained computation of the password hash (http://en.wikipedia.org/wiki/PBKDF2). This parameter is used in OS X. This field is required for managing passwords on OS X >= 10.8.</p>"/>
|
|
<properties name="password" documentation="<p>The user's password, in whatever encrypted format the local system requires.</p><ul><li><p>Most modern Unix-like systems use salted SHA1 password hashes. You can use Puppet's built-in <tt>sha1</tt> function to generate a hash from a password.</p></li><li><p>Mac OS X 10.5 and 10.6 also use salted SHA1 hashes.</p></li><li><p>Mac OS X 10.7 (Lion) uses salted SHA512 hashes. The Puppet Labs [stdlib][] module contains a <tt>str2saltedsha512</tt> function which can generate password hashes for Lion.</p></li><li><p>Mac OS X 10.8 and higher use salted SHA512 PBKDF2 hashes. When managing passwords on these systems the salt and iterations properties need to be specified as well as the password.</p></li><li><p>Windows passwords can only be managed in cleartext, as there is no Windows API for setting the password hash.</p></li></ul><p>[stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/</p><p>Be sure to enclose any value that includes a dollar sign ($) in single quotes (') to avoid accidental variable interpolation.</p>"/>
|
|
<properties name="expiry" documentation="<p>The expiry date for this user. Must be provided in a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19. If you want to make sure the user account does never expire, you can pass the special value <tt>absent</tt>.</p>"/>
|
|
<properties name="project" documentation="<p>The name of the project associated with a user.</p>"/>
|
|
<properties name="password_max_age" documentation="<p>The maximum number of days a password may be used before it must be changed.</p>"/>
|
|
<properties name="roles" documentation="<p>The roles the user has. Multiple roles should be specified as an array.</p>"/>
|
|
<properties name="gid" documentation="<p>The user's primary group. Can be specified numerically or by name.</p><p>This attribute is not supported on Windows systems; use the <tt>groups</tt> attribute instead. (On Windows, designating a primary group is only meaningful for domain accounts, which Puppet does not currently manage.)</p>"/>
|
|
<properties name="attributes" documentation="<p>Specify AIX attributes for the user in an array of attribute = value pairs.</p>"/>
|
|
<properties name="profiles" documentation="<p>The profiles the user has. Multiple profiles should be specified as an array.</p>"/>
|
|
<properties name="comment" documentation="<p>A description of the user. Generally the user's full name.</p>"/>
|
|
<properties name="groups" documentation="<p>The groups to which the user belongs. The primary group should not be listed, and groups should be identified by name rather than by GID. Multiple groups should be specified as an array.</p>"/>
|
|
<properties name="salt" documentation="<p>This is the 32 byte salt used to generate the PBKDF2 password used in OS X. This field is required for managing passwords on OS X >= 10.8.</p>"/>
|
|
<properties name="ensure" documentation="<p>The basic state that the object should be in.</p>"/>
|
|
<parameters name="attribute_membership" documentation="<p>Whether specified attribute value pairs should be treated as the <strong>complete list</strong> (<tt>inclusive</tt>) or the <strong>minimum list</strong> (<tt>minimum</tt>) of attribute/value pairs for the user. Defaults to <tt>minimum</tt>.</p>"/>
|
|
<parameters name="system" documentation="<p>Whether the user is a system user, according to the OS's criteria; on most platforms, a UID less than or equal to 500 indicates a system user. This parameter is only used when the resource is created and will not affect the UID when the user is present. Defaults to <tt>false</tt>.</p>"/>
|
|
<parameters name="key_membership" documentation="<p>Whether specified key/value pairs should be considered the <strong>complete list</strong> (<tt>inclusive</tt>) or the <strong>minimum list</strong> (<tt>minimum</tt>) of the user's attributes. Defaults to <tt>minimum</tt>.</p>"/>
|
|
<parameters name="membership" documentation="<p>Whether specified groups should be considered the <strong>complete list</strong> (<tt>inclusive</tt>) or the <strong>minimum list</strong> (<tt>minimum</tt>) of groups to which the user belongs. Defaults to <tt>minimum</tt>.</p>"/>
|
|
<parameters name="forcelocal" documentation="<p>Forces the management of local accounts when accounts are also being managed by some other NSS</p>"/>
|
|
<parameters name="profile_membership" documentation="<p>Whether specified roles should be treated as the <strong>complete list</strong> (<tt>inclusive</tt>) or the <strong>minimum list</strong> (<tt>minimum</tt>) of roles of which the user is a member. Defaults to <tt>minimum</tt>.</p>"/>
|
|
<parameters name="name" documentation="<p>The user name. While naming limitations vary by operating system, it is advisable to restrict names to the lowest common denominator, which is a maximum of 8 characters beginning with a letter.</p><p>Note that Puppet considers user names to be case-sensitive, regardless of the platform's own rules; be sure to always use the same case when referring to a given user.</p>" namevar="true"/>
|
|
<parameters name="allowdupe" documentation="<p>Whether to allow duplicate UIDs. Defaults to <tt>false</tt>.</p>"/>
|
|
<parameters name="auth_membership" documentation="<p>Whether specified auths should be considered the <strong>complete list</strong> (<tt>inclusive</tt>) or the <strong>minimum list</strong> (<tt>minimum</tt>) of auths the user has. Defaults to <tt>minimum</tt>.</p>"/>
|
|
<parameters name="role_membership" documentation="<p>Whether specified roles should be considered the <strong>complete list</strong> (<tt>inclusive</tt>) or the <strong>minimum list</strong> (<tt>minimum</tt>) of roles the user has. Defaults to <tt>minimum</tt>.</p>"/>
|
|
<parameters name="purge_ssh_keys" documentation="<p>Whether to purge authorized SSH keys for this user if they are not managed with the <tt>ssh<i>authorized</i>key</tt> resource type. Allowed values are:</p><ul><li><p><tt>false</tt> (default) --- don't purge SSH keys for this user.</p></li><li><p><tt>true</tt> --- look for keys in the <tt>.ssh/authorized<i>keys</tt> file in the user's home directory. Purge any keys that aren't managed as <tt>ssh</i>authorized_key</tt> resources.</p></li><li><p>An array of file paths --- look for keys in all of the files listed. Purge any keys that aren't managed as <tt>ssh<i>authorized</i>key</tt> resources. If any of these paths starts with <tt>~</tt> or <tt>%h</tt>, that token will be replaced with the user's home directory.</p></li></ul>"/>
|
|
<parameters name="ia_load_module" documentation="<p>The name of the I&A module to use to manage this user.</p>"/>
|
|
<parameters name="managehome" documentation="<p>Whether to manage the home directory when managing the user. This will create the home directory when <tt>ensure => present</tt>, and delete the home directory when <tt>ensure => absent</tt>. Defaults to <tt>false</tt>.</p>"/>
|
|
</types>
|
|
<types name="whit" documentation="">
|
|
<parameters name="name" documentation="<p>The name of the whit, because it must have one.</p>"/>
|
|
</types>
|
|
<types name="tidy" documentation="<p>Remove unwanted files based on specific criteria. Multiple criteria are OR'd together, so a file that is too large but is not old enough will still get tidied.</p><p>If you don't specify either <tt>age</tt> or <tt>size</tt>, then all files will be removed.</p><p>This resource type works by generating a file resource for every file that should be deleted and then letting that resource perform the actual deletion.</p>">
|
|
<parameters name="matches" documentation="<p>One or more (shell type) file glob patterns, which restrict the list of files to be tidied to those whose basenames match at least one of the patterns specified. Multiple patterns can be specified using an array.</p><p>Example:</p><pre> tidy { "/tmp":
 age => "1w",
 recurse => 1,
 matches => [ "[0-9]pub*.tmp", "*.temp", "tmpfile?" ]
 }

</pre><p>This removes files from <tt>/tmp</tt> if they are one week old or older, are not in a subdirectory and match one of the shell globs given.</p><p>Note that the patterns are matched against the basename of each file -- that is, your glob patterns should not have any '/' characters in them, since you are only specifying against the last bit of the file.</p><p>Finally, note that you must now specify a non-zero/non-false value for recurse if matches is used, as matches only apply to files found by recursion (there's no reason to use static patterns match against a statically determined path). Requiering explicit recursion clears up a common source of confusion.</p>"/>
|
|
<parameters name="age" documentation="<p>Tidy files whose age is equal to or greater than the specified time. You can choose seconds, minutes, hours, days, or weeks by specifying the first letter of any of those words (e.g., '1w').</p><p>Specifying 0 will remove all files.</p>"/>
|
|
<parameters name="path" documentation="<p>The path to the file or directory to manage. Must be fully qualified.</p>" namevar="true"/>
|
|
<parameters name="rmdirs" documentation="<p>Tidy directories in addition to files; that is, remove directories whose age is older than the specified criteria. This will only remove empty directories, so all contained files must also be tidied before a directory gets removed.</p>"/>
|
|
<parameters name="type" documentation="<p>Set the mechanism for determining age. Default: atime.</p>"/>
|
|
<parameters name="recurse" documentation="<p>If target is a directory, recursively descend into the directory looking for files to tidy.</p>"/>
|
|
<parameters name="size" documentation="<p>Tidy files whose size is equal to or greater than the specified size. Unqualified values are in kilobytes, but <b>b</b>, <b>k</b>, <b>m</b>, <b>g</b>, and <b>t</b> can be appended to specify <b>bytes</b>, <b>kilobytes</b>, <b>megabytes</b>, <b>gigabytes</b>, and <b>terabytes</b>, respectively. Only the first character is significant, so the full word can also be used.</p>"/>
|
|
<parameters name="backup" documentation="<p>Whether tidied files should be backed up. Any values are passed directly to the file resources used for actual file deletion, so consult the <tt>file</tt> type's backup documentation to determine valid values.</p>"/>
|
|
</types>
|
|
<types name="resources" documentation="<p>This is a metatype that can manage other resource types. Any metaparams specified here will be passed on to any generated resources, so you can purge umanaged resources but set <tt>noop</tt> to true so the purging is only logged and does not actually happen.</p>">
|
|
<parameters name="name" documentation="<p>The name of the type to be managed.</p>"/>
|
|
<parameters name="unless_system_user" documentation="<p>This keeps system users from being purged. By default, it does not purge users whose UIDs are less than the minimum UID for the system (typically 500 or 1000), but you can specify a different UID as the inclusive limit.</p>"/>
|
|
<parameters name="unless_uid" documentation="<p>This keeps specific uids or ranges of uids from being purged when purge is true. Accepts integers, integer strings, and arrays of integers or integer strings. To specify a range of uids, consider using the range() function from stdlib.</p>"/>
|
|
<parameters name="purge" documentation="<p>Whether to purge unmanaged resources. When set to <tt>true</tt>, this will delete any resource that is not specified in your configuration and is not autorequired by any managed resources. <strong>Note:</strong> The <tt>ssh<i>authorized</i>key</tt> resource type can't be purged this way; instead, see the <tt>purge<i>ssh</i>keys</tt> attribute of the <tt>user</tt> type.</p>"/>
|
|
</types>
|
|
<types name="interface" documentation="<p>This represents a router or switch interface. It is possible to manage interface mode (access or trunking, native vlan and encapsulation) and switchport characteristics (speed, duplex).</p>">
|
|
<properties name="allowed_trunk_vlans" documentation="<p>Allowed list of Vlans that this trunk can forward.</p>"/>
|
|
<properties name="etherchannel" documentation="<p>Channel group this interface is part of.</p>"/>
|
|
<properties name="speed" documentation="<p>Interface speed.</p>"/>
|
|
<properties name="native_vlan" documentation="<p>Interface native vlan (for access mode only).</p>"/>
|
|
<properties name="description" documentation="<p>Interface description.</p>"/>
|
|
<properties name="ipaddress" documentation="<p>IP Address of this interface. Note that it might not be possible to set an interface IP address; it depends on the interface type and device type.</p><p>Valid format of ip addresses are:</p><ul><li><p>IPV4, like 127.0.0.1</p></li><li><p>IPV4/prefixlength like 127.0.1.1/24</p></li><li><p>IPV6/prefixlength like FE80::21A:2FFF:FE30:ECF0/128</p></li><li><p>an optional suffix for IPV6 addresses from this list: <tt>eui-64</tt>, <tt>link-local</tt></p></li></ul><p>It is also possible to supply an array of values.</p>"/>
|
|
<properties name="duplex" documentation="<p>Interface duplex.</p>"/>
|
|
<properties name="mode" documentation="<p>Interface switchport mode.</p>"/>
|
|
<properties name="encapsulation" documentation="<p>Interface switchport encapsulation.</p>"/>
|
|
<parameters name="name" documentation="<p>The interface's name.</p>"/>
|
|
<parameters name="device_url" documentation="<p>The URL at which the router or switch can be reached.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="mount" documentation="<p>Manages mounted filesystems, including putting mount information into the mount table. The actual behavior depends on the value of the 'ensure' parameter.</p><p><strong>Refresh:</strong> <tt>mount</tt> resources can respond to refresh events (via <tt>notify</tt>, <tt>subscribe</tt>, or the <tt>~></tt> arrow). If a <tt>mount</tt> receives an event from another resource <strong>and</strong> its <tt>ensure</tt> attribute is set to <tt>mounted</tt>, Puppet will try to unmount then remount that filesystem.</p><p><strong>Autorequires:</strong> If Puppet is managing any parents of a mount resource --- that is, other mount points higher up in the filesystem --- the child mount will autorequire them.</p>">
|
|
<properties name="dump" documentation="<p>Whether to dump the mount. Not all platform support this. Valid values are <tt>1</tt> or <tt>0</tt> (or <tt>2</tt> on FreeBSD). Default is <tt>0</tt>.</p>"/>
|
|
<properties name="fstype" documentation="<p>The mount type. Valid values depend on the operating system. This is a required option.</p>"/>
|
|
<properties name="blockdevice" documentation="<p>The device to fsck. This is property is only valid on Solaris, and in most cases will default to the correct value.</p>"/>
|
|
<properties name="atboot" documentation="<p>Whether to mount the mount at boot. Not all platforms support this.</p>"/>
|
|
<properties name="target" documentation="<p>The file in which to store the mount table. Only used by those providers that write to disk.</p>"/>
|
|
<properties name="device" documentation="<p>The device providing the mount. This can be whatever device is supporting by the mount, including network devices or devices specified by UUID rather than device path, depending on the operating system.</p>"/>
|
|
<properties name="pass" documentation="<p>The pass in which the mount is checked.</p>"/>
|
|
<properties name="options" documentation="<p>Mount options for the mounts, as they would appear in the fstab.</p>"/>
|
|
<properties name="ensure" documentation="<p>Control what to do with this mount. Set this attribute to <tt>unmounted</tt> to make sure the filesystem is in the filesystem table but not mounted (if the filesystem is currently mounted, it will be unmounted). Set it to <tt>absent</tt> to unmount (if necessary) and remove the filesystem from the fstab. Set to <tt>mounted</tt> to add it to the fstab and mount it. Set to <tt>present</tt> to add to fstab but not change mount/unmount status.</p>"/>
|
|
<parameters name="name" documentation="<p>The mount path for the mount.</p>" namevar="true"/>
|
|
<parameters name="remounts" documentation="<p>Whether the mount can be remounted <tt>mount -o remount</tt>. If this is false, then the filesystem will be unmounted and remounted manually, which is prone to failure.</p>"/>
|
|
</types>
|
|
<types name="maillist" documentation="<p>Manage email lists. This resource type can only create and remove lists; it cannot currently reconfigure them.</p>">
|
|
<parameters name="mailserver" documentation="<p>The name of the host handling email for the list.</p>"/>
|
|
<parameters name="admin" documentation="<p>The email address of the administrator.</p>"/>
|
|
<parameters name="description" documentation="<p>The description of the mailing list.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the email list.</p>"/>
|
|
<parameters name="webserver" documentation="<p>The name of the host providing web archives and the administrative interface.</p>"/>
|
|
<parameters name="password" documentation="<p>The admin password.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="group" documentation="<p>Manage groups. On most platforms this can only create groups. Group membership must be managed on individual users.</p><p>On some platforms such as OS X, group membership is managed as an attribute of the group, not the user record. Providers must have the feature 'manages_members' to manage the 'members' property of a group record.</p>">
|
|
<properties name="gid" documentation="<p>The group ID. Must be specified numerically. If no group ID is specified when creating a new group, then one will be chosen automatically according to local system standards. This will likely result in the same group having different GIDs on different systems, which is not recommended.</p><p>On Windows, this property is read-only and will return the group's security identifier (SID).</p>"/>
|
|
<properties name="attributes" documentation="<p>Specify group AIX attributes in an array of <tt>key=value</tt> pairs.</p>"/>
|
|
<properties name="members" documentation="<p>The members of the group. For directory services where group membership is stored in the group objects, not the users.</p>"/>
|
|
<parameters name="attribute_membership" documentation="<p>Whether specified attribute value pairs should be treated as the only attributes of the user or whether they should merely be treated as the minimum list.</p>"/>
|
|
<parameters name="system" documentation="<p>Whether the group is a system group with lower GID.</p>"/>
|
|
<parameters name="forcelocal" documentation="<p>Forces the management of local accounts when accounts are also being managed by some other NSS</p>"/>
|
|
<parameters name="name" documentation="<p>The group name. While naming limitations vary by operating system, it is advisable to restrict names to the lowest common denominator, which is a maximum of 8 characters beginning with a letter.</p><p>Note that Puppet considers group names to be case-sensitive, regardless of the platform's own rules; be sure to always use the same case when referring to a given group.</p>" namevar="true"/>
|
|
<parameters name="allowdupe" documentation="<p>Whether to allow duplicate GIDs. Defaults to <tt>false</tt>.</p>"/>
|
|
<parameters name="auth_membership" documentation="<p>whether the provider is authoritative for group membership.</p>"/>
|
|
<parameters name="ia_load_module" documentation="<p>The name of the I&A module to use to manage this user</p>"/>
|
|
<parameters name="ensure" documentation="<p>Create or remove the group.</p>"/>
|
|
</types>
|
|
<types name="zpool" documentation="<p>Manage zpools. Create and delete zpools. The provider WILL NOT SYNC, only report differences.</p><p>Supports vdevs with mirrors, raidz, logs and spares.</p>">
|
|
<properties name="mirror" documentation="<p>List of all the devices to mirror for this pool. Each mirror should be a space separated string:</p><pre> mirror => ["disk1 disk2", "disk3 disk4"],


</pre>"/>
|
|
<properties name="raidz" documentation="<p>List of all the devices to raid for this pool. Should be an array of space separated strings:</p><pre> raidz => ["disk1 disk2", "disk3 disk4"],


</pre>"/>
|
|
<properties name="spare" documentation="<p>Spare disk(s) for this pool.</p>"/>
|
|
<properties name="disk" documentation="<p>The disk(s) for this pool. Can be an array or a space separated string.</p>"/>
|
|
<properties name="log" documentation="<p>Log disks for this pool. This type does not currently support mirroring of log disks.</p>"/>
|
|
<parameters name="pool" documentation="<p>The name for this pool.</p>" namevar="true"/>
|
|
<parameters name="raid_parity" documentation="<p>Determines parity when using the <tt>raidz</tt> parameter.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="schedule" documentation="<p>Define schedules for Puppet. Resources can be limited to a schedule by using the [<tt>schedule</tt>](http://docs.puppetlabs.com/references/latest/metaparameter.html#schedule) metaparameter.</p><p>Currently, <strong>schedules can only be used to stop a resource from being applied;</strong> they cannot cause a resource to be applied when it otherwise wouldn't be, and they cannot accurately specify a time when a resource should run.</p><p>Every time Puppet applies its configuration, it will apply the set of resources whose schedule does not eliminate them from running right then, but there is currently no system in place to guarantee that a given resource runs at a given time. If you specify a very restrictive schedule and Puppet happens to run at a time within that schedule, then the resources will get applied; otherwise, that work may never get done.</p><p>Thus, it is advisable to use wider scheduling (e.g., over a couple of hours) combined with periods and repetitions. For instance, if you wanted to restrict certain resources to only running once, between the hours of two and 4 AM, then you would use this schedule:</p><pre> schedule { 'maint':
 range => "2 - 4",
 period => daily,
 repeat => 1,
 }

</pre><p>With this schedule, the first time that Puppet runs between 2 and 4 AM, all resources with this schedule will get applied, but they won't get applied again between 2 and 4 because they will have already run once that day, and they won't get applied outside that schedule because they will be outside the scheduled range.</p><p>Puppet automatically creates a schedule for each of the valid periods with the same name as that period (e.g., hourly and daily). Additionally, a schedule named <tt>puppet</tt> is created and used as the default, with the following attributes:</p><pre> schedule { 'puppet':
 period => hourly,
 repeat => 2,
 }

</pre><p>This will cause resources to be applied every 30 minutes by default.</p>">
|
|
<parameters name="weekday" documentation="<p>The days of the week in which the schedule should be valid. You may specify the full day name (Tuesday), the three character abbreviation (Tue), or a number corresponding to the day of the week where 0 is Sunday, 1 is Monday, etc. Multiple days can be specified as an array. If not specified, the day of the week will not be considered in the schedule.</p><p>If you are also using a range match that spans across midnight then this parameter will match the day that it was at the start of the range, not necessarily the day that it is when it matches. For example, consider this schedule:</p><pre> schedule { 'maintenance_window':
 range => '22:00 - 04:00',
 weekday => 'Saturday',
 }

</pre><p>This will match at 11 PM on Saturday and 2 AM on Sunday, but not at 2 AM on Saturday.</p>"/>
|
|
<parameters name="range" documentation="<p>The earliest and latest that a resource can be applied. This is always a hyphen-separated range within a 24 hour period, and hours must be specified in numbers between 0 and 23, inclusive. Minutes and seconds can optionally be provided, using the normal colon as a separator. For instance:</p><pre> schedule { 'maintenance':
 range => "1:30 - 4:30",
 }

</pre><p>This is mostly useful for restricting certain resources to being applied in maintenance windows or during off-peak hours. Multiple ranges can be applied in array context. As a convenience when specifying ranges, you may cross midnight (e.g.: range => "22:00 - 04:00").</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the schedule. This name is used when assigning the schedule to a resource with the <tt>schedule</tt> metaparameter:</p><pre> schedule { 'everyday':
 period => daily,
 range => "2 - 4",
 }

 exec { "/usr/bin/apt-get update":
 schedule => 'everyday',
 }
</pre>" namevar="true"/>
|
|
<parameters name="repeat" documentation="<p>How often a given resource may be applied in this schedule's <tt>period</tt>. Defaults to 1; must be an integer.</p>"/>
|
|
<parameters name="period" documentation="<p>The period of repetition for resources on this schedule. The default is for resources to get applied every time Puppet runs.</p><p>Note that the period defines how often a given resource will get applied but not when; if you would like to restrict the hours that a given resource can be applied (e.g., only at night during a maintenance window), then use the <tt>range</tt> attribute.</p><p>If the provided periods are not sufficient, you can provide a value to the <b>repeat</b> attribute, which will cause Puppet to schedule the affected resources evenly in the period the specified number of times. Take this schedule:</p><pre> schedule { 'veryoften':
 period => hourly,
 repeat => 6,
 }

</pre><p>This can cause Puppet to apply that resource up to every 10 minutes.</p><p>At the moment, Puppet cannot guarantee that level of repetition; that is, the resource can applied <i>up to</i> every 10 minutes, but internal factors might prevent it from actually running that often (e.g. if a Puppet run is still in progress when the next run is scheduled to start, that next run will be suppressed).</p><p>See the <tt>periodmatch</tt> attribute for tuning whether to match times by their distance apart or by their specific value.</p>"/>
|
|
<parameters name="periodmatch" documentation="<p>Whether periods should be matched by number (e.g., the two times are in the same hour) or by distance (e.g., the two times are 60 minutes apart).</p>"/>
|
|
</types>
|
|
<types name="selmodule" documentation="<p>Manages loading and unloading of SELinux policy modules on the system. Requires SELinux support. See man semodule(8) for more information on SELinux policy modules.</p><p><strong>Autorequires:</strong> If Puppet is managing the file containing this SELinux policy module (which is either explicitly specified in the <tt>selmodulepath</tt> attribute or will be found at {<tt>selmoduledir</tt>}/{<tt>name</tt>}.pp), the selmodule resource will autorequire that file.</p>">
|
|
<properties name="syncversion" documentation="<p>If set to <tt>true</tt>, the policy will be reloaded if the version found in the on-disk file differs from the loaded version. If set to <tt>false</tt> (the default) the only check that will be made is if the policy is loaded at all or not.</p>"/>
|
|
<parameters name="selmodulepath" documentation="<p>The full path to the compiled .pp policy module. You only need to use this if the module file is not in the <tt>selmoduledir</tt> directory.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the SELinux policy to be managed. You should not include the customary trailing .pp extension.</p>" namevar="true"/>
|
|
<parameters name="selmoduledir" documentation="<p>The directory to look for the compiled pp module file in. Currently defaults to <tt>/usr/share/selinux/targeted</tt>. If the <tt>selmodulepath</tt> attribute is not specified, Puppet will expect to find the module in <tt><selmoduledir>/<name>.pp</tt>, where <tt>name</tt> is the value of the <tt>name</tt> parameter.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="yumrepo" documentation="<p>The client-side description of a yum repository. Repository configurations are found by parsing <tt>/etc/yum.conf</tt> and the files indicated by the <tt>reposdir</tt> option in that file (see <tt>yum.conf(5)</tt> for details).</p><p>Most parameters are identical to the ones documented in the <tt>yum.conf(5)</tt> man page.</p><p>Continuation lines that yum supports (for the <tt>baseurl</tt>, for example) are not supported. This type does not attempt to read or verify the exinstence of files listed in the <tt>include</tt> attribute.</p>">
|
|
<properties name="s3_enabled" documentation=""/>
|
|
<properties name="metadata_expire" documentation=""/>
|
|
<properties name="throttle" documentation=""/>
|
|
<properties name="repo_gpgcheck" documentation=""/>
|
|
<properties name="protect" documentation=""/>
|
|
<properties name="includepkgs" documentation=""/>
|
|
<properties name="gpgcakey" documentation=""/>
|
|
<properties name="bandwidth" documentation=""/>
|
|
<properties name="metalink" documentation=""/>
|
|
<properties name="proxy_username" documentation=""/>
|
|
<properties name="gpgcheck" documentation=""/>
|
|
<properties name="gpgkey" documentation=""/>
|
|
<properties name="priority" documentation=""/>
|
|
<properties name="sslverify" documentation=""/>
|
|
<properties name="proxy" documentation=""/>
|
|
<properties name="mirrorlist" documentation=""/>
|
|
<properties name="keepalive" documentation=""/>
|
|
<properties name="mirrorlist_expire" documentation=""/>
|
|
<properties name="proxy_password" documentation=""/>
|
|
<properties name="enabled" documentation=""/>
|
|
<properties name="sslclientkey" documentation=""/>
|
|
<properties name="exclude" documentation=""/>
|
|
<properties name="http_caching" documentation=""/>
|
|
<properties name="cost" documentation=""/>
|
|
<properties name="include" documentation=""/>
|
|
<properties name="sslcacert" documentation=""/>
|
|
<properties name="skip_if_unavailable" documentation=""/>
|
|
<properties name="retries" documentation=""/>
|
|
<properties name="baseurl" documentation=""/>
|
|
<properties name="failovermethod" documentation=""/>
|
|
<properties name="sslclientcert" documentation=""/>
|
|
<properties name="descr" documentation=""/>
|
|
<properties name="enablegroups" documentation=""/>
|
|
<properties name="timeout" documentation=""/>
|
|
<parameters name="name" documentation="<p>The name of the repository. This corresponds to the <tt>repositoryid</tt> parameter in <tt>yum.conf(5)</tt>.</p>"/>
|
|
<parameters name="target" documentation="<p>The filename to write the yum repository to.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="vlan" documentation="<p>Manages a VLAN on a router or switch.</p>">
|
|
<properties name="description" documentation="<p>The VLAN's name.</p>"/>
|
|
<parameters name="name" documentation="<p>The numeric VLAN ID.</p>" namevar="true"/>
|
|
<parameters name="device_url" documentation="<p>The URL of the router or switch maintaining this VLAN.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="router" documentation="<p>Manages connected router.</p>">
|
|
<parameters name="url" documentation="<p>An SSH or telnet URL at which to access the router, in the form <tt>ssh://user:pass:enable@host/</tt> or <tt>telnet://user:pass:enable@host/</tt>.</p>" namevar="true"/>
|
|
</types>
|
|
<types name="exec" documentation="<p>Executes external commands.</p><p>Any command in an <tt>exec</tt> resource <strong>must</strong> be able to run multiple times without causing harm --- that is, it must be <b>idempotent</b>. There are three main ways for an exec to be idempotent:</p><ul><li><p>The command itself is already idempotent. (For example, <tt>apt-get update</tt>.)</p></li><li><p>The exec has an <tt>onlyif</tt>, <tt>unless</tt>, or <tt>creates</tt> attribute, which prevents Puppet from running the command unless some condition is met.</p></li><li><p>The exec has <tt>refreshonly => true</tt>, which only allows Puppet to run the command when some other resource is changed. (See the notes on refreshing below.)</p></li></ul><p>A caution: There's a widespread tendency to use collections of execs to manage resources that aren't covered by an existing resource type. This works fine for simple tasks, but once your exec pile gets complex enough that you really have to think to understand what's happening, you should consider developing a custom resource type instead, as it will be much more predictable and maintainable.</p><p><strong>Refresh:</strong> <tt>exec</tt> resources can respond to refresh events (via <tt>notify</tt>, <tt>subscribe</tt>, or the <tt>~></tt> arrow). The refresh behavior of execs is non-standard, and can be affected by the <tt>refresh</tt> and <tt>refreshonly</tt> attributes:</p><ul><li><p>If <tt>refreshonly</tt> is set to true, the exec will <i>only</i> run when it receives an event. This is the most reliable way to use refresh with execs.</p></li><li><p>If the exec already would have run and receives an event, it will run its command <strong>up to two times.</strong> (If an <tt>onlyif</tt>, <tt>unless</tt>, or <tt>creates</tt> condition is no longer met after the first run, the second run will not occur.)</p></li><li><p>If the exec already would have run, has a <tt>refresh</tt> command, and receives an event, it will run its normal command, then run its <tt>refresh</tt> command (as long as any <tt>onlyif</tt>, <tt>unless</tt>, or <tt>creates</tt> conditions are still met after the normal command finishes).</p></li><li><p>If the exec would <strong>not</strong> have run (due to an <tt>onlyif</tt>, <tt>unless</tt>, or <tt>creates</tt> attribute) and receives an event, it still will not run.</p></li><li><p>If the exec has <tt>noop => true</tt>, would otherwise have run, and receives an event from a non-noop resource, it will run once (or run its <tt>refresh</tt> command instead, if it has one).</p></li></ul><p>In short: If there's a possibility of your exec receiving refresh events, it becomes doubly important to make sure the run conditions are restricted.</p><p><strong>Autorequires:</strong> If Puppet is managing an exec's cwd or the executable file used in an exec's command, the exec resource will autorequire those files. If Puppet is managing the user that an exec should run as, the exec resource will autorequire that user.</p>">
|
|
<properties name="returns" documentation="<p>The expected exit code(s). An error will be returned if the executed command has some other exit code. Defaults to 0. Can be specified as an array of acceptable exit codes or a single value.</p><p>On POSIX systems, exit codes are always integers between 0 and 255.</p><p>On Windows, <strong>most</strong> exit codes should be integers between 0 and 2147483647.</p><p>Larger exit codes on Windows can behave inconsistently across different tools. The Win32 APIs define exit codes as 32-bit unsigned integers, but both the cmd.exe shell and the .NET runtime cast them to signed integers. This means some tools will report negative numbers for exit codes above 2147483647. (For example, cmd.exe reports 4294967295 as -1.) Since Puppet uses the plain Win32 APIs, it will report the very large number instead of the negative number, which might not be what you expect if you got the exit code from a cmd.exe session.</p><p>Microsoft recommends against using negative/very large exit codes, and you should avoid them when possible. To convert a negative exit code to the positive one Puppet will use, add it to 4294967296.</p>"/>
|
|
<parameters name="logoutput" documentation="<p>Whether to log command output in addition to logging the exit code. Defaults to <tt>on_failure</tt>, which only logs the output when the command has an exit code that does not match any value specified by the <tt>returns</tt> attribute. As with any resource type, the log level can be controlled with the <tt>loglevel</tt> metaparameter.</p>"/>
|
|
<parameters name="umask" documentation="<p>Sets the umask to be used while executing this command</p>"/>
|
|
<parameters name="onlyif" documentation="<p>If this parameter is set, then this <tt>exec</tt> will only run if the command has an exit code of 0. For example:</p><pre> exec { "logrotate":
 path => "/usr/bin:/usr/sbin:/bin",
 onlyif => "test `du /var/log/messages | cut -f1` -gt 100000"
 }

</pre><p>This would run <tt>logrotate</tt> only if that test returned true.</p><p>Note that this command follows the same rules as the main command, which is to say that it must be fully qualified if the path is not set. It also uses the same provider as the main command, so any behavior that differs by provider will match.</p><p>Also note that onlyif can take an array as its value, e.g.:</p><pre> onlyif => ["test -f /tmp/file1", "test -f /tmp/file2"]

</pre><p>This will only run the exec if <i>all</i> conditions in the array return true.</p>"/>
|
|
<parameters name="cwd" documentation="<p>The directory from which to run the command. If this directory does not exist, the command will fail.</p>"/>
|
|
<parameters name="creates" documentation="<p>A file to look for before running the command. The command will only run if the file <strong>doesn't exist.</strong></p><p>This parameter doesn't cause Puppet to create a file; it is only useful if <strong>the command itself</strong> creates a file.</p><pre> exec { "tar -xf /Volumes/nfs02/important.tar":
 cwd => "/var/tmp",
 creates => "/var/tmp/myfile",
 path => ["/usr/bin", "/usr/sbin"]
 }

</pre><p>In this example, <tt>myfile</tt> is assumed to be a file inside <tt>important.tar</tt>. If it is ever deleted, the exec will bring it back by re-extracting the tarball. If <tt>important.tar</tt> does <strong>not</strong> actually contain <tt>myfile</tt>, the exec will keep running every time Puppet runs.</p>"/>
|
|
<parameters name="refreshonly" documentation="<p>The command should only be run as a refresh mechanism for when a dependent object is changed. It only makes sense to use this option when this command depends on some other object; it is useful for triggering an action:</p><pre> # Pull down the main aliases file
 file { "/etc/aliases":
 source => "puppet://server/module/aliases"
 }

 # Rebuild the database, but only when the file changes
 exec { newaliases:
 path => ["/usr/bin", "/usr/sbin"],
 subscribe => File["/etc/aliases"],
 refreshonly => true
 }

</pre><p>Note that only <tt>subscribe</tt> and <tt>notify</tt> can trigger actions, not <tt>require</tt>, so it only makes sense to use <tt>refreshonly</tt> with <tt>subscribe</tt> or <tt>notify</tt>.</p>"/>
|
|
<parameters name="environment" documentation="<p>Any additional environment variables you want to set for a command. Note that if you use this to set PATH, it will override the <tt>path</tt> attribute. Multiple environment variables should be specified as an array.</p>"/>
|
|
<parameters name="unless" documentation="<p>If this parameter is set, then this <tt>exec</tt> will run unless the command has an exit code of 0. For example:</p><pre> exec { "/bin/echo root >> /usr/lib/cron/cron.allow":
 path => "/usr/bin:/usr/sbin:/bin",
 unless => "grep root /usr/lib/cron/cron.allow 2>/dev/null"
 }

</pre><p>This would add <tt>root</tt> to the cron.allow file (on Solaris) unless <tt>grep</tt> determines it's already there.</p><p>Note that this command follows the same rules as the main command, which is to say that it must be fully qualified if the path is not set. It also uses the same provider as the main command, so any behavior that differs by provider will match.</p>"/>
|
|
<parameters name="try_sleep" documentation="<p>The time to sleep in seconds between 'tries'.</p>"/>
|
|
<parameters name="command" documentation="<p>The actual command to execute. Must either be fully qualified or a search path for the command must be provided. If the command succeeds, any output produced will be logged at the instance's normal log level (usually <tt>notice</tt>), but if the command fails (meaning its return code does not match the specified code) then any output is logged at the <tt>err</tt> log level.</p>" namevar="true"/>
|
|
<parameters name="path" documentation=""/>
|
|
<parameters name="tries" documentation="<p>The number of times execution of the command should be tried. Defaults to '1'. This many attempts will be made to execute the command until an acceptable return code is returned. Note that the timeout paramater applies to each try rather than to the complete set of tries.</p>"/>
|
|
<parameters name="group" documentation="<p>The group to run the command as. This seems to work quite haphazardly on different platforms -- it is a platform issue not a Ruby or Puppet one, since the same variety exists when running commands as different users in the shell.</p>"/>
|
|
<parameters name="user" documentation="<p>The user to run the command as. Note that if you use this then any error output is not currently captured. This is because of a bug within Ruby. If you are using Puppet to create this user, the exec will automatically require the user, as long as it is specified by name.</p><p>Please note that the $HOME environment variable is not automatically set when using this attribute.</p>"/>
|
|
<parameters name="refresh" documentation="<p>How to refresh this command. By default, the exec is just called again when it receives an event from another resource, but this parameter allows you to define a different command for refreshing.</p>"/>
|
|
<parameters name="timeout" documentation="<p>The maximum time the command should take. If the command takes longer than the timeout, the command is considered to have failed and will be stopped. The timeout is specified in seconds. The default timeout is 300 seconds and you can set it to 0 to disable the timeout.</p>"/>
|
|
</types>
|
|
<types name="package" documentation="<p>Manage packages. There is a basic dichotomy in package support right now: Some package types (e.g., yum and apt) can retrieve their own package files, while others (e.g., rpm and sun) cannot. For those package formats that cannot retrieve their own files, you can use the <tt>source</tt> parameter to point to the correct file.</p><p>Puppet will automatically guess the packaging format that you are using based on the platform you are on, but you can override it using the <tt>provider</tt> parameter; each provider defines what it requires in order to function, and you must meet those requirements to use a given provider.</p><p><strong>Autorequires:</strong> If Puppet is managing the files specified as a package's <tt>adminfile</tt>, <tt>responsefile</tt>, or <tt>source</tt>, the package resource will autorequire those files.</p>">
|
|
<properties name="package_settings" documentation="<p>Settings that can change the contents or configuration of a package.</p><p>The formatting and effects of package_settings are provider-specific; any provider that implements them must explain how to use them in its documentation. (Our general expectation is that if a package is installed but its settings are out of sync, the provider should re-install that package with the desired settings.)</p><p>An example of how package_settings could be used is FreeBSD's port build options --- a future version of the provider could accept a hash of options, and would reinstall the port if the installed version lacked the correct settings.</p><pre> package { 'www/apache22':
 package_settings => { 'SUEXEC' => false }
 }

</pre><p>Again, check the documentation of your platform's package provider to see the actual usage.</p>"/>
|
|
<parameters name="platform" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="status" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="root" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="vendor" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="flavor" documentation="<p>OpenBSD supports 'flavors', which are further specifications for which type of package you want.</p>"/>
|
|
<parameters name="allowcdrom" documentation="<p>Tells apt to allow cdrom sources in the sources.list file. Normally apt will bail if you try this.</p>"/>
|
|
<parameters name="configfiles" documentation="<p>Whether configfiles should be kept or replaced. Most packages types do not support this parameter. Defaults to <tt>keep</tt>.</p>"/>
|
|
<parameters name="uninstall_options" documentation="<p>An array of additional options to pass when uninstalling a package. These options are package-specific, and should be documented by the software vendor. For example:</p><pre> package { 'VMware Tools':
 ensure => absent,
 uninstall_options => [ { 'REMOVE' => 'Sync,VSS' } ],
 }

</pre><p>Each option in the array can either be a string or a hash, where each key and value pair are interpreted in a provider specific way. Each option will automatically be quoted when passed to the uninstall command.</p><p>On Windows, this is the <strong>only</strong> place in Puppet where backslash separators should be used. Note that backslashes in double-quoted strings <i>must</i> be double-escaped and backslashes in single-quoted strings <i>may</i> be double-escaped.</p>"/>
|
|
<parameters name="install_options" documentation="<p>An array of additional options to pass when installing a package. These options are package-specific, and should be documented by the software vendor. One commonly implemented option is <tt>INSTALLDIR</tt>:</p><pre> package { 'mysql':
 ensure => installed,
 source => 'N:/packages/mysql-5.5.16-winx64.msi',
 install_options => [ '/S', { 'INSTALLDIR' => 'C:\mysql-5.5' } ],
 }

</pre><p>Each option in the array can either be a string or a hash, where each key and value pair are interpreted in a provider specific way. Each option will automatically be quoted when passed to the install command.</p><p>On Windows, this is the <strong>only</strong> place in Puppet where backslash separators should be used. Note that backslashes in double-quoted strings <i>must</i> be double-escaped and backslashes in single-quoted strings <i>may</i> be double-escaped.</p>"/>
|
|
<parameters name="category" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="source" documentation="<p>Where to find the actual package. This must be a local file (or on a network file system) or a URL that your specific packaging type understands; Puppet will not retrieve files for you, although you can manage packages as <tt>file</tt> resources.</p>"/>
|
|
<parameters name="responsefile" documentation="<p>A file containing any necessary answers to questions asked by the package. This is currently used on Solaris and Debian. The value will be validated according to system rules, but it should generally be a fully qualified path.</p>"/>
|
|
<parameters name="description" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="allow_virtual" documentation="<p>Specifies if virtual package names are allowed for install and uninstall.</p>"/>
|
|
<parameters name="name" documentation="<p>The package name. This is the name that the packaging system uses internally, which is sometimes (especially on Solaris) a name that is basically useless to humans. If you want to abstract package installation, then you can use aliases to provide a common name to packages:</p><pre> # In the 'openssl' class
 $ssl = $operatingsystem ? {
 solaris => SMCossl,
 default => openssl
 }

 # It is not an error to set an alias to the same value as the
 # object name.
 package { $ssl:
 ensure => installed,
 alias => openssl
 }

 . etc. .

 $ssh = $operatingsystem ? {
 solaris => SMCossh,
 default => openssh
 }

 # Use the alias to specify a dependency, rather than
 # having another selector to figure it out again.
 package { $ssh:
 ensure => installed,
 alias => openssh,
 require => Package[openssl]
 }


</pre>" namevar="true"/>
|
|
<parameters name="instance" documentation="<p>A read-only parameter set by the package.</p>"/>
|
|
<parameters name="adminfile" documentation="<p>A file containing package defaults for installing packages. This is currently only used on Solaris. The value will be validated according to system rules, which in the case of Solaris means that it should either be a fully qualified path or it should be in <tt>/var/sadm/install/admin</tt>.</p>"/>
|
|
<parameters name="ensure" documentation="<p>What state the package should be in. On packaging systems that can retrieve new packages on their own, you can choose which package to retrieve by specifying a version number or <tt>latest</tt> as the ensure value. On packaging systems that manage configuration files separately from "normal" system files, you can uninstall config files by specifying <tt>purged</tt> as the ensure value. This defaults to <tt>installed</tt>.</p>"/>
|
|
</types>
|
|
<types name="stage" documentation="">
|
|
<parameters name="name" documentation="<p>The name of the stage. Use this as the value for the <tt>stage</tt> metaparameter when assigning classes to this stage.</p>"/>
|
|
</types>
|
|
<types name="augeas" documentation="<p>Apply a change or an array of changes to the filesystem using the augeas tool.</p><p>Requires:</p><ul><li><p>[Augeas](http://www.augeas.net)</p></li><li><p>The ruby-augeas bindings</p></li></ul><p>Sample usage with a string:</p><pre> augeas{"test1" :
 context => "/files/etc/sysconfig/firstboot",
 changes => "set RUN_FIRSTBOOT YES",
 onlyif => "match other_value size > 0",
 }

</pre><p>Sample usage with an array and custom lenses:</p><pre> augeas{"jboss_conf":
 context => "/files",
 changes => [
 "set etc/jbossas/jbossas.conf/JBOSS_IP $ipaddress",
 "set etc/jbossas/jbossas.conf/JAVA_HOME /usr",
 ],
 load_path => "$/usr/share/jbossas/lenses",
 }
</pre>">
|
|
<properties name="returns" documentation="<p>The expected return code from the augeas command. Should not be set.</p>"/>
|
|
<parameters name="incl" documentation="<p>Load only a specific file, e.g. <tt>/etc/hosts</tt>. This can greatly speed up the execution the resource. When this parameter is set, you must also set the <tt>lens</tt> parameter to indicate which lens to use.</p>"/>
|
|
<parameters name="show_diff" documentation="<p>Whether to display differences when the file changes, defaulting to true. This parameter is useful for files that may contain passwords or other secret data, which might otherwise be included in Puppet reports or other insecure outputs. If the global <tt>show_diff</tt> setting is false, then no diffs will be shown even if this parameter is true.</p>"/>
|
|
<parameters name="type_check" documentation="<p>Whether augeas should perform typechecking. Defaults to false.</p>"/>
|
|
<parameters name="load_path" documentation="<p>Optional colon-separated list or array of directories; these directories are searched for schema definitions. The agent's <tt>$libdir/augeas/lenses</tt> path will always be added to support pluginsync.</p>"/>
|
|
<parameters name="root" documentation="<p>A file system path; all files loaded by Augeas are loaded underneath <tt>root</tt>.</p>"/>
|
|
<parameters name="onlyif" documentation="<p>Optional augeas command and comparisons to control the execution of this type. Supported onlyif syntax:</p><ul><li><p><tt>get <AUGEAS_PATH> <COMPARATOR> <STRING></tt></p></li><li><p><tt>match <MATCH_PATH> size <COMPARATOR> <INT></tt></p></li><li><p><tt>match <MATCH_PATH> include <STRING></tt></p></li><li><p><tt>match <MATCH<i>PATH> not</i>include <STRING></tt></p></li><li><p><tt>match <MATCH<i>PATH> == <AN</i>ARRAY></tt></p></li><li><p><tt>match <MATCH<i>PATH> != <AN</i>ARRAY></tt></p></li></ul><p>where:</p><ul><li><p><tt>AUGEAS_PATH</tt> is a valid path scoped by the context</p></li><li><p><tt>MATCH_PATH</tt> is a valid match syntax scoped by the context</p></li><li><p><tt>COMPARATOR</tt> is one of <tt>>, >=, !=, ==, <=,</tt> or <tt><</tt></p></li><li><p><tt>STRING</tt> is a string</p></li><li><p><tt>INT</tt> is a number</p></li><li><p><tt>AN_ARRAY</tt> is in the form <tt>['a string', 'another']</tt></p></li></ul>"/>
|
|
<parameters name="name" documentation="<p>The name of this task. Used for uniqueness.</p>" namevar="true"/>
|
|
<parameters name="context" documentation="<p>Optional context path. This value is prepended to the paths of all changes if the path is relative. If the <tt>incl</tt> parameter is set, defaults to <tt>/files + incl</tt>; otherwise, defaults to the empty string.</p>"/>
|
|
<parameters name="force" documentation="<p>Optional command to force the augeas type to execute even if it thinks changes will not be made. This does not overide the <tt>onlyif</tt> parameter.</p>"/>
|
|
<parameters name="lens" documentation="<p>Use a specific lens, e.g. <tt>Hosts.lns</tt>. When this parameter is set, you must also set the <tt>incl</tt> parameter to indicate which file to load. The Augeas documentation includes [a list of available lenses](http://augeas.net/stock_lenses.html).</p>"/>
|
|
<parameters name="changes" documentation="<p>The changes which should be applied to the filesystem. This can be a command or an array of commands. The following commands are supported:</p><ul><li><p><tt>set <PATH> <VALUE></tt> --- Sets the value <tt>VALUE</tt> at loction <tt>PATH</tt></p></li><li><p><tt>setm <PATH> <SUB> <VALUE></tt> --- Sets multiple nodes (matching <tt>SUB</tt> relative to <tt>PATH</tt>) to <tt>VALUE</tt></p></li><li><p><tt>rm <PATH></tt> --- Removes the node at location <tt>PATH</tt></p></li><li><p><tt>remove <PATH></tt> --- Synonym for <tt>rm</tt></p></li><li><p><tt>clear <PATH></tt> --- Sets the node at <tt>PATH</tt> to <tt>NULL</tt>, creating it if needed</p></li><li><p><tt>clearm <PATH> <SUB></tt> --- Sets multiple nodes (matching <tt>SUB</tt> relative to <tt>PATH</tt>) to <tt>NULL</tt></p></li><li><p><tt>ins <LABEL> (before|after) <PATH></tt> --- Inserts an empty node <tt>LABEL</tt> either before or after <tt>PATH</tt>.</p></li><li><p><tt>insert <LABEL> <WHERE> <PATH></tt> --- Synonym for <tt>ins</tt></p></li><li><p><tt>mv <PATH> <OTHER PATH></tt> --- Moves a node at <tt>PATH</tt> to the new location <tt>OTHER PATH</tt></p></li><li><p><tt>move <PATH> <OTHER PATH></tt> --- Synonym for <tt>mv</tt></p></li><li><p><tt>defvar <NAME> <PATH></tt> --- Sets Augeas variable <tt>$NAME</tt> to <tt>PATH</tt></p></li><li><p><tt>defnode <NAME> <PATH> <VALUE></tt> --- Sets Augeas variable <tt>$NAME</tt> to <tt>PATH</tt>, creating it with <tt>VALUE</tt> if needed</p></li></ul><p>If the <tt>context</tt> parameter is set, that value is prepended to any relative <tt>PATH</tt>s.</p>"/>
|
|
</types>
|
|
<types name="k5login" documentation="<p>Manage the <tt>.k5login</tt> file for a user. Specify the full path to the <tt>.k5login</tt> file as the name, and an array of principals as the <tt>principals</tt> attribute.</p>">
|
|
<properties name="principals" documentation="<p>The principals present in the <tt>.k5login</tt> file. This should be specified as an array.</p>"/>
|
|
<properties name="mode" documentation="<p>The desired permissions mode of the <tt>.k5login</tt> file. Defaults to <tt>644</tt>.</p>"/>
|
|
<parameters name="path" documentation="<p>The path to the <tt>.k5login</tt> file to manage. Must be fully qualified.</p>" namevar="true"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="mailalias" documentation="<p>Creates an email alias in the local alias database.</p>">
|
|
<properties name="target" documentation="<p>The file in which to store the aliases. Only used by those providers that write to disk.</p>"/>
|
|
<properties name="recipient" documentation="<p>Where email should be sent. Multiple values should be specified as an array.</p>"/>
|
|
<parameters name="name" documentation="<p>The alias name.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="component" documentation="">
|
|
<parameters name="name" documentation="<p>The name of the component. Generally optional.</p>" namevar="true"/>
|
|
</types>
|
|
<types name="scheduled_task" documentation="<p>Installs and manages Windows Scheduled Tasks. All attributes except <tt>name</tt>, <tt>command</tt>, and <tt>trigger</tt> are optional; see the description of the <tt>trigger</tt> attribute for details on setting schedules.</p>">
|
|
<properties name="trigger" documentation="<p>One or more triggers defining when the task should run. A single trigger is represented as a hash, and multiple triggers can be specified with an array of hashes.</p><p>A trigger can contain the following keys:</p><ul><li><p>For all triggers:<pre>* `schedule` **(Required)** --- The schedule type. Valid values are
 `daily`, `weekly`, `monthly`, or `once`.
* `start_time` **(Required)** --- The time of day when the trigger should
 first become active. Several time formats will work, but we
 suggest 24-hour time formatted as HH:MM.
* `start_date` --- The date when the trigger should first become active.
 Defaults to the current date. You should format dates as YYYY-MM-DD,
 although other date formats may work. (Under the hood, this uses `Date.parse`.)
</pre></p></li><li><p>For daily triggers:<pre>* `every` --- How often the task should run, as a number of days. Defaults
 to 1. ("2" means every other day, "3" means every three days, etc.)
</pre></p></li><li><p>For weekly triggers:<pre>* `every` --- How often the task should run, as a number of weeks. Defaults
 to 1. ("2" means every other week, "3" means every three weeks, etc.)
* `day_of_week` --- Which days of the week the task should run, as an array.
 Defaults to all days. Each day must be one of `mon`, `tues`,
 `wed`, `thurs`, `fri`, `sat`, `sun`, or `all`.
</pre></p></li><li><p>For monthly-by-date triggers:<pre>* `months` --- Which months the task should run, as an array. Defaults to
 all months. Each month must be an integer between 1 and 12.
* `on` **(Required)** --- Which days of the month the task should run,
 as an array. Each day must beeither an integer between 1 and 31,
 or the special value `last,` which is always the last day of the month.
</pre></p></li><li><p>For monthly-by-weekday triggers:<pre>* `months` --- Which months the task should run, as an array. Defaults to
 all months. Each month must be an integer between 1 and 12.
* `day_of_week` **(Required)** --- Which day of the week the task should
 run, as an array with only one element. Each day must be one of `mon`,
 `tues`, `wed`, `thurs`, `fri`, `sat`, `sun`, or `all`.
* `which_occurrence` **(Required)** --- The occurrence of the chosen weekday
 when the task should run. Must be one of `first`, `second`, `third`,
 `fourth`, `fifth`, or `last`.

</pre></p></li></ul><p>Examples:</p><pre> # Run at 8am on the 1st, 15th, and last day of the month in January, March,
 # May, July, September, and November, starting after August 31st, 2011.
 trigger => {
 schedule => monthly,
 start_date => '2011-08-31', # Defaults to current date
 start_time => '08:00', # Must be specified
 months => [1,3,5,7,9,11], # Defaults to all
 on => [1, 15, last], # Must be specified
 }

 # Run at 8am on the first Monday of the month for January, March, and May,
 # starting after August 31st, 2011.
 trigger => {
 schedule => monthly,
 start_date => '2011-08-31', # Defaults to current date
 start_time => '08:00', # Must be specified
 months => [1,3,5], # Defaults to all
 which_occurrence => first, # Must be specified
 day_of_week => [mon], # Must be specified
 }
</pre>"/>
|
|
<properties name="enabled" documentation="<p>Whether the triggers for this task should be enabled. This attribute affects every trigger for the task; triggers cannot be enabled or disabled individually.</p>"/>
|
|
<properties name="arguments" documentation="<p>Any arguments or flags that should be passed to the command. Multiple arguments should be specified as a space-separated string.</p>"/>
|
|
<properties name="command" documentation="<p>The full path to the application to run, without any arguments.</p>"/>
|
|
<properties name="working_dir" documentation="<p>The full path of the directory in which to start the command.</p>"/>
|
|
<properties name="user" documentation="<p>The user to run the scheduled task as. Please note that not all security configurations will allow running a scheduled task as 'SYSTEM', and saving the scheduled task under these conditions will fail with a reported error of 'The operation completed successfully'. It is recommended that you either choose another user to run the scheduled task, or alter the security policy to allow v1 scheduled tasks to run as the 'SYSTEM' account. Defaults to 'SYSTEM'.</p><p>Please also note that Puppet must be running as a privileged user in order to manage <tt>scheduled_task</tt> resources. Running as an unprivileged user will result in 'access denied' errors.</p>"/>
|
|
<parameters name="name" documentation="<p>The name assigned to the scheduled task. This will uniquely identify the task on the system.</p>" namevar="true"/>
|
|
<parameters name="password" documentation="<p>The password for the user specified in the 'user' attribute. This is only used if specifying a user other than 'SYSTEM'. Since there is no way to retrieve the password used to set the account information for a task, this parameter will not be used to determine if a scheduled task is in sync or not.</p>"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="macauthorization" documentation="<p>Manage the Mac OS X authorization database. See the [Apple developer site](http://developer.apple.com/documentation/Security/Conceptual/Security<i>Overview/Security</i>Services/chapter<i>4</i>section_5.html) for more information.</p><p>Note that authorization store directives with hyphens in their names have been renamed to use underscores, as Puppet does not react well to hyphens in identifiers.</p><p><strong>Autorequires:</strong> If Puppet is managing the <tt>/etc/authorization</tt> file, each macauthorization resource will autorequire it.</p>">
|
|
<properties name="shared" documentation="<p>Whether the Security Server should mark the credentials used to gain this right as shared. The Security Server may use any shared credentials to authorize this right. For maximum security, set sharing to false so credentials stored by the Security Server for one application may not be used by another application.</p>"/>
|
|
<properties name="session_owner" documentation="<p>Whether the session owner automatically matches this rule or right. Corresponds to <tt>session-owner</tt> in the authorization store.</p>"/>
|
|
<properties name="allow_root" documentation="<p>Corresponds to <tt>allow-root</tt> in the authorization store. Specifies whether a right should be allowed automatically if the requesting process is running with <tt>uid == 0</tt>. AuthorizationServices defaults this attribute to false if not specified.</p>"/>
|
|
<properties name="k_of_n" documentation="<p>How large a subset of rule mechanisms must succeed for successful authentication. If there are 'n' mechanisms, then 'k' (the integer value of this parameter) mechanisms must succeed. The most common setting for this parameter is <tt>1</tt>. If <tt>k-of-n</tt> is not set, then every mechanism --- that is, 'n-of-n' --- must succeed.</p>"/>
|
|
<properties name="authenticate_user" documentation="<p>Corresponds to <tt>authenticate-user</tt> in the authorization store.</p>"/>
|
|
<properties name="auth_class" documentation="<p>Corresponds to <tt>class</tt> in the authorization store; renamed due to 'class' being a reserved word in Puppet.</p>"/>
|
|
<properties name="auth_type" documentation="<p>Type --- this can be a <tt>right</tt> or a <tt>rule</tt>. The <tt>comment</tt> type has not yet been implemented.</p>"/>
|
|
<properties name="rule" documentation="<p>The rule(s) that this right refers to.</p>"/>
|
|
<properties name="tries" documentation="<p>The number of tries allowed.</p>"/>
|
|
<properties name="group" documentation="<p>A group which the user must authenticate as a member of. This must be a single group.</p>"/>
|
|
<properties name="comment" documentation="<p>The <tt>comment</tt> attribute for authorization resources.</p>"/>
|
|
<properties name="mechanisms" documentation="<p>An array of suitable mechanisms.</p>"/>
|
|
<properties name="timeout" documentation="<p>The number of seconds in which the credential used by this rule will expire. For maximum security where the user must authenticate every time, set the timeout to 0. For minimum security, remove the timeout attribute so the user authenticates only once per session.</p>"/>
|
|
<parameters name="name" documentation="<p>The name of the right or rule to be managed. Corresponds to <tt>key</tt> in Authorization Services. The key is the name of a rule. A key uses the same naming conventions as a right. The Security Server uses a rule's key to match the rule with a right. Wildcard keys end with a '.'. The generic rule has an empty key value. Any rights that do not match a specific rule use the generic rule.</p>" namevar="true"/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="filebucket" documentation="<p>A repository for storing and retrieving file content by MD5 checksum. Can be local to each agent node, or centralized on a puppet master server. All puppet masters provide a filebucket service that agent nodes can access via HTTP, but you must declare a filebucket resource before any agents will do so.</p><p>Filebuckets are used for the following features:</p><ul><li><p><strong>Content backups.</strong> If the <tt>file</tt> type's <tt>backup</tt> attribute is set to the name of a filebucket, Puppet will back up the <i>old</i> content whenever it rewrites a file; see the documentation for the <tt>file</tt> type for more details. These backups can be used for manual recovery of content, but are more commonly used to display changes and differences in a tool like Puppet Dashboard.</p></li><li><p><strong>Content distribution.</strong> The optional static compiler populates the puppet master's filebucket with the <i>desired</i> content for each file, then instructs the agent to retrieve the content for a specific checksum. For more details, [see the <tt>static_compiler</tt> section in the catalog indirection docs](http://docs.puppetlabs.com/references/latest/indirection.html#catalog).</p></li></ul><p>To use a central filebucket for backups, you will usually want to declare a filebucket resource and a resource default for the <tt>backup</tt> attribute in site.pp:</p><pre> # /etc/puppet/manifests/site.pp
 filebucket { 'main':
 path => false, # This is required for remote filebuckets.
 server => 'puppet.example.com', # Optional; defaults to the configured puppet master.
 }

 File { backup => main, }

</pre><p>Puppet master servers automatically provide the filebucket service, so this will work in a default configuration. If you have a heavily restricted <tt>auth.conf</tt> file, you may need to allow access to the <tt>file<i>bucket</i>file</tt> endpoint.</p>">
|
|
<parameters name="port" documentation=""/>
|
|
<parameters name="name" documentation="<p>The name of the filebucket.</p>" namevar="true"/>
|
|
<parameters name="path" documentation="<p>The path to the <i>local</i> filebucket; defaults to the value of the <tt>clientbucketdir</tt> setting. To use a remote filebucket, you <i>must</i> set this attribute to <tt>false</tt>.</p>"/>
|
|
<parameters name="server" documentation="<p>The server providing the remote filebucket service. Defaults to the value of the <tt>server</tt> setting (that is, the currently configured puppet master server).</p><p>This setting is <i>only</i> consulted if the <tt>path</tt> attribute is set to <tt>false</tt>.</p>"/>
|
|
</types>
|
|
<types name="nagios_host" documentation="">
|
|
<parameters name="notification_period" documentation=""/>
|
|
<parameters name="icon_image" documentation=""/>
|
|
<parameters name="check_interval" documentation=""/>
|
|
<parameters name="max_check_attempts" documentation=""/>
|
|
<parameters name="contacts" documentation=""/>
|
|
<parameters name="passive_checks_enabled" documentation=""/>
|
|
<parameters name="realm" documentation=""/>
|
|
<parameters name="check_freshness" documentation=""/>
|
|
<parameters name="action_url" documentation=""/>
|
|
<parameters name="event_handler_enabled" documentation=""/>
|
|
<parameters name="stalking_options" documentation=""/>
|
|
<parameters name="3d_coords" documentation=""/>
|
|
<parameters name="retry_interval" documentation=""/>
|
|
<parameters name="first_notification_delay" documentation=""/>
|
|
<parameters name="display_name" documentation=""/>
|
|
<parameters name="initial_state" documentation=""/>
|
|
<parameters name="retain_nonstatus_information" documentation=""/>
|
|
<parameters name="check_command" documentation=""/>
|
|
<parameters name="parents" documentation=""/>
|
|
<parameters name="process_perf_data" documentation=""/>
|
|
<parameters name="vrml_image" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="obsess_over_host" documentation=""/>
|
|
<parameters name="poller_tag" documentation=""/>
|
|
<parameters name="freshness_threshold" documentation=""/>
|
|
<parameters name="failure_prediction_enabled" documentation=""/>
|
|
<parameters name="notes_url" documentation=""/>
|
|
<parameters name="high_flap_threshold" documentation=""/>
|
|
<parameters name="active_checks_enabled" documentation=""/>
|
|
<parameters name="notifications_enabled" documentation=""/>
|
|
<parameters name="hostgroups" documentation=""/>
|
|
<parameters name="flap_detection_enabled" documentation=""/>
|
|
<parameters name="2d_coords" documentation=""/>
|
|
<parameters name="icon_image_alt" documentation=""/>
|
|
<parameters name="notification_options" documentation=""/>
|
|
<parameters name="notification_interval" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
<parameters name="statusmap_image" documentation=""/>
|
|
<parameters name="low_flap_threshold" documentation=""/>
|
|
<parameters name="business_impact" documentation=""/>
|
|
<parameters name="alias" documentation=""/>
|
|
<parameters name="flap_detection_options" documentation=""/>
|
|
<parameters name="check_period" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="address" documentation=""/>
|
|
<parameters name="event_handler" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="retain_status_information" documentation=""/>
|
|
<parameters name="notes" documentation=""/>
|
|
<parameters name="contact_groups" documentation=""/>
|
|
</types>
|
|
<types name="nagios_hostgroup" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="notes_url" documentation=""/>
|
|
<parameters name="realm" documentation=""/>
|
|
<parameters name="alias" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="hostgroup_members" documentation=""/>
|
|
<parameters name="notes" documentation=""/>
|
|
<parameters name="action_url" documentation=""/>
|
|
<parameters name="members" documentation=""/>
|
|
<parameters name="hostgroup_name" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_service" documentation="">
|
|
<parameters name="notification_period" documentation=""/>
|
|
<parameters name="servicegroups" documentation=""/>
|
|
<parameters name="icon_image" documentation=""/>
|
|
<parameters name="check_interval" documentation=""/>
|
|
<parameters name="max_check_attempts" documentation=""/>
|
|
<parameters name="contacts" documentation=""/>
|
|
<parameters name="passive_checks_enabled" documentation=""/>
|
|
<parameters name="check_freshness" documentation=""/>
|
|
<parameters name="action_url" documentation=""/>
|
|
<parameters name="event_handler_enabled" documentation=""/>
|
|
<parameters name="stalking_options" documentation=""/>
|
|
<parameters name="_naginator_name" documentation=""/>
|
|
<parameters name="retry_interval" documentation=""/>
|
|
<parameters name="first_notification_delay" documentation=""/>
|
|
<parameters name="display_name" documentation=""/>
|
|
<parameters name="initial_state" documentation=""/>
|
|
<parameters name="retain_nonstatus_information" documentation=""/>
|
|
<parameters name="check_command" documentation=""/>
|
|
<parameters name="process_perf_data" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="poller_tag" documentation=""/>
|
|
<parameters name="freshness_threshold" documentation=""/>
|
|
<parameters name="failure_prediction_enabled" documentation=""/>
|
|
<parameters name="hostgroup_name" documentation=""/>
|
|
<parameters name="notes_url" documentation=""/>
|
|
<parameters name="active_checks_enabled" documentation=""/>
|
|
<parameters name="normal_check_interval" documentation=""/>
|
|
<parameters name="is_volatile" documentation=""/>
|
|
<parameters name="high_flap_threshold" documentation=""/>
|
|
<parameters name="notifications_enabled" documentation=""/>
|
|
<parameters name="obsess_over_service" documentation=""/>
|
|
<parameters name="flap_detection_enabled" documentation=""/>
|
|
<parameters name="icon_image_alt" documentation=""/>
|
|
<parameters name="notification_options" documentation=""/>
|
|
<parameters name="notification_interval" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
<parameters name="low_flap_threshold" documentation=""/>
|
|
<parameters name="business_impact" documentation=""/>
|
|
<parameters name="retry_check_interval" documentation=""/>
|
|
<parameters name="flap_detection_options" documentation=""/>
|
|
<parameters name="check_period" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="parallelize_check" documentation=""/>
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="event_handler" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="retain_status_information" documentation=""/>
|
|
<parameters name="notes" documentation=""/>
|
|
<parameters name="service_description" documentation=""/>
|
|
<parameters name="contact_groups" documentation=""/>
|
|
</types>
|
|
<types name="nagios_servicegroup" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="notes_url" documentation=""/>
|
|
<parameters name="alias" documentation=""/>
|
|
<parameters name="servicegroup_members" documentation=""/>
|
|
<parameters name="servicegroup_name" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="notes" documentation=""/>
|
|
<parameters name="action_url" documentation=""/>
|
|
<parameters name="members" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_contact" documentation="">
|
|
<parameters name="host_notification_period" documentation=""/>
|
|
<parameters name="host_notification_commands" documentation=""/>
|
|
<parameters name="service_notification_period" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="address1" documentation=""/>
|
|
<parameters name="address2" documentation=""/>
|
|
<parameters name="address3" documentation=""/>
|
|
<parameters name="contact_name" documentation=""/>
|
|
<parameters name="service_notifications_enabled" documentation=""/>
|
|
<parameters name="contactgroups" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
<parameters name="pager" documentation=""/>
|
|
<parameters name="host_notification_options" documentation=""/>
|
|
<parameters name="alias" documentation=""/>
|
|
<parameters name="service_notification_options" documentation=""/>
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="address6" documentation=""/>
|
|
<parameters name="host_notifications_enabled" documentation=""/>
|
|
<parameters name="address5" documentation=""/>
|
|
<parameters name="service_notification_commands" documentation=""/>
|
|
<parameters name="address4" documentation=""/>
|
|
<parameters name="email" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="retain_nonstatus_information" documentation=""/>
|
|
<parameters name="retain_status_information" documentation=""/>
|
|
<parameters name="can_submit_commands" documentation=""/>
|
|
</types>
|
|
<types name="nagios_contactgroup" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="contactgroup_members" documentation=""/>
|
|
<parameters name="alias" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="members" documentation=""/>
|
|
<parameters name="contactgroup_name" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_timeperiod" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="timeperiod_name" documentation=""/>
|
|
<parameters name="wednesday" documentation=""/>
|
|
<parameters name="alias" documentation=""/>
|
|
<parameters name="thursday" documentation=""/>
|
|
<parameters name="monday" documentation=""/>
|
|
<parameters name="sunday" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="exclude" documentation=""/>
|
|
<parameters name="saturday" documentation=""/>
|
|
<parameters name="friday" documentation=""/>
|
|
<parameters name="tuesday" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_command" documentation="">
|
|
<parameters name="command_name" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="poller_tag" documentation=""/>
|
|
<parameters name="command_line" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_servicedependency" documentation="">
|
|
<parameters name="_naginator_name" documentation=""/>
|
|
<parameters name="inherits_parent" documentation=""/>
|
|
<parameters name="notification_failure_criteria" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="hostgroup_name" documentation=""/>
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="dependent_service_description" documentation=""/>
|
|
<parameters name="dependent_host_name" documentation=""/>
|
|
<parameters name="execution_failure_criteria" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="dependency_period" documentation=""/>
|
|
<parameters name="service_description" documentation=""/>
|
|
<parameters name="dependent_hostgroup_name" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_serviceescalation" documentation="">
|
|
<parameters name="escalation_options" documentation=""/>
|
|
<parameters name="first_notification" documentation=""/>
|
|
<parameters name="_naginator_name" documentation=""/>
|
|
<parameters name="servicegroup_name" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="hostgroup_name" documentation=""/>
|
|
<parameters name="contacts" documentation=""/>
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="escalation_period" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="service_description" documentation=""/>
|
|
<parameters name="last_notification" documentation=""/>
|
|
<parameters name="notification_interval" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
<parameters name="contact_groups" documentation=""/>
|
|
</types>
|
|
<types name="nagios_hostdependency" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="dependent_host_name" documentation=""/>
|
|
<parameters name="_naginator_name" documentation=""/>
|
|
<parameters name="notification_failure_criteria" documentation=""/>
|
|
<parameters name="execution_failure_criteria" documentation=""/>
|
|
<parameters name="inherits_parent" documentation=""/>
|
|
<parameters name="dependency_period" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="dependent_hostgroup_name" documentation=""/>
|
|
<parameters name="hostgroup_name" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_hostescalation" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="escalation_options" documentation=""/>
|
|
<parameters name="first_notification" documentation=""/>
|
|
<parameters name="_naginator_name" documentation=""/>
|
|
<parameters name="escalation_period" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="last_notification" documentation=""/>
|
|
<parameters name="notification_interval" documentation=""/>
|
|
<parameters name="contact_groups" documentation=""/>
|
|
<parameters name="contacts" documentation=""/>
|
|
<parameters name="hostgroup_name" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_hostextinfo" documentation="">
|
|
<parameters name="statusmap_image" documentation=""/>
|
|
<parameters name="icon_image" documentation=""/>
|
|
<parameters name="vrml_image" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="3d_coords" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="notes_url" documentation=""/>
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="2d_coords" documentation=""/>
|
|
<parameters name="icon_image_alt" documentation=""/>
|
|
<parameters name="notes" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<types name="nagios_serviceextinfo" documentation="">
|
|
<parameters name="register" documentation=""/>
|
|
<parameters name="notes_url" documentation=""/>
|
|
<parameters name="_naginator_name" documentation=""/>
|
|
<parameters name="icon_image" documentation=""/>
|
|
<parameters name="target" documentation=""/>
|
|
<parameters name="use" documentation=""/>
|
|
<parameters name="icon_image_alt" documentation=""/>
|
|
<parameters name="notes" documentation=""/>
|
|
<parameters name="host_name" documentation=""/>
|
|
<parameters name="service_description" documentation=""/>
|
|
<parameters name="action_url" documentation=""/>
|
|
<parameters name="ensure" documentation=""/>
|
|
</types>
|
|
<typeFragments name="file">
|
|
<properties name="owner" documentation="<p>The user to whom the file should belong. Argument can be a user name or a user ID.</p><p>On Windows, a group (such as "Administrators") can be set as a file's owner and a user (such as "Administrator") can be set as a file's group; however, a file's owner and group shouldn't be the same. (If the owner is also the group, files with modes like <tt>0640</tt> will cause log churn, as they will always appear out of sync.)</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<parameters name="checksum" documentation="<p>The checksum type to use when determining whether to replace a file's contents.</p><p>The default checksum type is md5.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="content" documentation="<p>The desired contents of a file, as a string. This attribute is mutually exclusive with <tt>source</tt> and <tt>target</tt>.</p><p>Newlines and tabs can be specified in double-quoted strings using standard escaped syntax --- \n for a newline, and \t for a tab.</p><p>With very small files, you can construct content strings directly in the manifest...</p><pre> define resolve(nameserver1, nameserver2, domain, search) {
 $str = "search $search
 domain $domain
 nameserver $nameserver1
 nameserver $nameserver2
 "

 file { "/etc/resolv.conf":
 content => "$str",
 }
 }

</pre><p>...but for larger files, this attribute is more useful when combined with the [template](http://docs.puppetlabs.com/references/latest/function.html#template) or [file](http://docs.puppetlabs.com/references/latest/function.html#file) function.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="ctime" documentation="<p>A read-only state to check the file ctime. On most modern \*nix-like systems, this is the time of the most recent change to the owner, group, permissions, or content of the file.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<parameters name="source" documentation="<p>A source file, which will be copied into place on the local system. Values can be URIs pointing to remote files, or fully qualified paths to files available on the local system (including files on NFS shares or Windows mapped drives). This attribute is mutually exclusive with <tt>content</tt> and <tt>target</tt>.</p><p>The available URI schemes are <b>puppet</b> and <b>file</b>. <b>Puppet</b> URIs will retrieve files from Puppet's built-in file server, and are usually formatted as:</p><p><tt>puppet:///modules/name<i>of</i>module/filename</tt></p><p>This will fetch a file from a module on the puppet master (or from a local module when using puppet apply). Given a <tt>modulepath</tt> of <tt>/etc/puppetlabs/puppet/modules</tt>, the example above would resolve to <tt>/etc/puppetlabs/puppet/modules/name<i>of</i>module/files/filename</tt>.</p><p>Unlike <tt>content</tt>, the <tt>source</tt> attribute can be used to recursively copy directories if the <tt>recurse</tt> attribute is set to <tt>true</tt> or <tt>remote</tt>. If a source directory contains symlinks, use the <tt>links</tt> attribute to specify whether to recreate links or follow them.</p><p>Multiple <tt>source</tt> values can be specified as an array, and Puppet will use the first source that exists. This can be used to serve different files to different system types:</p><pre> file { "/etc/nfs.conf":
 source => [
 "puppet:///modules/nfs/conf.$host",
 "puppet:///modules/nfs/conf.$operatingsystem",
 "puppet:///modules/nfs/conf"
 ]
 }

</pre><p>Alternately, when serving directories recursively, multiple sources can be combined by setting the <tt>sourceselect</tt> attribute to <tt>all</tt>.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<parameters name="source_permissions" documentation="<p>Whether (and how) Puppet should copy owner, group, and mode permissions from the <tt>source</tt> to <tt>file</tt> resources when the permissions are not explicitly specified. (In all cases, explicit permissions will take precedence.) Valid values are <tt>use</tt>, <tt>use<i>when</i>creating</tt>, and <tt>ignore</tt>:</p><ul><li><p><tt>use</tt> (the default) will cause Puppet to apply the owner, group, and mode from the <tt>source</tt> to any files it is managing.</p></li><li><p><tt>use<i>when</i>creating</tt> will only apply the owner, group, and mode from the <tt>source</tt> when creating a file; existing files will not have their permissions overwritten.</p></li><li><p><tt>ignore</tt> will never apply the owner, group, or mode from the <tt>source</tt> when managing a file. When creating new files without explicit permissions, the permissions they receive will depend on platform-specific behavior. On POSIX, Puppet will use the umask of the user it is running as. On Windows, Puppet will use the default DACL associated with the user it is running as.</p></li></ul>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="group" documentation="<p>Which group should own the file. Argument can be either a group name or a group ID.</p><p>On Windows, a user (such as "Administrator") can be set as a file's group and a group (such as "Administrators") can be set as a file's owner; however, a file's owner and group shouldn't be the same. (If the owner is also the group, files with modes like <tt>0640</tt> will cause log churn, as they will always appear out of sync.)</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<parameters name="selinux_ignore_defaults" documentation="<p>If this is set then Puppet will not ask SELinux (via matchpathcon) to supply defaults for the SELinux attributes (seluser, selrole, seltype, and selrange). In general, you should leave this set at its default and only set it to true when you need Puppet to not try to fix SELinux labels automatically.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="seluser" documentation="<p>What the SELinux user component of the context of the file should be. Any valid SELinux user component is accepted. For example <tt>user_u</tt>. If not specified it defaults to the value returned by matchpathcon for the file, if any exists. Only valid on systems with SELinux support enabled.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="selrole" documentation="<p>What the SELinux role component of the context of the file should be. Any valid SELinux role component is accepted. For example <tt>role_r</tt>. If not specified it defaults to the value returned by matchpathcon for the file, if any exists. Only valid on systems with SELinux support enabled.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="seltype" documentation="<p>What the SELinux type component of the context of the file should be. Any valid SELinux type component is accepted. For example <tt>tmp_t</tt>. If not specified it defaults to the value returned by matchpathcon for the file, if any exists. Only valid on systems with SELinux support enabled.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="selrange" documentation="<p>What the SELinux range component of the context of the file should be. Any valid SELinux range component is accepted. For example <tt>s0</tt> or <tt>SystemHigh</tt>. If not specified it defaults to the value returned by matchpathcon for the file, if any exists. Only valid on systems with SELinux support enabled and that have support for MCS (Multi-Category Security).</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="mode" documentation="<p>The desired permissions mode for the file, in symbolic or numeric notation. This value should be specified as a quoted string; do not use un-quoted numbers to represent file modes.</p><p>The <tt>file</tt> type uses traditional Unix permission schemes and translates them to equivalent permissions for systems which represent permissions differently, including Windows. For detailed ACL controls on Windows, you can leave <tt>mode</tt> unmanaged and use [the puppetlabs/acl module.](https://forge.puppetlabs.com/puppetlabs/acl)</p><p>Numeric modes should use the standard four-digit octal notation of <tt><setuid/setgid/sticky><owner><group><other></tt> (e.g. 0644). Each of the "owner," "group," and "other" digits should be a sum of the permissions for that class of users, where read = 4, write = 2, and execute/search = 1. When setting numeric permissions for directories, Puppet sets the search permission wherever the read permission is set.</p><p>Symbolic modes should be represented as a string of comma-separated permission clauses, in the form <tt><who><op><perm></tt>:</p><ul><li><p>"Who" should be u (user), g (group), o (other), and/or a (all)</p></li><li><p>"Op" should be = (set exact permissions), + (add select permissions), or - (remove select permissions)</p></li><li><p>"Perm" should be one or more of:<pre>* r (read)
* w (write)
* x (execute/search)
* t (sticky)
* s (setuid/setgid)
* X (execute/search if directory or if any one user can execute)
* u (user's current permissions)
* g (group's current permissions)
* o (other's current permissions)

</pre></p></li></ul><p>Thus, mode <tt>0664</tt> could be represented symbolically as either <tt>a=r,ug<tt>w</tt> or <tt>ug=rw,o=r</tt>. However, symbolic modes are more expressive than numeric modes: a mode only affects the specified bits, so <tt>mode => 'ug</tt>w'</tt> will set the user and group write bits, without affecting any other bits.</p><p>See the manual page for GNU or BSD <tt>chmod</tt> for more details on numeric and symbolic modes.</p><p>On Windows, permissions are translated as follows:</p><ul><li><p>Owner and group names are mapped to Windows SIDs</p></li><li><p>The "other" class of users maps to the "Everyone" SID</p></li><li><p>The read/write/execute permissions map to the <tt>FILE<i>GENERIC</i>READ</tt>, <tt>FILE<i>GENERIC</i>WRITE</tt>, and <tt>FILE<i>GENERIC</i>EXECUTE</tt> access rights; a file's owner always has the <tt>FULL_CONTROL</tt> right</p></li><li><p>"Other" users can't have any permissions a file's group lacks, and its group can't have any permissions its owner lacks; that is, 0644 is an acceptable mode, but 0464 is not.</p></li></ul>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="type" documentation="<p>A read-only state to check the file type.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="ensure" documentation="<p>Whether the file should exist, and if so what kind of file it should be. Possible values are <tt>present</tt>, <tt>absent</tt>, <tt>file</tt>, <tt>directory</tt>, and <tt>link</tt>.</p><ul><li><p><tt>present</tt> will accept any form of file existence, and will create a normal file if the file is missing. (The file will have no content unless the <tt>content</tt> or <tt>source</tt> attribute is used.)</p></li><li><p><tt>absent</tt> will make sure the file doesn't exist, deleting it if necessary.</p></li><li><p><tt>file</tt> will make sure it's a normal file, and enables use of the <tt>content</tt> or <tt>source</tt> attribute.</p></li><li><p><tt>directory</tt> will make sure it's a directory, and enables use of the <tt>source</tt>, <tt>recurse</tt>, <tt>recurselimit</tt>, <tt>ignore</tt>, and <tt>purge</tt> attributes.</p></li><li><p><tt>link</tt> will make sure the file is a symlink, and <strong>requires</strong> that you also set the <tt>target</tt> attribute. Symlinks are supported on all Posix systems and on Windows Vista / 2008 and higher. On Windows, managing symlinks requires puppet agent's user account to have the "Create Symbolic Links" privilege; this can be configured in the "User Rights Assignment" section in the Windows policy editor. By default, puppet agent runs as the Administrator account, which does have this privilege.</p></li></ul><p>Puppet avoids destroying directories unless the <tt>force</tt> attribute is set to <tt>true</tt>. This means that if a file is currently a directory, setting <tt>ensure</tt> to anything but <tt>directory</tt> or <tt>present</tt> will cause Puppet to skip managing the resource and log either a notice or an error.</p><p>There is one other non-standard value for <tt>ensure</tt>. If you specify the path to another file as the ensure value, it is equivalent to specifying <tt>link</tt> and using that path as the <tt>target</tt>:</p><pre> # Equivalent resources:

 file { "/etc/inetd.conf":
 ensure => "/etc/inet/inetd.conf",
 }

 file { "/etc/inetd.conf":
 ensure => link,
 target => "/etc/inet/inetd.conf",
 }

</pre><p>However, we recommend using <tt>link</tt> and <tt>target</tt> explicitly, since this behavior can be harder to read.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="target" documentation="<p>The target for creating a link. Currently, symlinks are the only type supported. This attribute is mutually exclusive with <tt>source</tt> and <tt>content</tt>.</p><p>Symlink targets can be relative, as well as absolute:</p><pre> # (Useful on Solaris)
 file { "/etc/inetd.conf":
 ensure => link,
 target => "inet/inetd.conf",
 }

</pre><p>Directories of symlinks can be served recursively by instead using the <tt>source</tt> attribute, setting <tt>ensure</tt> to <tt>directory</tt>, and setting the <tt>links</tt> attribute to <tt>manage</tt>.</p>"/>
|
|
</typeFragments>
|
|
<typeFragments name="file">
|
|
<properties name="mtime" documentation="<p>A read-only state to check the file mtime. On \*nix-like systems, this is the time of the most recent change to the content of the file.</p>"/>
|
|
</typeFragments>
|
|
<metaType name="Type" documentation="">
|
|
<parameters name="loglevel" documentation="<p>Sets the level that information will be logged. The log levels have the biggest impact when logs are sent to syslog (which is currently the default).</p><p>The order of the log levels, in decreasing priority, is:</p><ul><li><p><tt>crit</tt></p></li><li><p><tt>emerg</tt></p></li><li><p><tt>alert</tt></p></li><li><p><tt>err</tt></p></li><li><p><tt>warning</tt></p></li><li><p><tt>notice</tt></p></li><li><p><tt>info</tt> / <tt>verbose</tt></p></li><li><p><tt>debug</tt></p></li></ul>"/>
|
|
<parameters name="schedule" documentation="<p>A schedule to govern when Puppet is allowed to manage this resource. The value of this metaparameter must be the <tt>name</tt> of a <tt>schedule</tt> resource. This means you must declare a schedule resource, then refer to it by name; see [the docs for the <tt>schedule</tt> type](http://docs.puppetlabs.com/references/latest/type.html#schedule) for more info.</p><pre> schedule { 'everyday':
 period => daily,
 range => "2-4"
 }

 exec { "/usr/bin/apt-get update":
 schedule => 'everyday'
 }

</pre><p>Note that you can declare the schedule resource anywhere in your manifests, as long as it ends up in the final compiled catalog.</p>"/>
|
|
<parameters name="subscribe" documentation="<p>One or more resources that this resource depends on, expressed as [resource references](http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#resource-references). Multiple resources can be specified as an array of references. When this attribute is present:</p><ul><li><p>The subscribed resource(s) will be applied <i>before</i> this resource.</p></li><li><p>If Puppet makes changes to any of the subscribed resources, it will cause this resource to <i>refresh.</i> (Refresh behavior varies by resource type: services will restart, mounts will unmount and re-mount, etc. Not all types can refresh.)</p></li></ul><p>This is one of the four relationship metaparameters, along with <tt>before</tt>, <tt>require</tt>, and <tt>notify</tt>. For more context, including the alternate chaining arrow (<tt>-></tt> and <tt>~></tt>) syntax, see [the language page on relationships](http://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html).</p>"/>
|
|
<parameters name="alias" documentation="<p>Creates an alias for the resource. Puppet uses this internally when you provide a symbolic title and an explicit namevar value:</p><pre> file { 'sshdconfig':
 path => $operatingsystem ? {
 solaris => '/usr/local/etc/ssh/sshd_config',
 default => '/etc/ssh/sshd_config',
 },
 source => '...'
 }

 service { 'sshd':
 subscribe => File['sshdconfig'],
 }

</pre><p>When you use this feature, the parser sets <tt>sshdconfig</tt> as the title, and the library sets that as an alias for the file so the dependency lookup in <tt>Service['sshd']</tt> works. You can use this metaparameter yourself, but note that aliases generally only work for creating relationships; anything else that refers to an existing resource (such as amending or overriding resource attributes in an inherited class) must use the resource's exact title. For example, the following code will not work:</p><pre> file { '/etc/ssh/sshd_config':
 owner => root,
 group => root,
 alias => 'sshdconfig',
 }

 File['sshdconfig'] {
 mode => 644,
 }

</pre><p>There's no way here for the Puppet parser to know that these two stanzas should be affecting the same file.</p>"/>
|
|
<parameters name="before" documentation="<p>One or more resources that depend on this resource, expressed as [resource references](http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#resource-references). Multiple resources can be specified as an array of references. When this attribute is present:</p><ul><li><p>This resource will be applied <i>before</i> the dependent resource(s).</p></li></ul><p>This is one of the four relationship metaparameters, along with <tt>require</tt>, <tt>notify</tt>, and <tt>subscribe</tt>. For more context, including the alternate chaining arrow (<tt>-></tt> and <tt>~></tt>) syntax, see [the language page on relationships](http://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html).</p>"/>
|
|
<parameters name="tag" documentation="<p>Add the specified tags to the associated resource. While all resources are automatically tagged with as much information as possible (e.g., each class and definition containing the resource), it can be useful to add your own tags to a given resource.</p><p>Multiple tags can be specified as an array:</p><pre> file {'/etc/hosts':
 ensure => file,
 source => 'puppet:///modules/site/hosts',
 mode => 0644,
 tag => ['bootstrap', 'minimumrun', 'mediumrun'],
 }

</pre><p>Tags are useful for things like applying a subset of a host's configuration with [the <tt>tags</tt> setting](/references/latest/configuration.html#tags) (e.g. <tt>puppet agent --test --tags bootstrap</tt>) or filtering alerts with [the <tt>tagmail</tt> report processor](http://docs.puppetlabs.com/references/latest/report.html#tagmail).</p>"/>
|
|
<parameters name="noop" documentation="<p>Whether to apply this resource in noop mode.</p><p>When applying a resource in noop mode, Puppet will check whether it 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 <i>would</i> 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 <i>would</i> have been sent.</p><p><strong>Important note:</strong> [The <tt>noop</tt> setting](http://docs.puppetlabs.com/references/latest/configuration.html#noop) allows you to globally enable or disable noop mode, but it will <i>not</i> override the <tt>noop</tt> metaparameter on individual resources. That is, the value of the global <tt>noop</tt> setting will <i>only</i> affect resources that do not have an explicit value set for their <tt>noop</tt> attribute.</p>"/>
|
|
<parameters name="notify" documentation="<p>One or more resources that depend on this resource, expressed as [resource references](http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#resource-references). Multiple resources can be specified as an array of references. When this attribute is present:</p><ul><li><p>This resource will be applied <i>before</i> the notified resource(s).</p></li><li><p>If Puppet makes changes to this resource, it will cause all of the notified resources to <i>refresh.</i> (Refresh behavior varies by resource type: services will restart, mounts will unmount and re-mount, etc. Not all types can refresh.)</p></li></ul><p>This is one of the four relationship metaparameters, along with <tt>before</tt>, <tt>require</tt>, and <tt>subscribe</tt>. For more context, including the alternate chaining arrow (<tt>-></tt> and <tt>~></tt>) syntax, see [the language page on relationships](http://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html).</p>"/>
|
|
<parameters name="audit" documentation="<p>Marks a subset of this resource's unmanaged attributes for auditing. Accepts an attribute name, an array of attribute names, or <tt>all</tt>.</p><p>Auditing a resource attribute has two effects: First, whenever a catalog is applied with puppet apply or puppet agent, Puppet will check whether that attribute of the resource has been modified, comparing its current value to the previous run; any change will be logged alongside any actions performed by Puppet while applying the catalog.</p><p>Secondly, marking a resource attribute for auditing will include that attribute in inspection reports generated by puppet inspect; see the puppet inspect documentation for more details.</p><p>Managed attributes for a resource can also be audited, but note that changes made by Puppet will be logged as additional modifications. (I.e. if a user manually edits a file whose contents are audited and managed, puppet agent's next two runs will both log an audit notice: the first run will log the user's edit and then revert the file to the desired state, and the second run will log the edit made by Puppet.)</p>"/>
|
|
<parameters name="require" documentation="<p>One or more resources that this resource depends on, expressed as [resource references](http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#resource-references). Multiple resources can be specified as an array of references. When this attribute is present:</p><ul><li><p>The required resource(s) will be applied <strong>before</strong> this resource.</p></li></ul><p>This is one of the four relationship metaparameters, along with <tt>before</tt>, <tt>notify</tt>, and <tt>subscribe</tt>. For more context, including the alternate chaining arrow (<tt>-></tt> and <tt>~></tt>) syntax, see [the language page on relationships](http://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html).</p>"/>
|
|
<parameters name="stage" documentation="<p>Which run stage this class should reside in.</p><p><strong>Note: This metaparameter can only be used on classes,</strong> and only when declaring them with the resource-like syntax. It cannot be used on normal resources or on classes declared with <tt>include</tt>.</p><p>By default, all classes are declared in the <tt>main</tt> stage. To assign a class to a different stage, you must:</p><ul><li><p>Declare the new stage as a [<tt>stage</tt> resource](http://docs.puppetlabs.com/references/latest/type.html#stage).</p></li><li><p>Declare an order relationship between the new stage and the <tt>main</tt> stage.</p></li><li><p>Use the resource-like syntax to declare the class, and set the <tt>stage</tt> metaparameter to the name of the desired stage.</p></li></ul><p>For example:</p><pre> stage { 'pre':
 before => Stage['main'],
 }

 class { 'apt-updates':
 stage => 'pre',
 }

</pre>"/>
|
|
<parameters name="provider" documentation=""/>
|
|
</metaType>
|
|
<metaVariables name="name" documentation=""/>
|
|
<metaVariables name="title" documentation=""/>
|
|
<metaVariables name="module_name" documentation="<p>The name of the containing module</p>"/>
|
|
<metaVariables name="caller_module_name" documentation="<p>The name of the calling module</p>"/>
|
|
</pptp:PuppetDistribution>
|