Mise en place d’un cluster OpenLDAP avec Corosync / Pacemaker [1/3]

cluster_openldap

Comme je vous l’expliquais il y a quelques jours, j’ai récemment travaillé sur un cluster OpenLDAP à deux nœuds utilisant la réplication OpenLDAP ainsi que Corosync et Pacemaker.

Voici mes notes de travail. Elles me resserviront sans doute ou vous seront peut-être utiles.

Le « tutoriel » est découpé en trois parties :

C’est parti !

Introduction

Une fois n’est pas coutume je travaille sous CentOS 6.4. Fondamentalement peu de choses changent par rapport à Debian hormis le gestionnaire de paquets et une partie de l’arborescence du système de fichiers, notamment au niveau de certains scripts de configuration (je pense au réseau par exemple).

On part donc de deux machines fraîchement installées et à jour. Voici ce que nous aurons, à la fin des trois articles :

La couche SSL n'apparait pas sur le schéma...

La couche SSL n’apparait pas sur le schéma…

Pensez à remplir avec soin le fichier /etc/hosts de chaque machine, l’une pouvant contacter l’autre simplement avec le nom de nœud.

192.168.100.10 ldap
192.168.100.11 ldap1
192.168.100.12 ldap2

Installation et configuration du serveur OpenLDAP

La version disponible dans les dépôts au moment de la rédaction de cet article est la 2.4.23.

  1. Installation des paquets :
    yum install openldap-clients openldap-servers
  2. OpenLDAP fournit un modèle de configuration de base de données apte à fonctionner en production. Nous allons l’utiliser :
    cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
  3. Pour des raisons de sécurité, l’utilisateur ldap est seul propriétaire du dossier /var/lib/ldap :
    chown -R ldap: /var/lib/ldap

Depuis la version 2.4, la configuration d’OpenLDAP a changé et se situe maintenant directement dans l’annuaire, ce qui permet entre autres de la modifier à chaud, sans avoir à redémarrer le service. Heureusement les développeurs d’OpenLDAP sont conscients que de nombreux systèmes vont encore tourner avec l’ancien format de configuration et celui-ci (via un fichier .conf) reste entièrement compatible avec la dernière version d’OpenLDAP.

A cause de contraintes en interne, j’ai dû utiliser cet ancien format de configuration. Je vous propose donc le fichier slapd.conf suivant :

# Global Directives
sizelimit 500
timelimit -1
threads 8
allow bind_v2
loglevel 0
 
# Schemas de l'annuaire
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
 
pidfile		/var/run/openldap/slapd.pid
argsfile	/var/run/openldap/slapd.args
 
# Configuration de la base de donnees
backend		bdb
database	bdb
moduleload	syncprov.la
 
suffix		"dc=guillaume-leduc,dc=fr"
rootdn		"cn=Manager,dc=guillaume-leduc,dc=fr"
rootpw		{SSHA}V+DR1BH5V19abvMxamNkIEKpr4R5ZA0F
 
directory	/var/lib/ldap
 
index objectClass	    eq
index entryUUID             eq
index entryCSN              eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq

Le contenu de la ligne rootpw peut-être obtenu grâce à l’utilitaire slappasswd. Normalement à ce stade votre service OpenLDAP devrait pouvoir démarrer.

service slapd start

Et même s’il est vide pour le moment, vous devriez pouvoir le contacter et faire une petite recherche dessus. Par exemple avec la commande suivante :

ldapsearch -h ldap:/// -D "cn=Manager,dc=guillaume-leduc,dc=fr" -W -b "dc=guillaume-leduc,dc=fr" -s sub "objectclass=*"

Pour pouvoir accéder à notre annuaire avec un client, il va falloir ajouter le contenu racine de notre arborescence : notre domaine et le manager. La manipulation du contenu d’un annuaire se fait avec le format de fichier LDIF. C’est tout simplement un fichier texte formaté de manière standardisée et avec l’extension .ldif.

Voici ce que je vous propose pour démarrer (import.ldif) :

