Distribution EOLE » Modules » Scribe » eole-sympa

Les configurations des listes sympa sont stockées dans le répertoire : /var/lib/sympa/expl/i-ac-test.fr à partir de modèles visibles dans scribe-backend : https://dev-eole.ac-dijon.fr/projects/scribe-backend/repository/entry/scribe/templates.py?rev=2.7.2%2Fmaster

Une fois générées, elles ne sont plus modifiées sauf les listes "responsables" qui ont besoin du mot de passe du "reader" afin d'accéder à des attributs de l'annuaire non disponibles en connexion anonyme (cf. https://dev-eole.ac-dijon.fr/projects/eole-sympa/repository/entry/posttemplate/05-sympa?rev=2.7.2%2Fmaster#L77).

Il me semble que c'est la ligne suivante qui indique que tout le monde peut écrire :

send public

Si urgent, un gros sed doit pouvoir permettre de modifier ce paramètre pour toutes les listes.

A priori nous n'allons pas créer de code spécifique pour résoudre cette problématique mais il faudrait identifier des modèles cibles de liste qu'il faudra déployer sur les serveurs.

Les différents types de listes sont liés aux groupes du Scribe, on les retrouve dans sympa : https://dev-eole.ac-dijon.fr/projects/eole-sympa/repository/revisions/master/entry/tmpl/topics.conf
Voila la doc du paramètre send

Visiblement, il n'y a pas de notion d'utilisateurs/groupes autorisés autre que les membres de la liste de diffusion !
On pourrait envisager de jouer sur la notion de modérateur ? Mais c'est peut-être pas une bonne idée de déclarer tous les professeurs modérateurs de la plupart des listes ?

Bonjour Joël,

Merci pour ces suggestions et documentation. En espérant qu'elle soit à jour, la page https://itssc.rpi.edu/hc/en-us/articles/360010474552-SYMPA-roles-and-sender-configuration décrit un peu plus en détail les choix du paramètre "send" :

Effectivement, on pourrait utiliser le rôle modérateur et avoir les réglages suivants :

• donner le rôle modérateur à tous les personnels enseignants et administratifs sur toutes les listes

• pour les listes des catégories <classes>, <options> et <groupes> :
  

  send = private
  

  
  Effectivement ce serait bien de réduire l'écriture seulement aux enseignants de la classe mais cela parait compliqué...

• pour les listes des catégories <niveaux>, <resp-classes>, <resp-groupes> et la liste eleves :
  

  send = newsletter
  

• pour les listes des catégories <prof-classes>, <prof-options>, <équipes-pédagogiques>, <services-administratifs> et les listes administratifs et professeurs :
  

  send = editorkey
  

  
  Inconvénients : les élèves ne pourront plus écrire à tous les professeurs de la classe ou option, mais c'est un moindre mal.

Je m'interroge aussi sur la visibilité des adresses de listes dans Roundcube. Ce serait bien que si une liste apparaît pour un utilisateur, il puisse réellement écrire à cette liste. Sympa propose bien un paramètre visibility mais peut-être seulement pour l'interface web ? Et les réglages sont limités et n'incluent pas les modérateurs / propriétaires...

Je reste disponible pour l'échange.
Merci et à bientôt !

Dans l’idée de réviser les paramètres des listes, est-ce que ceux qui suivent ne devraient pas également être modifiés :
- subscribe : actuellement open_notify, pourrait être closed ou auth_notify ?
- invite : actuellement private, pourrait être closed ?
- unsubscribe : actuellement open_notify, pourrait être closed ? (je ne sais pas ce qu’il est possible de faire légalement à ce sujet).

Il me semble que l’attribut visibility n’a pas d’incidence sur la construction du carnet d’adresses dans roundcube.

En reprenant les idées de découpages et de révision des droits présentées précédemment, les listes de types newsletter et editorkey nécessitent une liste de modérateurs.
Dans la proposition, quatre listes de modérateurs sont créées, rassemblant respectivement les membres des groupes LDAP professeurs, edu, dir et adf (administratifs ?). Ces quatres listes sont utilisées pour toutes les listes de diffusion.
N’est-il pas souhaitable de limiter les droits en utilisant des listes de modérateurs plus restreintes ? Cela nécessiterait de contruire des listes de modérateurs plus ciblées pour chaque liste de diffusion ou, a minima, de revoir l’association listes de modérateurs / liste de diffusion (par exemple, ne pas mettre les professeurs en modérateur des listes de type service ?).

Pour certains groupes et donc listes de diffusions, il semble que les souscripteurs et les modérateurs potentiels sont les mêmes ensembles. Pour les listes de diffusions associées à ces groupes, il semble donc possible d’utiliser le type de liste private ou confidential, à moins que ces listes soient utilisées pour diffuser des messages externes ?

Bonjour Benjamin,

Pour les paramètres des listes, je suis d'accord avec toi et je suggère :
- subscribe : closed
- invite : closed
- unsubscribe : closed (de toute façon la synchro se chargera de réabonner...)

Il me semble que l’attribut visibility n’a pas d’incidence sur la construction du carnet d’adresses dans roundcube.

J'ai cherché et je confirme.
Si un utilisateur écrit sur une liste sur laquelle il n'est pas autorisé d'écrire, le mél part mais un message d'erreur arrive peu après.

Pour les modérateurs, on pourrait effectivement chercher à optimiser mais cela pourrait devenir compliqué, avec le risque d'être peu compréhensible pour les utilisateurs.
J'avais commencé à chercher dans cette direction avant de me raviser et de penser à la demande de la DNE : les élèves ne doivent pas pouvoir écrire à des listes.
Pour les personnels administratifs, j'avais pensé tous les inclure, mais ils sont parfois plus nombreux que les enseignants dans un annuaire avec les PsyEN de tout le bassin et les AESH de tout le réseau PIAL.

Merci d'avance et à bientôt !
Laurent

À propos de l’ajout de liste de modérateur, j’ai compris qu’il y a quatre groupes, quatre requêtes séparées, pour des raisons pratiques, dans quatre fichiers.

Ces quatres groupes sont-ils bien modérateurs de toutes les listes ? Est-ce que c’est une simplification ou est-ce que ça correspond à l’usage ? Faut-il prévoir plus de flexibilité dans l’assignation des modérateurs ?

Oui ces personnes doivent avoir le rôle modérateur, car il n'est plus possible d'écrire sur les listes avec le statut abonné.
J'avais proposé 4 groupes / fichiers / requêtes car cela me semblait plus simple à gérer mais il y a peut-être moyen de faire différemment.

Ces groupes sont issus des importations AAF, donc soumis possiblement soumis aux variations des nomenclatures AAF...
D'accord pour déclarer via genconfig.
Est-ce possible d'initialiser avec les 4 valeurs envisagées ?

Merci pour la confirmation. Il me semblait bien les avoir rencontrés dans mes premiers tests. Je suis sur un autre type d’import pour mes tests actuels.

Pour les variables multivaluées, c’est assez compliqué de fournir des valeurs par défaut. Il ne me semble pas non plus aisé, en l’état actuel, de déterminer le type d’import effectué, ce qui pourrait aider à fournir des ensembles de valeur par défaut pour chaque cas. Peut-être qu’on me contredira sur ce point.

Je cherche en ce sens (valeurs en fonction du type d’import). Ça me semble plus sûr de garder une cohérence entre valeurs utilisées et état de l’annuaire.
L’autre piste est l’homogénéisation des groupes quel que soit le type d’import (ajouter les groupes edu, adf et dir manquant généralement hors import AAF).

Benjamin,

Passer par des variables est puissant mais complexifie la mise en place.

Sinon, on peut faire plus simple, avec seulement 2 fichiers de modérateurs :
/etc/sympa/data_sources/ldap-professeurs.incl
/etc/sympa/data_sources/ldap-administratifs.incl

On reste dans la demande de la DNE et cela ne change par fondamentalement le fonctionnement.

Qu'en penses-tu ?

Ça me semble beaucoup plus abordable de se raccrocher à ces catégories de personnes plus génériques.

Pour le moment, dans certains cas, diagnose affiche une erreur tant que la demande https://dev-eole.ac-dijon.fr/issues/37322 n'est pas résolue. De plus, dans ces cas là, certaines listes se retrouvent sans modérateurs.

Bonjour,

Sur plusieurs serveurs, les fichiers incl ne sont pas accessibles par Sympa :

ll /etc/sympa/data_sources/
total 16
drwxr-xr-x  2 sympa sympa  4096 déc.  11 05:46 ./
drwxr-xr-x 14 sympa sympa  4096 juil.  9  2024 ../
-rw-r--r--  1 root  bareos  417 déc.  11 05:46 ldap-9740093H-administratifs.incl
-rw-r--r--  1 root  bareos  414 déc.  11 05:46 ldap-9740093H-professeurs.incl

Corrigé sur nos serveurs par :

chown -R sympa: /etc/sympa/data_sources/

Si cela peut être géré à la mise en place...
Merci !