Custom facts

Custom facts are a client-side technology for extracting arbitrary information from the node during the execution of the agent run, and they may be utilized in Puppet manifests or templates, along with any other distributed facts. Facts are executed on the Puppet agent.

The best way to create and distribute a new custom fact is to place it in a module, in the facter subdirectory of the lib directory, and it will then be distributed to the agent machine via pluginsync.

The following diagram illustrates the pluginsync process that precedes a normal catalog request. Usually, a GET method is called on the Puppet server using the FQDN, which then initiates the pluginsync process, and the appropriate facts, types, and providers are distributed back to the agent:

Most of the time, I have found that a fact is generally just an execution of an arbitrary command-line expression, and that is a good way to think generally about facts: they effectively consist of a Ruby wrapper, usually around a command-line expression that makes itself available to the Puppet ecosystem via Facter.

The following code would be a good snippet to use as a template for further development:

# <modulepath>/lib/facter/mycustomfact.rb
Facter.add(:mycustomfact) do
   confine :kernel => "Linux"
   ...
   myvar = Facter::Core::Execution.exec("foo")
  ...
 end

Do make sure that you confine your fact appropriately. There's nothing worse than when you introduce a new operating system to your infrastructure only to find that you are now executing failing facts because they don't use a certain command syntax. Or, what if we suddenly introduce a handful of Windows nodes, only to find that Windows doesn't, of course, understand most Linux commands?

Bear this in mind during your authoring of custom facts.