Re: glibc, bug 438179 et avenir de/dans etch

2007-09-27 Thread Julien Cristau 
On Wed, Sep 26, 2007 at 17:18:35 +0200, Pierre Habouzit wrote:

> On Wed, Sep 26, 2007 at 03:55:56PM +, [EMAIL PROTECTED] wrote:
> >   La migration de Sarge à Etch casse donc ce fonctionnement, ce qui
> 
>   Non etch n'a pas ça. Seul lenny est concernée.
> 
Le monsieur a raison, getaddrinfo() dans etch fait le tri.

Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: glibc, bug 438179 et avenir de/dans etch

2007-09-27 Thread Pierre Habouzit 
On Thu, Sep 27, 2007 at 09:28:04AM +, Julien Cristau wrote:
> On Wed, Sep 26, 2007 at 17:18:35 +0200, Pierre Habouzit wrote:
> 
> > On Wed, Sep 26, 2007 at 03:55:56PM +, [EMAIL PROTECTED] wrote:
> > >   La migration de Sarge à Etch casse donc ce fonctionnement, ce qui
> > 
> >   Non etch n'a pas ça. Seul lenny est concernée.
> > 
> Le monsieur a raison, getaddrinfo() dans etch fait le tri.

  Euh je suis surpris parce que Uli prétend le contraire Oo... En tout
cas son test est foireux, parce que il ne teste la rule 9 que ssi il
testait sur le host qui finit en 165. Pour faire le test correctement il
faudrait le faire sur des préfixes qui varient bien plus tot.

  De plus il faudrait etre sur de le faire sans nscd ni aucun cache (qui
parfois te choisissent un ordre). Donc en ayant bien vérifié avant que
dig renvoie des paquets DNS où il y a de la variabilité aussi...

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpozZPnGar1J.pgp
Description: PGP signature

Re: glibc, bug 438179 et avenir de/dans etch

2007-09-27 Thread j . combes . ml 
Bonjour,

Le 26.09.2007 19:16, Pierre Habouzit a écrit  :
>   Je ne sais pas quelles sont les conditions d'utilisation du programme,
> donc il est difficile de valider quoi que ce soit. Il y a mille raisons
> pour lesquelles ça a l'air d'être trié (nscd notamment). Mais:
>
>   (1) la rule 9 est à propos des plus longs préfixes, or vu que la
>   différence entre 165 et 166 est uniquement sur les deux derniers
>   bits, le test est tout simplement idiot.

