Montage smb/cifs impossible car le nom d'hôte ne serait soit-disant pas résolu

Le 11/02/2012 19:39, Francois Lafont a écrit :

Bonjour à tous,

J'ai un client Squeeze sur lequel je souhaite monter un partage smb/cifs
défini sur un serveur Lenny. Tout se passe dans un réseau local qui
possède un serveur DNS pour la zone locale. Je n'arrive pas à monter le
partage :

# mount -t cifs //se3.intranet.local/NETLOGON /mnt/NETLOGON -o ro,guest
mount error: could not resolve address for se3.intranet.local: Name or
service not known

Ok, le nom se3.intranet.local n'est pas résolu. Mais pourtant j'ai ceci :

# host se3.intranet.local
se3.intranet.local has address 192.168.71.2

Donc le nom est bien résolu. Du coup, je ne sais pas du tout où chercher
la solution. Si je tente de monter le partage avec « se3 » comme nom
(sans le .intranet.local) ou avec son IP (192.168.71.2), là ça marche
impeccable.

Mais pourquoi diable est-ce que cela ne fonctionne pas avec le nom fqdn
du serveur ?

J'allais te proposer de monter directement avec l'IP, c'est fait donc OK.

Pour le problème de résolution DNS, vérifie le resolv.conf, et si par
hasard il n'y aurait pas un conflit avec un serveur DNS qui retournerait
une autre adresse.

Francois Lafont , dans le message
<4f36b5ce$0$10609$426a74cc@news.free.fr>, a écrit :

# host se3.intranet.local
se3.intranet.local has address 192.168.71.2

host n'utilise pas la la même procédure de résolution que le reste du
système. Pour ça, utilise « getent hosts ». Et regarder « host -v » pour
aider à trouver où est la différence.

Bonjour,

Merci à tous les deux pour vos réponses.

Voici les résultat de ce que vous m'avez demandé, même si plus loin je
pense avoir trouvé la raison du problème.

# cat /etc/resolv.conf
# Generated by NetworkManager
search intranet.local
nameserver 192.168.71.1

Ceci qui me paraît bon vu que 192.168.71.1 est bien le DNS «local» du
réseau qui possède l'enregistrement du nom du serveur
(se3.intranet.local = 192.168.71.2) proposant le partage Samba.

Par rapport aux demandes de Nicolas, j'avoue ne pas avoir su y trouver
des éléments qui pourraient me mettre sur la piste.

#-------------------------------------------------------
# getent hosts
127.0.0.1 localhost
127.0.1.1 squeezec.intranet.local squeezec
127.0.0.1 ip6-localhost ip6-loopback
#-------------------------------------------------------


#-------------------------------------------------------
# host -v se3.intranet.local

Trying "se3.intranet.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63313
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;se3.intranet.local. IN A

;; ANSWER SECTION:
se3.intranet.local. 86400 IN A 192.168.71.2

;; AUTHORITY SECTION:
intranet.local. 86400 IN NS localhost.

;; ADDITIONAL SECTION:
localhost. 8579 IN A 127.0.0.1
localhost. 8579 IN AAAA ::1

Received 119 bytes from 192.168.71.1#53 in 4 ms
Trying "se3.intranet.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62585
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;se3.intranet.local. IN AAAA

;; AUTHORITY SECTION:
intranet.local. 7200 IN SOA intranet.local. dns-admin.ac-versailles.fr.
2012021201 21600 3600 1209600 7200

Received 98 bytes from 192.168.71.1#53 in 0 ms
Trying "se3.intranet.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36067
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;se3.intranet.local. IN MX

;; AUTHORITY SECTION:
intranet.local. 7200 IN SOA intranet.local. dns-admin.ac-versailles.fr.
2012021201 21600 3600 1209600 7200

Received 98 bytes from 192.168.71.1#53 in 0 ms
#-------------------------------------------------------

De ce côté, rien à signaler d'intéressant, non ?

Ceci étant dit, j'ai bien avancé, je crois, à partir du moment où j'ai
fait des tests avec Wireshark. Avec « host se3.intranet.local »,
Wireshark m'affichait une requête DNS vers le serveur DNS local et une
réponse ce dernier. Bref, normal. Avec la commande suivante :

