Je cherche à configurer l'ordre de recherche pour la résolution de nom d'hôte sur un environnement redhat.
Je veux simplement que la machine resolve les noms d'hôtes en se basant sur le fichier /etc/hosts.
L'environnement est configuré comme suit :
Le fichier /etc/resolv.conf est vide
Le fichier /etc/host.conf contient la ligne suivante :
order hosts
Le paramètre host de /etc/nsswitch.conf est le suivant :
hosts: files
Le fichier /etc/hosts contient divers enregistrements permettant l'association IP Nom d'hôte.
Maintenant, si je cherche à résoudre "localhost" avec les commandes host, nslookup ou même dig, j'obtiens un time out, tout simplement parce que ces 3 commandes cherchent à contacter un DNS.
La commande "strace" montre clairement que les commandes host, nslookup font un open sur /etc/resolv.conf, comme il n'y a pas de DNS ça tombe en time out, et ça ne va même pas lire /etc/hosts.
La commande ping a un comportement à peu près équivalent, elle cherche d'abord sur /etc/resolv.conf puis après sur /etc/hosts.
En lisant la page de manuel de la primitive gethostbyname :
Les interrogations du serveur de noms effectuées par gethostbyname() et gethostbyaddr() utilisent les éléments suivants : le serveur de noms named(8), les lignes de /etc/hosts, et l'annuaire Network Information Service (NIS ou YP), suivant le contenu de la ligne order du fichier /etc/host.conf.L'action par défaut consiste à interroger named(8), puis /etc/hosts.
Il semblerait que ce soit le comportement par défaut qui soit utilisé malgré la configuration explicite de mon /etc/host.conf.
L'url suivante mentionne exactement le même problème que moi:
http://www.frameip.com/nntp/fr-comp-reseaux-ip/28619-fr-comp(...)
Quelq'un aurait une idée ?
# /etc/resolv.conf vide
Posté par NeoX . Évalué à 1.
si tu as du reseau (il en faut meme pour faire un localhost)
tu dois avoir une entrée dans /etc/resolv.conf
ensuite seulement il ira lire /etc/hosts (sans passer par le dns vu que tu lui dis de passer par hosts)
[^] # Re: /etc/resolv.conf vide
Posté par Dabowl_92 . Évalué à 1.
Ensuite, je ne trouve pas ça normal qu'un open soit fait en premier sur /etc/resolv.conf, parce que d'après la page de manuel de la primitive gethostbyname, c'est ce que qui se trouve dans /etc/host.conf qui doit faire foi, enfin bon...
Donc d'après toi il faut obligatoirement un enregistrement dans /etc/resolv.conf, soit.
Mais quel enregistrement mettre ? J'ai mis nameserver tout court, le problème reste le même...j'ai mis nameserver et domain etc...
qu'entend précisément par "tu dois avoir une entrée dans /etc/resolv.conf" ?
[^] # Re: /etc/resolv.conf vide
Posté par NeoX . Évalué à 1.
user@machine:~$ cat /etc/resolv.conf
user@machine:~$ cat /etc/nsswitch.conf
user@machine:~$ cat /etc/host.conf
et si mon reseau ne fonctionne pas, ben j'ai quand meme ma resolution localhost qui fonctionne.
et je viens d'essayer, si je vide le resolv.conf mais que j'ai mis mes hotes dans /etc/hosts
avec la syntaxe suivante
IP_de_la_machine nom_complet nom_abrege
et ben je pingue bien cette machine.
le ping localhost qui ne fonctionne pas, ca me fait penser à l'interface lo qui ne serait pas active, ou une erreur de syntaxe dans le fichier /etc/hosts
[^] # Re: /etc/resolv.conf vide
Posté par Dabowl_92 . Évalué à 1.
Ce sont les commandes host, nslookup et dig qui ne fonctionnent pas car elles cherchent absolument à aller causer à un DNS, ça tombe en time out et elles s'arrêtent là !
Le ping fonctionne sauf que la commande cherche d'abord à ouvrir /etc/resolv.conf pour se connecter à un DNS et seulement ensuite fait un open sur le /etc/hosts, et là fort heureusement il résoud bien le nom.
Moi ce que je veux, c'est uniquement résoudre les noms avec /etc/hosts et à aucun moment ne faire appel à un DNS. Il semblerait que la primitive gethostbyname n'ai pas le comportement souhaité...pourtant sous AIX le comportement est normal....
Ensuite, quand tu réalise ton test, pense bien à stopper le name service cache daemon....avec un /etc/init.d/nscd stop parce que la commande ping (et surement d'autres) va voir la socket locale pour tenter de résoudre des noms en cache...
Refait ton test avec les commandes host, nslookup....
Analyse la sortie d'un strace surtout, histoire de voir ta primitive a bien le même comportement....
J'ai peut-être un bug...mon kernel est le suivant 2.4.21-27.ELsmp
[^] # Re: /etc/resolv.conf vide
Posté par NeoX . Évalué à 3.
man host :
man nslookup
man dig
les 3 outils que tu cites se base clairement sur le fichier /etc/resolv.conf
et c'est normal car ils font, par definition, du traitement de type DNS
et pour en revenir à la question initiale,
es-tu sur que ces 3 outils se basent sur les primitive gethostbyname() et gethostbyaddress() ?
[^] # Re: /etc/resolv.conf vide
Posté par Dabowl_92 . Évalué à 1.
La commande nslookup ne tient absolument pas compte du /etc/hosts qu'elle que soit l'implémentation et c'est annoncé clairement.
En revanche la commande host n'a pas le même comportement sous AIX où le fichier /etc/hosts est consulté selon l'ordre de recherche définit....c'est assurément ce qui m'a induit en erreur.
[^] # Re: /etc/resolv.conf vide
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: /etc/resolv.conf vide
Posté par NeoX . Évalué à 2.
il s'agit peut-etre d'un serveur en prod, et on ne change pas un serveur juste parce que cela fait plaisir ou parce que la derniere version est sortie.
[^] # Re: /etc/resolv.conf vide
Posté par BAud (site web personnel) . Évalué à 3.
avec 5 ans de support standard, ce serveur n'aurait plus que 1 an à vivre à moins d'obtenir un support étendu pour le faire vivoter.
Autant prévoir de le faire évoluer dès maintenant tout de même... Ce n'est pas comme un Solaris 8 qui peut-être maintenu en support étendu jusqu'en 2012 ;-) ('fin bon il reste sûrement des AIX 4.3.3patch10 qui traînent hein :/).
[^] # Re: /etc/resolv.conf vide
Posté par BAud (site web personnel) . Évalué à 3.
bon sinon ya un kernel 2.4.21-51 d'après https://rhn.redhat.com/errata/RHSA-2007-0671.html (mais bon mieux vaut l'avoir qualifié avant quoi :/)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.