Puppet/Facter "Could Not Retrieve Fact Fqdn": How to Fix or Circumvent

Puppet/Facter Could not retrieve fact fqdn: How to fix or circumvent?

Since puppet uses the fqdn fact to determine which node it is running as, it may not be possible to run if it can't be determined. Given what you're describing, the simplest thing to debug is facter fqdn instead of your puppet command-line.

If the "several seconds" is very close to exactly 5 seconds, it's very likely that your DNS configuration is broken with a single bad DNS server listed. What's in /etc/resolv.conf? What happens if you run dig -x $HOSTIP $DNSSERVERIP with the first nameserver listed in resolv.conf?

If you look in facter/fqdn.rb you can see what exactly facter is trying to do to resolve the fqdn. In the version I have most handy it's using facter/hostname.rb and facter/domainname.rb which call code from facter/util/resolution.rb.

Exactly what happens will depend on what version of facter you have, what OS, and possibly also what exactly you have installed. Calling /bin/hostname, uname (etc) and doing DNS lookups are all quite likely. You can always use strace -t facter fqdn to see what is taking the time (look for the gap in timestamps)

From everything you've described, it does sound like the problem is that puppet/facter really wants to have a domain name and you don't have one, you just have a naked hostname.

Adding domain example.com to /etc/resolv.conf should do the trick. Running hostname foo.example.com should also do the trick (but will need to be re-applied). Permanent solutions depend on the exact OS setup.

Puppet fact for fqdn doesn't return the fully qualified domain name

I created a fact called fqdn and changed the weight for it, it simple runs hostname -f.

Puppet agent daemon not reading a facter fact (EC2, cloud-init)

Another easy option would be to drop a fact into an external fact.

Dropping a file into /etc/facter/facts.d/* is fairly easy, and you can use a text file, yaml json or an executable to do it.

http://docs.puppetlabs.com/guides/custom_facts.html#external-facts

*that's on Open source puppet, on unix-y machines. See the link for the full docs.

Puppet custom facts - uninitialized constant Facter (NameError)

If you are testing this code anywhere other than the ruby lib directory that puppet will look for, then set the RUBYLIB first.
e.g. testing under a dir name /path/to/dir , create lib/ruby/facter/hardware_platform.rb

and you can then,

export RUBYLIB=/path/to/dir/lib/ruby

then, you can run

facter hardware_platform

that should give you a correct result.

As @lucas_clemente says, you also need to check if facter is installed in your system. If you are using yum, just check/install it using,

yum list facter 

it will result something like this if installed or it will show the version exists in your repo if not installed :

facter.x86_64        1:1.6.12-2.el5           installed

Configure remote rulesets with Puppet

This sounds like a job for exported resources (that makes two in one day!). This is a facility for one node's catalog building to generate resources that can be applied to other nodes (and also, optionally, to the exporting node itself). I'm still not tracking the details of what you want to manage where, so here's a more generic example: maintaining a local hosts file.

Generic example

Suppose we want to automatically manage a hosts file listing all our nodes under management. Puppet has a built-in resource, Host, representing one entry in a hosts file. We make use of that by having every node under management export an appropriate host resource. Something like this would go inside a class included on every node:

@@host { "$hostname": ip => $ipaddress; }

The @@ prefix marks the resource as exported. It is not applied to the current target node, unless by the mechanism I will describe in a moment. the $hostname and $ipaddress are just facts presented by the target node, and they are resolved in that context. Note, too, that the resource title is globally unique: each target node has a different hostname, therefore all the exported Host resources that apply to different target nodes will have distinct titles.

Then, separately, every node that wants all those Host entries applied to it will import them in its own catalog by using an exported resource collector:

<<|Host|>>

The nodes that export those resources can also collect some or all of them. Additionally, there are ways to be more selective about which resources are collected; see the link above.

Puppet3 | read values from different yaml file

TL;DR: You can't.

From the current docs and the Puppet documentation archive, I confirm that no version of the %{hiera} interpolation function or its replacement, %{lookup}, ever supported interpolating values other than strings. That's expressed in the current docs like so:

The lookup and hiera interpolation functions look up a key and return
the resulting value. The result of the lookup must be a string; any
other result causes an error.

(Emphasis added)

What you're looking for would be supported by Hiera 5's %{alias} function, provided that the data are available somewhere else in the same hierarchy (which is also a requirement for %{hiera}). Since you're stuck on Puppet 3, however, you're probably on Hiera 2, and certainly not later than Hiera 3.

"But wait!" You may say. "I'm getting a successful interpolation, but the data are just munged". Specifically, you wrote:

problem is that puppet was adding extra " " to the value and final value

Since %{hiera()} interpolates only strings, it is not surprising that you got a string value, given that you got a value at all. I do find it a bit surprising that Puppet did not throw an error, but I'm not prepared to comment further on that without a minimum reproducible example that demonstrates the behavior.

---

Related Topics