Montage smb/cifs impossible car le nom d'hôte ne serait soit-disant pas résolu
19 réponses
Francois Lafont
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 ?
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.
Ça y ressemblerait et au vu de la manpage, ça semble complètement logique : http://linux.die.net/man/5/avahi-daemon.conf
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu peux voir du coté de la rfc2606 qui propose .invalid
-- Je dois faire un exposé pour mon cours de communication. Le sujet : les crottes de nez ou la spéléologie nasale. recherche donc toute expression, image, plan, document scientifique, photo, page ouèbe concernant ce sujet. -+- TT in : <http://www.le-gnu.net> - Encore un sujet à creuser -+-
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.
Ça y ressemblerait et au vu de la manpage, ça semble complètement
logique :
http://linux.die.net/man/5/avahi-daemon.conf
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si
tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu
peux voir du coté de la rfc2606 qui propose .invalid
--
Je dois faire un exposé pour mon cours de communication. Le sujet : les
crottes de nez ou la spéléologie nasale. recherche donc toute expression,
image, plan, document scientifique, photo, page ouèbe concernant ce sujet.
-+- TT in : <http://www.le-gnu.net> - Encore un sujet à creuser -+-
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.
Ça y ressemblerait et au vu de la manpage, ça semble complètement logique : http://linux.die.net/man/5/avahi-daemon.conf
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu peux voir du coté de la rfc2606 qui propose .invalid
-- Je dois faire un exposé pour mon cours de communication. Le sujet : les crottes de nez ou la spéléologie nasale. recherche donc toute expression, image, plan, document scientifique, photo, page ouèbe concernant ce sujet. -+- TT in : <http://www.le-gnu.net> - Encore un sujet à creuser -+-
Francois Lafont
Le 12/02/2012 19:10, Eric Masson a écrit :
Ça y ressemblerait et au vu de la manpage, ça semble complètement logique : http://linux.die.net/man/5/avahi-daemon.conf
Oui mais encore une fois ce daemon est-il vraiment nécessaire ? J'ai bien compris, pas de .local je reconnais. Mais ceci étant, j'ai l'impression que daemon (et le protocole qui va avec) vient plus fiche la pagaille qu'autre chose, non ?
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu peux voir du coté de la rfc2606 qui propose .invalid
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau), il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
-- François Lafont
Le 12/02/2012 19:10, Eric Masson a écrit :
Ça y ressemblerait et au vu de la manpage, ça semble complètement
logique :
http://linux.die.net/man/5/avahi-daemon.conf
Oui mais encore une fois ce daemon est-il vraiment nécessaire ? J'ai
bien compris, pas de .local je reconnais. Mais ceci étant, j'ai
l'impression que daemon (et le protocole qui va avec) vient plus fiche
la pagaille qu'autre chose, non ?
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si
tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu
peux voir du coté de la rfc2606 qui propose .invalid
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau),
il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée
mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Ça y ressemblerait et au vu de la manpage, ça semble complètement logique : http://linux.die.net/man/5/avahi-daemon.conf
Oui mais encore une fois ce daemon est-il vraiment nécessaire ? J'ai bien compris, pas de .local je reconnais. Mais ceci étant, j'ai l'impression que daemon (et le protocole qui va avec) vient plus fiche la pagaille qu'autre chose, non ?
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu peux voir du coté de la rfc2606 qui propose .invalid
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau), il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
-- François Lafont
Arnaud Gomes-do-Vale
Francois Lafont writes:
Est-ce juste ? Si c'est juste, alors effectivement ça explique pourquoi un « ping se3 » fonctionnait (l'étape 2 - celle avec MDNS - était sautée) et pourquoi un « ping se3.intranet.local » échouait (l'étape 2 avait lieu, mais via le protocole MDNS il n'y a pas de réponse car mon serveur DNS ne parle pas ce protocole là). Et du coup, j'aurais ma réponse à la question 2 : le protocole MDNS est utilisé seulement pour les noms en .local.
Oui, c'est ça (pour mdns4_minimal, mdns4 résout tous les noms en mDNS).
Mais dans ce cas, est-il envisageable de virer carrément le paquet avahi-daemon étant donné qu'a priori je n'ai que faire de ce protocole MDNS ? Ou bien sa présence est-elle indispensable pour le bon fonctionnement du système ?
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison de ne pas l'enlever si tu n'utilises pas mDNS.
Tu peux aussi arrêter le dêmon, ça ne coûte pas grand chose, mais ça ne résoudra pas ton problème (par contre désinstaller le paquet avahi devrait aussi faire sauter nss-mdns par le jeu des dépendances).
Ok, j'ai eu tort sur le choix du nom de domaine et le problème ne serait pas produit avec un autre nom de domaine. En revanche, j'avoue ne pas trop comprendre quel nom je peux choisir pour un domaine privé sachant que je ne souhaite pas acheter un nom de domaine ? Est-ce que je peux utiliser un nom comme « .lafont.local.fr » par exemple même si je n'ai pas acheté ce nom de domaine inclus dans le domaine .fr qui lui est public ?
Pour ça, malheureusement, il n'y a pas vraiment de solution. Il y a bien quelques noms de domaines réservés pour des usages spéciaux (voir la RFC 2606) mais à ma connaissance rien de prévu pour une utilisation en réseau isolé. Il vaut tout de même mieux choisir un TLD inexistant, et être prêt à en changer le jour où..., ça limite les risques de collision.
Ceci dit, il y a aussi des fournisseurs de domaines gratuits (par exemple eu.org) histoire d'être tranquille une fois pour toutes.
Est-ce juste ? Si c'est juste, alors effectivement ça explique pourquoi
un « ping se3 » fonctionnait (l'étape 2 - celle avec MDNS - était
sautée) et pourquoi un « ping se3.intranet.local » échouait (l'étape 2
avait lieu, mais via le protocole MDNS il n'y a pas de réponse car mon
serveur DNS ne parle pas ce protocole là). Et du coup, j'aurais ma
réponse à la question 2 : le protocole MDNS est utilisé seulement pour
les noms en .local.
Oui, c'est ça (pour mdns4_minimal, mdns4 résout tous les noms en mDNS).
Mais dans ce cas, est-il envisageable de virer carrément le paquet
avahi-daemon étant donné qu'a priori je n'ai que faire de ce protocole
MDNS ? Ou bien sa présence est-elle indispensable pour le bon
fonctionnement du système ?
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client
qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison
de ne pas l'enlever si tu n'utilises pas mDNS.
Tu peux aussi arrêter le dêmon, ça ne coûte pas grand chose, mais ça ne
résoudra pas ton problème (par contre désinstaller le paquet avahi
devrait aussi faire sauter nss-mdns par le jeu des dépendances).
Ok, j'ai eu tort sur le choix du nom de domaine et le problème ne serait
pas produit avec un autre nom de domaine. En revanche, j'avoue ne pas
trop comprendre quel nom je peux choisir pour un domaine privé sachant
que je ne souhaite pas acheter un nom de domaine ? Est-ce que je peux
utiliser un nom comme « .lafont.local.fr » par exemple même si je n'ai
pas acheté ce nom de domaine inclus dans le domaine .fr qui lui est public ?
Pour ça, malheureusement, il n'y a pas vraiment de solution. Il y a bien
quelques noms de domaines réservés pour des usages spéciaux (voir la RFC
2606) mais à ma connaissance rien de prévu pour une utilisation en
réseau isolé. Il vaut tout de même mieux choisir un TLD inexistant, et
être prêt à en changer le jour où..., ça limite les risques de
collision.
Ceci dit, il y a aussi des fournisseurs de domaines gratuits (par
exemple eu.org) histoire d'être tranquille une fois pour toutes.
Est-ce juste ? Si c'est juste, alors effectivement ça explique pourquoi un « ping se3 » fonctionnait (l'étape 2 - celle avec MDNS - était sautée) et pourquoi un « ping se3.intranet.local » échouait (l'étape 2 avait lieu, mais via le protocole MDNS il n'y a pas de réponse car mon serveur DNS ne parle pas ce protocole là). Et du coup, j'aurais ma réponse à la question 2 : le protocole MDNS est utilisé seulement pour les noms en .local.
Oui, c'est ça (pour mdns4_minimal, mdns4 résout tous les noms en mDNS).
Mais dans ce cas, est-il envisageable de virer carrément le paquet avahi-daemon étant donné qu'a priori je n'ai que faire de ce protocole MDNS ? Ou bien sa présence est-elle indispensable pour le bon fonctionnement du système ?
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison de ne pas l'enlever si tu n'utilises pas mDNS.
Tu peux aussi arrêter le dêmon, ça ne coûte pas grand chose, mais ça ne résoudra pas ton problème (par contre désinstaller le paquet avahi devrait aussi faire sauter nss-mdns par le jeu des dépendances).
Ok, j'ai eu tort sur le choix du nom de domaine et le problème ne serait pas produit avec un autre nom de domaine. En revanche, j'avoue ne pas trop comprendre quel nom je peux choisir pour un domaine privé sachant que je ne souhaite pas acheter un nom de domaine ? Est-ce que je peux utiliser un nom comme « .lafont.local.fr » par exemple même si je n'ai pas acheté ce nom de domaine inclus dans le domaine .fr qui lui est public ?
Pour ça, malheureusement, il n'y a pas vraiment de solution. Il y a bien quelques noms de domaines réservés pour des usages spéciaux (voir la RFC 2606) mais à ma connaissance rien de prévu pour une utilisation en réseau isolé. Il vaut tout de même mieux choisir un TLD inexistant, et être prêt à en changer le jour où..., ça limite les risques de collision.
Ceci dit, il y a aussi des fournisseurs de domaines gratuits (par exemple eu.org) histoire d'être tranquille une fois pour toutes.
-- Arnaud http://blogs.glou.org/arnaud/
Arnaud Gomes-do-Vale
Arnaud Gomes-do-Vale writes:
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison de ne pas l'enlever si tu n'utilises pas mDNS.
Juste pour préciser, quand je dis l'enlever, ça peut vouloir dire la désinstaller ou simplement enlever les références à mDNS de nsswitch.conf.
-- Arnaud http://blogs.glou.org/arnaud/
Arnaud Gomes-do-Vale <aun@glou.org> writes:
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client
qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison
de ne pas l'enlever si tu n'utilises pas mDNS.
Juste pour préciser, quand je dis l'enlever, ça peut vouloir dire la
désinstaller ou simplement enlever les références à mDNS de
nsswitch.conf.
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison de ne pas l'enlever si tu n'utilises pas mDNS.
Juste pour préciser, quand je dis l'enlever, ça peut vouloir dire la désinstaller ou simplement enlever les références à mDNS de nsswitch.conf.
-- Arnaud http://blogs.glou.org/arnaud/
Eric Masson
Francois Lafont writes:
'Lut,
Oui mais encore une fois ce daemon est-il vraiment nécessaire ?
Si tu n'as pas d'équipements implémentant Zeroconf (l'appellation Apple de mDNS), non.
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau), il est marqué : « .invalid : réservé pour une utilisation manifestement non valide »
La RFC spécifie : ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.
Donc, tu es sur que ton nom de domaine est vraiment invalide et que tu n'auras pas de collisions avec un nom valide.
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Bof, moche, pas moche, on s'en tape, ce qui importe c'est que ça fonctionne proprement.
Certains de mes clients utilisent les tld .priv ou .private
-- «Ca te derange ??? Je fait ce que je veut si ca te plait pas tu vas ailleurs gros c,, Mis a part ca si quelqun voulait bien me repondre ce serais sympa.» TOTO in Guide du linuxien pervers : "Bien préparer sa repartie"
Oui mais encore une fois ce daemon est-il vraiment nécessaire ?
Si tu n'as pas d'équipements implémentant Zeroconf (l'appellation Apple
de mDNS), non.
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau),
il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
La RFC spécifie :
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
Donc, tu es sur que ton nom de domaine est vraiment invalide et que tu
n'auras pas de collisions avec un nom valide.
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée
mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Bof, moche, pas moche, on s'en tape, ce qui importe c'est que ça
fonctionne proprement.
Certains de mes clients utilisent les tld .priv ou .private
--
«Ca te derange ??? Je fait ce que je veut si ca te plait pas tu vas
ailleurs gros c,, Mis a part ca si quelqun voulait bien me repondre
ce serais sympa.»
TOTO in Guide du linuxien pervers : "Bien préparer sa repartie"
Oui mais encore une fois ce daemon est-il vraiment nécessaire ?
Si tu n'as pas d'équipements implémentant Zeroconf (l'appellation Apple de mDNS), non.
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau), il est marqué : « .invalid : réservé pour une utilisation manifestement non valide »
La RFC spécifie : ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.
Donc, tu es sur que ton nom de domaine est vraiment invalide et que tu n'auras pas de collisions avec un nom valide.
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Bof, moche, pas moche, on s'en tape, ce qui importe c'est que ça fonctionne proprement.
Certains de mes clients utilisent les tld .priv ou .private
-- «Ca te derange ??? Je fait ce que je veut si ca te plait pas tu vas ailleurs gros c,, Mis a part ca si quelqun voulait bien me repondre ce serais sympa.» TOTO in Guide du linuxien pervers : "Bien préparer sa repartie"
Arnaud Gomes-do-Vale
Francois Lafont writes:
Heu, avec la triple négation dans cette dernière phrase je m'y perds un peu. En gros, ça doit vouloir dire que si je n'utilise pas mDNS (ce qui est le cas), je peux le virer.
Oui, c'est ça. :-)
C'est étrange car dans man avahi-daemon, je vois : « The Avahi mDNS/DNS-SD daemon implements Apple's Zeroconf [...] ». Du coup, comment le daemon peut-il fonctionner correctement si la bibliothèque libnss-mdns n'est plus installée ?
Le démon, c'est le côté serveur, il diffuse les annonces. La bibliothèque est un greffon NSS qui implémente la partie client. Il existe aussi une bibliothèque libavahi-core sur laquelle s'appuie le démon ; sous Fedora elle est dans le paquet avahi, je ne sais pas ce qu'il en est ailleurs.
Autre truc super curieux : si je supprime avahi-daemon alors là je me retrouve avec des tonnes de paquets qui « ne sont plus nécessaires » et que je pourrais soit-disant enlever sans problème. La liste est longue mais voici deux exemples qui me frappent :
Je n'ai pas de Debian pour tester sous la main, est-ce que ça enlève uniquement avahi-daemon ? Ça ne désinstallerait pas aussi un méta-paquet GNOME ?
Heu, avec la triple négation dans cette dernière phrase je m'y perds un
peu. En gros, ça doit vouloir dire que si je n'utilise pas mDNS (ce qui
est le cas), je peux le virer.
Oui, c'est ça. :-)
C'est étrange car dans man avahi-daemon, je vois : « The Avahi
mDNS/DNS-SD daemon implements Apple's Zeroconf [...] ». Du coup, comment
le daemon peut-il fonctionner correctement si la bibliothèque
libnss-mdns n'est plus installée ?
Le démon, c'est le côté serveur, il diffuse les annonces. La
bibliothèque est un greffon NSS qui implémente la partie client. Il
existe aussi une bibliothèque libavahi-core sur laquelle s'appuie le
démon ; sous Fedora elle est dans le paquet avahi, je ne sais pas ce
qu'il en est ailleurs.
Autre truc super curieux : si je supprime avahi-daemon alors là je me
retrouve avec des tonnes de paquets qui « ne sont plus nécessaires » et
que je pourrais soit-disant enlever sans problème. La liste est longue
mais voici deux exemples qui me frappent :
Je n'ai pas de Debian pour tester sous la main, est-ce que ça enlève
uniquement avahi-daemon ? Ça ne désinstallerait pas aussi un méta-paquet
GNOME ?
Heu, avec la triple négation dans cette dernière phrase je m'y perds un peu. En gros, ça doit vouloir dire que si je n'utilise pas mDNS (ce qui est le cas), je peux le virer.
Oui, c'est ça. :-)
C'est étrange car dans man avahi-daemon, je vois : « The Avahi mDNS/DNS-SD daemon implements Apple's Zeroconf [...] ». Du coup, comment le daemon peut-il fonctionner correctement si la bibliothèque libnss-mdns n'est plus installée ?
Le démon, c'est le côté serveur, il diffuse les annonces. La bibliothèque est un greffon NSS qui implémente la partie client. Il existe aussi une bibliothèque libavahi-core sur laquelle s'appuie le démon ; sous Fedora elle est dans le paquet avahi, je ne sais pas ce qu'il en est ailleurs.
Autre truc super curieux : si je supprime avahi-daemon alors là je me retrouve avec des tonnes de paquets qui « ne sont plus nécessaires » et que je pourrais soit-disant enlever sans problème. La liste est longue mais voici deux exemples qui me frappent :
Je n'ai pas de Debian pour tester sous la main, est-ce que ça enlève uniquement avahi-daemon ? Ça ne désinstallerait pas aussi un méta-paquet GNOME ?
-- Arnaud http://blogs.glou.org/arnaud/
denis.paris
Le 12/02/2012 19:26, Francois Lafont a écrit :
Le 12/02/2012 19:10, Eric Masson a écrit :
Ça y ressemblerait et au vu de la manpage, ça semble complètement logique : http://linux.die.net/man/5/avahi-daemon.conf
Oui mais encore une fois ce daemon est-il vraiment nécessaire ? J'ai bien compris, pas de .local je reconnais. Mais ceci étant, j'ai l'impression que daemon (et le protocole qui va avec) vient plus fiche la pagaille qu'autre chose, non ?
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu peux voir du coté de la rfc2606 qui propose .invalid
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau), il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Chez moi j'utilise .loc
Le 12/02/2012 19:26, Francois Lafont a écrit :
Le 12/02/2012 19:10, Eric Masson a écrit :
Ça y ressemblerait et au vu de la manpage, ça semble complètement
logique :
http://linux.die.net/man/5/avahi-daemon.conf
Oui mais encore une fois ce daemon est-il vraiment nécessaire ? J'ai
bien compris, pas de .local je reconnais. Mais ceci étant, j'ai
l'impression que daemon (et le protocole qui va avec) vient plus fiche
la pagaille qu'autre chose, non ?
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si
tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu
peux voir du coté de la rfc2606 qui propose .invalid
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau),
il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée
mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Ça y ressemblerait et au vu de la manpage, ça semble complètement logique : http://linux.die.net/man/5/avahi-daemon.conf
Oui mais encore une fois ce daemon est-il vraiment nécessaire ? J'ai bien compris, pas de .local je reconnais. Mais ceci étant, j'ai l'impression que daemon (et le protocole qui va avec) vient plus fiche la pagaille qu'autre chose, non ?
Donc, pour éviter les problèmes, tu n'utilises pas le tld .local et si tu ne veux pas utiliser un domaine valide que tu n'as pas enregistré, tu peux voir du coté de la rfc2606 qui propose .invalid
Sur Wikipédia (http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau), il est marqué :
« .invalid : réservé pour une utilisation manifestement non valide »
Alors est-ce que c'est vraiment adapté comme TLD pour un usage privée mais quand même un peu valide, non ? Par ailleurs, ça fait moche comme TLD.
Chez moi j'utilise .loc
denis.paris
Le 12/02/2012 19:26, Arnaud Gomes-do-Vale a écrit :
Francois Lafont writes:
Est-ce juste ? Si c'est juste, alors effectivement ça explique pourquoi un « ping se3 » fonctionnait (l'étape 2 - celle avec MDNS - était sautée) et pourquoi un « ping se3.intranet.local » échouait (l'étape 2 avait lieu, mais via le protocole MDNS il n'y a pas de réponse car mon serveur DNS ne parle pas ce protocole là). Et du coup, j'aurais ma réponse à la question 2 : le protocole MDNS est utilisé seulement pour les noms en .local.
Oui, c'est ça (pour mdns4_minimal, mdns4 résout tous les noms en mDNS).
Mais dans ce cas, est-il envisageable de virer carrément le paquet avahi-daemon étant donné qu'a priori je n'ai que faire de ce protocole MDNS ? Ou bien sa présence est-elle indispensable pour le bon fonctionnement du système ?
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison de ne pas l'enlever si tu n'utilises pas mDNS.
Tu peux aussi arrêter le dêmon, ça ne coûte pas grand chose, mais ça ne résoudra pas ton problème (par contre désinstaller le paquet avahi devrait aussi faire sauter nss-mdns par le jeu des dépendances).
Ok, j'ai eu tort sur le choix du nom de domaine et le problème ne serait pas produit avec un autre nom de domaine. En revanche, j'avoue ne pas trop comprendre quel nom je peux choisir pour un domaine privé sachant que je ne souhaite pas acheter un nom de domaine ? Est-ce que je peux utiliser un nom comme « .lafont.local.fr » par exemple même si je n'ai pas acheté ce nom de domaine inclus dans le domaine .fr qui lui est public ?
Pour ça, malheureusement, il n'y a pas vraiment de solution. Il y a bien quelques noms de domaines réservés pour des usages spéciaux (voir la RFC 2606) mais à ma connaissance rien de prévu pour une utilisation en réseau isolé. Il vaut tout de même mieux choisir un TLD inexistant, et être prêt à en changer le jour où..., ça limite les risques de collision.
Ceci dit, il y a aussi des fournisseurs de domaines gratuits (par exemple eu.org) histoire d'être tranquille une fois pour toutes.
Il ne faut pas s'exagérer le risque de doublon, il me semble que dans ce cas le seul effet de bord est que le vrai domaine est alors masqué. Bien sur si on utilise "linux.com" ou "hp.com" on peut avoir des problèmes (on ne peut plus accéder à ces domaines).
Les ".loc" me semble une bonne option.
Le 12/02/2012 19:26, Arnaud Gomes-do-Vale a écrit :
Est-ce juste ? Si c'est juste, alors effectivement ça explique pourquoi
un « ping se3 » fonctionnait (l'étape 2 - celle avec MDNS - était
sautée) et pourquoi un « ping se3.intranet.local » échouait (l'étape 2
avait lieu, mais via le protocole MDNS il n'y a pas de réponse car mon
serveur DNS ne parle pas ce protocole là). Et du coup, j'aurais ma
réponse à la question 2 : le protocole MDNS est utilisé seulement pour
les noms en .local.
Oui, c'est ça (pour mdns4_minimal, mdns4 résout tous les noms en mDNS).
Mais dans ce cas, est-il envisageable de virer carrément le paquet
avahi-daemon étant donné qu'a priori je n'ai que faire de ce protocole
MDNS ? Ou bien sa présence est-elle indispensable pour le bon
fonctionnement du système ?
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client
qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison
de ne pas l'enlever si tu n'utilises pas mDNS.
Tu peux aussi arrêter le dêmon, ça ne coûte pas grand chose, mais ça ne
résoudra pas ton problème (par contre désinstaller le paquet avahi
devrait aussi faire sauter nss-mdns par le jeu des dépendances).
Ok, j'ai eu tort sur le choix du nom de domaine et le problème ne serait
pas produit avec un autre nom de domaine. En revanche, j'avoue ne pas
trop comprendre quel nom je peux choisir pour un domaine privé sachant
que je ne souhaite pas acheter un nom de domaine ? Est-ce que je peux
utiliser un nom comme « .lafont.local.fr » par exemple même si je n'ai
pas acheté ce nom de domaine inclus dans le domaine .fr qui lui est public ?
Pour ça, malheureusement, il n'y a pas vraiment de solution. Il y a bien
quelques noms de domaines réservés pour des usages spéciaux (voir la RFC
2606) mais à ma connaissance rien de prévu pour une utilisation en
réseau isolé. Il vaut tout de même mieux choisir un TLD inexistant, et
être prêt à en changer le jour où..., ça limite les risques de
collision.
Ceci dit, il y a aussi des fournisseurs de domaines gratuits (par
exemple eu.org) histoire d'être tranquille une fois pour toutes.
Il ne faut pas s'exagérer le risque de doublon, il me semble que dans ce
cas le seul effet de bord est que le vrai domaine est alors masqué. Bien
sur si on utilise "linux.com" ou "hp.com" on peut avoir des problèmes
(on ne peut plus accéder à ces domaines).
Le 12/02/2012 19:26, Arnaud Gomes-do-Vale a écrit :
Francois Lafont writes:
Est-ce juste ? Si c'est juste, alors effectivement ça explique pourquoi un « ping se3 » fonctionnait (l'étape 2 - celle avec MDNS - était sautée) et pourquoi un « ping se3.intranet.local » échouait (l'étape 2 avait lieu, mais via le protocole MDNS il n'y a pas de réponse car mon serveur DNS ne parle pas ce protocole là). Et du coup, j'aurais ma réponse à la question 2 : le protocole MDNS est utilisé seulement pour les noms en .local.
Oui, c'est ça (pour mdns4_minimal, mdns4 résout tous les noms en mDNS).
Mais dans ce cas, est-il envisageable de virer carrément le paquet avahi-daemon étant donné qu'a priori je n'ai que faire de ce protocole MDNS ? Ou bien sa présence est-elle indispensable pour le bon fonctionnement du système ?
Ce n'est pas le démon Avahi qui est fautif, c'est la bibliothèque client qui sert à NSS (paquet nss-mdns sur ma Fedora). Je ne vois pas de raison de ne pas l'enlever si tu n'utilises pas mDNS.
Tu peux aussi arrêter le dêmon, ça ne coûte pas grand chose, mais ça ne résoudra pas ton problème (par contre désinstaller le paquet avahi devrait aussi faire sauter nss-mdns par le jeu des dépendances).
Ok, j'ai eu tort sur le choix du nom de domaine et le problème ne serait pas produit avec un autre nom de domaine. En revanche, j'avoue ne pas trop comprendre quel nom je peux choisir pour un domaine privé sachant que je ne souhaite pas acheter un nom de domaine ? Est-ce que je peux utiliser un nom comme « .lafont.local.fr » par exemple même si je n'ai pas acheté ce nom de domaine inclus dans le domaine .fr qui lui est public ?
Pour ça, malheureusement, il n'y a pas vraiment de solution. Il y a bien quelques noms de domaines réservés pour des usages spéciaux (voir la RFC 2606) mais à ma connaissance rien de prévu pour une utilisation en réseau isolé. Il vaut tout de même mieux choisir un TLD inexistant, et être prêt à en changer le jour où..., ça limite les risques de collision.
Ceci dit, il y a aussi des fournisseurs de domaines gratuits (par exemple eu.org) histoire d'être tranquille une fois pour toutes.
Il ne faut pas s'exagérer le risque de doublon, il me semble que dans ce cas le seul effet de bord est que le vrai domaine est alors masqué. Bien sur si on utilise "linux.com" ou "hp.com" on peut avoir des problèmes (on ne peut plus accéder à ces domaines).
Les ".loc" me semble une bonne option.
Arnaud Gomes-do-Vale
Francois Lafont writes:
Ça a l'air d'être un truc dans le genre. Je copie-colle ici une simulation de la désinstallation de ce paquet via apt-get que chacun puisse voir. Je trouve que c'est un peu fort de café quand même. En gros, si je vire ce daemon je vire plein truc du système.
Manifestement c'est une dépendance de gnome-desktop-environment, qui a lui-même amené toute la liste. Donc en désinstallant gnome-desktop-environment, tu marques tous les autres paquets dont tu parles comme candidats à la désinstallation par «apt-get autoremove». Je suppose que ça se passerait pareil si tu désinstallais nautilus ou evolution.
Je crois que GNOME utilise Avahi pour pas mal de choses, en gros tout ce qui est découverte de services en réseau local ; du coup c'est assez compréhensible.
Ça a l'air d'être un truc dans le genre. Je copie-colle ici une
simulation de la désinstallation de ce paquet via apt-get que chacun
puisse voir. Je trouve que c'est un peu fort de café quand même. En
gros, si je vire ce daemon je vire plein truc du système.
Manifestement c'est une dépendance de gnome-desktop-environment, qui a
lui-même amené toute la liste. Donc en désinstallant
gnome-desktop-environment, tu marques tous les autres paquets dont tu
parles comme candidats à la désinstallation par «apt-get autoremove». Je
suppose que ça se passerait pareil si tu désinstallais nautilus ou
evolution.
Je crois que GNOME utilise Avahi pour pas mal de choses, en gros tout ce
qui est découverte de services en réseau local ; du coup c'est assez
compréhensible.
Ça a l'air d'être un truc dans le genre. Je copie-colle ici une simulation de la désinstallation de ce paquet via apt-get que chacun puisse voir. Je trouve que c'est un peu fort de café quand même. En gros, si je vire ce daemon je vire plein truc du système.
Manifestement c'est une dépendance de gnome-desktop-environment, qui a lui-même amené toute la liste. Donc en désinstallant gnome-desktop-environment, tu marques tous les autres paquets dont tu parles comme candidats à la désinstallation par «apt-get autoremove». Je suppose que ça se passerait pareil si tu désinstallais nautilus ou evolution.
Je crois que GNOME utilise Avahi pour pas mal de choses, en gros tout ce qui est découverte de services en réseau local ; du coup c'est assez compréhensible.
