Facter 1.7 Introduces External Facts

Puppet Labs released Facter 1.7 this week, introducing a number of under-the-hood enhancements and a new feature called "external facts" that's been waiting in the wings for about a year now.

Facter is a cross-platform library for gathering information about nodes managed by Puppet, including domain names, IP addresses, operating systems, Linux distributions, and more. External facts provide a simple way for a puppet agent to provide custom facts without having to write Ruby. Eric Sorenson, Puppet's open source product owner, told me, "they're probably the easiest way for people to get an entry into Puppet for extending Puppet or customizing Puppet for their own site."

Until this release, external facts were provided as part of stdlib, a Puppet module that provides a collection of resources and functions to assist with Puppet module development. Though stdlib's external fact support was useful, "the out-of-the-box experience wasn't as good as it could be," said Eric.

Hailey Kenney, who interned at Puppet Labs last summer, wrote what Eric calls "a great implementation" of external facts for Facter, "but we didn't have a release vehicle until now."

The simplest external facts are nothing more than simple text files containing key/value pairs.

As Eric notes, "You can literally just drop files with 'some name equals some value' in a directory and they'll automatically get turned into facter facts." Like this:

Place the file into the proper directory (on a Unix or Linux system it will be /etc/facter/facts.d; on Windows there are different locations depending on the version) and Facter will start reporting the new facts.

According to Eric, "a real common use for this is, there's a lot of data AMIs on Amazon leave on-system. You generally want to import some of the info that's contained in them into Facter, but it's hard to do without external facts support."

External facts make the process of gathering this information and providing it through Facter much more direct than it might have been with a Ruby custom fact.

"The data's already there in this format. It makes a lot more sense to read it in in the native way, rather than do a complicated round-trip thing, then make Ruby [that] parses it then puts it back out as the same thing it started out as."

If you prefer JSON or YAML, you can also write your custom facts in either of those formats. Whichever format you choose, external facts are a great way to capture node information that might be computationally expensive to retrieve, and handle retrieval only once in a while, maybe by writing a script that runs via cron.

You can also use the same script to return facts straight from Facter, provided it outputs the same key=value format Facter expects for a plain text file. Make sure the script is executable and drop it into the same facts.d directory you'd place a plain text file, and Facter will start using its output to provide facts.

If you're interested in reading more about external facts, make sure to visit the docs on custom and external facts on the Puppet Labs docs site.

Facter Has More Facts, Too

As with most Facter iterations, the new release includes a collection of new core facts:

  • ZFS version and zpool membership
  • Mounted Linux filesystem types
  • Facts related to Solaris zones (a node's zone name and zones available on a system)

The docs team also updated some previously undocumented facts, including a collection related to SE Linux.

And one thing that doesn't turn up if you're just looking at the list of new facts is better support for identifying nodes running OpenWRT, a Linux distribution for embedded devices that works really well for managing wireless access points. With OpenWRT you can take a consumer-grade Wi-Fi device, flash it with its new OS, and gain all sorts of flexibility. As it turns out, you can even manage it with Puppet. Combined with recent support for Junos, the improved support for OpenWRT means Puppet will be turning up on more and more network hardware.

And Something for Fact Developers

Finally, Facter 1.7 introduces a new DSL method, on_flush. From the release notes, the new method "allows the fact author to register a callback Facter will invoke whenever a cached fact value is flushed. This is useful to keep a set of dynamically generated facts in sync without making lots of expensive system calls to resolve each fact value."

If you're interested in using this new DSL method, writing new external facts, or taking advantage of the improved support for OpenWRT, you can download Facter 1.7 as a tarball, RPM, or .deb file from the Puppet Labs download site.




I have defined some key value pairs in /etc/facter/facts.d/value.txt file. I could use those keys inside my init.pp script and successfully for the values using


I want to get those values inside my template file. I have used

<%= @key1 %>

but it doesn't give me the value. What is the correct way to get the value of the external fact inside template.



Leave a comment