Voici mes (ThomasNoël) propositions pour le système de gestion des utilisateurs.

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 simple mais permettant de multiples extensions. Voir ci-dessous pour ma proposition de structure.

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
2. une interface en ligne de commande pour permettre une gestion "système"
3. plus tard, un application native pour Gnome ou KDE

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

Le logiciel de gestion de la base

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.

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 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.

Schéma de la base de données

Idées générales

• 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 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