Différences

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

--- fr:openldap [2025/09/21 08:46] – sldap.conf n'est pas si obsolète zatalyz
+++ fr:openldap [2025/09/23 06:55] (Version actuelle) – ça aussi était obsolète dans mon tuto... zatalyz
@@ Ligne 137: / 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 157: / 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)