Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI)

TableOfContents

Avancement du code

Le développement du code de l'application se passe sur un trac/subversion ici : http://trac.sn.auf.org/guia (serveur hébergé à Dakar avec parfois quelques soucis de routage ou d'électricité en ce moment).

Discussions, propositions

Objectifs du projet

Idées générales

Le système se décompose en trois parties :

Une base de données
elle décrit l'ensemble des utilisateurs et des abonnements associés. Elle doit avoir un schéma de base simple, correspondant au noyau dur du système, mais également autoriser une intégration simple de modules d'extension.
Un moteur de gestion
de quoi remplir et gérer cette base de données, notamment :
  1. une interface Web, rapide et ergonomique
  2. une interface en ligne de commande pour permettre une gestion « système »

  3. plus tard, une application native pour Gnome ou KDEFootNote(La tendance est à l'inverse, c'est à dire la migration de tous les outils vers des technologies web, et je doute qu'il y ait un retour en arrière de si tôt !)

Cette application sera adaptable en fonction des contraintes locales. Par exemple elle sera capable, via des extensions, de synchroniser les données avec d'autres systèmes (authentification, messagerie, etc.).
Des modules d'extension
tout ce qu'il faut pour s'adapter aux besoins locaux, pas exemple :
  1. pour l'intégration au niveau du système d'exploitation :
    1. extraction des informations vers le système d'authentification local, par exemple :

      1. vers les fichiers /etc/passwd et /etc/shadow, pour un système avec ou sans NIS

      2. vers une base de données MySQL d'authentification
    2. extraction des informations vers le système de messagerie local, par exemple :

      1. extraction des informations vers les fichiers /etc/aliases, /etc/postfix/virtual, etc, pour la messagerie

      2. une base de données MySQL pour la messagerie
    3. extraction des informations vers un annuaire LDAP
    4. etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs
  2. pour la gestion de fonctionnalités additionnelles :
    1. saisie, suivi et statistiques sur les commandes de documents primaires
    2. gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
  3. attachement d'informations diverses et variées autour des utilisateurs :
    1. leurs commandes, leurs emprunts, leurs dates d'anniversaire, leurs passions, ... enfin tout ce qui n'est pas interdit au nom du respect de la vie privée, c'est à dire finalement plus grand chose.
Parfois avec un schéma on voit mieux
attachment:gestion-utilisateurs-campus.png

(source de ce schéma : attachment:gestion-utilisateurs-campus.dia)

Description plus détaillée

Schéma de la base de données

Voir /SchemaBase

Le logiciel de gestion de la base

En utilisant un système comme Django, on simplifie la programmation (validation des données, interfaçages). Une fois l'ensemble des fonctions de gestion définies (l'API), elle est disponible directement via Python, on peut donc l'utiliser dans de nombreux cas : outils en ligne de commande, scripts, cron, etc.

L'idée est donc d'avoir un système Django/Python qui proposera toute l'API de gestion. Ensuite au niveau des applications on n'aura qu'à appeler l'API, sans jamais accéder directement à la base de données (pas de requête SQL directe).

Définition de l'API

L'API est l'ensemble des fonctions qui vont permettre de faire toutes les opérations nécessaires sur la base de données. Par exemple (non-contractuel) :

<!> Il faut donc définir l'ensemble des fonctions.

Extensions

Les fonctions du moteur de base seront extensibles afin d'être adaptées aux conditions locales. Exemple d'extension possibles :

Un ensemble d'extensions sera proposé par défaut recouvrant le maximum de besoins. Chaque extension disposera d'un fichier de configuration de base.

Chaque extension proposera aussi de gérer des champs extras sur les tables.

<!> Pour l'instant nous ne savons pas encore quelle forme concrète va prendre cette programmation des extensions. Idéalement, un répertoire « extensions » dans lequel on placerait des fichiers Django/Python (.py), et des hooks au niveau des fonctions de l'API standard qui appeleront les extensions à certains endroit... Quelque chose comme ça... Quelque chose de facile à installer.

Pour se donner des idées, voir la gestion des modules Python : http://docs.python.org/tut/node8.html On doit pouvoir s'en sortir très élégament grâce à ça.

Les systèmes d'extraction

À partir d'un système comme Django, on peut extraire les données assez facilement via des templates. Pour la plupart des extractions il ne sera pas nécessaire à l'administrateur système de savoir programmer en Python.

Chaque système d'extraction disposera d'un fichier de configuration par défaut. Par exemple pour un système qui générera le fichier /etc/passwd via une extraction, on indiquera le shell par défaut. Ce shell par défaut pourra être éventuellement écrasé pour tel ou tel utilisateur s'il existe des informations spécifiques pour cet utilisateur (voir plus loin la notion de champ extra dans la base de donnée).

Calendrier

Phase 1

Phase 1,5

Phase 2 : Développement et Documentation

Phase 3 : Déploiement Pilote, Test, Déboguage

Phase 4 : Déploiement

