Puppet / Facter "Could not find fqdn fact": how to fix or work around?

Question

I am studying a puppet and trying to experiment with it in a virtual machine at home. I am not using a puppet server yet, just working locally. It works fine, but every time I run puppet apply ... , I get a delay of a few seconds, and then displays a message

 warning: Could not retrieve fact fqdn 

I assume that the message is related to the delay, and I want to get rid of it (delay - I can live with the message). Googling for the solution seems to indicate that it has something to do with DNS lookups, but I can't find anything else that seems surprising. All I want is to quickly apply the manifest in my vm so that I can experiment. How can I speed up the process?

Update: I do not see additional information in the debug output, but it looks like this:

 $ puppet apply -dv puppet-1.pp warning: Could not retrieve fact fqdn debug: Failed to load library 'rubygems' for feature 'rubygems' debug: Failed to load library 'selinux' for feature 'selinux' debug: Puppet::Type::File::ProviderMicrosoft_windows: feature microsoft_windows is missing ... 

Update: I added the tag “ruby” because the puppet has so few followers. If this does not apply to ruby, or if you know the best tag for it, let me know.

Refresh again: Having learned a little more about the puppet, I now understand that this message comes from a component called "Facter", which sniffs out "facts" about the system in which Puppet works. I found some configuration options and played with "certname" , "node_name" and "node_name_value" , but I could not get the delay to go away. Does anyone know specifically how to either tell Facter to ignore fqdn, or how to get Facter to find fqdn on Ubuntu 11.10 vm?

Progress:

 $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.1.1 

What is my router that runs Dnsmasq through Tomato.

 $ dig -x 192.168.1.129 192.168.1.1 ; <<>> DiG 9.7.3 <<>> -x 192.168.1.129 192.168.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21838 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;129.1.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 129.1.168.192.in-addr.arpa. 0 IN PTR desk-vm-ubuntu-beta. ;; Query time: 14 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Oct 16 17:47:47 2011 ;; MSG SIZE rcvd: 77 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27462 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;192.168.1.1. IN A ;; ANSWER SECTION: 192.168.1.1. 0 IN A 192.168.1.1 ;; Query time: 11 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Oct 16 17:47:47 2011 ;; MSG SIZE rcvd: 45 

strace led me to arp, which was blocked for 5 seconds and called twice for each facter :

 $ time arp -a ? (10.0.2.2) at 52:54:00:12:35:02 [ether] on eth0 real 0m5.127s user 0m0.004s sys 0m0.016s 

I changed the VM from the NAT network to the bridge, so now it has an IP address on the network, and arp returns immediately. (I am not a network guru, so I have no idea why this worked, but it was wise to try.) But the facter still takes about 4-5 seconds to run and still reports “Failed to get fqdn fact”. facter -d shows several occurrences of "the value for the domain is still zero", up to the end. I think that is still not quite right.

Answer 1

Since the puppet uses the fact fqdn to determine which node it works as, it cannot be started if it cannot be determined. Given what you are describing, the easiest to debug is facter fqdn instead of your manual command line.

If the “few seconds” is very close to exactly 5 seconds, it is very likely that your DNS configuration will be split into one bad DNS server. What is in /etc/resolv.conf? What happens if you run dig -x $HOSTIP $DNSSERVERIP with the first name server specified in resolv.conf?

If you look in facter/fqdn.rb , you can see what exactly this fact does to resolve fqdn. In the version, it is most convenient for me to use facter/hostname.rb and facter/domainname.rb , which call the code from facter/util/resolution.rb .

What happens will depend on which version of the fax machine you have, which OS, and possibly what you installed. Calling /bin/hostname , uname (etc.) and performing a DNS lookup are likely. You can always use strace -t facter fqdn to find out what takes time (find the time span)

From all that you described, the problem seems to be that the puppet / factorist really wants to have a domain name, but you don’t have it, you just have a bare host name.

Adding domain example.com to /etc/resolv.conf should do the trick. Running hostname foo.example.com should also do the trick (but it will need to be hostname foo.example.com ). Permanent decisions depend on the specific OS setting.

Answer 2

I have the same error when starting a puppet on my home machine (Xubuntu). The second line of the /etc/hosts worked for me. The first two lines before the change:

 127.0.0.1 localhost 127.0.1.1 box 

And after the change:

 127.0.0.1 localhost 127.0.1.1 box.example.com box 

Now the hostname -f command returns box.example.com instead of box , and the puppet is happy.

Answer 3

Adding

  config.vm.hostname = "vagrant.example.com" 

for my Vagrantfile fixed it for me.

Answer 4

FQDN means "fully qualified domain name". For example, in a Windows domain (or other similar domain based on LDAP), this will be the name of your network domain, for example, "organization.internal" - the domain to which your computers and servers are connected, and the domain that contains network groups and user accounts.

So there was probably a problem getting fqdn for some authentication needed to complete the rest of the configuration steps would be my guess.

http://en.wikipedia.org/wiki/Fully_qualified_domain_name

You might get a better answer to ServerFault, since system and configuration management also crosses their scope.

Answer 5

add this line to /etc/resolv.conf

 domain abc.com 

run fqdn again

Fqdn requires a domain name that may not be present in your recently installed ubu12

Answer 6

Another possible workaround is to override this fact.

http://www.puppetcookbook.com/posts/override-a-facter-fact.html

 FACTER_fqdn=box.example.com facter 

On Windows, it will be

 SET FACTER_fqdn=box.example.com facter fqdn