Nous installons un nouveau serveur openLDAP consumer. Il est répliqué sur le même serveur LDAP producer que tous nos autres serveurs LDAP consumers. La configuration est strictement identique, car intégralement gérée par Puppet.
Plus de 24 heures après son installation, nous lançons une recherche LDAP très classique : ldapsearch -xLLL -H ldaps://serveurldap.masociete.example -b ou=people,dc=masociete,dc=example monattribut=830
. Elle retourne 38 résultats quand c'est l'un de nos consumers déjà en place qui y répond et 30 résultats quand c'est notre nouveau serveur qui y répond.
Problème de réplication ? Non, un coup de ldapvi sur le producer et une recherche sur ce nouveau consumer montre qu'elle fonctionne. Notre script de supervision qui surveille la réplication LDAP le confirme. De plus, les 8 entrées qui constituent la différence ont été crées il y a plusieurs années !
Encore plus étrange : si l'on remplace le filtre de recherche (monattribut=830
) par monattribut=*830
ou monattribut=830*
ou même monattribut=*830*
, notre nouveau serveur LDAP retourne bien le bon nombre de résultats. :O
C'est cela qui m'a mis la puce à l'oreille. Le filtre « monattribut=830 » effectue une recherche exacte. Les autres filtres exposés ci-dessus effectuent une recherche de sous-chaîne. Or, nous avons créé, de longue date, un index pour la recherche exacte (« olcDbIndex: monattribut eq » dans la configuration), mais pas pour la recherche d'une sous-chaîne (qui s'écrit « sub »). Conclusion : l'index est foireux.
On force la (re)génération des index avec la commande sudo -u openldap slapindex
.
Problème réparé. Ce n'est pas comme si c'était la première fois que la fonctionnalité d'indexation d'openLDAP a eu un comportement foireux…