[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/hosts : pourquoi mettre le hostname sur un ip different que le localhost ?



Salut,

giggz a écrit :
> 
> d'après
> http://www.debian.org/doc/manuals/reference/ch05.en.html#_the_basic_network_infrastructure
> the "/etc/hosts" file associates IP addresses with hostnames contains
> the following.
> 
> 127.0.0.1 localhost
> 127.0.1.1 <host_name>.<domain_name> <host_name>
> 
> # The following lines are desirable for IPv6 capable hosts
> ::1     ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> ff02::3 ip6-allhosts

Grmbl, ça n'a toujours pas été corrigé ?
fe00:: et ff00:: sont des *préfixes*, ils n'ont rien à faire dans le
fichiers *hosts*. Quant à l'adresse ff02::3, elle n'a jamais été
reconnue comme "all hosts" dans aucun document normatif, et d'ailleurs
ne marche pas.

>> Il me semble que l'adresse 127.0.1.1 est identique à 127.0.0.1, ça
>> pointe toujours vers ton interfaces loopback (lo).

Similaire mais pas identique. Une socket qui écoute sur 127.0.0.1
n'accepte pas les communications à destination de 127.0.1.1.

>> Il faut mettre l'adresse IP de eth0 avec le nom de ta machine.

Oui, si cette adresse est fixe.

> pourquoi ? quelle est la différence ? qu'est ce que ça apporte ?

Le paragraphe du manuel de référence ci-dessus pointe vers le rapport de
bug <http://bugs.debian.org/316099> où il est dit :

     If there is no permanent IP address with which the system hostname
     (i.e., that which is returned by the "hostname" command) can be
     associated in /etc/hosts then associate it with address 127.0.1.1

"S'il n'y a pas d'adresse IP permanente qui puisse être associée au nom
d'hôte".

Si l'hôte a une adresse IP permanente "réelle" (non loopback), alors
c'est elle qui devrait être associée au nom d'hôte car ainsi la
résolution du nom est identique aussi bien à l'intérieur qu'à
l'extérieur de l'hôte.

Il y a quand même un problème avec la résolution du nom d'hôte en
127.0.1.1. Le texte de la correction de bug dit :

     Programs that access local services at the IP address obtained by
     resolving the system hostname SHOULD NOT DO THIS, but those that
     do so will not be disappointed: most services that listen locally
     listen on all 127/8 addresses, not just on 127.0.0.1.

"La plupart des services qui écoutent localement écoutent sur toutes les
adresses 127.0.0.0/8, pas seulement 127.0.0.1."

Mon expérience est inverse. Il y a deux cas :

1) Le service écoute sur n'importe quelle adresse (0.0.0.0), mais alors
il n'écoute pas seulement "localement" mais aussi sur les adresses de la
machine accessibles de l'extérieur.

2) Le service écoute sur une (ou plusieurs) adresse spécifique. A ma
connaissance on ne peut pas spécifier à une socket d'écouter un préfixe
entier.

J'ai en tête l'exemple du serveur DNS BIND : par défaut il scanne les
adresses des interfaces et écoute dessus (une socket par adresse). Mais
concernant l'interface de loopback, il n'écoute que sur 127.0.0.1 car
c'est celle-ci qui est configurée. Par conséquent une commande comme :

$ dig <requete> @<hostname>

ne marchera pas sur le serveur lui-même si <hostname> est résolu dans
son fichier hosts en 127.0.1.1 sur laquelle BIND n'écoute pas, alors
qu'elle marchera sur une autre machine pour laquelle <hostname> est
résolu en l'adresse IP "réelle" (non loopback) du serveur.


Reply to: