Modifications entre les versions 11 et 12
Version 11 à la date du 2006-11-28 14:59:56
Taille: 4321
Éditeur: ThomasNoël
Commentaire:
Version 12 à la date du 2006-11-29 10:56:27
Taille: 4221
Éditeur: ThomasNoël
Commentaire:
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
## page was renamed from Projet/GestionDesUtilisateursDesCampus/Discussion
## page was renamed from Projet/GestionDesUtilisateursDesCampus/DiscussionBase
Ajoutez vos commentaires ici
N'hésitez pas à ajoutez vos commentaires et questions sur cette page.
Ligne 10: Ligne 8:
 * applications "métier" à étudier : authentification, postfix  * applications "métier" à étudier : authentification (NSS, Samba), postfix

N'hésitez pas à ajoutez vos commentaires et questions sur cette page.

Compte-rendu visio 28 nov 2007

Nous avons fait une petite visio rapide : ThomasNoël, JérômeSantini, JeanChristopheAndré, OusmaneWilane (et ZoserBiziki en modérateur ;) ). Ce qu'il en ressort :

  • la notion noyau + plugin semble ok pour tout le monde, notamment le fait que le noyau informera les plugin de tout évenement sur la base (les plugins devront réagir en fonction)
  • applications "métier" à étudier : authentification (NSS, Samba), postfix
  • application métier plus lourde : gestion des commandes de doc primaires. A priori pas trop de soucis car les plugins pourraient être des applis Django (JC nous fournira un accès à son système pour qu'Ousmane voit mieux l'engin)
  • il faut étudier les possibilités "poussées" du coté de la personnalisation du module Admin de Django, afin de voir si on peut un peu améliorer l'ergonomie : définir des mockups pour cela
  • replication des bases : il faut qu'on puisse extraire les infos d'un site afin de les envoyer dans un autre. Tout le monde est ok pour des login du type "login@implantation2" lorsque le login provient d'une base "externe". Il reste à étudier les implications diverses de tout cela au niveau des plugins notamment.
  • interfaces "publiques" :
    • pour tout ce qui est stat & co : templates Django (il faudra éventuellement API-ser coté Django pour aider à la programmation de ces templates)

    • les utilisateurs devront pouvoir modifier (au moins) leur mot de passe et leur nom_complet

Export

  • L'idée est bien sûr de reprendre l'information de la base de suivi, d'en exporter un maximum vers une base d'authentification et de recueillir ce que manque. Voici donc quelques idées sur comment le faire. Merci d'ajouter vos commentaires dans la section appropriée ou d'ajouter celles qui manques.
  • J'aurais sans doutes besoins d'aide pour recueillir les informations / la structure nécessaires pour chaque système. Je suis principalement familier avec MySQL et SAMBA.
  • Je suis tombé sur ceci. http://www.zbyte64.com/code.shtml . Ca serait bien d'export certaines choses directement en format Open Document.

Proposition 1

Un module d'exportation par technologie.

MySQL

  • Il serait sans doute intéressant d'avoir un module d'exportation MySQL adaptable pour permettre de faire la synchronisation entre différentes bases MySQL. Dans le cas d'un CNF avec une base d'authentification MySQL et une base PMB par exemple.

LDAP

NIS

SAMBA

Proposition 2

Exportation modularisée avec profil

  • Chaque type d'exportation est effectuée à partir d'un profil qui contient
    • Un hôte (adresse IP, port, etc) (table hote)

    • Un type de connexion et les options spécifiques à celle-ci (MySQL, NIS, LDAP, etc) (table connexion)

    • Les valeurs par défaut des paramètres d'authentification (uid, gid, domaine, alias, shell, homedir, etc) (table valeurs)

      • Les valeurs par défaut sont écrasées par les valeurs existantes si elles existent dans la base de suivi.
      • Les tables "extras" proposées par Jérôme deviennent très utiles en nous permettant de bien gérer les cas qui diffèrent. On pourrait par exemple définir un /bin/bash par défaut pour les usagers et /bin/ksh pour l'usager jsantini en spécifiant ("shell", "/bin/ksh") dans la table userExtra.

Table Usager

  • Un champ photo ? (SebastienLanteigne)

    • Je confirme qu'une photo serait indispensable, cela nous a permis à Libreville d'identifier des tricheurs. (Matthieu)
    • Des fichiers login.jpg et zou. Pas la peine de balancer des blob dans le MySQL, c'est ch**nt à gérer. -- ThomasNoël

    • Sinon une image encodée en Base64 avec restriction sur quelques paramètres (essentiellement dimensions et nombre de couleurs). -- JeanChristopheAndré

    • Je suis d'accord avec Thomas j'ai d'ailleur fait des tests en chargeant le fichier à l'extérieur de la base. Ne pourrait on pas utiliser les champs 'extras' pour ça? On pourrait par exemple imaginer 'photo' 'bob.jpg' ou 'CV' 'bob.pdf'

Projet/GUIA/Discussion (dernière édition le 2008-02-21 22:10:06 par localhost)