version: 1
dn: dc=guillaume-leduc,dc=fr
objectClass: top
objectClass: organization
objectClass: dcObject
dc: guillaume-leduc
o: guillaume-leduc
description: Moi :)
 
dn: cn=Manager,dc=guillaume-leduc,dc=fr
objectClass: simpleSecurityObject
objectClass: organizationalRole
objectClass: top
cn: Manager
userPassword: {SSHA}V+DR1BH5V19abvMxamNkIEKpr4R5ZA0F

Ici aussi le mot de passe est obtenu avec l’outil slappasswd mais vous pouvez très bien utiliser un mot de passe en clair. Enfin, l’envoi du contenu vers l’annuaire s’effectue très simplement :

ldapadd -h ldap:/// -D "cn=Manager,dc=guillaume-leduc,dc=fr" -W -f import.ldif

Accès au premier annuaire avec un client LDAP

La manipulation d’annuaire LDAP en ligne de commandes n’est pas forcément des plus attirantes. Si vous n’avez que quelques modifications à faire de temps en temps, vous pouvez très bien utiliser un client graphique.

J’ai travaillé avec JXplorer. C’est un client LDAP en Java qui fonctionne donc sur toutes les plateformes et va vous permettre de parcourir et de modifier votre annuaire en toute simplicité.

JXplorer propose aussi des fonctionnalités plus avancées notamment au niveau de la gestion et de l’affichage des classes et schémas utilisés, ou encore l’export / import de portions d’annuaires au format LDIF.

JXplorer_connexion

Coquille sur l’IP de l’hôte, c’est 192.168.100.11 normalement…

Tentez de vous connecter, JXplorer devrait vous afficher la racine de votre annuaire, ainsi que le compte administrateur.

Vous n’avez plus qu’à recommencer cette étape sur le deuxième nœud en conservant une configuration strictement identique, notamment pour les mots de passe, avant de passer à la réplication.

Mise en place de la réplication

Comme tout serveur LDAP qui se respecte, OpenLDAP propose un système de réplication de données à travers plusieurs serveurs afin de mettre en place des solutions de répartition de charge ou de tolérance de pannes. Le résultat visé est donc d’avoir au moins deux serveurs OpenLDAP avec des annuaires strictement identiques à chaque instant. Il va donc falloir configurer un mécanisme de synchronisation entre les serveurs. OpenLDAP en propose deux :

  • Un mécanisme basé sur une architecture maître / esclave : un serveur LDAP est le serveur maître, sur lequel sont effectuées les modifications, et un daemon intitulé sluprd tourne sur ce serveur maître pour transmettre régulièrement les modifications effectuées aux serveurs esclaves.
  • Un mécanisme basé sur une architecture serveurs homologues. Ce mécanisme implémente la RFC 4533 (LDAP Content Synchronization Operation) et fonctionne sans serveur supplémentaire. C’est un thread du daemon slapd lui-même qui agit comme consommateur pour demande à un autre daemon slapd les informations modifiées et les nouvelles valeurs.

C’est cette deuxième méthode que nous allons mettre en place dans la mesure où son alternative avec slurpd tend à devenir obsolète.

Principe de l’architecture

Avec OpenLDAP, le mécanisme de réplication que nous allons mettre en place est directement intégré dans le daemon slapd. Un premier daemon slapd dit consommateur lance le moteur de réplication syncrepl dans un thread. syncrepl se connecte alors à un autre daemon slapd dit fournisseur, charge une première version de l’annuaire et se maintient à jour.

Il existe deux mode de fonctionnement possibles : refreshOnly et refreshAndPersist :

  • Dans le mode refreshOnly, le fournisseur envoie, à la fin de l’opération de synchronisation, un message SearchResultDone, comme lors d’une opération de recherche standard. Le fournisseur arrête le processus de recherche, et syncrepl sur le serveur consommateur s’arrête aussi. Le daemon slapd du serveur consommateur active syncrepl aux intervalles spécifiés pour qu’il interroge le fournisseur.
  • Dans le mode refreshAndPersist, le fournisseur n’envoie pas le message SearchResultDone, et la recherche reste active pour envoyer, au fur et à mesure des modifications, les synchronisations à effectuer. Syncrepl reste actif sur le serveur consommateur en attente de mises à jour envoyées régulièrement par le fournisseur.

