Supervision d’un annuaire LDAP
[Nagios] Vérification du statut de la réplication OpenLDAP
Présentation
Le script slurpd_status.pl analyse les fichiers utilisés par slurpd, le serveur de réplication d’OpenLDAP. Un minimum d’explications sur le fonctionnement de slurpd est nécessaire pour comprendre la manière dont agit le script de supervision :
Le mécanisme de réplication permet de propager des modifications effectuées sur un annuaire, dit « maître », vers un autre annuaire, dit « esclave ». L’annuaire maître est donc le référentiel et concentre toutes les opérations d’écriture, les modifications parviennent ensuite à ou aux annuaires esclaves.
 Première étape : une opération d’écriture est réalisée sur l’annuaire maître (1A). Le processus slapd enregistre la modification dans l’annuaire maître (1B) et l’inscrit dans son fichier replog (1C).
Deuxième étape : le processus slurpd vérifie régulièrement le fichier replog de slapd (2A) pour voir si des modifications sont en attente de réplication. Quand il en trouve, il les copie dans son fichier replog (2B) et les efface du fichier replog de slapd (2A).
Troisième étape : le processus slurpd analyse son fichier replog et tente de propager les modifications à l’annuaire esclave concerné. Si l’annuaire esclave n’est pas accessible, ou si l’identifiant ou le mot de passe de l’utilisateur de la réplication sont incorrects, la modification demeure dans le fichier replog de slurpd et aucune action n’est faite. Si la connexion à l’esclave fonctionne (3A), l’opération est propagée. Si l’annuaire esclave a accepté la modification (3B), le fichier statut est mis à jour avec la date et le rang de la dernière entrée acceptée (3C), sinon le fichier de rejet spécifique à l’annuaire esclave est rempli avec l’opération qui a échoué et le message d’erreur renvoyé par l’esclave (3E), et le fichier statut est également mis à jour avec la date et le rang de la dernière opération rejetée (3D).
Régulièrement : le processus slurpd lit la date présente dans le fichier de statut et tente de propager à l’annuaire esclave toutes les opérations contenues dans son fichier replog qui sont plus vieilles que la date précédemment relevée. Il s’agit en général des entrées non transmises pour cause de connexion refusée par l’annuaire esclave. Il est clair par contre qu’une entrée rejetée par l’annuaire esclave (et donc stockée dans le fichier de rejet) n’est jamais repropagée par slurpd. En outre les plus anciennes entrées déjà propagées sont supprimées du fichier replog de slurpd.
Il y a donc 4 fichiers importants à analyser pour connaître le statut de la réplication :
Le fichier replog de slapd : il contient les modifications enregistrées sur l’annuaire maître mais pas encore récupérées par slurpd.
Le fichier replog de slurpd : il contient les modifications qui se trouvaient dans le fichier replog de slapd et qui ont été récupérées par slurpd.
Le fichier de statut : chaque ligne de ce fichier contient l’adresse et le port d’un annuaire esclave, ainsi que la date et le rang de la dernière modification acceptée ou rejetée.
Le fichier de rejet : il est spécifique à un esclave et contient les modifications rejetées.
Les modifications, appelées aussi entrées de réplication, peuvent donc se trouver dans 4 états différents :
en transition : Les entrées sont dans le fichier replog de slapd, donc en transition entre slapd et slurpd.
en attente : Les entrées sont dans le fichier replog de slurpd et possèdent une date plus élevée que celle inscrite dans le fichier de statut. Cela signifie que slurpd n’a pas encore eu le temps de les envoyer à l’esclave, ou que l’esclave n’est pas disponible, ou encore que l’identifiant ou le mot de passe de réplication utilisés sont incorrects.
rejetées : Les entrées se trouvent dans le fichier de rejet. La cause de l’erreur est indiquée au début de chaque entrée.
propagées : Les entrées ont été acceptées par l’esclave. Elles restent temporairement dans le fichier replog de slurpd jusqu’à ce que celui-ci les efface.
Le script de supervision slurpd_status.pl comptabilise les entrées se trouvant dans les trois premiers états cités. Les alertes Ok, Warning ou Critical sont envoyées selon les seuils spécifiés en paramètres d’entrée du script.
Pré-requis
Les modules Perl suivants sont utilisés par le script, ils doivent être installés sur la machine sur laquelle il sera hébergé :
Le module Getopt::Std
La fonction max() du module List::Util
L’utilisateur exécutant le script doit avoir accès en lecture aux fichiers listés dans le paragraphe précédent. L’exécution du script en mode debug permet de le vérifier.
Attention : l’activation des droits de lecture sur les fichiers concernés peut ne pas suffir, il faut également s’assurer que l’utilisateur a le droit de franchir les répertoires menants au fichier (le droit d’exécution doit être postionné sur ces répertoires).
Usage
Le script s’utilise ainsi :
./slurpd_status -w warning_level -c critical_level [-h hostname] [-p hostport] [-v]
Les paramètres obligatoires sont :
warning_level et critical_level : ce sont les valeurs au-dessus desquelles une alerte de type Warning ou de type Critical est envoyée. Cette valeur peut être définie de deux façons :
- soit par une liste de trois entiers séparés par des virgules (ex : 100,3,60). Le premier numéro correspond au seuil des entrées en transition, le deuxième aux entrées rejetées et le dernier aux entrées en attente.
- soit par un entier seul, qui correspondra au seuil du maximum des trois types d’entrées. En d’autres termes, si le nombre d’entrées en transition, rejetées ou en attente dépasse cette valeur, une alerte sera envoyée.
Les paramètres facultatifs sont :
hostname : adresse IP ou nom du serveur esclave, comme indiqué dans la configuration d’OpenLDAP, à la ligne replica du fichier slapd.conf (par défaut). Si ce paramètre n’est pas renseigné, la valeur "localhost" sera utilisée.
hostport : port du serveur esclave, comme indiqué dans la configuration d’OpenLDAP, à la ligne replica du fichier slapd.conf (par défaut). Si ce paramètre n’est pas renseigné, la valeur "0" sera utilisée : en effet, lorsque slurpd constate qu’aucun port n’est déclaré pour le serveur esclave, il utilise la valeur "0" dans ses propres fichiers.
L’option -v active le mode debug. Elle affiche un grand nombre de messages et ne doit donc pas être activée lorsque le script est rattaché à Nagios.
Exemple :
./sluprd_status.pl -w 30,2,10 -c 100,5,30 -h slave.linagora.com -p 389
Remarque : Le fichier de configuration OpenLDAP pour cet exemple contiendrait :
replica host=slave.linagora.com:389
binddn="uid=replicateur,o=linagora,c=com"
bindmethod=simple
credentials=secret
Configuration interne au script
Le script a de fortes chances de ne pas fonctionner si les paramètres internes ne sont pas modifiés. Il faut alors éditer le script et changer la valeur des variables :
$slurpd_tempdir : c’est le répertoire dans lequel slurpd stocke ses fichiers. Dans une installation d’OpenLDAP par défaut, ce répertoire est /var/openldap-slurp/replica/.
$slapd_replog_file : Localisation du fichier replog de slapd, comme indiqué dans le fichier de configuration d’OpenLDAP à la ligne replogfile. Dans une installation d’OpenLDAP par défaut, ce fichier est /var/replog.
%code : table de hachage contenant les codes de retour de Nagios. À moins d’une reprogrammation totale de Nagios, elle ne doit pas être modifiée.
Intégration dans Nagios
Un tutoriel spécifique décrit les manipulations nécessaires à l’intégration de ce script dans Nagios. Il est clair qu’il faut définir autant de services différents qu’il y a d’esclaves différents indiqués dans la configuration de l’annuaire OpenLDAP maître.
Pour exécuter ce script sur des hôtes distants, il est conseillé de passer par la commande check_by_ssh ou d’utiliser NRPE.
2004 (c) Clément OUDOT
Script Perl - Remplacer l’extention .txt par .pl après le téléchargement.
|