Noeud MAAS incapable de résoudre son propre nom d'hôte
J'ai déployé un serveur MAAS de région/rack, l'interface eth principale se connectant à WAN et un autre se connectant à un commutateur par à l'aide de iptables comme étant MAAS-vlan avec DHCP configuré.
Je me suis trouvé dans l'impossibilité d'obtenir des informations de stockage sur mes deux machines (avec un matériel différent). Après des heures de recherche, j'ai constaté que la résolution du nom comportait une erreur et que les nœuds étaient incapables de résoudre leur propre nom d'hôte lors de la mise en service. ce qui a également rendu le processus de mise en service extrêmement long, car il attend la résolution du nom pour expirer la plupart du temps. (C'est une hypothèse, mais après avoir réussi à me connecter à la boîte, ping golden-moose prend environ 10 secondes, puis une erreur "hôte inconnu")
la sortie de mise en service 00-maas-07-block-devices.err lit:
Sudo: unable to resolve Host golden-moose: Connection timed out
Sudo: unable to resolve Host golden-moose: Connection timed out
Sudo: unable to resolve Host golden-moose: Connection timed out
Sudo: unable to resolve Host golden-moose: Connection timed out
J'utilise MAAS version 2.1.1 + bzr5544-0ubuntu1 (16.04.1) et je ne suis pas sûr de savoir comment déboguer ce problème, aidez-moi, merci.
Le service DNS semble fonctionner correctement. Les nœuds ont pu résoudre les hôtes externes et le domaine .maas.
UPDATE
J'ai mis à jour MAAS à la version 2.1.3 et le même problème. Une fois connecté à un nœud de mise en service (à l'aide de l'option "Autoriser l'accès SSH et empêcher la machine de s'éteindre"), j'ai constaté que le nœud était capable d'envoyer une requête ping aux noms d'hôte UNIQUEMENT AVEC ".maas" APPENDED. Ce qui signifie que le nom de domaine n'a pas été correctement défini.
$ hostname -f
hostname: Name or service not known
$ domainname
(none)
Les règles iptables semblent bien fonctionner. Les commandes suivantes impriment toutes les sorties raisonnables (avec un nombre de paquets différent de zéro)
$ Sudo iptables -t raw -L -n -v
Chain PREROUTING (policy ACCEPT 645K packets, 185M bytes)
Chain OUTPUT (policy ACCEPT 411K packets, 1140M bytes)
$ Sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 73538 packets, 11M bytes)
Chain INPUT (policy ACCEPT 62414 packets, 9009K bytes)
Chain OUTPUT (policy ACCEPT 6585 packets, 493K bytes)
Chain POSTROUTING (policy ACCEPT 360 packets, 54084 bytes)
$ Sudo iptables -t filter -L -n -v
Chain INPUT (policy ACCEPT 1772K packets, 875M bytes)
Chain FORWARD (policy DROP 694 packets, 185K bytes)
Chain OUTPUT (policy ACCEPT 1033K packets, 2318M bytes)
UPDATE - Sauvegarde DNS
À l'aide de l'outil tcpdump, j'ai tracé les requêtes DNS du nœud.
Les requêtes de nom d'hôte de nœud typiques par Sudo ressemblent à ce qui suit (deux fois):
11:48:02.836710 IP (tos 0x0, ttl 64, id 53634, offset 0, flags [DF], proto UDP (17), length 57)
<node-ip>.35343 > <maas-ip>.53: [udp sum ok] 8298+ A? pure-mammal. (29)
11:48:02.836750 IP (tos 0x0, ttl 64, id 53635, offset 0, flags [DF], proto UDP (17), length 57)
<node-ip>.35343 > <maas-ip>.53: [udp sum ok] 36815+ AAAA? pure-mammal. (29)
11:48:02.836938 IP (tos 0x0, ttl 64, id 40343, offset 0, flags [none], proto UDP (17), length 132)
<maas-ip>.53 > <node-ip>.35343: [bad udp cksum 0x71e4 -> 0x8095!] 36815 NXDomain q: AAAA? pure-mammal. 0/1/0 ns: . [2h34m56s] SOA a.root-servers.net. nstld.verisign-grs.com. 2017012101 1800 900 604800 86400 (104)
11:48:02.836945 IP (tos 0x0, ttl 64, id 40461, offset 0, flags [none], proto UDP (17), length 132)
<maas-ip>.53 > <node-ip>.35343: [bad udp cksum 0x71e4 -> 0x0afb!] 8298 NXDomain q: A? pure-mammal. 0/1/0 ns: . [2h34m56s] SOA a.root-servers.net. nstld.verisign-grs.com. 2017012101 1800 900 604800 86400 (104)
Bien que je remarque le bit [bad udp cksum], j'ai vérifié plus tard que cela n'affectait pas le résultat du nœud.
Un appel Dig avec pure-mammal.maas à partir du nœud de mise en service aboutirait à un journal:
11:50:57.723037 IP (tos 0x0, ttl 64, id 24007, offset 0, flags [none], proto UDP (17), length 73)
<node-ip>.53704 > <maas-ip>.53: [udp sum ok] 5376+ [1au] A? pure-mammal.maas. ar: . OPT UDPsize=4096 (45)
11:50:57.723321 IP (tos 0x0, ttl 64, id 5403, offset 0, flags [none], proto UDP (17), length 119)
<maas-ip>.53 > <node-ip>.53704: [bad udp cksum 0x71d7 -> 0x8af0!] 5376* q: A? pure-mammal.maas. 1/1/2 pure-mammal.maas. [30s] A <node-ip> ns: maas. [30s] NS maas. ar: maas. [30s] A <maas-ip>, . OPT UDPsize=4096 (91)
Cet appel entraîne une sortie Dig valide du noeud.
Mise à jour finale et conclusion
Bien que le problème du nom d’hôte soit bel et bien au rendez-vous, le problème qui a conduit à ce qu’aucune configuration de stockage ne soit complètement différente.
Après des heures de vérification et de nombreux conseils de @mpontillo, j'ai enfin effectué les travaux de mise en service. La surprise a été les 2 des 3 options de mise en service, à savoir "Conserver la configuration réseau" et "Conserver la configuration de stockage". J'ai vérifié ces 2 à chaque fois, car je pensais que c'était pour "conserver" les informations des nœuds. La configuration de stockage a été lue correctement après celles non cochées.
Tout d'abord, je vous recommande de mettre à jour MAAS 2.1.3, qui est disponible dans xenial-updates, et de relancer la mise en service. Cela éliminera tout problème connu.
En pensant à ce problème, le message Connection timed out est ce qui me préoccupe le plus. Cela signifie que vous n'obtenez pas de réponse du serveur DNS. Je pense donc que ce problème est très probablement un problème de connectivité DNS. Pour résoudre ce problème, nous aurons peut-être besoin de voir le résultat des commandes suivantes sur votre serveur MAAS à double hébergement:
Sudo iptables -t raw -L -n -v
Sudo iptables -t nat -L -n -v
Sudo iptables -t filter -L -n -v
Si les règles du pare-feu semblent bonnes, je résoudrais le problème en mettant en service le nœud avec l'option Allow SSH access and prevent machine from powering off. Puis entrez SSH et utilisez Dig $(hostname -f) pour vérifier que vous pouvez résoudre l'hôte à partir du noeud de mise en service lui-même. Vous pouvez aussi essayer Host $(hostname), ce qui vérifierait que le chemin de recherche fonctionne correctement.
Ensuite, je vérifie /etc/bind/maas/named.conf.maas sur le serveur MAAS pour m'assurer que le réseau à partir duquel vous essayez d'atteindre MAAS figure dans la liste des réseaux sécurisés. (MAAS devrait mettre à jour automatiquement cette ACL.)
Enfin, vérifiez le journal système sur le serveur MAAS pour vous assurer que tout se passe bien, tel que grep named /var/log/syslog.
Un peu lié est bogue n ° 108718 , qui explique le fait qu’une installation standard d’Ubuntu ajoute une ligne avec le nom d’hôte à /etc/hosts, mais que dans MAAS cela a posé des problèmes, MAAS doit donc compter sur DNS.
Lors de la mise en service, resolv.conf ne dispose que d’un serveur de noms. Lorsque nous déployons, il a une liste de recherche complète, avec le nom de la machine en premier, bien sûr.
Lors de la mise en service, la machine reçoit son DNSDOMAIN, mais il semble que le domaine ne soit pas entré dans /etc/resolv.conf.
J'ai déposé Bogue 165875 pour ce problème.
Par souci de clarté, si Sudo ne résout pas le nom, le message d’avertissement en cours d’impression apparaît: il ne fait rien d’autre et Sudo fait ce que vous lui avez dit. (Il essaie d'obtenir le nom d'hôte afin qu'il puisse le comparer à toutes les règles verrouillées par l'hôte dans sudoers, dont il n'y en a pas.)