je souhaiterai avoir une machine qui r=C3=A9cup=C3=A8re une adresse une IPv=
4 et IPv6 si=20
cela est possible (c'est fait) et fasse par d=C3=A9faut des requ=C3=AAtes D=
NS IPv6. Je=20
souhaite aussi avoir syst=C3=A9matiquement un search sur 3 domaines en plus=
de=20
ceux fourni par l'=C3=A9ventuel DHCP IPv4 disponible.
J'ai r=C3=A9ussi =C3=A0 faire tout ceci de mani=C3=A8re propre avec n=C3=A9=
anmoins une perte de=20
contr=C3=B4le sur le fichier resolv.conf g=C3=A9n=C3=A9r=C3=A9. L=C3=A0 est=
mon probl=C3=A8me.
Voici ce que j'ai fait pour obtenir ce r=C3=A9sultat.
1) Au d=C3=A9but j'avais ajout=C3=A9 append domain-search domaine1 domaine2=
domain3 =C3=A0=20
dhclient.conf afin d'inclure syst=C3=A9matiquement les domaines 1 2 et 3 au=
x=20
recherches par d=C3=A9faut, en plus de ceux re=C3=A7us par DHCP.
2) Ensuite, j'ai regard=C3=A9 du c=C3=B4t=C3=A9 du man de resolv.conf et ai=
d=C3=A9couvert=20
l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de=20
kame.net qui danse. Malgr=C3=A9 tout au premier invoke-rc.d networking rest=
art=20
venu, le fichier resolv.conf est r=C3=A9g=C3=A9n=C3=A9r=C3=A9 et "options i=
net6" disparait. Il ne=20
semble y avoir aucune option dans dhclient.conf pour ajouter au fichier=20
resolv.conf g=C3=A9n=C3=A9r=C3=A9 l'option inet6, ce qui est assez logique =
puisque=20
dhclient.conf ne concerne que le DHCP IPv4.
3) J'ai donc regard=C3=A9 du c=C3=B4t=C3=A9 de resolvconf et ai pu obtenir =
ma configuration=20
actuelle en ajoutant options inet6 dans le=20
fichier /etc/resolvconf/resolv.conf.d/tail et search domain1 domain2 domain=
3=20
dans /etc/resolvconf/resolv.conf.d/base
L=C3=A0 o=C3=B9 le bas blesse c'est que d'apr=C3=A8s le fichier README.gz, =
la fusion entre le=20
fichier base et ce que retourne dhclient se fait en ajoutant les informatio=
ns=20
apr=C3=A8s celles du fichier base :
- resolv.conf.d/base
Information always included in the resolv.conf file. Dynamic
information gets merged with this information. E.g., if base
contains 'search a.b.c' and another record is added that contains
'search x.y.z' then the resulting file will have
'search a.b.c x.y.z'.
resolvconf semble =C3=AAtre donc beaucoup moins souple que dhclient qui per=
met de=20
remplacer, ajouter au d=C3=A9but ou ajouter =C3=A0 la fin certaines informa=
tions. La=20
seule solution que je vois serait d'utiliser uniquement dhclient.conf (et=20
donc supprimer resolvconf) et modifier les hook de dhclient pour ajouter=20
options inet6 =C3=A0 la fin du resolv.conf. Mais je ne trouve pas cela tr=
=C3=A8s joli,=20
qu'en pensez-vous ?
J'en profite au passage pour vous notifier d'un avantage =C3=A0 IPv6 auquel=
je=20
n'avais jamais pens=C3=A9. Si je fais un reconfigure les interfaces r=C3=A9=
seaux en=20
=C3=A9coutant un flux radio, celui-ci se poursuivra (=C3=A9ventuellement av=
ec une=20
coupure si le buffer est trop petit) sans probl=C3=A8me, n'ayant aucune m=
=C3=A9moire=20
contrairement au NAT.
En esp=C3=A9rant que mon petit bricolage serve un jour =C3=A0 quelqu'un.
--nextPart27925208.nKgHWSNMhA
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en adresse IPv6 en premier. C'est le cas par défaut, ce que certains regrettent.
Malgré tout au premier invoke-rc.d networking restart venu, le fichier resolv.conf est régénéré et "options inet6" disparait.
Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient probablement pas de l'option inet6 manquante.
J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une coupure si le buffer est trop petit) sans problème, n'ayant aucune mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
Thomas Preud'homme a écrit :
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en
adresse IPv6 en premier. C'est le cas par défaut, ce que certains
regrettent.
Malgré tout au premier invoke-rc.d networking restart
venu, le fichier resolv.conf est régénéré et "options inet6" disparait.
Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient
probablement pas de l'option inet6 manquante.
J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je
n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en
écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une
coupure si le buffer est trop petit) sans problème, n'ayant aucune mémoire
contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en adresse IPv6 en premier. C'est le cas par défaut, ce que certains regrettent.
Malgré tout au premier invoke-rc.d networking restart venu, le fichier resolv.conf est régénéré et "options inet6" disparait.
Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient probablement pas de l'option inet6 manquante.
J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une coupure si le buffer est trop petit) sans problème, n'ayant aucune mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Salut,
Thomas Preud'homme a écrit : > 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert > l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de > kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en adresse IPv6 en premier. C'est le cas par défaut, ce que certains regrettent.
Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu quelque chose de spécial dans sysctl.conf ?
> Malgré tout au premier invoke-rc.d networking restart > venu, le fichier resolv.conf est régénéré et "options inet6" di sparait.
Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient probablement pas de l'option inet6 manquante.
Oui si je retire cette option la tortue ne danse plus. En plus d'après le man de resolv.conf options inet6 sert précisément à demander à faire de s requêtes IPv6 avant IPv4 donc cela me semble cohérent comme comportement, non ? Je suis curieux de savoir ce qui te donne le même comportement sans l'option inet6 dans resolv.conf
> J'en profite au passage pour vous notifier d'un avantage à IPv6 auque l je > n'avais jamais pensé. Si je fais un reconfigure les interfaces rése aux en > écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une > coupure si le buffer est trop petit) sans problème, n'ayant aucune > mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de connexion d'iptables. Donc même en renouvelant la requête dhcp ça ne devrait avoir aucun effet sur la règle qui laisse passer les connexions établie s. Et sinon le fait de redémarrer l'interface réseau devrait effectivement m ême dans ce cas purger iptables et donc considérer les paquets arrivant à p artir de ce moment comme une nouvelle connexion. Pourtant il y a bien un effet quelque part, avant un restart me faisait systématiquement perdre le flux , plus maintenant...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Salut,
Thomas Preud'homme a écrit :
> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert
> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
> kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en
adresse IPv6 en premier. C'est le cas par défaut, ce que certains
regrettent.
Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu
quelque chose de spécial dans sysctl.conf ?
> Malgré tout au premier invoke-rc.d networking restart
> venu, le fichier resolv.conf est régénéré et "options inet6" di sparait.
Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient
probablement pas de l'option inet6 manquante.
Oui si je retire cette option la tortue ne danse plus. En plus d'après le man
de resolv.conf options inet6 sert précisément à demander à faire de s requêtes
IPv6 avant IPv4 donc cela me semble cohérent comme comportement, non ? Je
suis curieux de savoir ce qui te donne le même comportement sans l'option
inet6 dans resolv.conf
> J'en profite au passage pour vous notifier d'un avantage à IPv6 auque l je
> n'avais jamais pensé. Si je fais un reconfigure les interfaces rése aux en
> écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une
> coupure si le buffer est trop petit) sans problème, n'ayant aucune
> mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas
le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de
connexion d'iptables. Donc même en renouvelant la requête dhcp ça ne devrait
avoir aucun effet sur la règle qui laisse passer les connexions établie s. Et
sinon le fait de redémarrer l'interface réseau devrait effectivement m ême
dans ce cas purger iptables et donc considérer les paquets arrivant à p artir
de ce moment comme une nouvelle connexion. Pourtant il y a bien un effet
quelque part, avant un restart me faisait systématiquement perdre le flux ,
plus maintenant...
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Salut,
Thomas Preud'homme a écrit : > 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert > l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de > kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en adresse IPv6 en premier. C'est le cas par défaut, ce que certains regrettent.
Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu quelque chose de spécial dans sysctl.conf ?
> Malgré tout au premier invoke-rc.d networking restart > venu, le fichier resolv.conf est régénéré et "options inet6" di sparait.
Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient probablement pas de l'option inet6 manquante.
Oui si je retire cette option la tortue ne danse plus. En plus d'après le man de resolv.conf options inet6 sert précisément à demander à faire de s requêtes IPv6 avant IPv4 donc cela me semble cohérent comme comportement, non ? Je suis curieux de savoir ce qui te donne le même comportement sans l'option inet6 dans resolv.conf
> J'en profite au passage pour vous notifier d'un avantage à IPv6 auque l je > n'avais jamais pensé. Si je fais un reconfigure les interfaces rése aux en > écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une > coupure si le buffer est trop petit) sans problème, n'ayant aucune > mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de connexion d'iptables. Donc même en renouvelant la requête dhcp ça ne devrait avoir aucun effet sur la règle qui laisse passer les connexions établie s. Et sinon le fait de redémarrer l'interface réseau devrait effectivement m ême dans ce cas purger iptables et donc considérer les paquets arrivant à p artir de ce moment comme une nouvelle connexion. Pourtant il y a bien un effet quelque part, avant un restart me faisait systématiquement perdre le flux , plus maintenant...
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
On Fri, Dec 05, 2008 at 06:39:56PM +0100, Thomas Preud'homme wrote a message of 112 lines which said:
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise IPv6). D'après le manuel, elle sert à demander des enregistrements AAAA même lorsque l'application client a utilisé gethostbyname(), le vieux sous-programme de traduction de nom en adresse, remplacé depuis dix ans par getaddrinfo(). Cette option me semble donc inutile.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Fri, Dec 05, 2008 at 06:39:56PM +0100,
Thomas Preud'homme <thomas.preudhomme@celest.fr> wrote
a message of 112 lines which said:
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise
IPv6). D'après le manuel, elle sert à demander des enregistrements
AAAA même lorsque l'application client a utilisé gethostbyname(), le
vieux sous-programme de traduction de nom en adresse, remplacé depuis
dix ans par getaddrinfo(). Cette option me semble donc inutile.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Fri, Dec 05, 2008 at 06:39:56PM +0100, Thomas Preud'homme wrote a message of 112 lines which said:
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise IPv6). D'après le manuel, elle sert à demander des enregistrements AAAA même lorsque l'application client a utilisé gethostbyname(), le vieux sous-programme de traduction de nom en adresse, remplacé depuis dix ans par getaddrinfo(). Cette option me semble donc inutile.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
On Fri, Dec 05, 2008 at 08:24:39PM +0100, Pascal Hambourg wrote a message of 34 lines which said:
C'est le cas par défaut, ce que certains regrettent.
Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Fri, Dec 05, 2008 at 08:24:39PM +0100,
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote
a message of 34 lines which said:
C'est le cas par défaut, ce que certains regrettent.
Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Fri, Dec 05, 2008 at 08:24:39PM +0100, Pascal Hambourg wrote a message of 34 lines which said:
C'est le cas par défaut, ce que certains regrettent.
Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Stephane Bortzmeyer a écrit :
Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?
Peut-être parce qu'ils ne connaissent pas (et moi non plus).
L'exemple de la page de manuel ne contient que des préfixes IPv6, et la RFC 3484 à laquelle elle se réfère ne concerne que les adresses IPv6. Comment peut-on utiliser gai.conf pour favoriser les adresses IPv4 ?
Au fait, c'est utilisable avec la glibc d'etch ? Le paquet libc6 ne contient ni ce fichier ni sa page de manuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer a écrit :
Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?
Peut-être parce qu'ils ne connaissent pas (et moi non plus).
L'exemple de la page de manuel ne contient que des préfixes IPv6, et la
RFC 3484 à laquelle elle se réfère ne concerne que les adresses IPv6.
Comment peut-on utiliser gai.conf pour favoriser les adresses IPv4 ?
Au fait, c'est utilisable avec la glibc d'etch ? Le paquet libc6 ne
contient ni ce fichier ni sa page de manuel.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?
Peut-être parce qu'ils ne connaissent pas (et moi non plus).
L'exemple de la page de manuel ne contient que des préfixes IPv6, et la RFC 3484 à laquelle elle se réfère ne concerne que les adresses IPv6. Comment peut-on utiliser gai.conf pour favoriser les adresses IPv4 ?
Au fait, c'est utilisable avec la glibc d'etch ? Le paquet libc6 ne contient ni ce fichier ni sa page de manuel.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Stephane Bortzmeyer a écrit :
Thomas Preud'homme wrote a message of 112 lines which said:
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise IPv6). D'après le manuel, elle sert à demander des enregistrements AAAA même lorsque l'application client a utilisé gethostbyname(), le vieux sous-programme de traduction de nom en adresse, remplacé depuis dix ans par getaddrinfo(). Cette option me semble donc inutile.
J'ai eu des résultats bizarres avec nc lorsque je l'ai spécifiée. Faut que je creuse un peu plus.
La page de manuel dit "mapping IPv4 responses in IPv6 tunnelled form". As-tu une idée de quelle "tunnelled form" il s'agit ? 6to4, IPv4-compatible, IPv4-mapped... ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer a écrit :
Thomas Preud'homme <thomas.preudhomme@celest.fr> wrote
a message of 112 lines which said:
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise
IPv6). D'après le manuel, elle sert à demander des enregistrements
AAAA même lorsque l'application client a utilisé gethostbyname(), le
vieux sous-programme de traduction de nom en adresse, remplacé depuis
dix ans par getaddrinfo(). Cette option me semble donc inutile.
J'ai eu des résultats bizarres avec nc lorsque je l'ai spécifiée. Faut
que je creuse un peu plus.
La page de manuel dit "mapping IPv4 responses in IPv6 tunnelled form".
As-tu une idée de quelle "tunnelled form" il s'agit ? 6to4,
IPv4-compatible, IPv4-mapped... ?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Thomas Preud'homme wrote a message of 112 lines which said:
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise IPv6). D'après le manuel, elle sert à demander des enregistrements AAAA même lorsque l'application client a utilisé gethostbyname(), le vieux sous-programme de traduction de nom en adresse, remplacé depuis dix ans par getaddrinfo(). Cette option me semble donc inutile.
J'ai eu des résultats bizarres avec nc lorsque je l'ai spécifiée. Faut que je creuse un peu plus.
La page de manuel dit "mapping IPv4 responses in IPv6 tunnelled form". As-tu une idée de quelle "tunnelled form" il s'agit ? 6to4, IPv4-compatible, IPv4-mapped... ?
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Thomas Preud'homme a écrit :
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit :
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en adresse IPv6 en premier. C'est le cas par défaut, ce que certains regrettent.
Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu quelque chose de spécial dans sysctl.conf ?
Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour empêcher les communications IPv4 sur les sockets IPv6. Au départ c'était pour contourner un bug de BIND9, mais ça a aussi un effet de bord intéressant : les adresses IPv4 n'apparaissent plus sous la forme ::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la même façon sur toutes mes Debian (sarge et etch), même celles qui n'ont pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du noyau pourrait influencer la résolution DNS de la glibc qui est en userland.
Il faudrait creuser un peu plus pour voir ce qui se passe, notamment faire une capture des paquets DNS, et utiliser des outils plus bas niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et IPv6, et affiche l'adresse destination effectivement choisie pour établir la connexion.
J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une coupure si le buffer est trop petit) sans problème, n'ayant aucune mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de connexion d'iptables.
En effet. Sauf si la machine utilise la cible MASQUERADE sur ces connexions. Quand l'adresse IPv4 de l'interface de sortie change, les connexions masquées avec l'ancienne adresse sont supprimées.
Donc même en renouvelant la requête dhcp ça ne devrait avoir aucun effet sur la règle qui laisse passer les connexions établies. Et sinon le fait de redémarrer l'interface réseau devrait effectivement même dans ce cas purger iptables et donc considérer les paquets arrivant à partir de ce moment comme une nouvelle connexion.
Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour purger la table de suivi des connexions il faut décharger le module noyau correspondant ou le faire explicitement avec le programme 'conntrack' du paquet du même nom.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Thomas Preud'homme a écrit :
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit :
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en
adresse IPv6 en premier. C'est le cas par défaut, ce que certains
regrettent.
Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu
quelque chose de spécial dans sysctl.conf ?
Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour
empêcher les communications IPv4 sur les sockets IPv6. Au départ c'était
pour contourner un bug de BIND9, mais ça a aussi un effet de bord
intéressant : les adresses IPv4 n'apparaissent plus sous la forme
::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la
même façon sur toutes mes Debian (sarge et etch), même celles qui n'ont
pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du
noyau pourrait influencer la résolution DNS de la glibc qui est en userland.
Il faudrait creuser un peu plus pour voir ce qui se passe, notamment
faire une capture des paquets DNS, et utiliser des outils plus bas
niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et
IPv6, et affiche l'adresse destination effectivement choisie pour
établir la connexion.
J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je
n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en
écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une
coupure si le buffer est trop petit) sans problème, n'ayant aucune
mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas
le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de
connexion d'iptables.
En effet. Sauf si la machine utilise la cible MASQUERADE sur ces
connexions. Quand l'adresse IPv4 de l'interface de sortie change, les
connexions masquées avec l'ancienne adresse sont supprimées.
Donc même en renouvelant la requête dhcp ça ne devrait
avoir aucun effet sur la règle qui laisse passer les connexions établies. Et
sinon le fait de redémarrer l'interface réseau devrait effectivement même
dans ce cas purger iptables et donc considérer les paquets arrivant à partir
de ce moment comme une nouvelle connexion.
Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour
purger la table de suivi des connexions il faut décharger le module
noyau correspondant ou le faire explicitement avec le programme
'conntrack' du paquet du même nom.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit :
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de kame.net qui danse.
Jamais eu besoin de cette option pour faire les résolutions DNS en adresse IPv6 en premier. C'est le cas par défaut, ce que certains regrettent.
Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu quelque chose de spécial dans sysctl.conf ?
Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour empêcher les communications IPv4 sur les sockets IPv6. Au départ c'était pour contourner un bug de BIND9, mais ça a aussi un effet de bord intéressant : les adresses IPv4 n'apparaissent plus sous la forme ::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la même façon sur toutes mes Debian (sarge et etch), même celles qui n'ont pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du noyau pourrait influencer la résolution DNS de la glibc qui est en userland.
Il faudrait creuser un peu plus pour voir ce qui se passe, notamment faire une capture des paquets DNS, et utiliser des outils plus bas niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et IPv6, et affiche l'adresse destination effectivement choisie pour établir la connexion.
J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une coupure si le buffer est trop petit) sans problème, n'ayant aucune mémoire contrairement au NAT.
Je ne vois pas le rapport. Tu peux détailler ?
Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de connexion d'iptables.
En effet. Sauf si la machine utilise la cible MASQUERADE sur ces connexions. Quand l'adresse IPv4 de l'interface de sortie change, les connexions masquées avec l'ancienne adresse sont supprimées.
Donc même en renouvelant la requête dhcp ça ne devrait avoir aucun effet sur la règle qui laisse passer les connexions établies. Et sinon le fait de redémarrer l'interface réseau devrait effectivement même dans ce cas purger iptables et donc considérer les paquets arrivant à partir de ce moment comme une nouvelle connexion.
Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour purger la table de suivi des connexions il faut décharger le module noyau correspondant ou le faire explicitement avec le programme 'conntrack' du paquet du même nom.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
The Sunday 07 December 2008 14:27:49 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit : > The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote : >> Thomas Preud'homme a écrit : >>> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai d écouvert >>> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de >>> kame.net qui danse. >> >> Jamais eu besoin de cette option pour faire les résolutions DNS en >> adresse IPv6 en premier. C'est le cas par défaut, ce que certains >> regrettent. > > Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. > As-tu quelque chose de spécial dans sysctl.conf ?
Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour empêcher les communications IPv4 sur les sockets IPv6. Au départ c' était pour contourner un bug de BIND9, mais ça a aussi un effet de bord intéressant : les adresses IPv4 n'apparaissent plus sous la forme
::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la
même façon sur toutes mes Debian (sarge et etch), même celles qui n 'ont pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du noyau pourrait influencer la résolution DNS de la glibc qui est en userland.
Il faudrait creuser un peu plus pour voir ce qui se passe, notamment faire une capture des paquets DNS, et utiliser des outils plus bas niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et IPv6, et affiche l'adresse destination effectivement choisie pour établir la connexion.
Je veux bien regarder mais a priori il n'y a juste aucune tentative pour récupérer un champ AAAA. Ou en tout cas s'il y en a une c'est pas l'adr esse choisie. Il doit bien y avoir un paramètre chez moi qui pose problème. Pourriez-vous coller un /etc/network/interfaces à tout hasard (je doute q ue le problème se situe dans ce fichier mais sait-on jamais).
>>> J'en profite au passage pour vous notifier d'un avantage à IPv6 auq uel >>> je n'avais jamais pensé. Si je fais un reconfigure les interfaces >>> réseaux en écoutant un flux radio, celui-ci se poursuivra >>> (éventuellement avec une coupure si le buffer est trop petit) sans >>> problème, n'ayant aucune mémoire contrairement au NAT. >> >> Je ne vois pas le rapport. Tu peux détailler ? > > Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois > effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir > avec le suivi de connexion d'iptables.
En effet. Sauf si la machine utilise la cible MASQUERADE sur ces connexions. Quand l'adresse IPv4 de l'interface de sortie change, les connexions masquées avec l'ancienne adresse sont supprimées.
Ce n'est pas le cas, c'est le routeur qui l'utilise. Et je n'ai plus de routeur depuis deux mois environ. De plus mon IP externe était fixe comme les IPs du réseau local (fixée par adresse MAC dans dhcpd.conf).
> Donc même en renouvelant la requête dhcp ça ne devrait > avoir aucun effet sur la règle qui laisse passer les connexions éta blies. > Et sinon le fait de redémarrer l'interface réseau devrait effective ment > même dans ce cas purger iptables et donc considérer les paquets arr ivant > à partir de ce moment comme une nouvelle connexion.
Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour purger la table de suivi des connexions il faut décharger le module noyau correspondant ou le faire explicitement avec le programme 'conntrack' du paquet du même nom.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
The Sunday 07 December 2008 14:27:49 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit :
> The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
>> Thomas Preud'homme a écrit :
>>> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai d écouvert
>>> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
>>> kame.net qui danse.
>>
>> Jamais eu besoin de cette option pour faire les résolutions DNS en
>> adresse IPv6 en premier. C'est le cas par défaut, ce que certains
>> regrettent.
>
> Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus.
> As-tu quelque chose de spécial dans sysctl.conf ?
Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour
empêcher les communications IPv4 sur les sockets IPv6. Au départ c' était
pour contourner un bug de BIND9, mais ça a aussi un effet de bord
intéressant : les adresses IPv4 n'apparaissent plus sous la forme
::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la
même façon sur toutes mes Debian (sarge et etch), même celles qui n 'ont
pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du
noyau pourrait influencer la résolution DNS de la glibc qui est en
userland.
Il faudrait creuser un peu plus pour voir ce qui se passe, notamment
faire une capture des paquets DNS, et utiliser des outils plus bas
niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et
IPv6, et affiche l'adresse destination effectivement choisie pour
établir la connexion.
Je veux bien regarder mais a priori il n'y a juste aucune tentative pour
récupérer un champ AAAA. Ou en tout cas s'il y en a une c'est pas l'adr esse
choisie. Il doit bien y avoir un paramètre chez moi qui pose problème.
Pourriez-vous coller un /etc/network/interfaces à tout hasard (je doute q ue
le problème se situe dans ce fichier mais sait-on jamais).
>>> J'en profite au passage pour vous notifier d'un avantage à IPv6 auq uel
>>> je n'avais jamais pensé. Si je fais un reconfigure les interfaces
>>> réseaux en écoutant un flux radio, celui-ci se poursuivra
>>> (éventuellement avec une coupure si le buffer est trop petit) sans
>>> problème, n'ayant aucune mémoire contrairement au NAT.
>>
>> Je ne vois pas le rapport. Tu peux détailler ?
>
> Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois
> effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir
> avec le suivi de connexion d'iptables.
En effet. Sauf si la machine utilise la cible MASQUERADE sur ces
connexions. Quand l'adresse IPv4 de l'interface de sortie change, les
connexions masquées avec l'ancienne adresse sont supprimées.
Ce n'est pas le cas, c'est le routeur qui l'utilise. Et je n'ai plus de
routeur depuis deux mois environ. De plus mon IP externe était fixe comme les
IPs du réseau local (fixée par adresse MAC dans dhcpd.conf).
> Donc même en renouvelant la requête dhcp ça ne devrait
> avoir aucun effet sur la règle qui laisse passer les connexions éta blies.
> Et sinon le fait de redémarrer l'interface réseau devrait effective ment
> même dans ce cas purger iptables et donc considérer les paquets arr ivant
> à partir de ce moment comme une nouvelle connexion.
Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour
purger la table de suivi des connexions il faut décharger le module
noyau correspondant ou le faire explicitement avec le programme
'conntrack' du paquet du même nom.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
The Sunday 07 December 2008 14:27:49 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit : > The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote : >> Thomas Preud'homme a écrit : >>> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai d écouvert >>> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de >>> kame.net qui danse. >> >> Jamais eu besoin de cette option pour faire les résolutions DNS en >> adresse IPv6 en premier. C'est le cas par défaut, ce que certains >> regrettent. > > Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. > As-tu quelque chose de spécial dans sysctl.conf ?
Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour empêcher les communications IPv4 sur les sockets IPv6. Au départ c' était pour contourner un bug de BIND9, mais ça a aussi un effet de bord intéressant : les adresses IPv4 n'apparaissent plus sous la forme
::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la
même façon sur toutes mes Debian (sarge et etch), même celles qui n 'ont pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du noyau pourrait influencer la résolution DNS de la glibc qui est en userland.
Il faudrait creuser un peu plus pour voir ce qui se passe, notamment faire une capture des paquets DNS, et utiliser des outils plus bas niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et IPv6, et affiche l'adresse destination effectivement choisie pour établir la connexion.
Je veux bien regarder mais a priori il n'y a juste aucune tentative pour récupérer un champ AAAA. Ou en tout cas s'il y en a une c'est pas l'adr esse choisie. Il doit bien y avoir un paramètre chez moi qui pose problème. Pourriez-vous coller un /etc/network/interfaces à tout hasard (je doute q ue le problème se situe dans ce fichier mais sait-on jamais).
>>> J'en profite au passage pour vous notifier d'un avantage à IPv6 auq uel >>> je n'avais jamais pensé. Si je fais un reconfigure les interfaces >>> réseaux en écoutant un flux radio, celui-ci se poursuivra >>> (éventuellement avec une coupure si le buffer est trop petit) sans >>> problème, n'ayant aucune mémoire contrairement au NAT. >> >> Je ne vois pas le rapport. Tu peux détailler ? > > Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois > effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir > avec le suivi de connexion d'iptables.
En effet. Sauf si la machine utilise la cible MASQUERADE sur ces connexions. Quand l'adresse IPv4 de l'interface de sortie change, les connexions masquées avec l'ancienne adresse sont supprimées.
Ce n'est pas le cas, c'est le routeur qui l'utilise. Et je n'ai plus de routeur depuis deux mois environ. De plus mon IP externe était fixe comme les IPs du réseau local (fixée par adresse MAC dans dhcpd.conf).
> Donc même en renouvelant la requête dhcp ça ne devrait > avoir aucun effet sur la règle qui laisse passer les connexions éta blies. > Et sinon le fait de redémarrer l'interface réseau devrait effective ment > même dans ce cas purger iptables et donc considérer les paquets arr ivant > à partir de ce moment comme une nouvelle connexion.
Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour purger la table de suivi des connexions il faut décharger le module noyau correspondant ou le faire explicitement avec le programme 'conntrack' du paquet du même nom.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
The Saturday 06 December 2008 21:37:46 Stephane Bortzmeyer, you wrote :
On Fri, Dec 05, 2008 at 06:39:56PM +0100, Thomas Preud'homme wrote
a message of 112 lines which said: > 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert > l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise IPv6). D'après le manuel, elle sert à demander des enregistrements AAAA même lorsque l'application client a utilisé gethostbyname(), le vieux sous-programme de traduction de nom en adresse, remplacé depuis dix ans par getaddrinfo(). Cette option me semble donc inutile.
Ah intéressant. Tout du moins si je rencontre des problèmes avec des vi eux programmes. Ceci dit je ne vois pas pourquoi je n'ai pas d'IPv6 sans inet6. Quelqu'un aurait-il une idée d'un fichier qui pourrait poser problème ? Il doit bien y avoir un fichier sur le système pour spécifier la préfé rence entre IPv6 et IPv4. J'ai regardé gai.conf mais tout est commenté donc c ela ne doit pas venir de là.
Merci pour vos réponses, j'ai au moins appris des choses ce qui en soit e st déjà très bien.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
The Saturday 06 December 2008 21:37:46 Stephane Bortzmeyer, you wrote :
On Fri, Dec 05, 2008 at 06:39:56PM +0100,
Thomas Preud'homme <thomas.preudhomme@celest.fr> wrote
a message of 112 lines which said:
> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert
> l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise
IPv6). D'après le manuel, elle sert à demander des enregistrements
AAAA même lorsque l'application client a utilisé gethostbyname(), le
vieux sous-programme de traduction de nom en adresse, remplacé depuis
dix ans par getaddrinfo(). Cette option me semble donc inutile.
Ah intéressant. Tout du moins si je rencontre des problèmes avec des vi eux
programmes. Ceci dit je ne vois pas pourquoi je n'ai pas d'IPv6 sans inet6.
Quelqu'un aurait-il une idée d'un fichier qui pourrait poser problème ? Il
doit bien y avoir un fichier sur le système pour spécifier la préfé rence
entre IPv6 et IPv4. J'ai regardé gai.conf mais tout est commenté donc c ela ne
doit pas venir de là.
Merci pour vos réponses, j'ai au moins appris des choses ce qui en soit e st
déjà très bien.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
The Saturday 06 December 2008 21:37:46 Stephane Bortzmeyer, you wrote :
On Fri, Dec 05, 2008 at 06:39:56PM +0100, Thomas Preud'homme wrote
a message of 112 lines which said: > 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert > l'option inet6.
Je ne me suis jamais servi de cette option (et j'utilise IPv6). D'après le manuel, elle sert à demander des enregistrements AAAA même lorsque l'application client a utilisé gethostbyname(), le vieux sous-programme de traduction de nom en adresse, remplacé depuis dix ans par getaddrinfo(). Cette option me semble donc inutile.
Ah intéressant. Tout du moins si je rencontre des problèmes avec des vi eux programmes. Ceci dit je ne vois pas pourquoi je n'ai pas d'IPv6 sans inet6. Quelqu'un aurait-il une idée d'un fichier qui pourrait poser problème ? Il doit bien y avoir un fichier sur le système pour spécifier la préfé rence entre IPv6 et IPv4. J'ai regardé gai.conf mais tout est commenté donc c ela ne doit pas venir de là.
Merci pour vos réponses, j'ai au moins appris des choses ce qui en soit e st déjà très bien.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
On Sun, Dec 07, 2008 at 12:59:13PM +0100, Pascal Hambourg wrote a message of 21 lines which said:
Peut-être parce qu'ils ne connaissent pas (et moi non plus).
http://www.bortzmeyer.org/5220.html
L'exemple de la page de manuel ne contient que des préfixes IPv6, et la RFC 3484 à laquelle elle se réfère ne concerne que les adresses IPv6. Comment peut-on utiliser gai.conf pour favoriser les adresses IPv4 ?
% cat /etc/gai.conf # For testing purposes, always use IPv6 for AFNIC precedence 2001:660:3003:2::/48 200 precedence 2001:660:3003:3::/48 200 # Otherwise, always prefer IPv4 precedence ::ffff:0:0/96 100
(C'est documenté dans /etc/gai.conf lui-même, dans les commentaires.)
Au fait, c'est utilisable avec la glibc d'etch ?
En effet, ça semble être apparu avec lenny.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Sun, Dec 07, 2008 at 12:59:13PM +0100,
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote
a message of 21 lines which said:
Peut-être parce qu'ils ne connaissent pas (et moi non plus).
http://www.bortzmeyer.org/5220.html
L'exemple de la page de manuel ne contient que des préfixes IPv6, et
la RFC 3484 à laquelle elle se réfère ne concerne que les adresses
IPv6. Comment peut-on utiliser gai.conf pour favoriser les adresses
IPv4 ?
% cat /etc/gai.conf
# For testing purposes, always use IPv6 for AFNIC
precedence 2001:660:3003:2::/48 200
precedence 2001:660:3003:3::/48 200
# Otherwise, always prefer IPv4
precedence ::ffff:0:0/96 100
(C'est documenté dans /etc/gai.conf lui-même, dans les commentaires.)
Au fait, c'est utilisable avec la glibc d'etch ?
En effet, ça semble être apparu avec lenny.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sun, Dec 07, 2008 at 12:59:13PM +0100, Pascal Hambourg wrote a message of 21 lines which said:
Peut-être parce qu'ils ne connaissent pas (et moi non plus).
http://www.bortzmeyer.org/5220.html
L'exemple de la page de manuel ne contient que des préfixes IPv6, et la RFC 3484 à laquelle elle se réfère ne concerne que les adresses IPv6. Comment peut-on utiliser gai.conf pour favoriser les adresses IPv4 ?
% cat /etc/gai.conf # For testing purposes, always use IPv6 for AFNIC precedence 2001:660:3003:2::/48 200 precedence 2001:660:3003:3::/48 200 # Otherwise, always prefer IPv4 precedence ::ffff:0:0/96 100
(C'est documenté dans /etc/gai.conf lui-même, dans les commentaires.)
Au fait, c'est utilisable avec la glibc d'etch ?
En effet, ça semble être apparu avec lenny.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/DebFrFrenchLists Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