mount -t cifs //se3.intranet.local/NETLOGON /mnt/NETLOGON -o ro,guest

Wireshare m'indiquait qu'il y avait non pas une requête DNS mais une
requête *MDNS* vers l'IP 224.0.0.251 (une IP de multicast si j'ai bien
compris) et là il n'y a jamais de réponse du serveur DNS. En revanche,
la même commande que précédemment mais avec le nom se3 (sans le
.intranet.local) et là c'est bien le protocole DNS qui est utilisé et
non le protocole MDNS.

En fait, Samba est bien sûr hors de cause dans cette histoire car j'ai
testé un simple ping vers se3 et j'ai le même problème :

* ping se3.intranet.local --> utilisation du protocole MDNS -->
Résolution impossible

* ping se3 --> utilisation du protocole DNS --> Résolution Ok

Du coup, je suis allé dans /etc/nsswitch.conf et j'avais cette ligne là :

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


Du coup, en mettant simplement « hosts: files dns », tout est rentré
dans l'ordre. Ceci étant, j'aimerais bien avoir quelques
éclaircissements sur certains points si c'est possible.

1. Déjà, d'un point de vue purement pratique, est-ce gênant si je laisse
la ligne « hosts: files dns » dans le fichier /etc/nsswitch.conf et si,
du coup, je n'utilise plus du tout le protocole MDNS ? Ce ne sera pas la
source de problème ultérieurement ? J'aurais tendance à dire qu'au
contraire c'est ce protocole MDNS que me fichait la pagaille, mais bon
je ne suis pas un spécialiste.

2. Avec le réglage « hosts: files mdns4_minimal [NOTFOUND=return] dns
mdns4 », comment est-ce possible que l'appel au protocole DNS se fasse
vu qu'il y a le [NOTFOUND=return] ? J'ai l'impression que lors de la
résolution d'un nom, avec un tel réglage :

- soit mdns4_minimal permet la résolution et on ne va pas plus loin
- soit mdns4_minimal ne permet pas la résolution et on est dans le cas
NOTFOUND et à cause du return le protocole DNS n'est pas utilisé.

Donc, dans tous les cas, DNS n'est pas utilisé. C'est forcément faux
sinon la ligne aurait été simplement « hosts: files mdns4_minimal
[NOTFOUND=return] ». C'est possible d'avoir une petite explication sur
cette histoire ?

3. (Sans doute que la réponse à cette question se trouve dans la
question 2). Pourquoi, lorsque que j'avais le réglage « hosts: files
mdns4_minimal [NOTFOUND=return] dns mdns4 », si j'utilisais le nom fqdn
dans une commande (ping) alors il n'y avait pas usage de DNS pour la
résolution et si j'utilisais le nom se3 « tout court » alors là il y
avait usage de DNS pour la résolution ?

--
François Lafont

Francois Lafont <francois.lafont@nospam.invalid> writes:

3. (Sans doute que la réponse à cette question se trouve dans la
question 2). Pourquoi, lorsque que j'avais le réglage « hosts: files
mdns4_minimal [NOTFOUND=return] dns mdns4 », si j'utilisais le nom fqdn
dans une commande (ping) alors il n'y avait pas usage de DNS pour la
résolution et si j'utilisais le nom se3 « tout court » alors là il y
avait usage de DNS pour la résolution ?

