Les fiches LDAP

Chez moi, une fiche LDAP peut comprendre jusqu’à 4 attributs différents liés au mail :

• mail contient l’adresse « officielle » de l’utilisateur
• mailLocalAddress contient ses alias locaux ; ils seront réécrits et remplacés par la valeur de l’attribut mail en sortie de site
• mailAcceptingAddress contient des alias « en réception seule », typiquement pour les groupes de travail
• mailRoutingAddress contient la destination des messages envoyés aux mailAcceptingAddress et mailLocalAddress de la fiche

En termes de schéma LDAP, nous avons ajouté ça au schéma de base d’OpenLDAP :

attributetype ( 1.3.6.1.4.1.7568.1.1.10
    NAME 'mailAcceptingAddress'
    DESC 'RFC822 alternate email address of this recipient'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

objectclass ( 1.3.6.1.4.1.7568.1.2.2 NAME 'ircamLocalMailRecipient' AUXILIARY
    DESC ''
    MAY ( mailAcceptingAddress ) )

objectclass ( 1.3.6.1.4.1.7568.1.2.10 NAME 'ircamAlias' SUP top STRUCTURAL
    DESC ''
    MAY ( mailRoutingAddress ) )

La classe d’objet ircamAlias ne sert que pour la gestion des alias indépendants des utilisateurs (listes de diffusion et redirections « vers l’extérieur » notamment). Nous allons la laisser de côté pour le moment.
Concrètement, un utilisateur ressemble à ça :

dn: uid=empion, ou=People, dc=example, dc=com
objectClass: account
objectClass: top
objectClass: inetLocalMailRecipient
objectClass: ircamLocalMailRecipient
objectClass: inetOrgPerson
objectClass: pilotPerson
objectClass: ircamAccount
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
objectClass: ircamPerson
uid: empion
mailRoutingAddress: empion@mailboxes.example.com
mailAcceptingAddress: tout-le-monde@example.com
mailAcceptingAddress: groupe-de-travail@example.com
mailLocalAddress: tartempion@example.com
mailLocalAddress: tarte.empion@example.com
mail: Tarte.Empion@example.com
sn: Empion
cn: Tarte Empion
uidNumber: 12345
gidNumber: 333

La configuration de Postfix

Postfix, c’est bien. Si, si. Je sais que vous en êtes déjà convaincus, mais c’est encore une occasion de le dire. Pour utiliser ce qui précède, il suffit de ces quelques lignes de config dans main.cf :

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps = ldap:ldapcanon
ldapcanon_server_host = ldap.example.com
ldapcanon_server_port = 389
ldapcanon_search_base = dc=example,dc=com
ldapcanon_query_filter = (&(mailLocalAddress=%s)(mail=*))
ldapcanon_result_attribute = mail

virtual_maps = ldap:ldapvirt
ldapvirt_server_host = ldap.example.com
ldapvirt_server_port = 389
ldapvirt_search_base = dc=example,dc=com
ldapvirt_query_filter = (|(mailLocalAddress=%s)(mailAcceptingAddress=%s))
ldapvirt_result_attribute = mailRoutingAddress

C’est tout, rien de tordu à faire. Une fois ce bout de config en place, l’adresse source tartempion@example.com sera réécrite en Tarte.Empion@example.com (techniquement, tarte.empion@example.com sera réécrite aussi, mais ça ne fera ni chaud ni froid à la plupart des systèmes de courrier électronique actuels), et les messages envoyés à tarte.empion@example.com, tartempion@example.com, tout-le-monde@example.com et groupe-de-travail@example.com seront renvoyés à empion@mailboxes.example.com (et éventuellement à d’autres si ces mêmes alias sont aussi définis dans d’autres fiches). Elle est pas belle, la vie ?

Les scripts

OK, maintenant on sait à quoi les données peuvent ressembler, mais est-ce qu’il y a un outil plus simple que ldapvi pour les mettre dans l’annuaire ? Oui et non. J’ai bricolé récemment une petite série de scripts pour éditer l’attribut mailAcceptingAddress d’une fiche ; en pratique, c’est le seul qui varie plus ou moins souvent, les autres sont fixés à la création du compte. Les outils en question sont téléchargeables ici. L’archive contient :

• le module ircamldap.py qui initialise quelques variables utiles (serveur LDAP, mot de passe admin…)
• son fichier de configuration ircamldap.cfg
• les scripts add-mail-alias, remove-mail-alias et get-mail-aliases qui font l’essentiel du vrai boulot.

Pour l’utilisation de ces derniers, j’ai essayé de faire assez simple pour mes deux neurones ; en pratique, ça donne ça :

% get-mail-aliases empion
tout-le-monde@example.com
groupe-de-travail@example.com
% add-mail-alias empion monnouvelaliasquilestbien@example.net
% get-mail-aliases empion
tout-le-monde@example.com
groupe-de-travail@example.com
monnouvelaliasquilestbien@example.net
% remove-mail-alias empion monnouvelaliasquilestbien@example.net tout-le-monde@example.com
% get-mail-aliases empion
groupe-de-travail@example.com
%

Pour le moment, ces outils marchent à peu près mais il ne faut pas leur en demander trop. Entre autres, leur gestion des erreurs est assez minimale, et ils ne positionnent pas forcément toujours leur code de retour comme il faudrait. Ce sera pour la prochaine version.

Bien entendu, je suis preneur de toute suggestion, amélioration, patch ou autre « mais t’es con, ça fait 10 ans que ça existe en mieux ».

- Il est bizarre, ton café.
- Normal, c’est une bière. Tu es admin système ou pas ?

Le schéma LDAP

J’ai ajouté un attribut optionnel timePeriod à la classe nagiosHost. Il doit contenir le nom d’une période définie ailleurs dans la config (chez moi elles sont en dur dans localhost.cfg, ça vient de la configuration d’origine de Nagios) ; s’il n’est pas renseigné, on conviendra qu’il vaut 24×7 par défaut.

En langage schéma LDAP, ça se dit comme ça :

attributetype ( 1.3.6.1.4.1.7568.1.1.33 NAME ( 'timePeriod' ) SUP name )

objectclass ( 1.3.6.1.4.1.7568.1.2.12 NAME 'nagiosHost' SUP top AUXILIARY
DESC ''
MAY ( nagiosService $ nagiosName $ timePeriod ) )

Notez que je ne fais pas de différence entre les différents services associés à un hôte, ils sont tous surveillés ou pas en même temps. Dans mon cas ça se justifie, puisque je n’installe qu’une seule application par machine (virtuelle). Si vous avez besoin de surveiller plusieurs services sur la même machine de façon différenciée, je suppose que vous pouvez créer plusieurs fiches LDAP pour la machine en question, mais ça me semble un peu compliqué et ça risque d’avoir des effets de bord pour les autres applications qui s’appuient sur le même annuaire.

Les scripts

Le script gen-nagios-services-hosts de la dernière fois demande quelques modifications minimes pour s’adapter au nouveau schéma. Le patch étant presque aussi long que le script lui-même, voici la nouvelle version directement en ligne.

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.