Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

[David Verdin <address@concealed>]

Bonjour et désolé pour cette réponse tardive,

ce message tient lieu de réponse groupée à F. Perrichon et C. Zimmer, qui ont rencontré le même problème.

Effectivement, les précédentes versions de cette fonction géraient mal les erreurs renvoyées par LDAP. Le fait qu'elles acceptent une synchronisation sur le premier niveau alors que le second a échoué en est un effet secondaire fort gênant. On pourrait ainsi se retrouver avec des listes incomplètes, sans avoir d'indice que la requête a échoué.

Suite à ce rapport de bug, nous avons adapté le code de Sympa pour améliorer la gestion des erreurs.

Faites-nous savoir si vous rencontrez toujours ce problème sur des requêtes valides.

Cordialement,

francois.perichon a écrit :

Bonjour,

J'ai compris ce qui faisait échouer certaines de mes sources de données.
Dans les versions précédentes de sympa, je crois que lorsqu'il rencontrait une erreur dans la deuxième série de requêtes, il ne prenait pas en compte la requête problématique et il continuait à traiter la suite des requêtes.

Là, il s'arrête dès qu'il tombe sur une erreur.
Par exemple, dans le log suivant, l'uid 33544 fait bien partie du groupe, mais n'existe pas:

Dec 22 14:06:58 ldapserv slapdtest[19748]: conn=1 op=2 SRCH
base="uid=33544,ou=people,dc=univ-lille2,dc=fr" scope=0 deref=2
filter="(&(objectClass=qmailUser)(accessToService=receivemail))"
Dec 22 14:06:58 ldapserv slapdtest[19748]: conn=1 op=2 SRCH attr=mail
Dec 22 14:06:58 ldapserv slapdtest[19748]: conn=1 op=2 SEARCH RESULT
tag=101 err=32 nentries=0 text=
Dec 22 14:06:58 ldapserv slapdtest[19748]: conn=1 fd=13 closed
(connection lost)

C'est bien comme cela que cela doit fonctionner désormais?

-- 
David Verdin
Comité réseau des universités