Я изучаю марионетку и пытаюсь экспериментировать с ней на виртуальной машине дома. Я еще не использую марионеточный сервер, просто работая на месте. Он работает нормально, но каждый раз, когда я запускаю puppet apply ...
, я получаю задержку в несколько секунд, после чего выводит сообщение
warning: Could not retrieve fact fqdn
Я предполагаю, что сообщение связано с задержкой, и я хочу избавиться от него (задержка - я могу жить с сообщением). Googling для решения, похоже, указывает, что он каким-то образом связан с поиском DNS, но я не могу найти что-то еще, что кажется удивительным. Все, что я хочу, - это быстро применить манифеста в моем vm, чтобы я мог экспериментировать. Как я могу ускорить процесс?
Обновление: Я не вижу дополнительной информации в отладочном выходе, но выглядит так:
$ 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
...
Обновление: Я добавил тэг "ruby", потому что у марионетки так мало последователей. Если это не относится к рубину, или если вы знаете лучший тег для него, сообщите мне.
Обновить еще раз: Узнав еще немного о марионетке, теперь я понимаю, что это сообщение исходит от компонента, называемого "Facter", который вынюхивает "факты" о системе, в которой работает Puppet. Я нашел некоторые параметры конфигурации и играл с "certname" , "node_name" и "node_name_value" , но я не мог заставить задержку уйти. Кто-нибудь знает конкретно, как либо сказать Facter игнорировать fqdn, либо как заставить Facter найти fqdn на Ubuntu 11.10 vm?
Прогресс:
$ 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
Я изменил VM из сети NAT на мост, так что теперь он имеет IP-адрес в сети, а arp
немедленно возвращается. (Я не являюсь сетевым гуру, поэтому я понятия не имею, почему это сработало, но было разумно попробовать.) Но facter
по-прежнему занимает около 4-5 секунд для запуска и до сих пор отчетов "Не удалось получить факт fqdn". facter -d
показывает несколько вхождений "значение для домена по-прежнему равно нулю", вплоть до конца. Я думаю, что все еще не совсем правильно.