Conseils pour le debuggage et l'administration d'openldap¶

Loglevel¶

slapd écrit par défaut dans syslog.

Le niveau de log est défini par l'attribut olcLogLevel de cn=config. Par défaut, olcLogLevel=none.

Pour obtenir davantage de traces, modifier la valeur de olcLogLevel avec la somme d'un ou plusieurs des niveaux décrits ci-dessous:

Level     Keyword     Description
-1     any     enable all debugging
0           no debugging
1     (0x1 trace)     trace function callss
2     (0x2 packets)     debug packet handling
4     (0x4 args)     heavy trace debugging
8     (0x8 conns)     connection management
16     (0x10 BER)     print out packets sent and received
32     (0x20 filter)     search filter processing
64     (0x40 config)     configuration processing
128     (0x80 ACL)     access control list processing
256     (0x100 stats)     stats log connections/operations/results
512     (0x200 stats2)     stats log entries sent
1024     (0x400 shell)     print communication with shell backends
2048     (0x800 parse)     print entry parsing debugging
16384     (0x4000 sync)     syncrepl consumer processing
32768     (0x8000 none)     only messages that get logged whatever log level is set 

Valeurs couramment utilisées:

• olcLogLevel=256: affiche les requêtes traitées par le LDAP (permet de voir exactement ce que fait un service qui interroge le LDAP)
• olcLogLevel=256+16384: affiche les requêtes et les traces spécifiques à la réplication

Les logs peuvent vite être assez volumineux.
=> bien penser à repasser olcLogLevel à none une fois le débuggage terminé
=> monitorer l'espace libre dans /var/log

Slapd as root¶

Lorsque slapd ne démarre pas, on le lance parfois à la main en mode debug pour voir les messages. Attention: ne pas lancer slapd manuellement en tant que root avec /var/lib/ldap vide. Cela créerait la base HDB avec owner=root, et slapd ne démarrerait plus avec /etc/init.d/slapd start.

Si cela arrive néanmoins, chown openldap:openldap /var/lib/ldap/*.

Réinitialiser un consumer¶

Pour réinitialiser les données d'une réplique du ldap en syncronisation avec un provider:

/etc/init.d/slapd stop
rm /var/lib/ldap/*
/etc/init.d/slapd start

Openldap va alors créer une nouvelle base HDB vierge, et la réplication va reconstituer tout l'annuaire à partir du provider.

Défaillance d'un serveur LDAP¶

Mesures à prendre en cas de défaillance (prolongée) d'un des serveurs LDAP.

Défaillance d'un LDAP esclave¶

Retirer l'enregistrement A correspondant au serveur défaillant, pour le nom DNS ldap.illyse.org.
Le serveur en rade ne sera alors plus exploité par les services s'appuyant sur ldap.illyse.org.

Note: les services essaieront peut-être encore de contacter le serveur défaillant s'ils ont mis en cache DNS le nom ldap.illyse.org. Tout devrait alors rentrer dans l'ordre à l'expiration du TTL de l'enregistrement. Si cela ne suffit pas, purger les caches DNS locaux / redémarrer les services.

Défaillance du LDAP maître¶

Retirer l'enregistrement A correspondant au serveur défaillant, pour le nom DNS ldap.illyse.org.

Problème: le LDAP maître est le seul qui permet d'opérer des modification sur l'annuaire.

S'il est vital de faire des modifications sur l'annuaire avant que le LDAP maître n'ait été remis en état, modifier la configuration d'une des répliques pour en faire un nouveau LDAP maître:

• faire une sauvegarde de la conf actuelle (dossier /etc/ldap/slapd.d)
• retirer la directive olcSyncrepl de olcDatabase={1}hdb,cn=config
• configurer le serveur esclave choisi en provider (cf ldap-replica)
• faire pointer le nom DNS ldap0.illyse.org vers le nouveau master
• déposer le certificat et la clé privée de ldap0.illyse.org dans /etc/ldap
• faire pointer les attributs olcTLS* de cn=config vers le certificat et la clé de ldap0.illyse.org

Dès lors, les autres serveurs esclaves doivent utiliser le nouveau serveur maître pour la réplication.

Attention: dans ce cas, au rétablissement du LDAP maître, ses données ne seront plus à jour.La procédure sera alors la suivante:

• laisser le ldap maître temporaire configuré en tant que provider
• relancer le "véritable" ldap maître
• transférer les données (modifiées) du maître temporaire vers le "véritable" serveur maître (copier/coller dans ADS, ou export/import ldif)
• rétablir la configuration DNS d'origine
• reconfigurer le maître temporaire en consumer, rétablir ses certificats

Note: il est également possible de configurer openldap en mode "multi-master", avec plusieurs LDAP maîtres en réplication. Cette gymnastique ne serait alors plus nécessaire, mais d'après la doc, ce mode de fonctionnement garantit moins bien l'intégrité des données que le modèle provider/consumers.