Parce que la résolution se fait en mDNS uniquement pour les noms en
.local (par défaut, ça doit pouvoir se changer dans la config d'avahi,
mais dans l'absolu ce serait plutôt une mauvaise idée).

Au passage, un peu de lecture sur le choix d'un nom de domaine privé :

http://www.bortzmeyer.org/pourquoi-le-tld-local-n-est-pas-une-bonne-idee.html

--
Arnaud
http://blogs.glou.org/arnaud/

Le 12/02/2012 13:00, Francois Lafont a écrit :

Bonjour,

Merci à tous les deux pour vos réponses.

Voici les résultat de ce que vous m'avez demandé, même si plus loin je
pense avoir trouvé la raison du problème.

# cat /etc/resolv.conf
# Generated by NetworkManager
search intranet.local
nameserver 192.168.71.1

Ceci qui me paraît bon vu que 192.168.71.1 est bien le DNS «local» du
réseau qui possède l'enregistrement du nom du serveur
(se3.intranet.local = 192.168.71.2) proposant le partage Samba.

Par rapport aux demandes de Nicolas, j'avoue ne pas avoir su y trouver
des éléments qui pourraient me mettre sur la piste.

#-------------------------------------------------------
# getent hosts
127.0.0.1 localhost
127.0.1.1 squeezec.intranet.local squeezec
127.0.0.1 ip6-localhost ip6-loopback
#-------------------------------------------------------


#-------------------------------------------------------
# host -v se3.intranet.local

Trying "se3.intranet.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63313
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;se3.intranet.local. IN A

;; ANSWER SECTION:
se3.intranet.local. 86400 IN A 192.168.71.2

;; AUTHORITY SECTION:
intranet.local. 86400 IN NS localhost.

;; ADDITIONAL SECTION:
localhost. 8579 IN A 127.0.0.1
localhost. 8579 IN AAAA ::1

Received 119 bytes from 192.168.71.1#53 in 4 ms
Trying "se3.intranet.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62585
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;se3.intranet.local. IN AAAA

;; AUTHORITY SECTION:
intranet.local. 7200 IN SOA intranet.local. dns-admin.ac-versailles.fr.
2012021201 21600 3600 1209600 7200

Received 98 bytes from 192.168.71.1#53 in 0 ms
Trying "se3.intranet.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36067
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;se3.intranet.local. IN MX

;; AUTHORITY SECTION:
intranet.local. 7200 IN SOA intranet.local. dns-admin.ac-versailles.fr.
2012021201 21600 3600 1209600 7200

Received 98 bytes from 192.168.71.1#53 in 0 ms
#-------------------------------------------------------

De ce côté, rien à signaler d'intéressant, non ?

Ceci étant dit, j'ai bien avancé, je crois, à partir du moment où j'ai
fait des tests avec Wireshark. Avec « host se3.intranet.local »,
Wireshark m'affichait une requête DNS vers le serveur DNS local et une
réponse ce dernier. Bref, normal. Avec la commande suivante :

mount -t cifs //se3.intranet.local/NETLOGON /mnt/NETLOGON -o ro,guest

Wireshare m'indiquait qu'il y avait non pas une requête DNS mais une
requête *MDNS* vers l'IP 224.0.0.251 (une IP de multicast si j'ai bien
compris) et là il n'y a jamais de réponse du serveur DNS. En revanche,
la même commande que précédemment mais avec le nom se3 (sans le
.intranet.local) et là c'est bien le protocole DNS qui est utilisé et
non le protocole MDNS.

En fait, Samba est bien sûr hors de cause dans cette histoire car j'ai
testé un simple ping vers se3 et j'ai le même problème :

* ping se3.intranet.local --> utilisation du protocole MDNS -->
Résolution impossible

* ping se3 --> utilisation du protocole DNS --> Résolution Ok

Du coup, je suis allé dans /etc/nsswitch.conf et j'avais cette ligne là :

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


Du coup, en mettant simplement « hosts: files dns », tout est rentré
dans l'ordre. Ceci étant, j'aimerais bien avoir quelques
éclaircissements sur certains points si c'est possible.

1. Déjà, d'un point de vue purement pratique, est-ce gênant si je laisse
la ligne « hosts: files dns » dans le fichier /etc/nsswitch.conf et si,
du coup, je n'utilise plus du tout le protocole MDNS ? Ce ne sera pas la
source de problème ultérieurement ? J'aurais tendance à dire qu'au
contraire c'est ce protocole MDNS que me fichait la pagaille, mais bon
je ne suis pas un spécialiste.

2. Avec le réglage « hosts: files mdns4_minimal [NOTFOUND=return] dns
mdns4 », comment est-ce possible que l'appel au protocole DNS se fasse
vu qu'il y a le [NOTFOUND=return] ? J'ai l'impression que lors de la
résolution d'un nom, avec un tel réglage :

- soit mdns4_minimal permet la résolution et on ne va pas plus loin
- soit mdns4_minimal ne permet pas la résolution et on est dans le cas
NOTFOUND et à cause du return le protocole DNS n'est pas utilisé.

