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…

OpenLDAP génère des statistiques (cf la documentation très incomplète du projet) : nombre de connexions, nombre de requêtes par type (ajout, suppression, modification, recherche, etc.), etc.. Un module fourni par défaut, back-monitor, permet de les exposer via une requête LDAP standard. Il suffit ensuite d'écrire un script de supervision / métrologie qui parse la sortie d'un ldapsearch.

Il faut activer et configurer ce module de slapd :

• Créer un fichier /tmp/ldap-activer-module-supervision.ldif avec le contenu suivant :

  dn: cn=module{0},cn=config
  changetype: modify
  add: olcModuleLoad
  olcModuleLoad: back_monitor

  
  

• ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/ldap-activer-module-supervision.ldif
  
  

• Créer un fichier /tmp/ldap-configurer-module-supervision.ldif avec le contenu suivant (dans mon cas, l'utilisateur mentionné dans l'ACL existait déjà, sinon il convient de le créer d'abord) :

  dn: olcDatabase={2}Monitor,cn=config
  objectClass: olcDatabaseConfig
  objectClass: olcMonitorConfig
  olcDatabase: {2}Monitor
  olcAccess: {0}to dn.subtree="cn=Monitor" by dn.base="cn=supervision,ou=ldap,dc=masociete,dc=example" read by * none

  
  

• ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/ldap-configurer-module-supervision.ldif

Visualiser les informations disponibles : ldapsearch -xLLL -H ldaps://serveurldap.masociete.example -D cn=supervision,ou=ldap,dc=masociete,dc=example -W -b cn=Monitor -s sub +

Branches intéressantes (ou non) :

• cn=Operations,cn=Monitor : nombre total de requêtes initiées (monitorOpInitiated) / terminées (monitorOpCompleted) par type (recherche, ajout, etc.) depuis le démarrage de slapd ;
  
  
• cn=Connections,cn=Monitor : nombre total et instantané de connexions (y compris celles permettant la réplication), et détails techniques de chaque connexion. On peut ainsi surveiller si l'on n'arrive pas trop près de la limite du nombre de fichiers ouverts, qui comptabilise aussi les sockets, donc les connexions ;
  
  
• cn=Uptime,cn=Time,cn=Monitor : le nom parle de lui même ;
  
  
• cn=Statistics,cn=Monitor : nombre de paquets, d'octets et d'entrées envoyés par le serveur ;
  
  
• Je ne trouve pas pertinente la branche cn=Waiters,cn=Monitor. C'est toujours utile de surveiller les clients en attente de lecture et d'écriture, car ça peut révéler des problèmes de tenue de charge. L'ennui, c'est que les connexions persistantes sont considérées comme étant en attente de lecture, donc l'info est redondante avec la cn=Current,cn=Connections,cn=Monitor et un nombre élevé n'indique pas forcément un problème, mais l'existence d'un nombre elevé de connexions persistantes… qui peuvent être légitime si l'on a des applications qui font beaucoup de requêtes.

Quelques notes :

• La différence entre le nombre de bind (authentifications, même anonymes) et d'unbind (déconnexions) s'explique par les connexions persistantes et les déconnexions sauvages (un client ne signale pas la fin de l'échange, c'est un timeout qui le clôture brutalement) ;
  
  
• Si les compteurs de requêtes d'écriture (add, modify, modrdn, etc.) sont supérieurs à 0 sur un « consumer » (a priori bloqué en écriture), cela ne veut pas dire qu'une écriture a eu lieu, mais qu'elle a été demandée par un logiciel client, et que slapd a comptabilisé la requête… avant de rediriger le demandeur vers le serveur LDAP « producer » (principe du referral).