|
Taille: 4221
Commentaire:
|
Taille: 3985
Commentaire: compte rendu visio 5 décembre (et nettoyage discussions caduques)
|
| Texte supprimé. | Texte ajouté. |
| Ligne 3: | Ligne 3: |
| == Compte-rendu visio 28 nov 2007 == | == Compte-rendu visio 28 nov 2006 == |
| Ligne 16: | Ligne 16: |
| == Compte-rendu visio 5 déc 2006 == Nouvelle petite visio rapide : ThomasNoël, JérômeSantini, JeanChristopheAndré, OusmaneWilane. La discussion a porté sur les soucis de véritication de cohérence entre le noyau et les plugins, ainsi que la cohérence intra-plugin (ouaahh). * les plugin doivent informer le noyau en cas de soucis : Ousmane va étudier le fait que les plugin puissent lever des exception * quand le noyau reçoit une exception (erreur) en provenance d'un plugin, il renseigne une table "plantages". Le noyau enregistre cependant ses données (par exemple l'utilisateur sera bien créé au niveau du noyau) * la table plantage permet ensuite de savoir si un objet noyau a eu des soucis lors de sa gestion par un plugin. Dans ce cas, on pourra relancer la création/modification de l'utilisateur en appelant le/les plugins qui a/ont planté (ou tous les plugin, pour aller plus vite) * lorsqu'un utilisateur sera affiché, s'il existe un warning au niveau de la table "plantage", alors un bandeau rouge s'affichera sur la page d'admin qui dira que cet utilisateur n'est pas "fonctionnel" * la table "plantage" pourra également être considérée comme une liste d'attente des soucis à régler Les plugin doivent donc tous proposer une methode "synchro" afin de re-synchroniser un objet du noyau (utilsiateur, groupe, abonnement, etc). Cette méthode dans chaque plugin permettra également d'ajouter un plugin en cours de route : lors de son ajout, on déclenchera la synchro sur tous les objets noyau pour qu'ils soient tous prise en compte par le plugin. Les plugin pourraient éventuellement proposer une méthode "vérification" (sans action de correction) afin de pouvoir faire un "check" de la cohérence... à étudier. |
|
| Ligne 18: | Ligne 35: |
| == 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. |
Si on arrive à mettre en place cette technique, on aura un truc beaucoup plus robuste. |
| Ligne 23: | Ligne 37: |
| === Proposition 1 === Un module d'exportation par technologie. |
|
| Ligne 26: | Ligne 38: |
| ==== 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. |
== Autres idées == |
| Ligne 29: | Ligne 40: |
| ==== LDAP ==== | Extraites des anciennes discussions : |
| Ligne 31: | Ligne 42: |
| ==== 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' |
* Sebastien est tombé sur http://www.zbyte64.com/code.shtml . Ca serait bien d'export certaines choses directement en format Open Document. * 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 : chercher ce qu'est PMB (voir avec Sebastien Dornanon, Port Vila) |
N'hésitez pas à ajoutez vos commentaires et questions sur cette page.
Compte-rendu visio 28 nov 2006
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
Compte-rendu visio 5 déc 2006
Nouvelle petite visio rapide : ThomasNoël, JérômeSantini, JeanChristopheAndré, OusmaneWilane.
La discussion a porté sur les soucis de véritication de cohérence entre le noyau et les plugins, ainsi que la cohérence intra-plugin (ouaahh).
- les plugin doivent informer le noyau en cas de soucis : Ousmane va étudier le fait que les plugin puissent lever des exception
- quand le noyau reçoit une exception (erreur) en provenance d'un plugin, il renseigne une table "plantages". Le noyau enregistre cependant ses données (par exemple l'utilisateur sera bien créé au niveau du noyau)
- la table plantage permet ensuite de savoir si un objet noyau a eu des soucis lors de sa gestion par un plugin. Dans ce cas, on pourra relancer la création/modification de l'utilisateur en appelant le/les plugins qui a/ont planté (ou tous les plugin, pour aller plus vite)
- lorsqu'un utilisateur sera affiché, s'il existe un warning au niveau de la table "plantage", alors un bandeau rouge s'affichera sur la page d'admin qui dira que cet utilisateur n'est pas "fonctionnel"
- la table "plantage" pourra également être considérée comme une liste d'attente des soucis à régler
Les plugin doivent donc tous proposer une methode "synchro" afin de re-synchroniser un objet du noyau (utilsiateur, groupe, abonnement, etc).
Cette méthode dans chaque plugin permettra également d'ajouter un plugin en cours de route : lors de son ajout, on déclenchera la synchro sur tous les objets noyau pour qu'ils soient tous prise en compte par le plugin.
Les plugin pourraient éventuellement proposer une méthode "vérification" (sans action de correction) afin de pouvoir faire un "check" de la cohérence... à étudier.
Si on arrive à mettre en place cette technique, on aura un truc beaucoup plus robuste.
Autres idées
Extraites des anciennes discussions :
Sebastien est tombé sur http://www.zbyte64.com/code.shtml . Ca serait bien d'export certaines choses directement en format Open Document.
- 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 : chercher ce qu'est PMB (voir avec Sebastien Dornanon, Port Vila)