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

TableOfContents

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.
Des logiciels de gestion de cette base de données
de quoi remplir et gérer la 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 (surcharges), de synchroniser les données avec d'autres systèmes (authentification, messagerie, etc.).
Des systèmes d'extraction vers le système
tout ce qu'il faut pour extraire les données systèmes, pas exemple:

  1. les fichiers /etc/passwd et /etc/shadow pour être utilisés sur un serveur NIS

  2. les fichiers /etc/aliases, /etc/postfix/virtual, etc, pour la messagerie

  3. une base de données d'authentification MySQL
  4. une base de données MySQL pour la messagerie
  5. un arbre LDAP
  6. etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs
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

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.

La programmation objet permet de proposer des extensisons via des surcharges des fonctions.

L'idée est donc d'avoir un système Django/Python qui proposer toute l'API de gestion : ensuite au niveau des applications on n'aura qu'à appeler l'API, sans jamais toucher 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 :

Il faut définir l'ensemble des fonctions.

Chaque fonction sera surchargeable afin d'être adaptée aux conditions locales. Exemple de surcharges possibles :

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

<!> Pour l'instant nous ne savons pas encore quelle forme concrète va prendre cette programmation des surcharges. Idéalement, un répertoire "extensions" dans lequel on placerait des fichiers Django/Python (.py). Ca serait pratique.

Les systèmes d'extraction

A 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 ecrasé pour tel ou tel utilisateur s'il existe un champ extra pour cet utilisateur (voir plus loin la notion de champ extra dans la base de donnée).

Schéma de la base de données

<!> Pour l'instant rien n'est vraiment fixé. C'est pourtant un point capital qu'il faut régler RAPIDEMENT !

Quelques idées générales :

Voir :

Et combiner les idées ici:

<!> Question : ça serait pas mal, vu la configuration du monde universitaire actuel, qu'un abonné soit rattachable à plusieurs organismes :

<!> Réponse :

Calendrier Prévisionnel

Phase 1

Phase 2 : Développement

Phase 3 : Test, déboguage et documentation

Phase 4 : Déploiement

Documentation

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

Mise à jour (et FAQ)

Ou en est le projet ?
Après un retour assez difficile à Montréal j'ai finalement configurer 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éployer aujourd'hui, de gérer les usagers du CNF de PV. Il intègre certaines idées retenus lors de mon passages dans différent CNF. Notamment la gestions des groupes et la création de pièces comptable comme présenté à Tunis. Une collecte des informations d'usagers plus pousser que celui de Port Vila mais moindre que celle de l'IFAG à Sofia. De plus le test basé sur python et Django intègre automatiquement le suivit de transactions comme évoquer par Svetan à Sofia et Jérome à Dakar. Bien qu'un certains retard existe en raison du changement de technologie (le développement en PHP était prévu à l'origine). Le calendrier reste bon. Nous pouvons d'ailleur prendre un peu d'avance sur le déploiment de serveur de tests. Puisque le développement sera fait avec Django nous pouvons déjà déployer le premier test sur quelques serveurs. La procédure est disponible sur la page ["Django"]. De plus il est possible de télécharger le serveur de tests préconfigurer pour VMware.
Technologie choisie
Python, ["Django"], MySQL
Comment développent-on un application pour un CNF sans CNF ?
On le virtualise. Dans le bût de recréer les installations présentent dans nos CNF, l'application est développer 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 existe à http://osti.auf:8000/admin . Le modèle actuellement en place n'est pas à jour par contre je vais essayer de charger la dernière version les mardis et jeudi de chaque semaines.

Expression des besoins

Suite aux visites faite dans différentes CNF. Certains éléments communs étant directement lié à la gestion des usagers font surface. Nottament:

Besoins de fonctionnement

--CédricProtière : d'après la démo, il semblerait que chaque admin puisse mettre en place des groupes d'utilisateurs de l'outil et de spécifier les niveaux de pouvoir qu'il souhaite. Je trouve que c'est très appréciable et correspond aux besoins qu'on peut avoir. 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 2 notions, mais celle de groupe UNIX me paraît essentielle (faire partie du groupe foad ne suffit pas pour pouvoir utiliser windows ou skype, par exemple...)

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

<!> Seb : Est-ce qu'on peut définir la liste exacte des stats demander par l'AUF?

<!> Question : CédricProtière : en quoi consistent les propositions de Mme HOULE ? je crois que nous pouvons participer ici à l'allègement de Coda ! <!> Réponse: En un simple rapport montrant les nouveaux abonnements pour une période donné. Montrant l'abonement, sa durée et le prix payer. Très semblable au rapport fait par le système de Jérome à Dakar.

Autres besoins