|
Taille: 6749
Commentaire:
|
Taille: 13193
Commentaire: de la hiérarchisation => pas directement dans la base svp
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI) * Responsable : SebastienLanteigne * Participants : JeanChristopheAndré, SebastienDornano, ThomasNoël, CédricProtière, JérômeSantini... ''et tout le monde intéressé !'' |
|
| Ligne 3: | Ligne 8: |
| Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI) | = Discussions, propositions = |
| Ligne 5: | Ligne 10: |
| * Responsable : SébastienLanteigne * Participants : SebastienDornano, CédricProtière, JeanChristopheAndré, ThomasNoël, JérômeSantini... ''et tout le monde intéressé !'' |
On peut parler ici : ["/Discussion"] |
| Ligne 8: | Ligne 12: |
| = Historique du projet = | = Objectifs du projet = |
| Ligne 10: | Ligne 14: |
| * 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. |
. '''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.) = 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. 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 Cette application sera adaptable en fonction des contraintes locales. Par exemple elle sera capable, via des extensions (surcharges), de synchroniser les données avec d'autres systèmes (authentification, messagerie, etc.). 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 = Description plus détaillée = == 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. La programmation objet permet de proposer des extensisons via des surcharges des fonctions. 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). === 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 : . {{{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 définir l'ensemble des fonctions. Chaque fonction sera ''surchargeable'' afin d'être adaptée aux conditions locales. Exemple de surcharges possibles : * une surcharge ''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 ; * une surcharge ''Postfix'' pour le système de messagerie afin de mettre à jour en temps réel des tables pour Postfix ; * une surcharge ''mkdir'' pour créer le répertoire d'un utilisateur sur un serveur distant (via ssh) lors de sa création * etc. Un ensemble de surcharge sera proposé par défaut recouvrant le maximum de besoins. Charque surcharge disposera d'un fichier de configuration de base. <!> Pour l'instant nous ne savons pas encore quelle forme concrète va prendre cette programmation des surcharges. Idéalement, un répertoire "extensions" dans lequel on placerait des fichiers Django/Python (''.py''). Ca serait pratique. == 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. 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 ecrasé pour tel ou tel utilisateur s'il existe un champ ''extra'' pour cet utilisateur (voir plus loin la notion de champ ''extra'' dans la base de donnée). == Schéma de la base de données == <!> Pour l'instant rien n'est vraiment fixé. C'est pourtant un point capital qu'il faut régler RAPIDEMENT ! Quelques 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é. Voir : . /PropositionThomas . /PropositionSebastien Et combiner les idées ici: . /PropositionBase <!> Question : ça serait pas mal, vu la configuration du monde universitaire actuel, qu'un abonné soit rattachable à plusieurs organismes. C'est pour cela qu'il ne faut pas hierachiser cette appartenance mais simplement faire des liens relationnel. -- Progfou |
| Ligne 18: | Ligne 95: |
| * 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. | * 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. |
| Ligne 33: | Ligne 110: |
| = Mise à jou = | = Documentation = |
| Ligne 35: | Ligne 112: |
| La documentation suivante est en cours d'écriture/adaptation/à faire: | |
| Ligne 36: | Ligne 114: |
| == Première proposition de base == === Table user : === Contient toute l'information qui nous sert à identifer une personne. (Ajouter 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 | | +-------------+--------------+------+-----+------------+----------------+ }}} |
* 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) |
| Ligne 63: | Ligne 120: |
| === Table user : === 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 | | | +-------+--------------+------+-----+---------+----------------+ }}} |
== 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. 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. 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. |
| Ligne 74: | Ligne 124: |
| === Table user : === 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 | | +--------------+------------------+------+-----+---------+------- }}} |
Technologie choisie:: Python, ["Django"], MySQL |
| Ligne 101: | Ligne 126: |
| === Table user : === Contient les données d'abonements (la transaction). (Peut être ajouter un champ création pour la création d'abonnement avant la date de début de celui-ci) {{{ +-----------+---------+------+-----+------------+----------------+ | 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 | | +-----------+---------+------+-----+------------+----------------+ }}} |
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. Est-ce que je peux voir où on en est ?:: Oui. Un modèle existe à http://osti.auf:8000/admin . Le modèle actuellement en place n'est pas à jour par contre je vais essayer de charger la dernière version les mardis et jeudi de chaque semaines. = Expression des besoins = Suite aux visites faite dans différentes CNF. Certains éléments communs étant directement lié à la gestion des usagers font surface. Nottament: == 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) == 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. (Module de base) * 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. (À étudier et intégrer) * 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) * Statistiques : Tous nos CNF ont besoin d'une forme ou autre de statistiques. * Inscriptions : (À intégrer) * Fréquentation : (À modulariser) * 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. à ce sujet, a eu lieux avec Mme. Nathalie Houle à sont retour de mission. La rencontre avec 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. 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égré au système de gestion de comptes présente au CNF. == 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éressantes dans ce domaine. La création d'un autre outil est sans doutes inutiles. * Contrôle des accès web : Encore là les outils existant sont à explorer. Voir Squid, Squidguard, dansguardian, etc. * contrôle des impresssions/photocopies: (À voir) * Réservation : Poste, salle, etc. (À Modulariser) |
Projet de Système Gestion des abonnés d'une implantations AUF (CNF/CAI)
Responsable : SebastienLanteigne
Participants : JeanChristopheAndré, SebastienDornano, ThomasNoël, CédricProtière, JérômeSantini... et tout le monde intéressé !
Discussions, propositions
- On peut parler ici : ["/Discussion"]
Objectifs du projet
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.)
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.
- Des logiciels de gestion de la base de données
- de quoi remplir et gérer la 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, 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:
les fichiers /etc/passwd et /etc/shadow pour être utilisés sur un serveur NIS
les fichiers /etc/aliases, /etc/postfix/virtual, etc, pour la messagerie
- une base de données d'authentification MySQL
- une base de données MySQL pour la messagerie
- un arbre LDAP
- etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs
Description plus détaillée
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.
La programmation objet permet de proposer des extensisons via des surcharges des fonctions.
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).
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 :
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 définir l'ensemble des fonctions.
Chaque fonction sera surchargeable afin d'être adaptée aux conditions locales. Exemple de surcharges possibles :
une surcharge 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 ;
une surcharge Postfix pour le système de messagerie afin de mettre à jour en temps réel des tables pour Postfix ;
une surcharge mkdir pour créer le répertoire d'un utilisateur sur un serveur distant (via ssh) lors de sa création
- etc.
Un ensemble de surcharge sera proposé par défaut recouvrant le maximum de besoins. Charque surcharge disposera d'un fichier de configuration de base.
Pour l'instant nous ne savons pas encore quelle forme concrète va prendre cette programmation des surcharges. Idéalement, un répertoire "extensions" dans lequel on placerait des fichiers Django/Python (.py). Ca serait pratique.
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.
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 ecrasé pour tel ou tel utilisateur s'il existe un champ extra pour cet utilisateur (voir plus loin la notion de champ extra dans la base de donnée).
Schéma de la base de données
Pour l'instant rien n'est vraiment fixé. C'est pourtant un point capital qu'il faut régler RAPIDEMENT !
Quelques 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é.
Voir :
Et combiner les idées ici:
Question : ça serait pas mal, vu la configuration du monde universitaire actuel, qu'un abonné soit rattachable à plusieurs organismes.
- C'est pour cela qu'il ne faut pas hierachiser cette appartenance mais simplement faire des liens relationnel. -- Progfou
Calendrier Prévisionnel
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 : 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
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
Phase 3 : Test, déboguage et documentation
- 13 novembre - 15 décembre : déboguage et transfert du développement ver les ressources internes
Phase 4 : Déploiement
- À définir
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)
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. 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. 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.
- Technologie choisie
- Python, ["Django"], MySQL
- 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.
- Est-ce que je peux voir où on en est ?
Oui. Un modèle existe à http://osti.auf:8000/admin . Le modèle actuellement en place n'est pas à jour par contre je vais essayer de charger la dernière version les mardis et jeudi de chaque semaines.
Expression des besoins
Suite aux visites faite dans différentes CNF. Certains éléments communs étant directement lié à la gestion des usagers font surface. Nottament:
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)
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. (Module de base)
- 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. (À étudier et intégrer)
- 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)
- Statistiques : Tous nos CNF ont besoin d'une forme ou autre de statistiques.
- Inscriptions : (À intégrer)
- Fréquentation : (À modulariser)
- 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. à ce sujet, a eu lieux avec Mme. Nathalie Houle à sont retour de mission. La rencontre avec 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. 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égré au système de gestion de comptes présente au CNF.
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éressantes dans ce domaine. La création d'un autre outil est sans doutes inutiles.
- Contrôle des accès web : Encore là les outils existant sont à explorer. Voir Squid, Squidguard, dansguardian, etc.
- contrôle des impresssions/photocopies: (À voir)
- Réservation : Poste, salle, etc. (À Modulariser)