Distribution EOLE » Outils Eole » SSO » EoleSSO

L'académie de Besançon a remonté des problèmes d'instabilité du service SSO sur leur serveur Seshat.

Des problèmes équivalents semblent également survenir dans une moindre mesure à la Réunion (Christophe a mis en place une surveillance régulière du service pour le relancer en cas d'arrêt).

message de Sylvain Dubuisson après étude du problème:

Bonjour,

Voici les dernieres nouvelles de mes recherches sur les pb OTP avec seshat (eole-sso) de Besançon.
Le problème ne peut clairement pas être résolu simplement chez nous. Il est necessaire de repenser la manière dont l'authentification OTP est faite par eole-sso pour que l'application puisse supporter des charges importantes.

J'ai ajouté avant et après pam.authenticate() un log.msg pour voir le nombre d'authentification et le temps qu'elles prennent.
Nous sommes à 2 à 3 secondes pour une authentification OTP.
Nous sommes à 140-160 demandes d'authentification OTP par heure sur les périodes où nous subissons les segfault/plantage.
Dès arret du serveur, nous perdons les tickets de session dans le serveur eole-sso ce qui provoque une vague de nouvelle ré-authentification donc un nouveau segfault de l'application.
Nous sommes à plus de 100 connexions OTP par heure sur le serveur en journée de notre coté. (en cette période, nous avons des enseignants qui utilisent Sconet Notes en passant par notre portail d'authentification unique)

Le segfault se fait systématiquement dans le module pam_securid.so. Ce module n'est chargé qu'une seule fois en mémoire par le module pam de python qui est lui même présente une seule fois en mémoire. (c'est par conception que çà se passe comme çà)
La librairie pam_securid.so ne supporte pas deux appels concurrents. Lors du deuxième appel, un segfault se produit au moment de la tentative de nettoyage de la mémoire par la librairie.
Apparemment le module supporte d'être chargé plusieurs fois en mémoire et exécuté plusieurs fois en parallèle mais je n'ai pas de moyen de le tester.

J'ai tenté d'utiliser le module threading.Lock() de Python pour gérer/réguler les accès concurrents et n'est obtenu comme résultat que des désynchronisations de clé OTP lié au temps de déblocage du verrou.

Les solutions possibles après cette analyse sont de mon point de vue :
- L'utilisation des fonctions avancées de Python/Twisted pour limiter à un appel à la fois sur pam
- La séparation dans un processus séparer de l'authentification OTP pour éviter la propagation au cache des tickets de eole-sso
- La mise en place d'un multichargement en python de la librairie pam_securid.so pour permettre les demandes simultanées
Ceci nécessite de toute façon de forte compétence en Python, programmation multithreadé et gestion des accès concurrents et compréhension des mécanismes d'appel de fonction.

C'est aujourd'hui un probleme important dans notre académie qui a mis en place ce portail uniquement qui ne supporte pas une charge importante sur l'authentification OTP.