A few special trusted facts appear in a $trusted hash. They can be accessed in manifests as $trusted['fact_name']. The variable name $trusted is reserved, so local scopes cannot re-use it.
Normal facts are self-reported by the node, and nothing guarantees their accuracy. Trusted facts are extracted from the node’s certificate, which can prove that the CA checked and approved them. This makes them useful for deciding whether a given node should receive sensitive data in its catalog.
#The available keys in the $trusted hash are:
authenticated — an indication of whether the catalog request was authenticated, as well as how it was authenticated. The value will be one of:
# remote for authenticated remote requests (as with agent/master Puppet configurations)local for all local requests (as with standalone Puppet apply nodes)false for unauthenticated remote requests (generally only possible if you’ve configured auth.conf to allow unauthenticated catalog requests)certname — the node’s subject CN, as listed in its certificate. (When first requesting its certificate, the node requests a subject CN matching the value of its certname setting.)
# authenticated is remote, this is the subject CN extracted from the node’s certificate.authenticated is local, this is read directly from the certname setting.authenticated is false, the value of this key will be an empty string.domain — the node’s domain, as derived from its validated certificate name. The value can be empty if the certificate name doesn’t contain a fully qualified domain name.extensions — a hash containing any custom extensions present in the node’s certificate.
# authenticated is local or false, this will be an empty hash.hostname — the node’s hostname, as derived from its validated certificate name.Facts also appear in a $facts hash. They can be accessed in manifests as $facts['fact_name']. The variable name $facts is reserved, so local scopes cannot re-use it. Structured facts show up as a nested structure inside the $facts namespace, and can be accessed using Puppet’s normal hash access syntax. Due to ambiguity with function invocation, the dot-separated access syntax that is available at the Facter command line is not available in manifests.
Benefits: More readable and maintainable code, by making facts visibly distinct from other variables. Eliminates possible confusion if you use a local variable whose name happens to match that of a common fact.
#Drawbacks: Only works with Puppet 3.5 or later. Disabled by default in open source releases prior to Puppet 4.0.
$facts = 'stub' #The $server_facts variable provides a hash of server-side facts that cannot be overwritten by client side facts. This is important because it enables you to get trusted server facts that could otherwise be overwritten by client-side facts.
For example, the Puppet master sets the global $::environment variable to contain the name of the node’s environment. However, if a node provides a fact with the name environment, that fact’s value overrides the server-set environment fact. The same happens with other server-set global variables, like $::servername and $::serverip. As a result, modules couldn’t reliably use these variables for whatever their intended purpose was.
The $server_facts variable is opt-in. Its trusted_server_facts setting is set to false by default. If you set trusted_server_facts to true, the $server_facts variable will be populated, and will ensure that you get trusted server facts.
In addition, a warning will be issued any time a node parameter is overwritten.
#The following is an example $server_facts hash.
{
# serverversion => "4.1.0",
# servername => "v85ix8blah.delivery.puppetlabs.net",
# serverip => "10.32.115.182",
# environment => "production",
# }
#
$server_facts = 'stub'
# Several variables are set by the Puppet master. These are most useful when managing Puppet with Puppet. (For example, managing puppet.conf with a template.)
#These are not available in the $facts hash.
$environment (also available to puppet apply) — the agent node’s environment. Note that nodes can accidentally or purposefully override this with a custom fact; the $server_facts['environment'] variable always contains the correct environment, and can’t be overridden.
Several variables are set by the Puppet master. These are most useful when managing Puppet with Puppet. (For example, managing puppet.conf with a template.)
#These are not available in the $facts hash.
$servername — 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.)
Several variables are set by the Puppet master. These are most useful when managing Puppet with Puppet. (For example, managing puppet.conf with a template.)
#These are not available in the $facts hash.
$serverip — the Puppet master’s IP address.
Several variables are set by the Puppet master. These are most useful when managing Puppet with Puppet. (For example, managing puppet.conf with a template.)
#These are not available in the $facts hash.
$serverversion — the current version of Puppet on the Puppet master.
These variables are set in every local scope by the compiler during compilation. They are mostly useful when implementing complex defined types.
#These are not available in the $facts hash.
These variables are always defined (by the standards of the strict_variables setting), but their value is undef whenever no other value is applicable.
$module_name — the name of the module that contains the current class or defined type.
These variables are set in every local scope by the compiler during compilation. They are mostly useful when implementing complex defined types.
#These are not available in the $facts hash.
These variables are always defined (by the standards of the strict_variables setting), but their value is undef whenever no other value is applicable.
$caller_module_name — the name of the module in which the specific instance of the surrounding defined type was declared. This is only useful when creating versatile defined types which will be re-used by several modules.
Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#Within conditional statements and node definitions, any captured substrings from parentheses in a regular expression will be available as numbered variables ($1, $2, etc.) inside the associated code section, and the entire match will be available as $0.
These are not normal variables, and have some special behaviors:
#