|
Taille: 4845
Commentaire:
|
Taille: 1719
Commentaire: chaque utilisateur peut être dans pls organismes, avec plusieurs fonctions éventuellement
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| Voici mes (ThomasNoël) idées et propositions pour le système de gestion des utilisateurs. | Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs. |
| Ligne 3: | Ligne 3: |
| = Rappels = | = Les utilisateurs = |
| Ligne 5: | Ligne 5: |
| . '''Objectifs du projet''' : unifier nos systèmes d'authentification et nos outils de suivi des utilisateurs des CNF. . '''Résultats attendus''' : 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 fort (NIS, passwd, LDAP, Samba, ...) et il faut prévoir toute sorte de particularités locales (services purement locaux, campus intégré, etc.) |
Table utilisateurs:: . id . login . mot_de_passe . courriel . nom . prénom . genre . date_naissance . adresses . téléphones . commentaires |
| Ligne 9: | Ligne 18: |
| = Idées générales = | Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') . valeur |
| Ligne 11: | Ligne 23: |
| Le système se décompose en trois parties : | = Les groupes = |
| Ligne 13: | Ligne 25: |
| Une base de données:: elle décrit l'ensemble des utilisateurs et des abonnements associés. Elle doit avoir un schéma simple mais permettant de multiples extensions. Voir ci-dessous pour ma proposition de structure. | Table groupes:: . id . nom . commentaires |
| Ligne 15: | Ligne 30: |
| Des logiciels de gestion de la base de données:: de quoi remplir et gérer la 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, un application native pour Gnome ou KDE |
Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 20: | Ligne 35: |
| 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 1. les fichiers {{{/etc/aliases}}}, {{{/etc/postfix/virtual}}}, etc, pour la messagerie 1. une base de données d'authentification MySQL 1. une base de données MySQL pour la messagerie 1. un arbre LDAP 1. etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs |
= Les abonnements = |
| Ligne 28: | Ligne 37: |
| = Le logiciel de gestion de la base = | Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. |
| Ligne 30: | Ligne 39: |
| En utilisant un système comme Django, on simplifie la programmation. Le mode objet devrait permettre de proposer des extensisons assez facilement. En outre, l'API de gestion étant disponible en Python, on peut l'utiliser directement pour écrire les outils en ligne de commande sans ré-inventer la roue. | Table abonnements:: . id_utilisateur . id_groupe . date_debut . date_fin . commentaires |
| Ligne 32: | Ligne 46: |
| 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). | = Les organismes = |
| Ligne 34: | Ligne 48: |
| = Les systèmes d'extraction = | Ils sont hiérarchisés (arbre simple : un parent peu avoir plusieurs fils). |
| Ligne 36: | Ligne 50: |
| 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. | Table organismes:: . id . nom . adresses . telephones . id_organisme_parent : pointe vers un id_organisme (0 pour la racine) . commentaires |
| Ligne 38: | Ligne 58: |
| = Schéma de la base de données = | Table organismes_extra:: . id_organisme . variable . valeur |
| Ligne 40: | Ligne 63: |
| == Idées générales == | Chaque utilisateur peut être rattaché à un ou plusieurs organismes. A chaque rattachement on indique la fonction de l'utilisateur dans l'organisme, via un triplet { utilisateur, organisme, fonction }. On peut donc imaginer qu'un utilisateur puisse avoir plusieurs fonctions au sein d'un organisme. |
| Ligne 42: | Ligne 65: |
| * des utilisateurs, des groupes et des abonnements qui permettent de dire que tel utilisateur est dans tel groupe de telle à telle date * la base n'est pas destinée à être utilisée telle quelle pour l'authentification ou la gestion système : des ''backends'' sont disponibles pour créer, à partir de cette base, les données système nécessaires (fichiers ''passwd+shadow'', base MySQL-auth, arbre LDAP, htpasswd, etc). * par défaut la base ne contient pas de données purement "système" : ces données (comme le shell, la homedir, etc) sont calculées par les backend, éventuellement en fonction de conditions locales (exemple: homedir du type /home/a/n/antoine). * un mecanisme de champ "extra" permet d'étendre les tables en associant des variables à un utilisateur, un groupe ou autre (merci JérômeSantini pour cette chouette idée) * la gestion des organismes d'appartenance est hierarchisée (par exemple université->faculté->département). Ainsi, si une personne est de tel département, on sait qu'elle est aussi de telle fac et de telle université. |
Table fonction:: . id . nom . commentaires |
| Ligne 48: | Ligne 70: |
| Table fonction_extra:: . id_fonction . variable . valeur |
|
| Ligne 49: | Ligne 75: |
| == Table utilisateurs == * '''id''' * '''login''' * '''mot_de_passe''' * '''courriel''' * '''nom''' * '''prénom''' * '''genre''' * '''date_naissance''' * '''adresses''' * '''téléphones''' * '''id_organisme''' * '''fonction''' * '''commentaires''' == Table utilisateurs_extra == * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' == Table groupes == * '''id''' * '''nom''' * '''commentaires''' == Table groupes_extra == * '''id_groupe''' * '''variable''' * '''valeur''' == Table abonnements == * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' == Table organismes == * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' == Table organismes_extra == * '''id_organisme''' * '''variable''' * '''valeur''' |
Table utilisateur_organisme_fonction:: . id_utilisateur . id_organisme . id_fonction . commentaires |
Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.
Les utilisateurs
- Table utilisateurs
- id
- login
- mot_de_passe
- courriel
- nom
- prénom
- genre
- date_naissance
- adresses
- téléphones
- commentaires
- Table utilisateurs_extra
- id_utilisateur : utilisateur concerné
variable : nom de la variable (par exemple : courriel_alias, homedir)
- valeur
Les groupes
- Table groupes
- id
- nom
- commentaires
- Table groupes_extra
- id_groupe
- variable
- valeur
Les abonnements
Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps.
- Table abonnements
- id_utilisateur
- id_groupe
- date_debut
- date_fin
- commentaires
Les organismes
Ils sont hiérarchisés (arbre simple : un parent peu avoir plusieurs fils).
- Table organismes
- id
- nom
- adresses
- telephones
- id_organisme_parent : pointe vers un id_organisme (0 pour la racine)
- commentaires
- Table organismes_extra
- id_organisme
- variable
- valeur
Chaque utilisateur peut être rattaché à un ou plusieurs organismes. A chaque rattachement on indique la fonction de l'utilisateur dans l'organisme, via un triplet { utilisateur, organisme, fonction }. On peut donc imaginer qu'un utilisateur puisse avoir plusieurs fonctions au sein d'un organisme.
- Table fonction
- id
- nom
- commentaires
- Table fonction_extra
- id_fonction
- variable
- valeur
- Table utilisateur_organisme_fonction
- id_utilisateur
- id_organisme
- id_fonction
- commentaires