Nous allons utiliser le deuxième mode et dans les deux sens ! Chaque nœud sera à la fois fournisseur et consommateur. Ainsi, toute modification sur le nœud 1 le sera sur le nœud 2 et inversement 🙂

Bon je vous l’admets, cela fait beaucoup de blabla mais c’est toujours intéressant de comprendre un minimum ce que l’on fait non ? Bref, passons à la suite …

Création du compte de réplication

Cette étape est facultative mais je préfère utiliser un compte dédié pour la réplication plutôt que le compte administrateur pour des raisons évidentes de sécurité. Je place ce compte dans une OU « management ».

Je vous propose le fichier LDIF suivant, à adapter à vos besoins :

version: 1
dn: ou=Management,dc=guillaume-leduc,dc=fr
objectClass: organizationalUnit
objectClass: top
ou: Management
 
dn: cn=syncuser,ou=Management,dc=guillaume-leduc,dc=fr
objectClass: simpleSecurityObject
objectClass: organizationalRole
objectClass: top
cn: syncuser
userPassword: un_joli_mot_de_passe

Que vous pouvez ajouter sur les deux nœuds avec la commande :

ldapadd –h ldap:/// -x -D "cn=Manager,dc=guillaume-leduc,dc=fr" -W -f syncuser.ldif

Configuration du mécanisme de réplication

Retour vers le fichier /etc/openldap/slapd.conf, à la fin duquel vous pouvez ajouter :

moduleload		syncprov.la

Pour activer le module de réplication,

serverID                1
overlay                 syncprov
syncprov-checkpoint     100 10

Pour la partie fournisseur et

syncrepl rid=001
provider=ldap://ldap2
type=refreshAndPersist
interval=00:00:00:01
bindmethod=simple
timeout=0
network-timeout=0
binddn="cn=syncuser,ou=Management,dc=guillaume-leduc,dc=fr"
credentials="un_joli_mot_de_passe"
attrs="*,+"
starttls=no
filter="(objectclass=*)"
searchbase="dc=guillaume-leduc,dc=fr"
scope=sub
schemachecking=on
retry="10 3 60 +"
mirrormode on

Pour la partie consommateur.

Copiez cette configuration sur le deuxième nœud en modifiant les valeurs serverID (mettre à 2 par exemple) et provider (ldap://ldap1).

Création des règles d’accès (ACL)

Il reste maintenant à autoriser l’utilisateur syncuser à parcourir notre annuaire afin de le dupliquer. Cet utilisateur doit donc avoir des autorisations spéciales. Le contenu suivant est à ajouter dans /etc/openldap/slapd.conf :

access to *
        by dn="cn=syncuser,ou=management,dc=guillaume-leduc,dc=fr" read
        by * none
 
limits dn="cn=syncuser,ou=management,dc=guillaume-leduc,dc=fr"
        size=unlimited
        time=unlimited

Et voilà ! Après un redémarrage du service, toute modification apportée sur l’un des deux annuaires sera automatiquement répliquée en temps réel ! Enjoy 🙂

Si on reprend le schéma du début de l’article, nous sommes rendus ici :

On va dire que le cadre orange représentait la couche SSL...

On va dire que le cadre orange représentait la couche SSL…

Dans le prochain article, nous mettrons en place la couche de chiffrement SSL afin de sécuriser tous nos échanges, même la réplication. On ne va tout de même pas laisser nos mots de passe transiter en clair sur le réseau !

Si vous avez des questions ou si malgré mes nombreuses relectures vous remarquez une coquille n’hésitez pas, les commentaires sont là pour ça !

Notes utiles

Pensez à ouvrir les ports de votre pare-feu

iptables -A INPUT -p tcp --dport 389 -j ACCEPT
iptables -A INPUT -p tcp --dport 636 -j ACCEPT
iptables-saves > /etc/sysconfig/iptables

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email