Puppet / Facter "Impossible de récupérer le fait fqdn": Comment corriger ou contourner?
J'apprends les marionnettes et j'essaye de les expérimenter sur un VM à la maison. Je n'utilise pas encore de serveur de marionnettes, je fais juste tourner les choses localement. Cela fonctionne bien, mais chaque fois que je courir puppet apply ..., J'obtiens un délai de plusieurs secondes, après quoi il affiche le message
warning: Could not retrieve fact fqdn
Je suppose que le message est lié au retard, et je veux m'en débarrasser (le retard - je peux vivre avec le message). La recherche d'une solution semble indiquer qu'elle est en quelque sorte liée aux recherches DNS, mais je ne trouve vraiment rien d'autre à ce sujet, ce qui semble surprenant. Tout ce que je veux, c'est pouvoir appliquer rapidement des manifestes dans mon vm pour pouvoir expérimenter. Comment puis-je accélérer les choses?
Mise à jour: Je ne vois aucune information supplémentaire dans la sortie de débogage, mais cela ressemble à ceci:
$ 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
...
Mise à jour: J'ai ajouté la balise "Ruby" car la marionnette a si peu d'adeptes. Si cela n'appartient pas à Ruby, ou si vous connaissez une meilleure étiquette, faites-le moi savoir.
Mettre à jour à nouveau: Ayant appris un peu plus sur les marionnettes, je comprends maintenant que ce message provient du composant appelé "Facter" qui flaire les "faits" sur le système sur lequel Puppet fonctionne. J'ai trouvé quelques options de configuration et joué avec "" certname " , " node_name " and " node_name_value " , mais je n'ai pas pu obtenir le délai s'en aller. Est-ce que quelqu'un sait spécifiquement comment dire à Facter d'ignorer le fqdn ou comment rendre Facter capable de trouver le fqdn sur un Ubuntu 11.10 vm?
Progression:
$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1
C'est mon routeur, qui exécute 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 m'a conduit à arp, qui bloquait pendant 5 secondes et appelé deux fois pour chaque 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
J'ai changé le VM de NAT réseau en ponté, afin qu'il ait maintenant une IP sur le réseau, et arp retourne immédiatement maintenant. (Je ne suis pas un gourou du réseautage, donc je ne sais pas pourquoi cela a fonctionné, mais cela semblait une chose raisonnable à essayer.) Mais facter prend toujours environ 4-5 secondes au total pour s'exécuter et signale toujours "Impossible récupérer le fait fqdn ". facter -d montre plusieurs occurrences de "la valeur pour le domaine est toujours nulle", jusqu'à la fin. Je pense que quelque chose ne va toujours pas.
Comme marionnette utilise le fait fqdn pour déterminer le nœud sur lequel il s'exécute, il peut ne pas être possible de l'exécuter s'il ne peut pas être déterminé. Compte tenu de ce que vous décrivez, la chose la plus simple à déboguer est facter fqdn au lieu de votre ligne de commande fantoche.
Si les "plusieurs secondes" sont très proches d'exactement 5 secondes, il est très probable que votre configuration DNS soit rompue avec un seul mauvais serveur DNS répertorié. Que contient /etc/resolv.conf? Que se passe-t-il si vous exécutez Dig -x $HOSTIP $DNSSERVERIP avec le premier serveur de noms répertorié dans resolv.conf?
Si vous regardez dans facter/fqdn.rb vous pouvez voir exactement ce que le facter essaie de faire pour résoudre le fqdn. Dans la version que j'ai la plus pratique, elle utilise facter/hostname.rb et facter/domainname.rb qui appelle le code de facter/util/resolution.rb.
Ce qui se passera dépendra de la version de Facter que vous possédez, du système d'exploitation et éventuellement de la version exacte que vous avez installée. Appeler /bin/hostname, uname (etc) et faire des recherches DNS sont tous très probables. Vous pouvez toujours utiliser strace -t facter fqdn pour voir ce qui prend du temps (recherchez l'écart dans les horodatages)
D'après tout ce que vous avez décrit, il semble que le problème est que la marionnette/facter veut vraiment avoir un nom de domaine et vous n'en avez pas, vous avez juste un nom d'hôte nu.
Ajouter domain example.com à /etc/resolv.conf devrait faire l'affaire. Fonctionnement hostname foo.example.com devrait également faire l'affaire (mais devra être appliqué de nouveau). Les solutions permanentes dépendent de la configuration exacte du système d'exploitation.
J'ai eu la même erreur lors de l'exécution de marionnettes sur ma machine domestique (Xubuntu). Ce qui a fonctionné pour moi, c'était de changer la deuxième ligne de fichier /etc/hosts. Les deux premières lignes avant le changement:
127.0.0.1 localhost
127.0.1.1 box
Et après le changement:
127.0.0.1 localhost
127.0.1.1 box.example.com box
Maintenant, la commande hostname -f Retour box.example.com au lieu de box, et la marionnette est contente.
Ajouter
config.vm.hostname = "vagrant.example.com"
à mon Vagrantfile l'a corrigé pour moi.
FQDN signifie "nom de domaine complet". Dans un domaine Windows (ou un autre domaine LDAP similaire), par exemple, ce serait le nom de votre domaine réseau, tel que "organization.internal" - le domaine auquel vos ordinateurs et serveurs sont joints et le domaine qui contient vos groupes réseau et vos comptes d'utilisateurs.
Donc, il a probablement eu du mal à obtenir le fqdn pour une authentification nécessaire pour effectuer le reste des étapes de configuration, serait ma supposition.
http://en.wikipedia.org/wiki/Fully_qualified_domain_name
Il est possible que vous obteniez une meilleure réponse sur ServerFault, car la gestion du système/de la configuration traverse également leur domaine.
ajoutez cette ligne dans /etc/resolv.conf
domain abc.com
exécuter à nouveau facter fqdn
Fqdn nécessite un nom de domaine, qui peut-être manquant dans votre ubu12 fraîchement installé
Une autre façon possible de contourner le problème est de passer outre le fait.
http://www.puppetcookbook.com/posts/override-a-facter-fact.html
FACTER_fqdn=box.example.com facter
Sous Windows, ce serait
SET FACTER_fqdn=box.example.com
facter fqdn