Mon test est probablement idiot, mais il met en évidence un comportement que
j'ai sur plusieurs dizaines de serveurs et que j'essaye tant bien que mal de
comprendre depuis plusieurs jours. Avant de venir passer pour un âne sur une
liste debian-devel archivée sur internet (ce qui n'était pas franchement mon
rêve je dois bien te l'avouer ;-) ), j'ai parlé du problème à un ami qui a pu le
reproduire sur ses propres serveurs en Debian etch.

Le rapprochement entre mon problème et le bug  438179 est peut-être malheureux.
Néanmoins, j'ai un problème, qui touche la glibc de Etch, qui n'est apparemment
pas si isolé que cela puisque nous sommes au minimum deux à l'avoir.

Peut-être est-il lié à l'environnement (matériel, logiciel, ou réseau) mais je
dois bien avouer que je suis à cours de piste. Par ailleurs, en patchant la
glibc 2.3.6 au niveau de la règle 9 (voir plus bas), je n'ai plus le problème.

Si je refais le test sur la glibc de Etch avec le petit programme du mail
précédent et en arrêtant le plus de démons possibles (voir fichier ps-ed.txt
joint) :
$ cat /etc/debian_version
4.0

$ dpkg -l "libc6*" |grep ^i
ii  libc6   2.3.6.ds1-13etch2 GNU C Library: Shared libraries

Avec getaddrinfo :
$  ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$  ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$  ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$  ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166

Avec gethostbyname :
$  ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$  ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine   10.xxx.yyy.166  10.xxx.yyy.165
$  ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$  ./reso-dns ldaprs.mon.domaine gethostbyname
gethostbyname : ldaprs.mon.domaine   10.xxx.yyy.166  10.xxx.yyy.165

Non seulement, il y a un tri, mais en plus sur des adresses proches...

De plus si j'applique ce patch à la glibc 2.3.6 [1], je n'ai plus le problème :
--- glibc-backup/sysdeps/posix/getaddrinfo.c2005-10-16 12:15:30.0 
+0200
+++ glibc-2.3.6/sysdeps/posix/getaddrinfo.c 2007-09-25 11:29:46.0 
+0200
@@ -1392,7 +1392,7 @@
   int bit1 = 0;
   int bit2 = 0;

-  if (a1->dest_addr->ai_family == PF_INET)
+  if (a1->dest_addr->ai_family == PF_INET && 0)
{
  assert (a1->source_addr.ss_family == PF_INET);
  assert (a2->source_addr.ss_family == PF_INET);


Or ce patch s'applique pile ici dans la fonction getaddrinfo de la glibc 2.3.6 :
  /* Rule 9: Use longest matching prefix.  */
  if (a1->got_source_addr
  && a1->dest_addr->ai_family == a2->dest_addr->ai_family)
{
  int bit1 = 0;
  int bit2 = 0;

  if (a1->dest_addr->ai_family == PF_INET)
{
  assert (a1->source_addr.ss_family == PF_INET);
  assert (a2->source_addr.ss_family == PF_INET);

[1] méthode utilisée pour appliquer le patch :
- dans l'archive debian  de la glibc-2.3.6, création d'un fichier
"debian/patches/any/patch-sortv4.diff" avec ce patch.
- ajout de "any/patch-sortv4.diff -p 1" à la suite des "any/" dans le fichier
"debian/patches/series"

Voici les tests des getaddrinfo avec la glibc patchée :
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.166  10.xxx.yyy.165
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.165  10.xxx.yyy.166
$ ./reso-dns ldaprs.mon.domaine getaddrinfo
getaddrinfo :   ldaprs.mon.domaine   10.xxx.yyy.166  10.xxx.yyy.165

Je suis prêt à faire d'autre test si cela peut aider.

Cordialement,
Julien$ ps -ef
UIDPID  PPID  C STIME TTY  TIME CMD
root 1 0  0 Sep04 ?00:00:01 init [2]
root 2 1  0 Sep04 ?00:00:00 [migration/0]
root 3 1  0 Sep04 ?00:00:00 [ksoftirqd/0]
root 4 1  0 Sep04 ?00:00:00 [migration/1]
root 5 1  0 Sep04 ?00:00:00 [ksoftirqd/1]
root 6 1  0 Sep04 ?00:00:00 [events/0]
root 7 1  0 Sep04 ?00:00:00 [events/1]

Re: glibc, bug 438179 et avenir de/dans etch

2007-09-27 Thread Pierre Habouzit 
On Thu, Sep 27, 2007 at 11:39:03AM +, [EMAIL PROTECTED] wrote:
> Bonjour,
> 
> Le 26.09.2007 19:16, Pierre Habouzit a écrit  :
> >   Je ne sais pas quelles sont les conditions d'utilisation du programme,
> > donc il est difficile de valider quoi que ce soit. Il y a mille raisons
> > pour lesquelles ça a l'air d'être trié (nscd notamment). Mais:
> >
> >   (1) la rule 9 est à propos des plus longs préfixes, or vu que la
> >   différence entre 165 et 166 est uniquement sur les deux derniers
> >   bits, le test est tout simplement idiot.
> 
> Mon test est probablement idiot, mais il met en évidence un comportement que
> j'ai sur plusieurs dizaines de serveurs et que j'essaye tant bien que mal de
> comprendre depuis plusieurs jours. Avant de venir passer pour un âne sur une
> liste debian-devel archivée sur internet (ce qui n'était pas franchement mon
> rêve je dois bien te l'avouer ;-) ), j'ai parlé du problème à un ami qui a pu 
> le
> reproduire sur ses propres serveurs en Debian etch.

  Disons que la règle 9 met en tete les adresses qui partagent le plus
long préfixe possible avec l'ip de la machine locale. Donc un test où la
variation du préfixe n'est sensible que sur les deux derniers bits
n'aura du sens que si le test est fait sur l'une des deux machines
concernées. Voilà pourquoi le test est mauvais.


> De plus si j'applique ce patch à la glibc 2.3.6 [1], je n'ai plus le problème 
> :
> --- glibc-backup/sysdeps/posix/getaddrinfo.c  2005-10-16 12:15:30.0 
> +0200
> +++ glibc-2.3.6/sysdeps/posix/getaddrinfo.c   2007-09-25 11:29:46.0 
> +0200
> @@ -1392,7 +1392,7 @@
>int bit1 = 0;
>int bit2 = 0;
> 
> -  if (a1->dest_addr->ai_family == PF_INET)
> +  if (a1->dest_addr->ai_family == PF_INET && 0)
>   {
> assert (a1->source_addr.ss_family == PF_INET);
> assert (a2->source_addr.ss_family == PF_INET);
> 
> 
> Or ce patch s'applique pile ici dans la fonction getaddrinfo de la glibc 
> 2.3.6 :
>   /* Rule 9: Use longest matching prefix.  */
>   if (a1->got_source_addr
>   && a1->dest_addr->ai_family == a2->dest_addr->ai_family)
> {
>   int bit1 = 0;
>   int bit2 = 0;
> 
>   if (a1->dest_addr->ai_family == PF_INET)
>   {
> assert (a1->source_addr.ss_family == PF_INET);
> assert (a2->source_addr.ss_family == PF_INET);

  Okay bah en effet, le code de tri de la rule 9 est présent depuis bien
plus de temps que ce que Uli dit p/r à la rfc 3484. Aurélien a fait un
patch qui au lien de mettre && 0 à cet endroit, utilise un réglage de
gai.conf pour ce faire, le patch est attaché, et devrait du coup sans
doute s'appliquer directement en glibc 2.3.X (en tout cas sans trop de
grosses difficultés).

  Avec le patch il suffit de mettre dans /etc/gai.conf: sortv4 no

  Désolé d'avoir été vite agacé donc, mais j'en ai un peu marre de me
faire taper dessus pour un changement de comportement de la glibc alors
que je suis qu'un des packagers, et pas l'upstream, donc j'ai tendance à
partir au 1/4 de tour sur ce problème.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
2007-08-16  Aurelien Jarno  <[EMAIL PROTECTED]>

* sysdeps/posix/getaddrinfo.c (gaiconf_reload_flag): Move
to the top of the file. 
(gaiconf_mtime): Likewise.
(sortv4): New configuration variable.
(gaiconf_init): Parse the sortv4 option in the configuration
file.
(rfc3484_sort): Ignore rule 9 for IPv4 adresses if sortv4
is false.
* posix/gai.conf: Add the new sortv4 option.


--- posix/gai.conf  2007-08-16 22:59:03.0 +0200
+++ posix/gai.conf  2007-08-16 22:58:48.0 +0200
@@ -15,6 +15,11 @@
 #changed and if necessary reload.  This option should not really be
 #used.  There are possible runtime problems.  The default is no.
 #
+# sortv4  
+#If set to no, getaddrinfo(3) will ignore IPv4 adresses in rule 9.  See
+#section 6 in RFC 3484.  The default is yes.  Setting this option to 
+#no breaks conformance to RFC 3484.
+#
 # label  
 #Add another rule to the RFC 3484 label table.  See section 2.1 in
 #RFC 3484.  The default is:
--- sysdeps/posix/getaddrinfo.c 2007-08-16 23:02:34.0 +0200
+++ sysdeps/posix/getaddrinfo.c 2007-08-16 22:31:53.0 +0200
@@ -79,6 +79,16 @@
 # define UNIX_PATH_MAX  108
 #endif
 
+/* Nozero if we are supposed to reload the config file automatically
+   whenever it changed.  */
+static int gaiconf_reload_flag;
+
+/* Zero if we are supposed to ignore rule 9 for IPv4 addresses */
+static int gaiconf_sortv4_flag = 1;
+
+/* Last modification time.  */
+static struct timespec gaiconf_mtime;
+
 struct gaih_service
   {
 const char *name;
@@ -1344,7 +1354,7 @@
   int bit1 = 0;
   int bit2 = 0;
 
-  if (a1->dest_addr->ai_family == PF_INET)
+  if (a1->dest_addr->ai_family

Re: glibc, bug 438179 et avenir de/dans etch

2007-09-27 Thread j . combes . ml 
Le 27.09.2007 13:49, Pierre Habouzit a écrit  :

>   Okay bah en effet, le code de tri de la rule 9 est présent depuis bien
> plus de temps que ce que Uli dit p/r à la rfc 3484. Aurélien a fait un
> patch qui au lien de mettre && 0 à cet endroit, utilise un réglage de
> gai.conf pour ce faire, le patch est attaché, et devrait du coup sans
> doute s'appliquer directement en glibc 2.3.X (en tout cas sans trop de
> grosses difficultés).

Bon, ca ne va pas être tout à fait trivial (mais pas forcement très compliquer)
: la patch commence par s'occuper d'un fichier posix/gai.conf qui n'existe pas
dans la glibc 2.3.6 et les numero de lignes ne correspondent pas ensuite. Je
regarde (probablement demain, une sombre histoire d'acl ldap à régler avant ;) )
si j'arrive à l'adapter pour cette version de la glibc. Je te tiens au courant.

>   Désolé d'avoir été vite agacé donc, mais j'en ai un peu marre de me
> faire taper dessus pour un changement de comportement de la glibc alors
> que je suis qu'un des packagers, et pas l'upstream, donc j'ai tendance à
> partir au 1/4 de tour sur ce problème.

Pas grave ;)
Qu'on soit bien d'accord, je ne cherche pas de coupable, j'essaye juste d'une
part de bien comprendre un problème qui touche mes serveurs et comment tout cela
va ou peut évoluer et d'autre part de le régler la meilleur façon possible.

Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

A Single Blade Of Grass Unsubscription

2007-09-27 Thread A Single Blade Of Grass 

The removal of the email address:

debian-devel-french@lists.debian.org

>From the mailing list: 

A Single Blade Of Grass 

is all set.

Date of this removal: Thu Sep 27 14:35:08 2007

Please save this email message for future reference.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

 

- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Welcome to A Single Blade Of Grass

2007-09-27 Thread A Single Blade Of Grass 

The subscription of the email address: 

debian-devel-french@lists.debian.org

To the mailing list: 

A Single Blade Of Grass

is all set. Thanks for subscribing! 

Date of this subscription: Thu Sep 27 15:40:18 2007

Please save this email message for future reference. 

---

You may automatically unsubscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

 

- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: glibc, bug 438179 et avenir de/dans etch

2007-09-27 Thread Julien Cristau 
On Thu, Sep 27, 2007 at 12:02:45 +0200, Pierre Habouzit wrote:

>   Euh je suis surpris parce que Uli prétend le contraire Oo... En tout
> cas son test est foireux, parce que il ne teste la rule 9 que ssi il
> testait sur le host qui finit en 165. Pour faire le test correctement il
> faudrait le faire sur des préfixes qui varient bien plus tot.
> 
>   De plus il faudrait etre sur de le faire sans nscd ni aucun cache (qui
> parfois te choisissent un ordre). Donc en ayant bien vérifié avant que
> dig renvoie des paquets DNS où il y a de la variabilité aussi...
> 
Je me suis contenté de comparer getent hosts security.debian.org et
getent ahosts security.debian.org.  Dans le premier cas ca tourne, dans
le 2eme cas 212.211.132.32 et 212.211.132.250 sont toujours avant
128.31.0.36 (et l'ordre entre les deux premiers change).

Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

A Single Blade Of Grass Unsubscription

2007-09-27 Thread A Single Blade Of Grass 

The removal of the email address:

debian-devel-french@lists.debian.org

>From the mailing list: 

A Single Blade Of Grass 

is all set.

Date of this removal: Thu Sep 27 16:10:14 2007

Please save this email message for future reference.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

 

- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]