Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:openldap [2025/09/20 21:12] – [Overlays] zatalyz
+++ fr:openldap [2025/09/23 06:55] (Version actuelle) – ça aussi était obsolète dans mon tuto... zatalyz
@@ Ligne 52: / Ligne 52: @@
 Ce qui est dans le dossier ''cn=config'' concerne... la configuration. Autrefois il y avait un fichier "/etc/ldap/sldap.conf", si je comprend bien ce n'est plus trop d'actualité. Mais on n'édite pas directement les ldif ici, il faut passer par l'utilitaire ldapmodify.
-Dans la suite du document, nous allons donc écrire nos documents "ldif", puis les injecter dans l'annuaire avec cette commande "ldapmodify". Il est conseillé de bosser dans un répertoire dédié (par exemple ''/root/ldap/conf/'') histoire de tout nettoyer à la fin avec un petit "rm -R". Ou de garder trace des bidouilles effectuées.
+Dans la suite du document, nous allons donc écrire nos documents "ldif", puis les injecter dans l'annuaire avec cette commande ''ldapmodify''. Il est conseillé de bosser dans un répertoire dédié (par exemple ''/root/ldap/conf/'') histoire de tout nettoyer à la fin avec un petit "rm -R". Ou de garder trace des bidouilles effectuées.
-<WRAP center round tip 100%>
-En fait, LDAP étant un vieux dinosaure utilisé très largement, l'usage de "/etc/ldap/sldap.conf" reste possible. C'est cependant déconseillé et considéré comme une pratique obsolète depuis la version 2.3. L'usage du fichier de configuration "sldap.conf" demande un redémarrage du service à chaque modification, alors que la modification de la configuration dans l'arbre ldap lui-même (via ces fichiers ldif dans "cn=config" est immédiatement pris en compte.
+===== Initialiser LDAP =====
+La méthode officielle consiste à modifier ldap à chaud (sans le redémarrer), en intervenant directement dans sa base via des commandes comme ''ldapmodify'' et ''ldapadd''. Et il faut impérativement utiliser cela, mais la syntaxe et le fonctionnement peuvent piquer les yeux (et c'est rien de le dire). Auparavant, on utilisait ''/etc/ldap/sldap.conf'' et on peut encore voir son écriture dans ''/usr/share/doc/slapd/examples/slapd.conf''((En tout cas sur Debian Bookworm.)). Et c'est tellement plus lisible...
+En fait, LDAP étant un vieux dinosaure utilisé très largement, l'usage de "/etc/ldap/sldap.conf" reste possible telle quelle. C'est cependant déconseillé et considéré comme une pratique obsolète depuis la version 2.3. L'usage du fichier de configuration "sldap.conf" demande un redémarrage du service à chaque modification, alors que la modification de la configuration dans l'arbre ldap lui-même (via ces fichiers ldif dans "cn=config") est immédiatement pris en compte.
 Cela semble anodin lors des tests, mais un gros annuaire peut mettre beaucoup de temps à redémarrer... Alors autant prendre l'habitude des bonnes pratiques, même si la syntaxe pique les yeux.
-</WRAP>
+On peut essayer de combiner le meilleur des deux mondes en paramétrant le fichier slapd.conf, puis en le transformant en ldif via la commande ''slaptest''. Cette méthode permet avant tout de vérifier si la syntaxe de nos ldif est adaptée à notre version actuelle de ldap. C'est utile pour relire et apprendre. Mais il y aura certainement des ldif qui seront à copier tel quel ou presque. Dans ce cas, il restera alors à injecter ces ldif (via ''ldapadd'' ou ''ldapmodify'') dans l'annuaire. Attention, autant ça devrait marcher sur un serveur vierge, autant ça semble plutôt risqué sur un serveur déjà rempli, et dans tout les cas, évitons d'y aller de façon trop bourrine.
+Les commandes de barbare :
+<code>
+# Convertir slapd.conf en fichiers ldif
+slaptest -f slapd.conf -F /tmp/ldif/
+# Injecter un fichier ldif dans l'annuaire
+ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/ldif/cn=config.ldif
+# etc pour chaque ldif dans l'arbre
+</code>
+On peut séparer les données (le peuplement de l'annuaire) de la configuration avec l'option ''-n''.
+<code bash>
+# Générer les ldif de la configuration seulement
+slaptest -f slapd.conf -F /tmp/ldif_config/ -n 0
+# Générer les ldif des données seulement
+slaptest -f slapd.conf -F /tmp/ldif_data/ -n 1</code>
@@ Ligne 116: / Ligne 137: @@
 Puis on redémarre rsyslog :
   sudo systemctl restart rsyslog
+</WRAP>
+===== Un peu de syntaxe (en vrac) et autres trucs trouvés au fil de l'exploration =====
+<WRAP center round todo 60%>
+Cette partie va être un gros brouillon pour le moment, je grappille dans les documentations. Mais autant noter ce que je trouve, je rangerais pus tard !
+</WRAP>
+==== Indexation ====
+Pour faire des recherches efficaces dans l'annuaire, mieux vaut bien paramétrer l'indexation((Cf [[https://www.openldap.org/doc/admin26/tuning.html#Indexes]]. On va indiquer à OpenLDAP que certaines entrées sont à indexer (et comment) pour éviter qu'il scanne tout (vraiment tout) à chaque recherche.
+J'ai trouvé ça dans un slapd.conf :
+<code>index		objectClass	eq
+index		cn		eq,sub
+index		sn		eq,sub
+index		uid		eq
+index		mail		eq
+index		memberOf	eq
+</code>
+Cela liste les attributs sur lequels faire les recherches, limiter ça aux plus pertinent. Trop d'index ralentit l'écriture. Par exemple, pas besoin de ''sn'' chez nous, cette info ne nous intéresse pas ; possible que le mail non plus (pas dans les recherches globales en tout cas). Les types d'index sont les suivants :
+  * eq : égalité (recherche exacte)
+  * sub : Recherches partielles (avec joker)
+  * pres : déconseillé à utiliser dans la doc, et j'ai pas compris ce que ça faisait vraiment
+  * approx : "approximatif", semble aussi assez foireux.
+Les index doivent être créé avant de peupler l'annuaire, sinon il faut le reconstruire :
+<code>
+sudo systemctl stop slapd
+sudo slapindex
+sudo chown -R openldap:openldap /var/lib/ldap/
+sudo systemctl start slapd
+</code>
+Et comme dit plus haut, redémarrer un ldap actif peut être très, très long suivant sa taille...
+Cependant l'usage des index est à utiliser avec discernement. La construction des index prend de la place sur l'espace disque, et on peut quand même chercher dans les données non indexées (par exemple faire une recherche sur "ou"). On indexe quand il y a beaucoup d'entrées (par exemple quelques milliers d'UID => là ça devient vital), qu'on fait régulièrement des recherches dessus, voir qu'on utilise des filtres un peu compliqués dans les recherches. Pas besoin quand il y a moins de 1000 entrées ou sur les trucs qu'on cherche rarement.
+<WRAP center round tip 60%>
+La blague étant donc que je saurais réellement ce que je dois indexer une fois que mon annuaire sera utilisé et donc peuplé. Il reste donc à trouver les bons index avant que la base ne grossisse trop, afin d'éviter une opération de maintenance trop longue...
 </WRAP>
@@ Ligne 136: / Ligne 194: @@
   * ''ppolicy'' : politique de mots de passe (complexité, expiration, verrouillage)
   * ''constraint'' : ajoute des contraintes sur les attributs, pour éviter de rentrer n'importe quoi (et donc de mettre en pseudo un truc qui va faire cracher les cms). Cela peut être des contraintes du type "une membre doit renseigner un mail" ou "si Untelle est membre de //sysadmin//, alors elle doit avoir renseigner aussi son téléphone"
-  * ''valsort'' : ordonne les résultats. Par exemple renseigner certains groupes (genre les assos) avant d'autres (genre les sous-groupes d'assos).
 Ceux où je ne sais pas encore quand ce sera utile (mais ça le sera très certainement à un moment)