|
Taille: 11905
Commentaire:
|
Taille: 7269
Commentaire: refonte (calendrier et besoins dans des sous pages)
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| ## page was renamed from Projet/GestionDesUtilisateursDesCampus Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI) * Responsable : SebastienLanteigne * Développeur : OusmaneWilane * Participants : JeanChristopheAndré, SebastienDornano, ThomasNoël, CédricProtière, JérômeSantini... ''et tout le monde intéressé !'' |
|
| Ligne 3: | Ligne 10: |
| (Page en cour de rédaction) Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI) |
|
| Ligne 6: | Ligne 11: |
| * Responsable : SébastienLanteigne * Participants : SebastienDornano, CédricProtière, JeanChristopheAndré, ThomasNoël, JérômeSantini... ''et tout le monde intéressé !'' |
= Objectifs du projet = |
| Ligne 9: | Ligne 13: |
| = Historique du projet = | . '''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.)]] ; . '''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é. |
| Ligne 11: | Ligne 19: |
| * Discussions à Rabat lors de la réunion DRI. Ebauche du cadre du projet : AncienWiki:ReunionDri2005CompteRenduSIGCampus (ancien wiki) * Entre temps, aucun temps libre dans les équipes respectives pour commencer le projet. * Discussions sur la liste tech sur la nécessité de pas laisser tomber ce projet... * La fin de mission de SébastienLanteigne comme responsable technique de l'antenne de Port-Vila (et du CNF associé), son intérêt pour le projet, nous a permis de le conserver "à contrat" pour réaliser le projet. |
Lire aussi la sous-page sur l'["/Besoins" expression des besoins] qui présente quelques autres aspects. Ajoutez-y vos demandes. |
| Ligne 16: | Ligne 21: |
| = Calendrier Prévisionnel = | = Le quotidien du projet = |
| Ligne 18: | Ligne 23: |
| == Phase 1 == * 23 août – 6 Septembre : Sébastien rentre de Port-Vila à Montréal en passant par le CAI de Sofia, le CNF de Tunis et le CNF de Dakar, histoire de compléter les besoins fonctionnels et l'expression des besoins avec la réalité de terrrain de Campus très différents du sien et différents les uns des autres. Voir : AncienWiki:SebastienLMissionSystemGestion (ancien wiki) pour le suivi. * 11 septembre : SebastienLanteigne s'installe à Montréal dans l'équipe informatique pour la réalisation du projet * 11 septembre – 15 septembre : Vidéconférences et compilation des données |
* 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"] |
| Ligne 23: | Ligne 26: |
| == Phase 2 : Développement == * 18 septembre – 6 octobre : Nettoyage du code existant * 9 octobre – 27 octobre : Adaptation et création de nouveaux modules * 30 octobre – 10 novembre : Déploiement de serveurs de tests |
= Idées générales = |
| Ligne 28: | Ligne 28: |
| == Phase 3 : Test, déboguage et documentation == * 13 novembre - 15 décembre : déboguage et transfert du développement ver les ressources internes |
Le système se décompose en trois parties : |
| Ligne 31: | Ligne 30: |
| == Phase 4 : Déploiement == * À définir |
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. |
| Ligne 34: | Ligne 32: |
| == Documentation == La documentation suivante est en cours d'écriture/adaptation/à faire: * Dango sur apache2 avec mod_python (["DjangoModPython"]) * Installation multiple (["DjangoInstallMultiple"]) * Django importer un application (["DjangoAppImport"]) * Authentification d'un poste client sur MySQL (["AuthMySQLClient"]) * Autre docs (à définir) |
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.). |
| Ligne 44: | Ligne 38: |
| == 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. |
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 48: | Ligne 54: |
| 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. | Parfois avec un schéma on voit mieux:: attachment:gestion-utilisateurs-campus.png |
| Ligne 50: | Ligne 56: |
| 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. | (source de ce schéma : attachment:gestion-utilisateurs-campus.dia) |
| Ligne 52: | Ligne 58: |
| * Technologie choisi ? Python, ["Django"], MySQL |
|
| Ligne 55: | Ligne 59: |
| * 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. |
= Description plus détaillée = |
| Ligne 58: | Ligne 61: |
| == Besoins == Suite aux visites faite dans différentes CNF. Certains éléments communs étant directement lié à la gestion des usagers font surface. Nottament: |
== Schéma de la base de données == |
| Ligne 61: | Ligne 63: |
| === Besoins de fonctionnement === * Suivit des opérations : L'application doit offrir un suivit des opérations sur la base. Ajout, modifications, suppressions, etc. (Ce suivit est intégré dans Django) |
Voir /SchemaBase |
| Ligne 64: | Ligne 65: |
| === Besoins === * Création de comptes d'usagers : Évidement il s'agit d'un besoin essentiel à tous nos CNF. Par contre dans certains cas aucun outils (ou des outils pas très ergonomique pour les personnels non technique) ne sont offert. (Besoin présent partout) |
== Le logiciel de gestion de la base == |
| Ligne 67: | Ligne 67: |
| * Suivit d'usagers : À ce niveau le passage à l'IFAG m'a montré un système très poussé, peut être même un peu trop, l'idée est sans doute à reprendre. | 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. |
| Ligne 69: | Ligne 69: |
| * Gestions de groupes : Il ne s'agit pas ici des groupes Unix mais bien de groupes administratif nous permettant de diviser nos utilisateurs de façon plus logique. Ce besoins est présent dans beaucoup de système notamment celui de Tunis. Jérome à Dakar aimerais reprendre cette idée pour pouvoir gérer l'accès aux salles par groupe. (À étudier et intégrer) | 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). |
| Ligne 71: | Ligne 71: |
| * Statistiques : Tous nos CNF ont besoin d'une forme ou autre de statistiques. * Inscriptions : À intégrer * Fréquentation : À modulariser |
== Définition de l'API == |
| Ligne 75: | Ligne 73: |
| * Suivit comptable : Il s'agit ici de générer des pièces comptable directement exploitable. Par exemple une facture à chaque création de compte ou un compte-rendu hebdomadaire ou mensuel des entrés d'argent liées à la création de comtpes. Évoquer par plusieurs dont Cédric Protière à Cotonou. Un rencontre est prévue avec Mme. Nathalie Houle, qui rentre d'une visite de certains CNF, est prévue le mardi 17 octobre à ce sujet. | 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 |
| Ligne 77: | Ligne 77: |
| La rencontre aec Mme. Houle me confirme plus ou moins les demandes de la compta à ce sujet. Ils veulent être en mesure de générer, sur demande, des reçus pour les abonnements. De plus la création de suivit comptable journalier, hebdomadaire ou mensuel est désirable. | <!> Il faut donc définir l'ensemble des fonctions. |
| Ligne 79: | Ligne 79: |
| Le CNF de Tunis me présentait, lors de mon passge, un application utilisé à cet effet. Malheureusement l'application en question n'est pas intégrer au système de gestion de comptes présente au CNF. | == Extensions == |
| Ligne 81: | Ligne 81: |
| === Autres besoins === * Gestions de bibliothèques : Certains CNF ont une sélection d'ouvrage offert aux usagers. À mon avis les outils existant, tel PMB, offre des possibilités intéressant dans ce domaines. La création d'un autre outil est sans doutes inutiles. |
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. |
| Ligne 84: | Ligne 88: |
| * Contrôles des accès web : Encore là les outils existant sont à explorer. Voir SQUID, Squidguard, dansguardian, etc. | Chaque extension proposera aussi de gérer des champs ''extras'' sur les tables. |
| Ligne 86: | Ligne 90: |
| * Réservation : Poste, salle, etc. (Modulariser) == Première proposition de base == === Table user : === Contient toute l'information qui nous sert à identifer une personne. |
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. |
| Ligne 92: | Ligne 92: |
| Commentaires : -Un champ photo? {{{ +-------------+--------------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+--------------+------+-----+------------+----------------+ | u_id | int(11) | | PRI | NULL | auto_increment | | nom | varchar(200) | | | | | | prenom | varchar(200) | | | | | | employeur | varchar(200) | | | | | | profession | varchar(200) | | | | | | adresse | varchar(200) | | | | | | rue | varchar(200) | | | | | | ville | varchar(200) | | | | | | pays | varchar(200) | | | | | | code_postal | varchar(200) | | | | | | tel | varchar(200) | | | | | | tel_tr | varchar(200) | | | | | | cell | varchar(200) | | | | | | email | varchar(75) | | | | | | email_tr | varchar(75) | | | | | | email_2 | varchar(75) | | | | | | naissance | date | | | 0000-00-00 | | +-------------+--------------+------+-----+------------+----------------+ }}} |
== Les systèmes d'extraction == |
| Ligne 118: | Ligne 94: |
| === Table groupe : === Elle contient les groupes ou catégories d'abonnements. {{{ +-------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+----------------+ | id | int(11) | | PRI | NULL | auto_increment | | nom | varchar(100) | | UNI | | | +-------+--------------+------+-----+---------+----------------+ }}} |
À 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. |
| Ligne 129: | Ligne 96: |
| === Table compte : === Contient l'information du compte de l'utilisateur. Ce sont les information normalement présentent dans les fichiers /etc/passwd et /etc/shadow. De plus elle contient également le domaine et l'alias de l'utilisateur. {{{ +--------------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+------------------+------+-----+---------+-------+ | user_id | int(11) | | PRI | 0 | | | login | varchar(200) | | UNI | | | | passwd | varchar(200) | | | | | | uid | int(10) unsigned | | | 0 | | | gid | int(10) unsigned | | | 0 | | | gecos | varchar(200) | | | | | | homedir | varchar(200) | | UNI | | | | minimum | varchar(200) | | | | | | maximum | varchar(200) | | | | | | warn | varchar(200) | | | | | | inact | varchar(200) | | | | | | expire | varchar(200) | | | | | | lastchg | varchar(200) | | | | | | shell | varchar(200) | | | | | | flag | smallint(6) | | | 0 | | | email_domain | varchar(200) | | | | | | email_user | varchar(200) | | | | | | active | tinyint(1) | | | 0 | | +--------------+------------------+------+-----+---------+------- }}} |
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). |
| Ligne 156: | Ligne 98: |
| === Table abonnement : === Contient les données d'abonements (la transaction). Comentaires : -Peut être ajouter un champ création? (pour la création d'abonnements avant leur date de début) {{{ +-----------+---------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------+---------+------+-----+------------+----------------+ | id | int(11) | | PRI | NULL | auto_increment | | user_id | int(11) | | | 0 | | | debut | date | | | 0000-00-00 | | | fin | date | | | 0000-00-00 | | | groupe_id | int(11) | | | 0 | | +-----------+---------+------+-----+------------+----------------+ }}} |
= Calendrier = Voir la sous-page ["/Calendrier"] |
Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI)
Responsable : SebastienLanteigne
Développeur : OusmaneWilane
Participants : JeanChristopheAndré, SebastienDornano, ThomasNoël, CédricProtière, JérômeSantini... 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 CNFFootNote(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.) ;
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"]
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 :
- une interface Web, rapide et ergonomique
- une interface en ligne de commande pour permettre une gestion « système »
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 !)
- Des modules d'extension
- tout ce qu'il faut pour s'adapter aux besoins locaux, pas exemple :
- pour l'intégration au niveau du système d'exploitation :
- extraction des informations vers le système d'authentification local, par exemple :
vers les fichiers /etc/passwd et /etc/shadow, pour un système avec ou sans NIS
- vers une base de données MySQL d'authentification
- extraction des informations vers le système de messagerie local, par exemple :
extraction des informations vers les fichiers /etc/aliases, /etc/postfix/virtual, etc, pour la messagerie
- une base de données MySQL pour la messagerie
- extraction des informations vers un annuaire LDAP
- etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs
- extraction des informations vers le système d'authentification local, par exemple :
- 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, ... enfin tout ce qui n'est pas interdit au nom du respect de la vie privée, c'est à dire finalement plus grand chose.
- pour l'intégration au niveau du système d'exploitation :
- 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) :
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).
Calendrier
Voir la sous-page ["/Calendrier"]