Evolution #19597
Optimisation Recherche LDAP
0%
Description
Contexte : ~ 20 000 utilisateurs avec ~ 400 groupes
Constat : La recherche d'un usager pour le partage : La recherche est extrêmement longue
Solutions:
1) les champs cn et displayName ne sont pas indexés dans le Ldap
=> rectifier le slapd.conf et en relançant les index (Eole ? )
2) dans apps/user_ldap/lib/access.php (Ligne 710)
il y a une méthode fetchListOfUsers qui fait appel $this->batchApplyUserAttributes($ldapRecords);
si je commente cette ligne le temps de réponse est divisé par 3 et les réponses sont bien envoyées
A priori batchApplyUserAttributes permet de mettre à jour la bdd owncloud des users avec les infos LDAP, sauf que cela est lancé a chaque recherche et du coup ça plombe la recherche
3) core/js/sharedialogview.js une valeur de limit de recherche en dur à 200,
=> a étudier le passage à une valeur plus basse
Christophe
Demandes liées
Révisions associées
ajouter uid displayname email comme attribut de recherche (ref #19597)
patch afin de limiter le scop des recherches à 20 et application de needrefresh (ref #19597)
Historique
#1 Mis à jour par Arnaud FORNEROT il y a environ 7 ans
- Lié à Tâche #19826: Optimisation recherche annuaire ajouté
#2 Mis à jour par Arnaud FORNEROT il y a environ 7 ans
Point 1
Pour eole
https://dev-eole.ac-dijon.fr/issues/19826
#3 Mis à jour par Arnaud FORNEROT il y a environ 7 ans
- Statut changé de Nouveau à En attente d'informations
Je viens de mettre des traces dans fetchListOfUsers
Il ne passe pas dedans dans le cas de la recherche d'un utilisateur pour partage
Après il rentre bien dedans quand on va dans l'écran des utilisateurs.
Du coup je ne crois pas que l'on soit bien au bonne endroit
Je me trompe ?
Après je trouve le filtre bien étrange sur fetchListOfUsers
(&(|(objectclass=inetOrgPerson))(displayName=*)(displayName=*))
batchApplyUserAttributes me semble indispensable
C'est ce qui fait la mise à jour de l'utilisateur en fonction de l'annuaire.
#4 Mis à jour par Christophe LEON il y a environ 7 ans
- Fichier own_ldap.png Voir ajouté
Précision suite a discussion sur IRC
Lors d'une recherche ( chris par exemple ), le filtre généré est le suivant apps/user_ldap/user_ldap.php:getUsers
(&(&(objectclass=ENTPerson))(displayName=*)(|(uid=chris*)(displayName=chris*)(mail=chris*)))L'index sur displayName serait donc en eq,subinitial
NOTE: uid, displayName et mail sont des éléments que nous avons renseignés dans la configuration 
#5 Mis à jour par Arnaud FORNEROT il y a environ 7 ans
- Statut changé de En attente d'informations à Résolu
- Version cible mis à Envole 5.5
#6 Mis à jour par Christophe BRENELIERE il y a environ 7 ans
- Fichier Owncloud_agenda_4.jpg Voir ajouté
- Fichier Owncloud_agenda_3.png Voir ajouté
- Fichier Owncloud_agenda_2.png Voir ajouté
- Fichier Owncloud_agenda_1.png Voir ajouté
La recherche fonctionne correctement si on saisit l'identifiant de l'utilisateur et pas toujours si on saisit une partie du nom (voir images ci-jointes).
Rq : dans la configuration de base d'Owncloud, l'entrée LDAP n'est pas présente.
#7 Mis à jour par Christophe LEON il y a environ 7 ans
Attention la recherche owncloud fait du subinitial sur ldap
Cela signifie qu'il faut saisir le début de uid ou mail mais pas le milieu
En d'autres termes la recherche est
search* et non search
Je ne sais pas si c'est paramétrable si c'est le cas il faut prévoir l'indexation ldap sur du sub et non plus du subinitial
#8 Mis à jour par Arnaud FORNEROT il y a presque 7 ans
- Statut changé de Résolu à Fermé