Re: [sympa-fr] Problème aléatoire de listes "sans propriétaires" (via API SOAP)

[David Verdin <adresse@cachée>]

Sympa est notoirement mal documenté.

Pour retrouver la valeur limite, j'ai dû aller consulter les sources.

On tombe tellement rarement sur le cas que documenter cette valeur n'est pas en haut de la pile des 264 trucs qu'on a à faire sur le logiciel...

Mais il faut qu'on corrige ça.

En revanche, ta liste ne devrait pas être créée du tout, preuve qu'il manque un contrôle dans Sympa. Je pense qu'elle était créé mais, en base de donnée, tronquée. Et du coup on ne retrouvait pas le propriétaire puisqu'on le cherchait avec la valeur non tronquée.

Bref, un bug.

On va y travailler.

Bonne journée !

David

On 30/09/2020 12:16, Dornbusch Joachim wrote:

Merci pour cet éclairage David.

Hypothèse validée.

>> >> c.create_list_from_trusted_app("ue1061-test-un-nom-de-50-caracte-pour-david-verdin", "la description de cette liste", 'listsem', 'description longue de la liste', 'EHESS')
=> true
>> >> c.create_list_from_trusted_app("ue1062-test-un-nom-de-51-caracter-pour-david-verdin", "la description de cette liste", 'listsem', 'description longue de la liste', 'EHESS')
=> true

Seule la première des deux listes est créée.

Faut avouer que c'est trompeur :

- l'API SOAP répond "true"

- les logs et les emails de notification aux admins se plaignent de listes sans propriétaire, ce qui est une fausse piste.

