Cela fait plusieurs mois que je cherchais à comprendre pourquoi la librairie nss_ldap (qui permet sous Linux/Unix d'utiliser un annuaire LDAP pour gérer les utilisateurs, groupes et autres bases de données dynamiques) est très lente avec de gros volumes de données, même quand on active nscd .

Aujourd'hui j'ai non seulement compris pourquoi, mais j'ai en plus cru trouver la solution miracle, avant d'avoir un gros coup de blues quand j'ai vu qu'un névrosé de chez Red Hat refuse que cette optimisation soit intégrée dans le code standard des librairies Linux

L'histoire de ma déconvenue est une bonne occasion pour parler de quelques "sales cons" du logiciels libres, qui font avancer l'informatique libre d'un (grand) pas, avant qu'un aspect névrotique de leur personnalité ne nous fassent reculer de deux pas...

LDAP, NSS et le système de cache NSCD

Sur un système comme Linux, il existe des bases de données qui stockent les informations d'authentifications ou d'identification des personnes ou ressources :

• Liste des comptes Unix : il s'agit du fameux fichier "passwd"
• Liste des groupes : le fichier "group"
• Liste des noms d'ordinateurs : généralement on utilise le DNS ou bien un fichier statique "hosts", pour résoudre leur IP
• etc.

Dans une architecture de petite ou moyenne taille, ces bases peuvent être de simples fichiers plats, ou des bases séquentielles indexées (fichier DB, DBM, GDBM, etc.). Ces bases sont de plus locales à chaque machine.

Pour un gros réseau, on voudra non seulement une base de données optimisée pour stocker un très grand volume de données, capable de répondre très rapidement à de nombreuses requêtes simultanées, mais qui en plus soit accessible en réseau par l'ensemble des serveurs Linux/Unix.

Un serveur LDAP, comme OpenLDAP ou Fedora Directory Server , convient relativement bien pour cette tâche. Mais ... il reste encore un peu lent pour certains types de requêtes. Par exemple, si l'on se base sur le langage C :

• Une requête de type getpwnam(), qui retourne les infos sur un compte unix, peut être mappée sur une seule requête LDAP. Par exemple, en simplifiant à l'extrème : "(&(objectclass=posixAccount)(cn=jdupont))".
• Par contre, la requête "je veux tous les groupes auxquels appartient jdupont", va nécessiter un appel getpwnam(), puis un appel setgrent() et ensuite une boucle getgrent() qui sera exécutée autant de fois qu'il y a de groupes Unix. Donc s'il y a 2000 groupes il faudra boucler 2000 fois ! Et si la requête se fait en LDAP, cela signifie
• 1 requête pour trouver le compte jdupont dans l'annuaire LDAP
  
• 1 requête qui va retourner les 2000 groupes depuis l'annuaire LDAP, sans distinction
• 2000 boucles en local pour sélectionner les seules groupes auxquels appartient jdupont.

Autant dire que ça peut être très lent, même avec un réseau et un annuaire rapide !

Heureusement, la librairie GNU Libc6 fournit un daemon du nom de nscd (Name Service Caching Daemon). Comme son nom l'indique, nscd va servir de cache local temporaire pour stocker les résultats de nos requêtes LDAP, et les resservir plus rapidement subséquemment.

Mais, si nscd sait traiter et mettre en cache les requête de type getpwnam(), getgrgid(), (car elles retournent 0 ou 1 réponse à une requête), il ne sait pas traiter une requête getgrent() ou getpwent(), qui peuvent retourner de 0 à N réponse, avec N très grand.

Nous sommes donc revenus à notre point de départ : nous somme passés de fichiers plats (/etc/passwd, /etc/shadow, /etc/group) ou DB (comme master.db sur les système *BSD) à une bases LDAP. nous avons créé des milliers d'entrées, et d'un seul coup notre serveur IMAP redevient très lent et génère des méga-octets de trafics inutiles lors du contrôle des droits d'accès

La solution miracle

Après avoir correctement analysé le problème, et donc trouvé les bons mots clés à taper dans Google (vous savez, la future World Company), j'ai donc trouvé la solution : un ingénieur de Google (tient, encore eux, est-ce un hasard ?) a développé un patch pour nscd et la libc6 qui ajoute le support de get*ent à nscd !

Joie et bonheur dans les chaumières ! Il n'y a plus qu'à attendre qu'un patch officieux sorte, puis un patch officiel, qui sera finalement intégré dans la libc6, et donc dans toutes les distributions Linux. 

C'était sans compter sur la névrose de certains membre éminents du logiciel libre...

La déconvenue

La réponse d'Ulrich Drepper , mainteneur officiel de la GNU libc6, éminent contributeur au logiciel libre et salarié Red Hat, fait froid dans le dos. En gros, pour résumer ce qui est sous-entendu dans ce commentaire lapidaire (il faut lire les autres commentaires pour avoir tout le contexte) :

• Tais toi, tu es un minable, tout comme ton patch
• J'ai raison mais je ne dirais pas pourquoi. Tu dois être assez intelligent pour savoir que j'ai raison. Si tu ne le sais pas, eh bien c'est parce qu'effectivement tu es un con.
• Toutes les applications Unix depuis la nuit des temps sont mal écrites, elle doivent toutes être réécrites plutôt que je rajoute ton patch à mon code, même s'il est techniquement (et humainement, financièrement) impossible de les réécrire.

Les névrosés du logiciel libre

Dans une certaine catégorie de personnes, quel que soit le mode de sélection, il y a toujours le même pourcentage d'individus nuisibles que partout ailleurs. Et, pour paraphaser un des directeurs de Polytechnique, plus on sélectionne ces individus, plus les cons deviennent dangereux.  Voilà comment on se retrouve avec des types comme Ulrich Drepper.

Il n'est malheureusement pas le seul dans ce cas, il ya a plusieurs exemples célèbres :

• Dan J. Bernstein : mathématicien et informaticien de génie. Concepteur notamment de Qmail , du format Maildir, de djbdns, défenseur du droit à l'utilisation de la cryptographie. On n'a jamais trouvé le moindre trou de sécurité dans ses applications, qui allient performance et sécurité. Malheureusement, DJB est un individu très arrogant, imbu de lui-même, et névrosé au point de créer des pages web pour diffamer les développeurs avec qui il est en désaccord ! Je ne trouve plus de trace de cette histoire sur le net malheureusement. De plus, il a développé un système de gestion des daemons sur Unix qui, s'il est très ingénieux, performant et sûr, ne ressemble à rien de connu et est totalement incompatible avec le reste de l'univers (à moins bien sûr de modifier son Linux/Unix pour l'adapter au système de DJB). Tout personne qui se permet de le critiquer se reçoit une volée de bois vert en retour.
• Joerg Schilling : Créateur de cdrecord , un des logiciels de gravure de CD/DVD le plus utilisés sous Linux et Unix en général. Tout comme DJB, Schilling ne se prend pas pour de la merde. Il passe par exemple son temps à critiquer la gestion des périphériques IDE et SCSI sous Linux en répétant à qui veut l'entendre, et ce depuis des années : "c'est écrit n'importe comment, c'est cassé. Ils ont fait n'importe quoi. Pffff si ça ne marche pas, passez à un vrai système d'exploitation comme Solaris. Votre question est idiote, c'est parce que vous utilisez Linux que ça ne marche pas...". Et comme il prend de haut toutes les personnes qui posent des questions sur la liste de diffusion cdrecord, non seulement tout le monde déserte cette liste, mais en plus il s'est fait plein d'ennemis qui s'amusent à abonner des spammeurs à cette liste... Monsieur j'ai-toujours-raison est aussi l'auteur de cdrecord-dvd, un (sans doute) excellent logiciel de gravure de DVD, mais qui n'est pas GPL contrairement à cdrecord. Bien évidemment personne n'utilise cdrecord-dvd, mais des produits concurrents vraiment libres. Curieusement, aucun développeur du kernel Linux ne daigne corriger les drivers IDE et SCSI comme M. Schilling le demande. Il faut dire que Schilling passe son temps à les insulter et les prendre de haut... Pour une bonne rigolage, on peut par exemple lire les commentaire anti-Linux et anti-utilisateurs sur la première page du site de cdrecord ou bien le blog pro-Solaris anti-Linux du monsieur aveci tous les spams qu'il reçoit en commentaire
• Christian Marillat et Branden Robinson : Respectivement mainteneur Debian de paquets Gnome (et de paquets multimédia) et mainteneur Debian de Xorg. Il vaut mieux éviter de poser une question à ces messieurs, ou même de faire un rapport de bug, car ils s'empressent de vous faire comprendre que vous êtes un con, au mieux un nul, qu'il n'y a pas de bug, et que si les applications qu'ils maintiennent ne marchent pas, c'est que justement vous êtes un nul. J'ai arrêté depuis longtemps d'ouvrir un bug report si Marillat ou Robison sont mainteneurs du paquet Debian concerné.

La liste est longue, mais sans doute incomplète. Il est amusant de constater à quel point Internet permet à des individus puérils et visiblement névrosés de se défouler sur les autres en toute impunité. L'internet fournit un certain anonymat, une distance par rapport à son interlocuteur, un écran au sens propre comme au figuré. Et puis, c'est bien connu, c'est toujours l'autre qui a tort !

Si vous vous reconnaissez dans ce type de personnalité, je ne peux que vous conseiller de faire un travail sur vous-même, de prendre un peu de recul pour analyser et comprendre vos propres faiblesse, et de respecter les autres si vous voulez vous-même être respecté(e). Je peux donner ce conseil d'autant plus gratuitement que, comme je le dis dans le chapitre précédent, je suis persuadé que personne ne se reconnaîtra dans ce modèle !

En attendant, c'est à cause de ce type d'individu pitoyable que je ne peux pas optimiser l'architecture système de mon client...