glibc, bug 438179 et avenir de/dans etch
Bonjour,
A travers ce mail, je souhaite évoquer les problèmes techniques qui découlent du bug 438179 de la glibc [1] et éventuellement de savoir ce qui peut-être fait pour faire avancer les choses (par debian ou par moi même).
Mon soucis est de bien comprendre les tenant et les aboutissants de ce qui est, sera ou pourra être fait tant au niveau de debian qu'à un niveau plus global afin de prendre la bonne décision pour les serveurs que j'administre.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438179
Pour faire un résumer (simpliste) du bug et de la situation, une implémentation dans getaddrinfo (dans la glibc) de la RFC 3484 pose problème en "cassant" les mécanismes de round robin dns utilisés depuis des années (pour des applications qui utilisent getaddrinfo et qui s'appuyaient à l'origine sur gethostbyname).
Ce système de répartition de charge par round robin dns n'est peut-être pas le meilleur, mais dans de nombreux cas, AMHA, il répond bien et à moindre coût (tant technique que matériel) à ce à quoi il est destiné.
Pour ma part, le problème se pose dans le fonctionnement du centre serveur sur lequel je travaille, notamment au niveau de l'ensemble de l'infrastructure openldap qui fonctionne avec des heartbeat en actif/actif pour la partie haut-disponbilité et un round robin dns pour l'équilibrage de charge. Ce système fonctionnait parfaitement avec Sarge.
La migration de Sarge à Etch casse donc ce fonctionnement, ce qui entraîne des problèmes de répartition de charge entre les serveurs et remet en cause les fonctionnements en actif/actif. De mon point de vue d'administrateur/utilisateur, c'est catastrophique.
Un patch à la glibc a été ajouté permettant de configurer le comportement de getaddrinfo (je n'ai pas encore tester cette version de la libc). Bien qu'à mon sens cette solution ne soit pas optimale, une modification définitive de getaddrinfo et de la RFC 3484 pour garantir un fonctionnement par défaut et une compatibilité avec le comportement historique de gethostbyname me paraissant meilleur, elle a l'avantage d'exister actuellement.
Pour rétablir ce fonctionnement sur mes serveurs, un backport ou une transposition du patch dans la glibc de etch sont-ils la seul solution ou une mise à disposition pour etch de cette version de la glibc est-elle envisagée ?
Au pire, une mise à disposition dans volatile (ou volatile-sloppy) est-elle possible ? Faut-il faire un mail ou un rapport de bug quelque part pour cela ?
Apparemment, de nombreux d'utilisateurs sont touchés par ce problème, il me semble dommage que tous essaient de vivre avec ou transposent ce patch dans leur coin.
Plus généralement, est-il prévu une action au niveau des développeurs de la glibc (upstream) et/ou de l'IETF pour une modification/évolution de la RFC 3484 ?
Cordialement,
Julien
P.S: il m'a semblé logique de poser ces questions à des développeurs debian (donc sur devel-french) plutôt que sur user-french. J'espère que cela n'offusquera personne.
Reply to: