Modifications entre les versions 42 et 49 (s'étendant sur 7 versions)

Ce projet a pour but d'écrire un système gestion des utilisateurs d'une implantations AUF (CNF, CAI, bureau, antenne... ou toute autre implantation où il y a des utilisateurs).

Responsable : ThomasNoël
Développeur principal : OusmaneWilane
Participants : JeanChristopheAndré, JérômeSantini, SebastienLanteigne... et tout le monde intéressé !

Objectifs du projet

Objectifs du projet : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des implantations AUF ;
Résultats attendus :
- faciliter le travail des gestionnaires en automatisant le plus grand nombre de tâches répétitives, longues ou complexes, progressivement (via l'ajout de nouveaux modules) ;
- simplifier le travail de tous en factorisant les soucis : les problèmes ne seront plus locaux, ils seront plus simples à résoudre si tout le monde fonctionne un peu de la même façon au départ ;
Contraintes : l'existant est très varié (NIS, passwd, LDAP, Samba, ...) et il faut donc prévoir toutes sortes de particularités locales (services purement locaux, campus intégré, etc.), d'où l'importance de la modularité.

Lire aussi la sous-page sur l'[:/Besoins: expression des besoins] qui présente quelques autres aspects. Ajoutez-y vos demandes.

Le quotidien du projet

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).
Les discussions ont lieu sur la sous-page ["/Discussion"]

Vue générale

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

Le noyau

il s'agit d'une base de donnée et un ensemble de fonctions permettant d'y accéder.

la base de données décrit l'ensemble des utilisateurs et des abonnements associés. Elle a un schéma de base simple, correspondant au noyau dur du système. Elle autorise une intégration simple de modules d'extension (greffons) via des champs extra sur ses objets. Voir /SchemaBase.
l'accès à la base est écrit en Python/Django. Chaque objet de la base est donc visible sous la forme d'un objet Python disposant de méthodes permettant de le gérer. L'appel à ces méthodes effectue les actions nécessaires sur la base de données. Là encore, chaque méthode peut être surchargée par des greffons.

Des interfaces

dans un premier temps une interface Web, rapide et ergonomique, permettant d'effectuer des actions sur la base. Django fourni une interface d'administration calculée automatiquement à partir de la définition des objets. Il faut la faire un peu évoluer pour la rendre plus ergonomique.
puisqu'il est écrit en Django, le noyau est accessible directement en Python. D'autres interfaces sont donc programmables, telle qu'une interface en ligne de commande.

Des greffons (modules d'extension, ''plug-ins'')

ils sont chargés, à partir d'informations fournies par le noyau, de gérer les aspects «métier», par exemple :

vers une base de données MySQL d'authentification (["/Greffons/NssMySQL"])
vers une base MySQL pour la messagerie (["/Greffons/Postfix"]-MySQL)
pour la gestion de fonctionnalités additionnelles : saisie, suivi et statistiques sur les commandes de documents primaires ; gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
attachement d'informations diverses et variées autour des utilisateurs : leurs commandes, leurs emprunts, leurs dates d'anniversaire, leurs passions, ...

Parfois avec un schéma on voit mieux

attachment:gestion-utilisateurs-campus.png

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

Documentations

La documentation détaillée du code est ici : ["/Code"]
La documentation d'installation et d'intégration... reste à écrire : ["/MiseEnPlace"]

Calendrier

Voir la sous-page ["/Calendrier"]

-  ⇤ ← Version 42 à la date du 2006-11-28 11:30:48 → 
  Taille: 7269
  Éditeur: ThomasNoël
  Commentaire: refonte (calendrier et besoins dans des sous pages)
+   ← Version 49 à la date du 2006-12-15 15:32:07 → ⇥
  Taille: 4042
  Éditeur: JérômeSantini
  Commentaire: lien vers la page greffon postfix
-Texte supprimé.
+Texte ajouté.
 Ligne 1:
-## page was renamed from Projet/GestionDesUtilisateursDesCampus
Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI)
+Ce projet a pour but d'écrire un système gestion des utilisateurs d'une implantations AUF (CNF, CAI, bureau, antenne... ou toute autre implantation où il y a des utilisateurs).
-Ligne 4:
+Ligne 3:
- * Responsable : SebastienLanteigne
 * Développeur : OusmaneWilane
 * Participants : JeanChristopheAndré, SebastienDornano, ThomasNoël, CédricProtière, JérômeSantini... ''et tout le monde intéressé !''
+ * Responsable : ThomasNoël
 * Développeur principal : OusmaneWilane
 * Participants : JeanChristopheAndré, JérômeSantini, SebastienLanteigne... ''et tout le monde intéressé !''
-Ligne 13:
+Ligne 12:
- . '''Objectifs du projet''' : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des CNF[[FootNote(Il serait même envisageable d'utiliser ce système sur n'importe quel serveur gérant un ensemble d'utilisateurs, à condition que le noyau dur des fonctionnalités soit le plus léger possible.)]] ;
+ . '''Objectifs du projet''' : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des implantations AUF ;
-Ligne 19:
+Ligne 18:
-Lire aussi la sous-page sur l'["/Besoins" expression des besoins] qui présente quelques autres aspects. Ajoutez-y vos demandes.
+Lire aussi la sous-page sur l'[:/Besoins: expression des besoins] qui présente quelques autres aspects. Ajoutez-y vos demandes.
-Ligne 23:
+Ligne 22:
- * 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).
+ * 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).
-Ligne 26:
+Ligne 25:
-= Idées générales =
+= Vue générale =
-Ligne 30:
+Ligne 29:
- 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.
+ Le noyau:: il s'agit d'une base de donnée et un ensemble de fonctions permettant d'y accéder.
  * la base de données décrit l'ensemble des utilisateurs et des abonnements associés. Elle a un schéma de base simple, correspondant au noyau dur du système. Elle autorise une intégration simple de modules d'extension (greffons) via des champs ''extra'' sur ses objets. Voir /SchemaBase.
  * l'accès à la base est écrit en Python/Django. Chaque objet de la base est donc visible sous la forme d'un objet Python disposant de méthodes permettant de le gérer. L'appel à ces méthodes effectue les actions nécessaires sur la base de données. Là encore, chaque méthode peut être surchargée par des greffons.
 
 Des interfaces:: 
  * dans un premier temps une interface Web, rapide et ergonomique, permettant d'effectuer des actions sur la base. Django fourni une interface d'administration calculée automatiquement à partir de la définition des objets. Il faut la faire un peu évoluer pour la rendre plus ergonomique.
  * puisqu'il est écrit en Django, le noyau est accessible directement en Python. D'autres interfaces sont donc programmables, telle qu'une interface en ligne de commande.
-Ligne 32:
+Ligne 37:
- Un moteur de gestion:: de quoi remplir et gérer cette base de données, notamment :
  1. une interface Web, rapide et ergonomique
  1. une interface en ligne de commande pour permettre une gestion « système »
  1. --(plus tard, une application native pour Gnome ou KDE)--[[FootNote(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 greffons (modules d'extension, ''plug-ins''):: ils sont chargés, à partir d'informations fournies par le noyau, de gérer les aspects «métier», par exemple :
  * vers une base de données MySQL d'authentification (["/Greffons/NssMySQL"])
  * vers une base MySQL pour la messagerie (["/Greffons/Postfix"]-MySQL) 
  * pour la gestion de fonctionnalités additionnelles : saisie, suivi et statistiques sur les commandes de documents primaires ; gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
  * attachement d'informations diverses et variées autour des utilisateurs : leurs commandes, leurs emprunts, leurs dates d'anniversaire, leurs passions, ...
-Ligne 38:
+Ligne 43:
- 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
    1. vers une base de données MySQL d'authentification
   1. 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
    1. une base de données MySQL pour la messagerie
   1. extraction des informations vers un annuaire LDAP
   1. etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs
  1. pour la gestion de fonctionnalités additionnelles :
   1. saisie, suivi et statistiques sur les commandes de documents primaires
   1. gestion de la caisse, via une gestion de reçus et un état de caisse mensuel
  1. 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.
-Ligne 58:
+Ligne 48:
+= Documentations =
-Ligne 59:
+Ligne 50:
-= 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) :
 . {{{utilisateur::ajouter(nom, prénom, age, genre, organisme, login, mot_de_passe)}}} pour ajouter un utilisateur
 . {{{utilisateur::abonner(login, service, date_début, date_fin)}}} pour abonner un utilisateur à un service

<!> 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 :
 * ''NSS-MySQL'' permettant de mettre à jour une table NSS-MySQL en parallèle : à chaque ajout/modification/suppression d'un abonnement, on met à jour une table MySQL à part, dédiée à l'authentification ;
 * ''Postfix'' pour le système de messagerie afin de mettre à jour en temps réel des tables pour Postfix ;
 * ''mkdir'' pour créer le répertoire d'un utilisateur sur un serveur distant (via ssh) lors de sa création
 * etc.
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.

Voir sur le [http://trac.sn.auf.org/guia serveur trac] la branche d'Ousmane pour avoir une idée de la programmation Python/Django de tout cela.

== 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).
+ * La documentation détaillée du code est ici : ["/Code"]
 * La documentation d'installation et d'intégration... reste à écrire : ["/MiseEnPlace"]

WikiTeki / Modifications de « Projet/GUIA »

Objectifs du projet

Le quotidien du projet

Vue générale

Documentations

Calendrier