Re: [sympa-fr] Problème de synchro des listes LDAP avec include_ldap_query: alternance add/remove

[Laurent Spagnol <adresse@cachée>]

Bonjour,

Je suppose que tu utilise OpenLDAP ?

Comment fonctionne ton annuaire ?
Si ton annuaire est en mode "standalone", pas de problème avec l'overlay 
"memberOf"

Le résultat que tu donne fait penser à des requêtes qui arrivent 
alternativement sur un référentiel (pas de problème avec l'overlay 
memberOf) et un réplica (l'attribut est vide).

"memberOf" et "syncrepl" ne font pas bon ménage. Il est indiqué dans la 
doc que ce n'est pas conseillé.

J'ai testé. Au début ça fonctionne. Mais au fil du temps, le contenu de 
memberOf "saute" dans certaines circonstances.

"memberOf" est vraiment très pratique, mais vu que ça ne fonctionne pas 
(bien) avec des réplicas, j'ai contourné le problème.
J'ai ajouté une entrée "memberOf" dans notre propre schéma (on fait ce 
qu'on veut dedans) et j'ai écrit un petit script qui le maintient à jour 
à partir des groupes. Il est exécuté toutes les 5 minutes, ça prend ~ 1 
secondes sur un annuaire de ~ 50000 comptes.

Le résultat est exactement le même qu'avec l'overlay, sauf que c'est pas 
instantané et que "ça marche" ;)

Notre archi LDAP:
- 1 référentiel accessible uniquement pour les rares applications qui on 
besoin d'écrire dedans (changement de mot de passe par exemple). Les 
scripts de synchro / SI tournent sur cette machine.
- des réplicas en mode "syncrepl"
- frontal HA/LB (haproxy) qui tape les réplicas

Cdlt,

LS


Le 02/07/2020 à 12:30, Cédric Archambeau a écrit :
> Bonjour,
>
> Nous préparons notre migration de Mailman à Sympa. Niveau débutant, donc ;-)
> Nous synchronisons nos listes avec des fichiers d'inclusion requêtant 
> sur notre annuaire openldap.
>
> Si nous utilisons *include_ldap_query* avec ce type de requête :
>
>     ...
>     filter (memberOf=cn=[% param.0 %],ou=groupes,o=organisation,dc=fr)
>     attrs mail,displayName
>     scope sub
>     select all
>     ...
>
> à chaque synchro, nous avons une alternance de peuplement et de 
> dépeuplement des listes.
>
> Exemple avec un ttl de 300 sec :
>
>     Jul  1 10:47:17 servername task_manager[42629]: notice
>     Sympa::List::sync_include(Sympa::List <adresse@cachée>) 43
>     users added
>     Jul  1 10:47:17 servername task_manager[42629]: notice
>     Sympa::List::sync_include(Sympa::List <adresse@cachée>) 0
>     users updated
>     Jul  1 10:53:17 servername task_manager[42629]: notice
>     Sympa::List::sync_include(Sympa::List <adresse@cachée>) 43
>     users removed
>     Jul  1 10:53:17 servername task_manager[42629]: notice
>     Sympa::List::sync_include(Sympa::List <adresse@cachée>) 0
>     users updated
>     Jul  1 10:59:17 servername task_manager[42629]: notice
>     Sympa::List::sync_include(Sympa::List <adresse@cachée>) 43
>     users added
>     Jul  1 10:59:17 servername task_manager[42629]: notice
>     Sympa::List::sync_include(Sympa::List <adresse@cachée>) 0
>     users updated
>
>
> A priori la requête renvoie des résultats différents à chaque fois donc 
> (sauf mauvaise interprétation). Pas de souci de connectivité avec 
> l'annuaire.
> Lorsque le peuplement est fait, il est correct.
>
> Nous ne rencontrons *pas* de souci en utilisant la version 2 passes 
> (*include_ldap_2level_query *- requête sur le groupe puis sur chaque 
> membre).
>
> Auriez-vous une idée de l'origine du problème ou d'une piste pour faire 
> fonctionner *include_ldap_query*?
>
> Merci d'avance de votre éclairage.
>
> Cédric Archambeau
> Solidaires Finances Publiques

--
Laurent Spagnol
Administrateur GNU/Linux

Responsable du pôle système
Service réseau et télécom
Direction du Numérique

Université de Reims
Campus du Moulin de la Housse
Bâtiment 3
BP 1039 - 51687 Reims cedex 2

Plan d'accès : https://frama.link/DN-URCA

Tel: +33 3 26 91 88 32
Fax: +33 3 26 91 31 87

https://numerique.univ-reims.fr