Puppet/Facter "Could not retrieve fact fqdn": How to fix or circumvent?
I'm learning about puppet and trying to experiment with it on a VM at home. I'm not using a puppet server yet, just running things locally. It works okay, but every time I run puppet apply ..., I get a delay of several seconds, after which it displays the message
warning: Could not retrieve fact fqdn
I assume the message is linked to the delay, and I want to get rid of it (the delay--I can live with the message). Googling for a solution seems to indicate that it's somehow related to DNS lookups, but I can't really find anything else about it, which seems surprising. All I want is to be able to apply manifests in my vm quickly so I can experiment. How can I speed things up?
Update: I don't see any extra info 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 "ruby" tag because puppet has so few followers. If this doesn't belong in ruby, or if you know a better tag for it, let me know.
Update again: Having learned some more about puppet, I now understand that this message is coming from the component called "Facter" that sniffs out "facts" about the system that Puppet is running on. I found some configuration options and played around with "certname", "node_name" and "node_name_value", but I couldn't get the delay to go away. Does anyone know specifically how to either tell Facter to ignore the fqdn or how to make Facter able to find the fqdn on an Ubuntu 11.10 vm?
Progress:
$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1
That's my router, which is running Dnsmasq via 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 blocking 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 NAT networking to bridged, so that it now has an IP on the network, and arp returns immediately now. (I'm no networking guru, so I have no idea why this worked, but it seemed a reasonable thing to try.) But facter still takes about 4-5 seconds total to run and still reports "Could not retrieve fact fqdn". facter -d shows several occurrences of "value for domain is still nil", all the way to the end. I'm thinking something still isn't quite right.
Answer
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.