Marionnette / Facter «Impossible de récupérer le fait fqdn»: comment réparer ou contourner?

J’apprends la marionnette et j’essaie de l’expérimenter sur une VM chez moi. Je n’utilise pas encore un serveur de marionnettes, je ne fais qu’exécuter des choses localement. Cela fonctionne bien, mais chaque fois que je lance une puppet apply ... , je reçois un délai de plusieurs secondes, après quoi il affiche le message

 warning: Could not resortingeve fact fqdn 

Je suppose que le message est lié au retard et je veux m’en débarrasser (le délai – je peux vivre avec le message). Googler pour une solution semble indiquer qu’elle est en quelque sorte liée aux recherches DNS, mais je ne trouve rien d’autre à ce sujet, ce qui semble surprenant. Tout ce que je veux, c’est pouvoir appliquer rapidement les manifestes dans ma 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 resortingeve 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” parce que la marionnette a si peu d’abonnés. Si cela n’appartient pas à ruby, ou si vous en connaissez un meilleur, faites le moi savoir.

Mise à jour à nouveau: Après en avoir appris davantage sur la marionnette, je comprends maintenant que ce message provient du composant appelé “Facter” qui détecte les “faits” sur le système sur lequel fonctionne Puppet. J’ai trouvé des options de configuration et j’ai joué avec “certname” , “node_name” et “node_name_value” , mais je n’ai pas pu obtenir le délai pour partir. Est-ce que quelqu’un sait comment dire à Facter d’ignorer le FQDN ou comment rendre Facter capable de trouver le FQDN sur une machine virtuelle Ubuntu 11.10?

Le progrès:

 $ 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<>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 a 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é la VM de la mise en réseau NAT à la passerelle, de sorte qu’elle possède désormais une adresse IP sur le réseau et que arp retourne immédiatement maintenant. (Je ne suis pas un gourou du réseautage, alors je ne sais pas pourquoi cela a fonctionné, mais cela a semblé une chose raisonnable à essayer). facter -d montre plusieurs occurrences de “value for domain is nil”, jusqu’à la fin. Je pense que quelque chose ne va toujours pas.

Puisque puppet utilise le fait fqdn pour déterminer quel nœud il exécute, il ne sera peut-être pas 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 de marionnettes.

Si “plusieurs secondes” est très proche de exactement 5 secondes, il est fort probable que votre configuration DNS soit interrompue par un seul serveur DNS incorrect répertorié. Qu’est-ce que dans /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 facteur essaie de faire pour résoudre le problème. Dans la version la plus pratique, facter/hostname.rb et facter/domainname.rb qui appellent le code de facter/util/resolution.rb .

Exactement ce qui se passera dépendra de la version de facteur que vous avez, quel système d’exploitation et éventuellement de ce que vous avez installé. Appeler /bin/hostname , uname (etc) et faire des recherches DNS est tout à fait probable. Vous pouvez toujours utiliser strace -t facter fqdn pour voir ce qui prend du temps (cherchez le décalage dans les horodatages)

D’après tout ce que vous avez décrit, le problème est que la marionnette / facteur veut vraiment avoir un nom de domaine et que vous n’en avez pas, vous avez juste un nom d’hôte nu.

Ajouter le domain example.com à /etc/resolv.conf devrait faire l’affaire. L’exécution de hostname foo.example.com devrait également faire l’affaire (mais devra être hostname foo.example.com ). 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 la marionnette sur mon ordinateur (Xubuntu). Ce qui a fonctionné pour moi a été de changer la deuxième ligne du 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 

À présent, la commande hostname -f renvoie box.example.com au lieu de box et la marionnette est heureuse.

Ajouter

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

à mon Vagrantfile corrigé pour moi.

FQDN signifie “nom de domaine complet”. Par exemple, dans un domaine Windows (ou un autre domaine LDAP similaire), ce serait le nom de votre domaine réseau, par exemple “organization.internal” – le domaine auquel vos ordinateurs et serveurs sont reliés et le domaine contient vos groupes de réseaux et vos comptes d’utilisateurs.

Donc, je suppose que cela a probablement du mal à obtenir le fqdn pour une certaine authentification nécessaire pour effectuer le rest des étapes de configuration.

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 se retrouve également dans leur domaine.

append cette ligne dans /etc/resolv.conf

 domain abc.com 

exécuter le facteur fqdn à nouveau

Fqdn nécessite un nom de domaine, qui peut-être manquer dans votre ubu12 récemment installé

Un autre moyen possible de contourner le problème est de passer outre.

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

 FACTER_fqdn=box.example.com facter 

Sur Windows ce serait

 SET FACTER_fqdn=box.example.com facter fqdn