Trusted and custom facts: what are they used for?📍

We’d like to help you understand trusted facts and custom facts, which are powerful and often misunderstood. Trusted facts are based on the information in your certificate. Custom facts allow you to add Ruby code to generate facts about a system.

Both are pluginsync based. We recommend that you enable pluginsync to manage the distribution of facts, functions, types, and providers for your agent nodes. Otherwise, you have to manage all of those things manually.

But first, let’s talk a little bit about facts.

Facts help you classify your nodes with node definitions in site.pp, your manifests directory, or your external node classifier.

They also play a crucial role in determining what data is looked up with Hiera during catalog compilation.

Hiera hierarchies provide a method of dynamically retrieving data using facts. Facts are available at the time of catalog compilation, so each node gets a customized set of paths to data. The hierarchy is always the same, but you can use facts to make dynamic decisions. For example, when you have a datacenter fact, you can set different DNS and NTP servers for each of your datacenters in one place and then reference the appropriate key in your code. You can also make decisions on what to manage based on the fact’s value, and reference that in your code. For example, if a datacenter has Splunk, go ahead and add a Splunk forwarder, but if Splunk isn’t present in a datacenter, don’t add a Splunk forwarder.

Learn more about facts from our docs.

Trusted facts

Trusted facts is a hash that contains trusted data from the node’s certificate. You can access the data using the syntax $trusted['fact_name']. The variable name $trusted is reserved, so local scopes cannot reuse it.

Learn more:

• Create a trusted fact, verify it, and then reference it in Hiera
• Read our trusted facts docs

Custom facts

Custom facts are written in Ruby and propagated to the agent nodes with pluginsync (if enabled.)

You can make decisions on how to name and structure custom facts for your organization’s style guide. You could name facts using a prefix. For example at Puppet, we might name facts pup_mydatacenter and pup_myapptier. You could also place all facts in a container module for easier management and distribution.

Learn more:

• Get a better understanding of plug-ins and pluginsync from our plug-ins in modules docs.
• Learn more about custom facts from our docs.
• Take a look at our Custom facts walkthrough.
• Introduction to pluginsync