Donc, dans tous les cas, DNS n'est pas utilisé. C'est forcément faux
sinon la ligne aurait été simplement « hosts: files mdns4_minimal
[NOTFOUND=return] ». C'est possible d'avoir une petite explication sur
cette histoire ?

3. (Sans doute que la réponse à cette question se trouve dans la
question 2). Pourquoi, lorsque que j'avais le réglage « hosts: files
mdns4_minimal [NOTFOUND=return] dns mdns4 », si j'utilisais le nom fqdn
dans une commande (ping) alors il n'y avait pas usage de DNS pour la
résolution et si j'utilisais le nom se3 « tout court » alors là il y
avait usage de DNS pour la résolution ?

Je ne suis pas sûr que l'altération de /etc/nsswitch.conf soit la bonne
solution. Je penche plutôt pour un défaut dans le fichier named.conf. Au
fait que donne "nslookup" avec le nom court puis le nom long? Est-ce que
le comportement est le même avec un autre nom de machine?

Francois Lafont , dans le message
<4f37a9e0$0$607$426a74cc@news.free.fr>, a écrit :

# getent hosts

Il manque l'argument.

Le 12/02/2012 15:25, denis.paris a écrit :

Je ne suis pas sûr que l'altération de /etc/nsswitch.conf soit la bonne
solution.

Et bien je me pose la question. Est-ce que la suppression du protocole
MDNS est gênant par la suite ? J'aurais tendance à dire que non mais
c'est une simple intuition non fondée.

Je penche plutôt pour un défaut dans le fichier named.conf.

D'après ce que j'ai pu comprendre des indications d'Arnaud, il n'y a pas
de « problème » : c'est juste qu'avec un nom en .local la config de
nsswitch.conf veut que j'utilise le protocole MDNS pour résoudre un nom
en .local et que si ça échoue (et ça échouera pour le cas de
se3.intranet.local car il est enregistré dans un serveur DNS qui ne
connaît pas le protocole MDNS) alors la résolution via DNS n'a pas lieu.

Au
fait que donne "nslookup" avec le nom court puis le nom long? Est-ce que
le comportement est le même avec un autre nom de machine?

Encore une fois, je crois que le DNS est vraiment ok. C'est juste qu'il
n'est pas appelé avec un nom en .local. Voici ce que tu demandes :

~$ nslookup se3
Server: 192.168.71.1
Address: 192.168.71.1#53

Name: se3.intranet.local
Address: 192.168.71.2

~$ nslookup se3.intranet.local
Server: 192.168.71.1
Address: 192.168.71.1#53

Name: se3.intranet.local
Address: 192.168.71.2

Mon domaine ne contient que 3 machines (le se3, le client squeeze pour
lequel aucun enregistrement n'a été fait et le DNS qui s'appelle slis).

~$ nslookup slis
Server: 192.168.71.1
Address: 192.168.71.1#53

** server can't find slis: NXDOMAIN

~$ nslookup slis.intranet.local
Server: 192.168.71.1
Address: 192.168.71.1#53

** server can't find slis.intranet.local: NXDOMAIN

~$ nslookup www.google.fr
Server: 192.168.71.1
Address: 192.168.71.1#53

Non-authoritative answer:
www.google.fr canonical name = www-cctld.l.google.com.
Name: www-cctld.l.google.com
Address: 209.85.147.94

Voilà.


--
François Lafont

Le 12/02/2012 16:39, Nicolas George a écrit :

# getent hosts

Il manque l'argument.

Désolé Nicolas, je n'avais pas compris. Je connais très mal la commande
getent. Voici ce que tu demandes :

~$ getent hosts se3.intranet.local
~$ getent hosts se3
192.168.71.2 se3.intranet.local

La première commande marque une pause d'une ou deux secondes et ne
renvoie rien. La deuxième commande est instantanée.

--
François Lafont

Le 12/02/2012 17:26, Francois Lafont a écrit :

Le 12/02/2012 15:25, denis.paris a écrit :

Je ne suis pas sûr que l'altération de /etc/nsswitch.conf soit la bonne
solution.

