Stocker la configuration de Nagios dans un annuaire LDAP

August 25, 2009 by nono
Catégories geekeries - Mots-clés LDAP Nagios

À ma gauche, un serveur Nagios. À ma droite, un annuaire LDAP. Le but de la manoeuvre est de générer automatiquement la configuration du premier à partir du deuxième. L'intérêt de la chose : s'assurer que le serveur Nagios est toujours à jour et surveille bien ce qu'il doit (étant entendu que l'annuaire LDAP est lui-même tenu à jour, ce qui devrait être le cas).

Tout ça s'applique à Nagios 2.x ; je l'utilise simplement parce que c'est la version immédiatement installable sur mon OS de prédilection (CentOS 5 avec EPEL). Je n'ai pas regardé à quoi ressemblait Nagios 3 mais j'imagine que les principes sont facilement adaptables.

Vue d'ensemble

Je suis parti de la configuration par défaut dont j'ai gardé trois fichiers : nagios.cfg, localhost.cfg et cgi.cfg, auxquels j'ai juste apporté les quelques modifications nécessaires pour les adapter à mon installation locale. La seule partie que je vais détailler est la liste des inclusions au début du fichier nagios.cfg, qui ressemble à ça :

# host and service definitions for monitoring this machine
cfg_file=/etc/nagios/localhost.cfg
# human-maintained parts, if any
cfg_dir=/etc/nagios/admin
cfg_dir=/etc/nagios/hosts
cfg_dir=/etc/nagios/services
# script-generated parts
cfg_file=/etc/nagios/commands.cfg
cfg_file=/etc/nagios/hosts.cfg
cfg_file=/etc/nagios/services.cfg

Le premier fichier, localhost.cfg, provient tel quel de la distribution Nagios. Les répertoires admin, hosts et services sont là au cas où je voudrais ajouter des bouts de config à la main. Les trois derniers fichiers sont générés par les scripts dont on va parler dans la suite.

Les commandes

Définitions

Une commande, au sens Nagios, se compose d'un nom (le paramètre command_name dans le fichier de config) et d'une ligne de commande (le paramètre command_line). J'ai donc ajouté une classe regroupant ces deux attributs à mon schéma LDAP. J'ai aussi crée un attribut command qui n'existait pas. Au final, ça donne ça :

attributetype ( 1.3.6.1.4.1.7568.1.1.32 NAME ( 'command' ) SUP name )
objectclass ( 1.3.6.1.4.1.7568.1.2.15 NAME 'nagiosCommand' SUP top STRUCTURAL
DESC 'Nagios command definition'
MUST ( cn $ command )
MAY ( description ) )

Données

Une fois le schéma à jour, une commande se définit comme ça :

dn: cn=check_ldap,ou=commands,ou=nagios,ou=tools,dc=ircam,dc=fr
objectClass: nagiosCommand
objectClass: top
cn: check_ldap
command: $USER1$/check_ldap -H $HOSTADDRESS$ -b dc=ircam,dc=fr -3

Pour ceux que ça intéresse, j'ai bricolé un bout de script Perl pour convertir le fichier commands.cfg d'origine au format LDIF ; il est disponible ici. Attention, il ne fonctionnera pas sur un fichier qui n'est pas écrit comme le commands.cfg d'origine de Nagios (disposition différente des espaces ou autres variantes du genre).

Génération

Maintenant qu'on a nos commandes dans l'annuaire, il suffit de les relire pour générer le fichier commands.cfg. Je fais ça avec ce script Python.

Le serveur et le DN de base LDAP y sont codés en dur, promis, dans la prochaine version, je mets des options. :-)

Les machines et les services

Dans mon esprit, les machines et les services « vont ensemble » ; je génère donc les fichiers hosts.cfg et services.cfg en même temps.

Définitions

Un service Nagios, tout comme une commande, est défini avant tout par un nom et une commande à exécuter (la commande en question n'a rien à voir avec celles du paragraphe précédent, mais peu importe, on n'a pas besoin de définir un attribut LDAP différent). Il doit aussi avoir une description (pas peut, doit, sinon Nagios râle très fort). Dans mon cas, les autres options (contacts, périodicités et autres) sont communes à tous les services et codées en dur dans le script de génération. Encore une fois, on verra dans la prochaine version pour une approche plus propre.

Une machine, quant à elle, est définie par un nom d'hôte, une adresse IP (tous deux définis dans la classe d'objet ipHost), une liste de services et éventuellement un alias qui apparaîtra dans l'interface web. Tout comme pour les services, tout le reste est pour le moment défini en dur dans le script de génération.

En termes de schéma LDAP, ça nous donne ça :

attributetype ( 1.3.6.1.4.1.7568.1.1.28 NAME ( 'nagiosService' ) SUP name )
attributetype ( 1.3.6.1.4.1.7568.1.1.29 NAME ( 'nagiosName' ) SUP name )
objectclass ( 1.3.6.1.4.1.7568.1.2.14 NAME 'nagiosServiceType' SUP top STRUCTURAL
DESC 'Nagios service definition'
MUST ( cn $ command $ description ) )
objectclass ( 1.3.6.1.4.1.7568.1.2.12 NAME 'nagiosHost' SUP top AUXILIARY
DESC ''
MAY ( nagiosService $ nagiosName ) )

Données

Maintenant qu'on sait ce que sont un service et une machine, on peut en ajouter dans l'annuaire. Il y a quelques bricoles pas strictement indispensables pour nous dans ce qui suit ; l'annuaire LDAP ne sert pas que pour Nagios. :-)

dn: cn=ldap,ou=services,ou=nagios,ou=tools,dc=ircam,dc=fr
objectClass: nagiosServiceType
objectClass: top
cn: ldap
command: check_ldap
description: LDAP
dn: cn=ldap4.ircam.fr,ou=virtuels,ou=Hosts,dc=ircam,dc=fr
cn: ldap4.ircam.fr
ipHostNumber: 129.102.6.196
objectClass: top
objectClass: device
objectClass: ircamDevice
objectClass: ieee802Device
objectClass: bootableDevice
objectClass: ipHost
objectClass: nagiosHost
nagiosService: ldap

Génération

On utilise le petit frère du script précédent. Il crée deux fichiers hosts.cfg et services.cfg dans le répertoire courant sans se poser de questions ; attention à ne pas effacer de données importantes !

Servez chaud !

En cadeau puisque vous êtes sages, le bout de Makefile qui va bien pour utiliser tout ça :

all:
/usr/local/sbin/gen-nagios-hosts-services
/usr/local/sbin/gen-nagios-commands > commands.cfg
/bin/chmod 0644 hosts.cfg services.cfg commands.cfg
/sbin/service nagios restart

La semaine prochaine, si j'ai le temps, vous aurez la classe puppet qui va avec. :-)

Edit 26/08/2009 : la description des services est obligatoire.