Accessing and using fact values

You have already seen the use of the processors fact in an example. In the manifest, each fact value is available as a global variable value. That is why you can just use the ::processors expression where you need it.

You will often see conventional uses such as $::processors['count'] or $::networking[‘ip’]. Prefixing the fact name with double colons is highly recommended. The official style guide at https://docs.puppetlabs.com/guides/style_guide.html#namespacing-variables recommends this. The prefix indicates that you are referring to a variable delivered from Facter. Facter variables are put into the Puppet master's top scope.

Some helpful facts have already been mentioned. The processors fact might play a role for your configuration. When configuring some services, you will want to use the machine's networking ['ip'] value in a configuration file or as an argument value:

file { '/etc/mysql/conf.d/bind-address':
  ensure  => 'file',
  mode    => '0644',
  content => "[mysqld]\nbind-address=${::networking['ip']}\n",
}

Apart from the hostname, your manifest can also make use of the Fully Qualified Domain Name (FQDN) of the agent machine.

The agent will use the value of its fqdn fact as the name of its certificate (clientcert) by default. The master receives both these values. Note that the agent can override the fqdn value of any name, whereas the clientcert value is tied to the signed certificate that the agent uses. Sometimes, you will want the master to pass sensitive information to individual nodes. The manifest must identify the agent by its clientcert fact and never use fqdn or hostname instead, for the reason mentioned. An example is shown in the following code:

file { '/etc/my-secret': 
  ensure => 'file', 
  mode   => '0600', 
  owner  => 'root', 
  source => 
  "puppet:///modules/secrets/${::clientcert}/key", 
} 

There is a whole group of facts that are used to describe the operating system. Each fact is useful in different situations. The os[‘name’] fact takes values such as Debian or CentOS:

if $::os['name'] != 'Ubuntu' {
  package { 'avahi-daemon':
    ensure => absent
  }
}

If your manifest will behave identically on RHEL, CentOS, and Fedora (but not on Debian and Ubuntu), you should make use of the osfamily fact instead:

if $::os['family'] == 'RedHat' {
  $kernel_package = 'kernel'
}

The os[‘release’][‘full’] fact allows you to tailor your manifests to the different versions of your OS:

if $::so['name'] == 'Debian' {
  if versioncmp($::os['release']['full'], '7.0') >= 0 {
    $ssh_ecdsa_support = true
  }
}

Facts such as mac address, the different SSH host keys, fingerprints, and others make it easy to use Puppet for keeping an inventory of your hardware. There are a slew of other useful facts. Of course, the collection will not suit every possible need of every user out there. That is why Facter comes readily extendible.