Et bien je me pose la question. Est-ce que la suppression du protocole
MDNS est gênant par la suite ? J'aurais tendance à dire que non mais
c'est une simple intuition non fondée.

Je penche plutôt pour un défaut dans le fichier named.conf.

D'après ce que j'ai pu comprendre des indications d'Arnaud, il n'y a pas
de « problème » : c'est juste qu'avec un nom en .local la config de
nsswitch.conf veut que j'utilise le protocole MDNS pour résoudre un nom
en .local et que si ça échoue (et ça échouera pour le cas de
se3.intranet.local car il est enregistré dans un serveur DNS qui ne
connaît pas le protocole MDNS) alors la résolution via DNS n'a pas lieu.

Au
fait que donne "nslookup" avec le nom court puis le nom long? Est-ce que
le comportement est le même avec un autre nom de machine?

Encore une fois, je crois que le DNS est vraiment ok. C'est juste qu'il
n'est pas appelé avec un nom en .local. Voici ce que tu demandes :

~$ nslookup se3
Server: 192.168.71.1
Address: 192.168.71.1#53

Name: se3.intranet.local
Address: 192.168.71.2

~$ nslookup se3.intranet.local
Server: 192.168.71.1
Address: 192.168.71.1#53

Name: se3.intranet.local
Address: 192.168.71.2

Mon domaine ne contient que 3 machines (le se3, le client squeeze pour
lequel aucun enregistrement n'a été fait et le DNS qui s'appelle slis).

~$ nslookup slis
Server: 192.168.71.1
Address: 192.168.71.1#53

** server can't find slis: NXDOMAIN

~$ nslookup slis.intranet.local
Server: 192.168.71.1
Address: 192.168.71.1#53

** server can't find slis.intranet.local: NXDOMAIN

~$ nslookup www.google.fr
Server: 192.168.71.1
Address: 192.168.71.1#53

Non-authoritative answer:
www.google.fr canonical name = www-cctld.l.google.com.
Name: www-cctld.l.google.com
Address: 209.85.147.94

Voilà.

Autrement-dit le serveur DNS ne se résout pas lui même, c'est au moins
un défaut identifié, non?

Sinon je ne comprends pas cette histoire de ".local", ce qu'indique le
lien mentionné dans ce fil est qu'il faut simplement s'assurer que le
domaine que l'on choisit est unique, même s'il est privé. Je ne vois pas
pourquoi cette extension serait "maudite".

Le 12/02/2012 18:30, denis.paris a écrit :

Autrement-dit le serveur DNS ne se résout pas lui même, c'est au moins
un défaut identifié, non?

Si, mais ça c'est juste parce que je n'ai pas mis son propre nom dans la
liste des enregistrements DNS. Désolé, c'est vrai que ça induit en
erreur. Si je le mets, plus de souci, nslookup et host arrive bien à
résoudre son nom sans problème (qui est slis.intranet.local).

Sinon je ne comprends pas cette histoire de ".local", ce qu'indique le
lien mentionné dans ce fil est qu'il faut simplement s'assurer que le
domaine que l'on choisit est unique, même s'il est privé. Je ne vois pas
pourquoi cette extension serait "maudite".

Le problème avec le TLD .local (en tout cas sur ma Debian Squeeze) est
que toute résolution demandée suite à une commande comme ping ou mount
(ou je ne sais quoi) ne fait tout simplement pas appel au protocole DNS
quand le nom est en ".local". Enfin c'est ce que j'ai compris suite à la
remarque décisive d'Arnaud. Tout ça est à cause de la ligne :

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

qui se trouve dans le fichier nsswitch.conf. Quand le nom finit en
".local" (et seulement dans ce cas là apparemment mais je ne suis pas
sûr), il y a tentative de résolution via le protocole MDNS (sauf s'il y
a une correspondante dans /etc/hosts.conf bien sûr). Mais à cause de ce
fichu « [NOTFOUND=return] » (que je trouve bien curieux d'ailleurs), si
la résolution MDNS échoue alors la résolution est terminée et *aucune*
tentative de résolution DNS n'est tentée. C'est ça qui rend le TLD «
maudit ». Enfin si j'ai bien compris.

--
François Lafont