Re: [sympa-fr] Modification de l'abonnement par lot

[Laurent Spagnol <adresse@cachée>]

Merci pour cette longue réponse détaillée et argumentée :)

Si je comprends bien, c'est pas simple ...

Le plus facile serait de fournir un outil de validation des adresses, à 
utiliser AVANT l'importation par lot. Encore faut-il qu'il existe et 
surtout qu'il soit utilisé ... et là, c'est encore aune autre histoire.

Le plus gênant, ce sont les mises à jour automatiques à partir de 
sources externes. Il s'agit, comme je l'ai dit, de données récupérées à 
partir de requêtes SQL dans les tables de tout un tas de bases de 
données sur lesquelles je n'ai évidemment aucune maîtrise.

Ces tables sont alimentées via des applications plus ou moins bien 
fichues (là non plus je ne maîtrise rien) par des utilisateurs plus ou 
moins consciencieux ...

Il arrive aussi que ces tables soient alimentées à partir de données 
externes: tu as déjà vu la tête ce celles fournies par certaines 
institutions ?

On peut mettre en place tout un tas de trucs en place en marge de Sympa: 
on aura le problème dès qu'une mise à jour sera faite automatiquement 
sur des jeux de données qui sont invérifiables en amont.

Le 16/01/2019 à 15:24, Marc Chantreux a écrit :
> salut Laurent,
>
> Il y a ici deux fragilités:
>
> premièrement: le crash face à une donnée accidentée est une fragilité de
> sympa. une bonne contribution possible est de nous fournir de quoi
> corriger le soucis:
>
> * un échantillon de données le plus petit possible capable de
>    faire crasher sympa

Vu le nombre d'utilisateurs, ça arrive au moins une fois par jour ... le 
problème, c'est que je ne sais jamais qui a fait quoi au moment ou ça 
arrive. J'ai déjà essayé de tracer ça dans les logs, mais j'ai abandonné 
quand mes yeux se sont mis à saigner: j'ai pas loin de 2000 listes et 
50000 utilisateurs ;)

=> je reçoit un mail qui prévient du crash, mais je ne sais pas quelle 
liste est concernée. Voici un échantillon:

***

Le processus task_manager.pl précédent (avec le pid 14355) est mort
brutalement.
Date du crash : 14 Jan 2019  09:35
Erreurs :

Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.
Use of uninitialized value in numeric ge (>=) at 
/home/sympa/bin/task_manager.pl line 1946, <TASK> line 6.

***

Le processus sympa_msg.pl précédent (avec le pid 17760) est mort 
brutalement.
Date du crash : 08 janv. 2019  07:06
Erreurs :

Use of uninitialized value $field in split at 
/home/sympa/bin/Sympa/Spindle/TransformOutgoing.pm line 140.
Use of uninitialized value $field in split at 
/home/sympa/bin/Sympa/Spindle/TransformOutgoing.pm line 140.


Consultez les logs pour plus de détails.

***

Le processus bulk.pl précédent (avec le pid 17763) est mort brutalement.
Date du crash : 08 Jan 2019  06:03
Erreurs :



Consultez les logs pour plus de détails.

***

En fait, il est assez rare que j'obtienne un jeu de données qui pose 
problème: l'utilisateur a rarement conscience qu'il a fait planter 
Sympa, il faut qu'il ai le réflexe de me contacter !

> * un niveau de confidentialité des données
>    * public: nous pouvons utiliser ces données telles que dans les jeux
>      de tests
Pas possible ...

>    * privé: nous nous engageons à ne pas diffuser les informations en
>      l'état. nous altererons les données de manière à reproduire le bug
> * un petit texte nous expliquant la marche à suivre pour reproduire,
> * éventuellement les conclusions d'une première investigation
Donc forger des listes d'adresses bidon qui ont les caractéristiques de 
véritables jeu de données. Effectivement, si vous-vous engagez à ne rien 
diffuser, ça peut se faire. Il faut que j'en parle à notre RSSI.

> secundo: la fragilité des données ... et là on est dans un problème qui
> concerne tout déplacement de données. réponse est la suivante
>
> > - Un script qui fait le ménage dans la base de Sympa et vide la colonne
> > "GECOS" pour les adresses de nos domaines
>
> alors ... perso j'avais tendance à faire en sorte de ne pas "infecter" les
> bases.
Réponse plus haut: vu que certaines listes sont alimentées via des 
sources auxquelles je n'ai pas accès, ce n'est pas possible. Le seul 
moyen d'éviter le problème est de purger carrément et régulièrement 
certaines données certaines données directement dans la base de Sympa.

> j'utilisais un "proxy": un serveur http utilisant directement dancer2
> pour produire des sources nettoyées en appliquant des fixes.
Pour une source de type "requête HTTP" sur un serveur externe, je vois à 
peu près, mais comment on fait pour du SQL ?

> Avantages:
>
> * c'est facile à déployer et a entretenir
> * c'est extensible à merci
> * ca permet de facilement mutualiser/partager du code
> * ca permet d'avoir n machines tiers qui n'est pas sympa et qui a plus
>    de droit dans le SI
>
> Inconvenients:
>
> * ca nécessite de programmer à minima!
>
> bon j'ai parlé de dancer2 parceque je pense que perl est de loin le
> meilleur langage (surtout dans ce genre de cas d'usage) mais évidement,
> un busybox http + cgi (shell, C, ...) ou python+(flask|bottle) sont de
> bonne solutions aussi: l'important c'est que ce soit assez simple et
> souple pour ne pas entrainer plus de problèmes que ca n'en amène.
>
> > - Pour l'abonnement par lot, quand un utilisateur a un problème avec une
> > liste de centaines (voire de milliers) d'utilisateurs, il doit m'envoyer ses
> > données pour que le la passe dans un script de filtrage/validation. Je lui
> > retourne ensuite la liste corrigée. Autant dire que c'est chronophage !
>
> en gros c'est donc la même solution que moi sauf que le filtrage et la
> vérification se font lorsque la source est consultée (via sympa ou par
> un simple navigateur). la chose que j'aurais voulu implémenter c'est de
> permettre aux usagers de déposer les sources dans un repertoire spécial
> des documents partagés pour que ca puisse servir de sources.
>
> > S'il y avait des améliorations à faire, ce serait sur le filtrage et la
> > validation des adresses à tous les niveaux, sans que ça bloque les
> > abonnements & mises à jour et surtout que ça ne fasse pas planter les
> > processus.
>
> D'accord pour le processus ne plante pas mais pourrais-tu décrire un peu
> mieux ce qui devrait être fait? on arrête l'import ? on ignore ? on
> isole ? Dans tous les cas c'est du code en plus est j'aurais tendance a
> dire que l'idée serait plutot d'utiliser un outils tiers de validation
> des données (comme on petit proxy dancer2). D'un autre coté la
> communauté sympa a toujours été d'une imagination débordante donc
> n'hésitons pas à en discuter :)

Avant chaque INSERT/UPDATE (adresse mail ou GECOS), vérifier l'intégrité 
de la donnée. Ignorer simplement les données invalides et envoyer 
éventuellement un mail aux proprios de la liste (avec les adresses 
ignorées) pour prévenir ?

Si tout ce qui touche à l'enregistrement / MAJ est centralisé dans un 
module / fonction, ça ne doit pas être bien compliqué, même en appelant 
un service externe. Mais ça posera un problème de performances si les 
adresses sont vérifiées une par une quand il y en a des dizaines de 
milliers ...

Cdlt,

LS


> a+
> marc

--
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