{
  "$type": "site.standard.document",
  "canonicalUrl": "https://handyman5.github.io//posts/custom-facter-fact",
  "path": "/posts/custom-facter-fact",
  "publishedAt": "2011-10-13T19:00:00.000Z",
  "site": "at://did:plc:yxhvd47p53gmb5zfiktqq3og/site.standard.publication/3mohn6mqvab25",
  "tags": "puppet",
  "textContent": "_(originally from <https://web.archive.org/web/20150422203246/http://ajcsystems.com/blog/page/2/>)_\n\nAt $work, we use Puppet to manage some of our servers, and part of that involves writing custom facts for Facter, Puppet’s tool for gathering node information. (If you’re not familiar, here’s a quick description of Facter.)\n\nThese custom facts can use information present on a given host, such as hostname or IP address, to make their determination. However, we’ve also found it useful to be able to ask a custom fact, “what answer would you give if you were run on a given host?”\n\nThe answer:\n\n<script src=\"https://gist.github.com/handyman5/1283770.js\"></script>\n\nThis is a simple Facter fact that takes a hostname and determines which Ganglia grid to place it in. When run as a part of Facter, it will operate as a fact:\n\n> $ facter \n> architecture => x86_64\n> [...]\n> grid => build\n> hardwareisa => x86_64\n> hardwaremodel => x86_64\n> [...]\n\nBut when called as a standalone script, it will operate as though it were running on that host:\n\n> $ ./grid.rb build01\n> build\n\nBuilding facts like this will let you keep any custom logic you might have in one place, but reuse it in different contexts. Code reuse FTW.\n\nP.S.- If you’re thinking about posting a comment to the effect that Facter can be run with one or more arguments of facts to output:\n\n> $ facter architecture\n> x86_64\n\nyou’re missing the point. This technique allows you to run Facter facts on a _different_ host than the target and still get the benefit of the logic embedded in the fact.",
  "title": "How to make a custom Facter fact that’s also a script"
}