Ask Your Question

puppet facts differ from facter -p [closed]

asked 2014-08-14 13:48:03 -0500

SweetJ21 gravatar image

To start things off, basically I'm just trying to get the environment saved into PuppetDB as a custom fact. I'm using PuppetBoard for reporting/querying the facts of clients, and want to be able to search based on the environment. I read somewhere that PuppetDB does store the environment somewhere, but I thought it would be easier to dump the environment variable to a custom fact and simply query it with existing PuppetBoard functionality rather than try to build out my own pages/queries from PuppetBoard.

So I built a custom module called customfacts, and use it to send a notify that the custom facts have been run and also a customfacts.rb file (contents below). The notify is just for debugging.

I have 1 test Windows server, and 2 CentOS Puppet Masters that also run the job. The Windows server returns everything exactly as expected, but the CentOS servers running from the same manifests and modules won't return the environment back to PuppetDB. I opened psql and queried PuppetDB directly to make sure it wasn't a problem from PuppetBoard, and there is no entry for the "environment" variable. I've even tried renaming the variable and the Windows client returns the new variable, but nothing from the CentOS systems.

So I tried running facter directly on the client and it returns the custom fact, but if I use the puppet agent to call the facts it doesn't show up (directly below). I used full paths, as taken from the output of ps command - the exact same way it's called from init scripts.

/usr/bin/ruby /usr/bin/puppet facts find #mynodename# | grep -i develop

facter -p | grep -i develop
environment => development

So I'm not sure how Puppet and Facter are not reporting back the same facts, since the custom facts were deployed using Puppet?

Here's the custom facts file, pulled from someone else's post on here. It worked great for a regular Windows client.

require 'facter'
require 'puppet'

Facter.add("environment") do
  setcode do
edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by SweetJ21
close date 2014-10-14 13:36:16.217610

2 Answers

Sort by ยป oldest newest most voted

answered 2014-08-26 13:50:06 -0500

WhatsARanjit gravatar image

Facter, being an open source product, by default doesn't execute "plugins" or facts created by other softwares. Simply running 'facter' will use native facts only. Running 'facter -p' will also run any plugins, include custom 3rd party scripts. When an agent uses facter, it always include plugins. On command line, we have to include the -p flag. This is by design.

edit flag offensive delete link more


OP does say he is using `facter -p`. Perhaps I'm missing something here.

Belmin Fernandez gravatar imageBelmin Fernandez ( 2014-09-02 07:54:09 -0500 )edit

Yes, I am using 'facter -p', which loads all of the plugins pulled from Puppet. So what I'm seeing is different results between running facter directly WITH the '-p' flag and when I run the Puppet agent. And keep in mind that I'm seeing this on a CentOS client only, it works on a Windows client.

SweetJ21 gravatar imageSweetJ21 ( 2014-09-02 10:38:33 -0500 )edit

answered 2014-10-14 13:32:39 -0500

SweetJ21 gravatar image

FYI, I did discover a resolution to my issue. I upgraded the Puppet Agent and Master on my CentOS servers, and noticed that my client version information wasn't updating properly in PuppetDB.

So I deactivated the CentOS nodes from PuppetDB then restarted the Puppet Agent on each of them. Once they ran again, they completely overwrote the old values in PuppetDB and I could see my custom facts and the updated client version.

So I believe it was an issue with the values stored in PuppetDB.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2014-08-14 13:48:03 -0500

Seen: 662 times

Last updated: Oct 14 '14