Documentation

La documentation suivante est en cours d'écriture/adaptation/à faire :

Mise à jour (et FAQ)

Où en est le projet ?
Après un retour assez difficile à Montréal j'ai finalement configuré mon environnement de travail et monté un test largement basé sur la configuration du CNF de Port Vila. Le test en question est fonctionnel et permettrait, s'il était déployé aujourd'hui, de gérer les usagers du CNF de Port Vila. Il intègre certaines idées retenus lors de mon passages dans les différents CNF. Notamment la gestion des groupes et la création de pièces comptable comme présenté à Tunis. Une collecte des informations sur les usagers plus poussée que celle de Port Vila mais moindre que celle de l'IFAG à Sofia. De plus le test basé sur python et Django intègre automatiquement le suivi des transactions comme évoqué par Svetan à Sofia et Jérome à Dakar. Bien qu'un certain retard existe en raison du changement de technologie (le développement était prévu en PHP à l'origine). Le calendrier reste bon. Nous pouvons d'ailleurs prendre un peu d'avance sur le déploiement de serveurs de tests. Puisque le développement sera fait avec Django nous pouvons déjà déployer les premiers tests sur quelques serveurs. La procédure est disponible sur la page ["Django"]. De plus il est possible de télécharger un serveur de tests pré-configuré pour VMware.
Technologie choisie
Python, ["Django"], MySQL
Comment développe-t'on une application pour un CNF sans CNF ?
On le virtualise. Dans le bût de recréer les installations présentes dans nos CNF, l'application est développée sur un serveur Debian GNU/Linux "Sarge" 3.1 présent dans un réseau virtuel sous VMware serveur.
Est-ce que je peux voir où on en est ?

Oui. Un modèle est visible sur http://osti.auf:8000/admin/ . Le modèle actuellement en place n'est peut être pas à jour mais je vais essayer de charger la dernière version lorsqu'il y aura des changements nottable.

Expression des besoins

Suite aux visites faites dans différents CNF. Certains éléments communs étant directement liés à la gestion des usagers font surface. Notamment :

Besoins de fonctionnement

De plus, lors de la visio avec Sébastien, nous avions abordé le fait que les utilisateurs du CNF doivent pouvoir modifier eux-même certains paramètres :

Besoins

<!> Commentaire: CédricProtière : je suis également preneur des groupes UNIX : lorsqu'un utilisateur fait partie d'un groupe "administratif", il doit être possible de le mettre aussi dans un groupe UNIX du même nom (ou du nom UNIXifié). On peut éventuellement séparer ces deux notions, mais celle de groupe UNIX me paraît essentielle (faire partie du groupe foad ne suffit pas pour pouvoir utiliser Windows, par exemple...) -- ThomasNoël : à faire via la notion d'abonement à des groupes. au niveau de l'extraction ça sera transformé en certains groupes Unix, si besoin.

<!> Commentaire: CédricProtière : + toutes les statistiques demandées par l'AUF (nombre de sites web, nombre de revues commandées, nb de mails reçus/envoyés...) devraient pouvoir être consultées/modifiées (avec états par mois, trimestre, année) - prévoir à ce propos un module d'upload des infos sur le wiki ou sur une bdd auf centrale (afin d'automatiser totalement les statistiques ou de permettre de remonter ou consulter plus facilement ces infos) <!> JC : prévoir plutôt un module d'extraction ; le reste se fera plus simplement via des scripts. -- ThomasNoël : tout "betement" des templates Django... ils permettent de faire très très facilement ce genre de synthèse, même par des gars qui ne savent pas programmer en Django. Ca ressemble à des templates spip, d'ailleurs. <!> Seb : Est-ce qu'on peut définir la liste exacte des stats demander par l'AUF ? -- ThomasNoël : voir déjà ce qui est demandé aux CNF par SQI, y'a pas mal de trucs.

<!> Question : CédricProtière : en quoi consistent les propositions de Mme HOULE ? je crois que nous pouvons participer ici à l'allègement de Coda ! <!> Note de JC : pas de Coda, car on n'y entre pas de si petites sommes une par une, mais effectivement le travail de la comptable via un état de caisse automatisé. <!> Réponse: En un simple rapport montrant les nouveaux abonnements pour une période donné. Montrant l'abonement, sa durée et le prix payé. Très semblable au rapport fait par le système de Jérome à Dakar.

Autres besoins

-- ThomasNoël : pour ça, faudrait surtout trouver comment contrôler vraiment les impressions. Depuis 10 ans que je joue avec des imprimantes réseaux, j'ai jamais rien vu de costaud non surbidouillé... -- Sébastien Lanteigne: Oui. Correctement, non. Le problèmes c'est la gestion des bourrages, les pages blanches, etc. Analyser le log ça donne des résultats mais quand une impression de 10 pages bloque à la deuxième page on retrouve quand même 10 pages dans le log. Comme le dis Thomas c'est 'borderline' bidouille.