Puppet / Facter «Не удалось получить факт fqdn»: как исправить или обойти?
Я изучаю puppet и пытаюсь поэкспериментировать с ним на виртуальной машине дома. Я пока не использую марионеточный сервер, просто запускаю все локально. Он работает нормально, но каждый раз, когда я запускаю puppet apply ... , я получаю задержку в несколько секунд, после чего отображается сообщение
warning: Could not retrieve fact fqdn
Я предполагаю, что сообщение связано с задержкой, и я хочу избавиться от него (задержка - я могу жить с сообщением). Поиск решения в Google, похоже, указывает на то, что оно каким-то образом связано с поиском в DNS, но я не могу найти в нем ничего другого, что кажется удивительным. Все, что я хочу, - это иметь возможность быстро применять манифесты в моей виртуальной машине, чтобы я мог экспериментировать. Как я могу ускорить процесс?
Обновление: Я не вижу дополнительной информации в отладочных данных, но это выглядит так:
$ 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
...
Обновление: Я добавил тег «рубиновый», потому что у марионетки так мало последователей. Если это не рубин, или если вы знаете более подходящий тег, дайте мне знать.
Обновите снова: Узнав больше о марионетке, я теперь понимаю, что это сообщение исходит от компонента под названием «Facter», который вынюхивает «факты» о системе, в которой работает Puppet.Я нашел некоторые параметры конфигурации и поигрался с "certname" , "node_name" и "node_name_value" , но я не мог заставить задержку исчезнуть . Кто-нибудь знает, как конкретно указать Facter игнорировать fqdn или как заставить Facter найти fqdn на виртуальной машине Ubuntu 11.10?
Прогресс:
$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1
Это мой маршрутизатор, на котором Dnsmasq запущен через 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 привел меня к arp, который блокировался на 5 секунд и вызывал дважды для каждого 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
Я изменил виртуальную машину с NAT-сети на мостовую, так что теперь у нее есть IP в сети, и arp немедленно возвращается. (Я не гуру в области сетевых технологий, поэтому понятия не имею, почему это сработало, но это казалось разумным, чтобы попробовать.) Но facter по-прежнему занимает в общей сложности около 4-5 секунд и по-прежнему сообщает: «Может, не получить факт fqdn ". facter -d показывает несколько случаев, когда «значение домена все еще равно нулю» до самого конца. Я думаю, что-то все еще не так.