Le client utilisé (https://rubygems.org/gems/mail-sympa/versions/1.2.0 ) ne semble pas en cause, apparemment c'est le retour API qui manque un peu de lisibilité.

Quand à la longueur maximale, j'ai cherché un peu dans la doc au départ et je n'ai pas trouvé l'info, j'ai peut-être mal cherché !

Merci infiniment en tout cas ! La solution est triviale maintenant.

Joachim

---

De: "Dornbusch Joachim" <adresse@cachée>
À: adresse@cachée
Envoyé: Mercredi 30 Septembre 2020 11:09:38
Objet: Re: [sympa-fr] Problème aléatoire de listes "sans propriétaires" (via API SOAP)

Bonjour David

Merci beaucoup pour cette aide précieuse.

Je me concentre sur le bogue  de création de listes, le plantage de l'interface apparaissant pour l'instant secondaire.

Je ne suis pas admin de Sympa, je n'ai accès que via l'API et l'interface utilisateur.

Mais un des administrateurs système vient de m'envoyer un extrait des logs qui pourrait bien expliquer mon problème.

Il s'agit d'un échec de requête SOAP envoyé par une instance de développement de l'application cliente. L'utilisateur a donc mon mail ('adresse@cachée').

Au départ il y avait quelques warning sur le chargement de la conf (pbs de sauts de lignes et paramètre en double) mais il les a corrigés et cela ne résout pas le problème : voici ce que nous obtenons au final.

Sep 30 10:59:50 atacama soap[12894]: sympasoap::authenticateRemoteAppAndRun() authenticateRemoteAppAndRun(listsem,adresse@cachée,createList,ue1059-geometries-phenomenologies-vivant-le-a-b-c-d-e,la description de cette liste,listsem,description longue de la liste,EHESS)
Sep 30 10:59:50 atacama soap[12894]: sympasoap::createList() SOAP createList(list = ue1059-geometries-phenomenologies-vivant-le-a-b-c-d-e\@ehess.fr,subject = la description de cette liste,template = listsem,description = description longue de la liste,topics = EHESS) from adresse@cachée via proxy application listsem
Sep 30 10:59:50 atacama soap[12894]: admin::check_topics() admin::check_topics(EHESS,ehess.fr)
Sep 30 10:59:50 atacama soap[12894]: List::new() The list "ue1059-geometries-phenomenologies-vivant-le-a-b-c-d-e" has got no owner defined
Sep 30 10:59:50 atacama soap[12894]: List::set_status_error_config() The list "ue1059-geometries-phenomenologies-vivant-le-a-b-c-d-e" is set in status error_config
Sep 30 10:59:51 atacama soap[12894]: admin::install_aliases() admin::install_aliases : Aliases installed successfully

Par contre, avec un nom court comme  "ue1060-geometries-phenomenologies" ça passe.

Sep 30 11:03:44 atacama soap[10283]: sympasoap::createList() SOAP createList(list = ue1060-geometries-phenomenologies\@ehess.fr,subject = la description de cette liste,template = listsem,description = description longue de la liste,topics = EHESS) from adresse@cachée via proxy application listsem
Sep 30 11:03:44 atacama soap[10283]: admin::check_topics() admin::check_topics(EHESS,ehess.fr)
Sep 30 11:03:44 atacama soap[10283]: admin::install_aliases() admin::install_aliases : Aliases installed successfully

Voici le template listsem

## Configuration de la liste sympa-l
## Cree le Mercredi 31 Mars 99
#send editorkey

subject [% subject %]

status [% status %]

visibility conceal

[% FOREACH o = owner -%]
owner
  email [% o.email %]
  profile privileged
  [% IF o.gecos -%]
  gecos [% o.gecos %]
  [% END -%]

[% END -%]

send private

[% IF topics -%]
topics [% topics %]
[% END -%]

web_archive
access private

archive
access owner
period week

max_size 15242880

remind owner

info private

subscribe closed

digest 1,4 13:26

review owner

shared_doc
d_edit default
d_read public

pictures_feature off

creation
date_epoch [% creation.date_epoch %]
date       [% creation.date %]
[% IF creation_email -%]
email      [% creation_email %]
[% END -%]

Merci beaucoup pour ton aide !

Joachim

---

De: "David Verdin" <adresse@cachée>
À: adresse@cachée
Envoyé: Mercredi 30 Septembre 2020 09:32:54
Objet: Re: [sympa-fr] Problème aléatoire de listes "sans propriétaires" (via API SOAP)

Bonjour Joachim,

Il y a plusieurs choses dans ton message. On va essayer de les traiter indépendamment.

1- le problème de création de liste

De ce que tu as écrit, il ressort que ta liste est bien créée par la requête SOAP. Le seul problème est que le propriétaire n'est pas provisionné.

Est-ce que, d'aventure, tes propriétaires ne seraient pas provisionnés depuis un référentiel externe, genre LDAP ou SQL ? Dans certaines versions de Sympa, ça posait problèe parce que Sympa essayait de charger la lsite avant d'avoir effectué la requête, et du coup se retrouvait sans propriétaire au moment du chargement.

Ce serait bien que tu nous donne les logs de sympasoap.fcgi quand tu crées une liste à problème.

Autre chose : pourrait-on voir le fichier config.tt2 que tu emploies, pour comprendre le rapport entre la lettre isolée en fin de nom de liste et le problème de chargement.

2- L'erreur Sympa sur la liste des listes

Cette erreur correspond à un timeout du serveur web lors de l'affichage de la liste des listes. C'est juste que recharge la liste des listes lui prend trop de temps.

Il y a plusieurs optimisation possibles, mais ça dépend de ta version de Sympa.

Celle qui marche sur toutes les version 6, c'est le cache en base de données. Il faut donner la valeur "on" au paramètre "db_list_cache" dans sympa.conf, puis jouer la commande "sympa.pl --sync_list_db".

Bonne journée,

David

On 30/09/2020 05:48, Dornbusch Joachim wrote:

Bonjour

Nous gérons des listes Sympa via une nouvelle application (organisation de l'enseignement en présentiel/distanciel) qui passe par l'API SOAP.

Un template spécifique a été défini pour les listes gérées par cette appli.

Je ne sais pas si cela vient de ce nouveau template ou d'une demande d'allongement des noms des listes, mais il se trouve que pour certaines listes, pas pour toutes, la création échoue depuis peu, pile quand on approchait de la mise en production, pas de chance.

C'est un peu aléatoire.

L'administrateur de Sympa reçoit ceci :

Aucun propriétaire défini pour la liste ue169-a-distance-initiation-a-l-histoire
Le statut de la liste a été positionné à error_config.
Consultez les logs de Sympa pour plus de précisions.

Avec des caractères isolés à la fin du listname (par exemple "ue1055-geometries-phenomenologies-vivant-le-a-l"), je reproduis le problème à tout coup. Quand je reproduis le problème, la fois suivante où je veux recharger la "liste des listes" en tant qu'utilisateur connecté (CAS) propriétaire des listes de l'appli, la page met très longtemps à s'afficher et au final j'ai :

Server error!
The server encountered an internal error and was unable to complete your request.
Error message:
Premature end of script headers: wwsympa.fcgi
If you think this is a server error, please contact the webmaster.
Error 500

Mais ça le fait une seule fois. Ensuite le fonctionnement redevient normal. Mais la liste "sans propriétaire" n'est pas visible pour moi. Si j'essaye de la recréer via SOAP, j'ai "List already exists".

J'ai vérifié, le webservice répond "true" à la requête SOAP de création même dans les cas d'échec.

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soap:Body><authenticateRemoteAppAndRunResponse xmlns="urn:sympasoap"><result xsi:type="xsd:boolean">true</result></authenticateRemoteAppAndRunResponse></soap:Body></soap:Envelope>

La requête SOAP envoyée par notre appli a l'air elle aussi tout à fait normale.

<?xml version="1.0" encoding="utf-8" ?>
<env:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <n1:authenticateRemoteAppAndRun env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:n1="urn:sympasoap">
      <appname xsi:type="xsd:string">listsem</appname>
      <apppassword xsi:type="xsd:string">*********************</apppassword>
      <vars xsi:type="xsd:string">adresse@cachée</vars>
      <service xsi:type="xsd:string">createList</service>
      <parameters xmlns:n2="http://schemas.xmlsoap.org/soap/encoding/"
          n2:arrayType="xsd:anyType[5]"
          xsi:type="n2:Array">
        <item xsi:type="xsd:string">ue1056-geometries-phenomenologies-vivant-le-a-l</item>
        <item xsi:type="xsd:string">la description de cette liste</item>
        <item xsi:type="xsd:string">listsem</item>
        <item xsi:type="xsd:string"> </item>
        <item xsi:type="xsd:string"> </item>
      </parameters>
    </n1:authenticateRemoteAppAndRun>
  </env:Body>
</env:Envelope>

Je vous remercie pour votre aide, on est bien embêtés, ça fait partie du dispositif de rentrée.

Bonne journée

Joachim Dornbusch
Direction des Systèmes d'Information
54 boulevard Raspail, 75006 Paris

-- 
"Mieux vaut viser la perfection et la rater que viser la médiocrité et l'atteindre."
- Francis Blanche

David Verdin
Chef de Projet Collaboratif
Département PROduits NUMériques
Direction des Services Applicatifs
RENATER - Rennes
              
            
          
          
        
      
    
-- 
"Mieux vaut viser la perfection et la rater que viser la médiocrité et l'atteindre."
- Francis Blanche

David Verdin
Chef de Projet Collaboratif
Département PROduits NUMériques
Direction des Services Applicatifs
RENATER - Rennes

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature