Intégration dun gestionnaire de versions pour les documents dans le portail web de travail collaboratif

Institut de la Francophonie pour l'Informatique Institut National des Télécommunications MÉMOIRE DE FIN D'ÉTUDES MASTER EN INFORMATIQUE Intégration d'un gestionnaire de versions pour les documents dans le portail Web de travail collaboratif NGO Van Cong Responsable de stage: Christian BAC Ce stage a été réalisé au sein du projet PFTCR du département Informatique de l'Institut National des Télécommunications(INT) Hanoi, 20 Décembre 2006 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Remerciements J’adresse toute ma gratitude mon responsable de stage, M Christian BAC, pour sa disponibilité, son soutien constant et son aide précieuse durant ce stage Je voudrais également remercier M Olivier BERGER, M Bent HAMET pour leurs collaborations serrées, leurs aides tout au long de mon stage Un grand merci toutes les personnes du département Informatique l'INT pour leurs aides et leur gentillesse pendant mon séjour en France Enfin, je voudrais exprimer mon entière reconnaissance envers ma famille, mes amis et ses professeurs l’IFI pour leurs soutiens, leurs aides et leurs encouragements NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Résumé Le problème de perte de mise jours dans l'environnement de travail collaboratif existe depuis longtemps On voudrait de pouvoir suivre ces changements pour aider les développeurs garder le contrôle du projet et communiquer (même des kilomètres de distance) tout en restant assez peu intrusif À notre jour il y a de nombreux utiles qui nous aident gérer des révisions par logiciel comme CVS, Subversion, Sourcesafe Ce stage vise intégrer le gestionnaire de versions(Subversion) dans un environnement de travail collaboratif(phpGroupWare) pour remplacer WebDAV(mod_dav d'Apache dans ProGet) Dans le cadre de stage, nous avons développé un nouveau module qu'il permet de manipuler les fichiers avec les méthodes du protocole DeltaV Ce Module est intégré dans la base de code standard du module APIs de la nouvelle version 0.9.18 de phpGroupWare Mots-clefs: WebDAV, DeltaV, Subversion, Filemanager, VFS NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Table des matières Remerciements Résumé Chapitre1: Introduction Objectifs du stage Contexte Organisation du rapport Chapitre 2: État de l'art Étude de cas pour la gestion de version 1.1 Travail concurrent 1.2 Correction de bogue 1.3 Travail distant CVS 2.1 Introduction 2.2 Le rôle de CVS 2.3 Le CVSROOT 2.4 Accès une base CVS 2.5 Session de CVS 2.6 Limite de CVS WebDAV 3.1 Introduction 3.2 Fonctionnalités 3.3 Méta-données 3.4 Gestion des accès concurrents 3.5 Les implémentations de serveur WebDAV 3.6 Limite de WebDAV DeltaV 4.1 Introduction 4.2 Les termes dans Deltav 4.3 Opération de version 4.4 Autoversoning 4.5 Espace de travail (Workspace) 4.6 Fonctionnement de DeltaV Étude de cas: subversion 5.1 Introduction 5.2 Avantages 5.3 Modèle Copier- Modifier – Fusionner 5.4 Subversion et Deltav Comparaison entre Subverson et CVS Chapitre 3: Intégration de système de gestion de versions dans le gestionnaire de fichiers de phpGroupWare Introduction Analyse 2.1 Subversion architecture 2.2 Architecture de gestionnaire de fichiers (filemanager) 2.3 Phpgwapi Utiliser subversion client API 3.1 Construire un wrapper de libsvn_client dans PHP 3.2 Le cycle de vie d'une extensions Implémenter des méthodes de protocole deltav NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Implémentation 37 5.1 Introduction 37 5.2 Accès au historique 37 5.3 Comparaison la différence entre deux révision 38 Chapitre 4: Contrôle des droits d'accès 40 Gestion par le serveur Web apache 40 1.1 Client et serveur d’authentification Handshake 40 1.2 Méthode de Contrôle d’accès 40 1.3 Méthode de passage des certificats 41 1.4 Authentification et autorisation 41 1.5 Les phases de sécurité d’Apache 42 Gestion par un accès direct subversion 43 2.1 Introduction 43 2.2 Modèle de sécurité d’Apache et Subversion 43 2.3 Autorisation 44 Conclusions 47 Bibliographie 48 Annexe A: Intégration Subverison dans Picolibre 49 NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Table de Figure Figure 1: Accès une base de CVS Figure 2: Checkout Figure 3: Commit Figure 4: Update Figure 5: Plusieurs applications en utilisant Delta-V Figure 6: Les opérations de protocole HTTP, WebDAV et DeltaV 20 Figure 7: Représentation de l'hitorique d'un fichier foo.html dans DeltaV Figure 8: Modèle copier-modifier-fusionner 26 Figure 9: Subverison Architecture Figure 10: Architecture de Filemanager Figure 11: Filemanager avec le wrapper de libsvn_client Figure 12: Filemanager avec WebDAV/DeltaV Figure 13: L'interface après avoir intégré le gestionnaire de version Figure 14: Comparaison entre deux fichiers et deux répertoires 39 Figure 15: Modèle de sécurité d'Apache et Subversion Figure 16: Mécanisme de NSS Figure 17: Mécanisme de PAM NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Chapitre1: Introduction Objectifs du stage L'objectif de ce stage est d'intégrer la gestion des révisions par le logiciel SubVersion dans des portails de travail collaboratifs appelés ProGet et PicoLibre, en replacement de CVS (Concurrent Version System) dans PicoLibre ou WebDAV(mod_dav d'Apache dans ProGet) Le but est de disposer d'un même référentiel de documents partagés dans les projets qui soit la fois accessible avec des clients DAV, de faỗon "transparente" pour un maximum d'utilisateurs ne souhaitant pas faire de gestion de versions, comme cela se passe dans ProGet actuellement et accessible avec un client SubVersion pour les utilisateurs désirant faire du suivi de version, comme c'est le cas dans PicoLibre actuellement avec CVS Contexte Ce stage se déroule dans le cadre d'un projet pour améliorer les plate-forme ProGet et PicoLibre ProGet Le portail ProGET présente l'ensemble des projets de recherche du GET(Groupe des Écoles des Télécomunications) répartis dans cinq programmes activités articulés autour de trois grandes thématiques - systèmes de communication , systèmes de traitement et d'élaboration de contenus, applications la société de l'information - couvrant la totalité des activités de recherche du GET Le portail propose une consultation facile et rapide des informations générales sur les 115 projets structurants (objectifs généraux, coordonnateurs, écoles participantes) ainsi qu'un descriptif des programmes Le moteur de recherche intégré au portail permet par ailleurs un accès direct une information ciblée par mot clés permettant d'identifier par exemple les projets traitant d'une thématique particulière ou bien encore les équipes de recherche impliquées sur un thème PicoLibre Le projet PicoLibre a pour le but de développer les outils nécessaires une plate-forme collaborative de développement de logiciel spécialement adaptée au contexte de l'enseignement supérieur Les principales caractéristiques de cette plate-forme résident dans sa simplicité (d'où le préfixe Pico) : simplicité d'installation et d'administration, facilité d'apprentissage et d'utilisation par des novices Elle permet en effet d’héberger des projets en mettant la NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif disposition des utilisateurs un espace de travail associé un ensemble d’outils Ces outils mettent en musique les différents registres d’activité de la vie d’un projet - communication au sein de l’équipe, communication externe, gestion et synchronisation des développements, planification des tâches, documentation du projet, suivi de bogues, mise disposition des sources - et favorisent ainsi une gestion efficace, cohérente et responsable Accessible partir de tout navigateur WEB, la plate-forme offre une mtrise complète de sécurisation des accès Ainsi un projet peut être visible de tout l’Internet (accès anonyme), alors qu’un autre n'est accessible que par un groupe de personnes identifiées PicoLibre est développée dans le cadre du projet PeCoRes[4] Dans l'avenir, PicoLibre respectera le protocole d'interconnexion de plateformes de développement CoopX en cours de définition [5], et PicoLibre est un Logiciel Libre publié sous la GNU General Public License [19] Organisation du rapport Le chapitre présente les notions générales sur l'aspect de gestionnaire de version, il décrit les protocoles WebDAV et DeltaV ainsi que le logiciel Subversion qui offre une implémentation du protocole DeltaV Dans le chapitre 3, nous abordons des possibilités d'intégration de gestionnaire de versions dans le gestionnaire de fichiers, ainsi qu'une partie de réalisation qui permet de choisir entre les approches présentées Ce chapitre contient également une description des interfaces de logiciel après l'intégration Le chapitre présente des aspects de sécurité de Apache et Subversion et l'association entre les deux Le rapport se termine par des conclusions, une bibliographie et une annexe qui décrit l'intégration du support de subversion dans PicoLibre NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Chapitre 2: État de l'art Étude de cas pour la gestion de version Le contrôle de versions aide les développeurs garder le contrôle du projet Il est possible de chercher un bogue et d’appliquer un correctif plusieurs versions de l’application Comme le système fonctionne aussi en mode déconnecté, il permet aux développeurs de travailler hors site Grâce au contrôle de versions, il est possible de gérer de nombreux cas Le contrôle de versions fournit mtrise et flexibilité 1.1 Travail concurrent Considérons les développeurs d’un même projet Avant de se mettre au travail, ils mettent jour la copie locale du code source du projet par rapport au système central de contrôle de versions et vérifient que rien ne risque de poser problème pour leurs développements de la journée En l’occurrence, une des classes principales du système a été modifiée et le commentaire associé instille le doute dans l’esprit d’un des développeurs La personne qui a fait cette modification est absente, c’est donc le système de contrôle de versions qui précise ce qui a été changé Des variables d’instances ont été ajoutées, mais leurs valeurs par défaut ne semblent pas évoluer par la suite Même si ces variables peuvent poser problème, cela ne gênera pas la journée de travail Notre développeur ajoute une nouvelle classe et quelques tests au système Au fur et mesure, il en informe le système de gestion des versions – les fichiers eux-mêmes ne seront transmis que lorsqu’il les aura validés Quelques heures plus tard, le développeur termine la première partie d’une nouvelle fonctionnalité Les tests ne posent pas de problème et rien n’est affecté dans le reste du code ; il transfère tout au système de contrôle de versions pour que les autres membres de l’équipe puissent y accéder 1.2 Correction de bogue Un bogue est signalé dans la version du logiciel utilisée chez un client : il faut le corriger d’urgence Le développeur affecté cette tâche extrait la version correspondante sur son disque dur et dispose maintenant de deux copies locales du code source : le tronc commun (trunk), qui suit les développements principaux, et la version livrée au client Grâce au système de contrôle de versions, il pose une marque (tag) sur son code source ; il en posera une seconde lorsque le bogue sera corrigé Les marques servent identifier les points saillants NGO Van Cong – Promotion 10 – IFI Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif du développement du code En les nommant de manière cohérente, il est facile de suivre ce qui a été modifié Il faut d’abord isoler le problème (ce que l’on fait par une série de tests) et en déterminer la cause – un bogue dans un logiciel livré un client ne devrait pas arriver, il faut éventuellement en discuter en réunion d’équipe Une fois le problème identifié, le développeur le corrige, puis il compile et teste le code Il propage ensuite la modification dans le système de contrôle de versions et pose une marque pour indiquer que le bogue a été corrigé Il reste une question : le bogue est-il encore présent dans la version de développement du code ? Pour le vérifier, le plus simple est de soumettre cette version au test écrit pour le code livré Fusionnez dans le tronc commun la modification propagée dans la branche de livraison Le test échoue : le bogue est toujours présent Il faut alors récupérer le correctif dans la version livrée et l’appliquer la version de développement, relancer les tests et propager la modification dans le système de contrôle de versions 1.3 Travail distant Le contrôle de versions permet aussi aux développeurs de travailler depuis un site distant Pour cela, il suffit de se connecter au dépôt par le biais d’une connexion sécurisée, d’extraire les développements en cours sur un ordinateur et de travailler Bien sûr, il faut pour cela que les propagations soient raisonnablement jour pour éviter les conflits – et penser propager les modifications effectuées hors site avant de vouloir y accéder sur le dépôt central CVS 2.1 Introduction CVS est un système client/serveur qui permet aux développeurs de conserver leurs projets sur un serveur central appelé dépôt En utilisant les clients CVS et les outils associés, les développeurs peuvent faire des modifications du contenu sur le serveur En fait, le dépôt CVS conserve chaque changement fait sur chaque fichier, créant ainsi un historique complet de toute l'évolution du développement du projet Les développeurs peuvent demander des versions antérieures d'un fichier particulier, regarder un historique des modifications et réaliser au besoin plusieurs autres actions utiles NGO Van Cong – Promotion 10 – IFI 10 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif "orientée événement", ce qui la distingue de l'autre API XML implémentée par nombre d'analyseurs, le DOM (Document Object Model), basée sur la construction d’une arborescence interne au document XML SAX renvoie ainsi l’application qui manipule le document XML les «événements» (ouverture de balise, fermeture de balise, contenu textuel) qui le constituent l'heure actuellement SAX existe dans plusieurs langages comme java, PHP, Perl etc SAX est événementiel, si l'on considère le flux XML entrant, il est facile de découvrir les événements : une balise ouvrante est un événement, une balise fermante un autre événement C'est l'essentiel de cette API, une fois que l'on répond ces deux événements, on a déjà traité un flux XML C'est étonnamment simple, et finalement extrêmement puissant Figure 13: L'interface après avoir intégré le gestionnaire de version Sur l'image, c'est une interface du gestionnaire de fichiers après avoir intégré le gestionnaire de versions avec le fait d'ajouter une méthode REPORT, il nous permet d'accéder l'historique d'une ressource et après de présenter un résultat de ce type l'utilisateur 5.3 Comparaison la différence entre deux révision Pour comparer entre deux révisions, nous avons décidé d'utiliser le diff client de Subversion Avec cet outil nous pouvons faire la comparaison entre les deux fichiers et même pour deux répertoires Le résultat obtenu est analysộ et affichộ de faỗon graphique pour que l'utilisateur puisse facilement suivre les changements entre les deux révisions NGO Van Cong – Promotion 10 – IFI 38 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Figure 14: Comparaison entre deux fichiers et deux répertoires L'image ci-dessus, est un résultat de comparaison entre deux fichiers, les régions rouges spécifient que c'est des parties qui ont été retirées entre les deux révisions et les régions vertes contiennent des parties qui ont été ajoutées Les régions grises sont identiques entre les deux révisions NGO Van Cong – Promotion 10 – IFI 39 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Chapitre 4: Contrôle des droits d'accès Gestion par le serveur Web apache 1.1 Client et serveur d’authentification Handshake Quand un client essaye d'accéder un document qui est sous une certaine sorte de contrôle d'accès,pPuisque c'est le premier essai le client ne sait pas que la ressource est protộgộe, il n'inclue aucun certificat Quand le serveur reỗoit la requête, il passe toutes les phases d'autorisation pour vérifier le droit d'accès, quand les certificats ne sont pas égaux ceux qui sont valides pour la ressource, le serveur retourne un statut ônon autorisộ ằ Un client qui reỗoit une rộponse ônon autorisộằ s'aperỗoit qu'il n'a envoyộ aucun certificat et affiche une bte de dialogue pour que l'utilisateur la remplisse Cette bte montre le nom de l’endroit (realm) dans lequel le document réside, et demande l'utilisateur un nom d'utilisateur et un mot de passe Une fois obtenu, le client réitère la requête , seulement cette fois il inclut les certificats Si le client obtient un statut «non autorisé» en réponse une requête incluant un certificat, il ouvre une bte de dialogue légérement différente avec l'utilisateur Il indique probablement que « ces certificats n'ont pas été acceptés, essayer encore ? », si l'utilisateur choisit de ne pas compléter le dialogue et appuie sur l'annulation, le client montre en général la page d'erreur que le serveur a envoyée avec le statut «non autorisé» 1.2 Méthode de Contrơle d’accès Il y a deux types de base de contrôle d'accès : ceux qui vérifient: qui vous dites que vous êtes, et ceux qui vérifient qui vous êtes vraiment Les trois méthodes de vérification de base sont de vérifier: ce que vous avez, ce que vous savez ce que vous êtes Les meilleurs systèmes de sécurité emploient une combinaison de ces trois possibilités Les mécanismes de contrôle d'accès discrétionnaires (DAC) vérifient la validité des certificats la discrétion de l'utilisateur, et les contrôles d'accès obligatoire (MAC) valident les aspects que l'utilisateur ne peut pas contrôler Par exemple, n'importe qui peut donner son nom d'utilisateur et le mot de passe associé, et permettre une autre personne d'entrer dans le NGO Van Cong – Promotion 10 – IFI 40 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif système Le nom d'utilisateur et le mot de passe fourni sont votre discrétion, et le système ne peut pas vous indiquer un vrai propriétaire En termes de Web, et d'Apache en particulier, des contrôles discrétionnaires sont basées sur des noms d'utilisateur et des mots de passe, et des contrôles obligatoires sont basés sur des choses comme l'adresse IP 1.3 Méthode de passage des certificats Il y a actuellement deux méthodes principales pour passer des certificats, appelées l'authentification de Basic et l'authentification de Digest La méthode de Digest est considérablement plus sûre, mais malheureusement moins largement déployée, ainsi la plupart des authentifications sur le Web est faite en utilisant le mécanisme de base moins sûr L'authentification Basic utilise simplement base64-encoding du nom de l'utilisateur et le mot de passe et transmet le résultat au serveur Ceci signifie que n'importe qui peut intercepter la transmission et déterminer le nom de l'utilisateur et le mot de passe Naturellement, c'est seulement utile si ces valeurs sont valides L'authentification de Digest transmet l'information de sorte que les autres ne peuvent pas être facilement la décoder En installant des contrôles d'accès discrétionnaire dans votre configuration d'Apache, se rappeler que la directive d'AuthType est exigée La configuration peut être héritée d'un répertoire de plus haut niveau, mais on doit placer la valeur hériter, il n'y a aucun défaut 1.4 Authentification et autorisation L'authentification est le processus de vérification que les certificats sont corrects c'est-àdire, le nom de l'utilisateur est dans la base de données et le mot de passe est correct pour cet utilisateur L’autorisation est le processus de vérification pour voir si un client validé est autorisé pour accéder une ressource particulière Par exemple, Bob a correctement fourni son nom d'utilisateur et mot de passe, mais il ne peut pas accéder au fichier de Jack parce qu'il n'est pas encore inclus dans la liste d'autorisation de Jack Dans Apache, la plupart des modules de sécurité font l'authentification et l'autorisation La caractéristique principale qui les distingue entre eux est leur aspect d'authentification, ils vous ont laissé stocker l'information de valide de certificat dans l'un ou l'autre format Le module de mod_auth, par exemple, regarde dans les fichiers normaux des textes pour l'information de nom de l'utilisateur et de mot de passe, et le mod_auth_ldap regarde celui dans un serveur de LDAP[16] Cependant ils manipulent le côté d'autorisation de manière essentiellement identique NGO Van Cong – Promotion 10 – IFI 41 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Les modules de sộcuritộ reỗoivent les informations sur les bases de données d'authentification employer par des directives, telles que l'AuthUserFile ou l'AuthLDAPURL La ressource protégée est déterminée partir de l'emplacement des directives dans les fichiers de configuration, Exemple: AuthName "Foo for Thought" AuthType Basic AuthUserFile /home/admin/foo.htpasswd Require valid-user La ressource protégée est « n'importe quel fichier appelé foo.bar » dans le répertoire / home/admin/public_html ou n'importe où sous lui De même, l'identification des certificats qui sont autorisés pour accéder foo.bar est énoncée par les directives dans ce cas, n'importe quel utilisateur avec le certificat valide dans le fichier de /home/admin/foo.htpasswd peut y accéder Avec le mécanisme de contrôle d'accès discrétionnaire sur le Web, chaque secteur protégé s'appelle un realm Quand un serveur défie un client pour des certificats, il fournit le nom du realm pour que le client puisse déterminer quels sont les certificats envoyer Le nom d'un realm est indiqué dans les fichiers de configuration d'Apache avec la directive d'AuthName, qui prend un argument simple : le nom du realm 1.5 Les phases de sécurité d’Apache Apache manipule toutes les requêtes par des phases Chaque module d'Apache a une occasion de traiter la requête pendant chacune des phases, bien que la plupart des modules fassent seulement une ou deux d'entre elles Apache a trois phases de traitement concernant la vérification de sécurité Elles se produisent dans l'ordre suivant, et ont les noms suivants : access_checker Cette phase est celle ó des contrơles d'accès mandataire sont appliqués, comme le contrôle de mod_access C'est dans cette phase que le serveur vérifie qu'une adresse IP du client a le droit d'accéder au document ou pas check_user_id C'est la phase d'authentification, où un module de DAC tel NGO Van Cong – Promotion 10 – IFI 42 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif que le mod_auth vérifie les certificats d'utilisateur pour voir si ils sont connus dans la base de données qu'il a été employée auth_checker C'est la phase où l'autorisation se produit, les modules comme le mod_auth vérifient pour voir si on permet l'utilisateur (qui a été déjà authentifié) d'accéder au document Les modules qui imposent les contrôles d'accès discrétionnaires participent habituellement aux deux dernières phases Gestion par un accès direct subversion 2.1 Introduction Puisque subversion fonctionne avec le serveur apache, donc il dépend beaucoup de la méthode de sécurité qu’apache fournit Donc nous avons abordé des méthodes de sécurité d’apache et maintenant nous étudions les aspects de coordination avec subversion Apache est un serveur de web très populaire, il utilise le module mod_dav_svn pour accéder aux dépôts de subversion Grâce au module mod_dav_svn, un client de protocole WebDAV/DeltaV peut voir les contenus du dépôt de Subversion Donc il faut avoir une stratégie pour protéger les dépôts de subversion par un accès direct d’un client WebDAV/Deltav 2.2 Modèle de sécurité d’Apache et Subversion Figure 15: Modèle de sécurité d'Apache et Subversion Pour la sécurité de subversion, pour l’étape d’authentification nous appliquons les méthodes de vérification d’Apache comme mod_auth_mysql, mod_auth_ldap etc En fait NGO Van Cong – Promotion 10 – IFI 43 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif chaque méthode a des avantages Pour la méthode LDAP on peut stocker les bases de données de l’utilisateur sur un annuaire LDAP qui nous permet de chercher des utilisateur rapidement et de plus on peut partager cet annuaire avec d’autres applications 2.3 Autorisation Pour l’étape d’autorisation, En fait il y a deux niveau d’autorisation, l’un permet tous les utilisateurs qui ont passé l’étape d’authentification d'avoir tous les droits ou juste accès certaines opérations sur un dépôt DAV svn SVNParentPath /usr/local/svn AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/users/file Require valid-user Sur l’exemple ci-dessus, nous spécifions que les opération part des opérations : GET PROPFIND OPTIONS REPORT doivent passer l’authentification avant de manipuler le dépôt Cette configuration ne nous permet pas d’autoriser l’accès une certaine partie de dépôt Ceux qui ont passé l’authentification ont le droit de lire ou écrire sur tout le dépôt Pour les gens qui veulent diviser l’accès par l’utilisateur ou par groupe d’utilisateur Subversion a construit un sous-module de mod_dav_svn, c’est mod_authz_svn qui nous permet de contrôler l’accès au dépôt par répertoire Avec le mod_authz, soit on déclare des utilisateurs dans un fichier texte soit on peut les récupérer partir d’un annuaire LDAP Voici un exemple de l’utilisation de mod_authz DAV svn SVNParentPath /usr/local/svn AuthzSVNAccessFile /path/to/access/file Le directive AuthzSVNAccessFile permet de spécifier le fichier texte qui définit les droit d’accès de chaque utilisateur ou chaque groupe d’utilisateur La syntaxe de fichier d’accès est familière avec le fichier de configuration d’Apache NGO Van Cong – Promotion 10 – IFI 44 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Chaque section commence par le nom de dépôt et le chemin dans dépôt [nom de dépơt: chemin dans dépơt] dans le cas ó on a plusieurs dépôt, par contre dans le cas on a juste un dépôt une section commence par [chemin dans dépôt] Au sein de chaque section, on définit des utilisateurs authentifiés avec des droits associés Un utilisateur peut avoir le droit d’accès r (read) ou rw(read-write), si l'utilisateur n'est pas mentionné du tout, on ne permet aucun accès [projet:/branches/projet] harry = rw sally = r Sur l’exemple au dessus, on a spécifié que avec le chemin « /branches/projet » dans le dépơt « projet«, l’utilisateur « harry » a le droit de lecture et d’écriture et l’utilisateur « sally » a seulement le droit de lecture, les autres ne peuvent pas accéder ce chemin Pour spé cifier tous les utilisateur on peut utiliser le « *« Des permissions sont héritées du répertoire parent au répertoire enfant, cela signifie que nous pouvons indiquer un sous-répertoire avec une politique d'accès différente de celle du répertoire parent, parce que le chemin le plus spécifique est toujours considéré d'abord Le module mod_authz essaye de comparer le chemin lui-même, et puis le parent du chemin, ceci de manière récursive L'effet de cela est toujours un chemin le plus spécifique dans le dépassement de fichier d’accès Le mod_authz nous permet également de définir des groupes d'utilisateurs La section de groupe commence par [groups] [groups] projet1-developers = harry, sally, joe projet2-developers = frank, sally, jane everyone = harry, sally, joe, frank, sally, jane Et après on peut assigner les permissions chaque groupe comme on fait avec l’utilisateur [projet1:/project1/source] @projet1-developers = rw [projet2:/project2/source] @projet2-developers = rw jane = r Autorisation vers un serveur LDAP [16] Pour que le mod_authz_svn puisse travailler avec le serveur LDAP, tout d’abord on a besoin de spécifier l’adresse de serveur LDAP avec la directive AuthzSVNLDAPURL Dans le cas où on veut que mod_authz travaille avec un groupe par défaut, c’est le group ayant le NGO Van Cong – Promotion 10 – IFI 45 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif même nom que le nom du dépôt Pour cela on active ce mode avec la directive AuthzSVNLDAPEnableDefaultGroup et aussi déclarer le domaine combiné avec le groupe défaut avec la directive AuthzSVNLDAPBindDN Voici un exemple de la configuration de mod_authz avec serveur LDAP DAV svn SVNParentPath /usr/local/svn AuthzSVNLDAPURL http://porphyre.int-evry.fr?dc=int-evry,dc=fr AuthzSVNLDAPEnableDefaultGroup on AuthzSVNLDAPBindDN ou=group,dc=int-evry,dc=fr AuthzSVNAccessFile /path/to/access/file Et dans le cas on étend le mode défaut group, on peut déclarer des groups de ldap dans le fichier d’accès, le group de ldap commence par le terme ‘ldap:’ Voici un exemple utilisant le groupe de ldap dans le fichier d’accès [groups] projet1-developers = harry, sally, joe group-ldap = ldap:cn=group1,ou=group,dc=int-evry,dc=fr Et après on peut assigner les permissions groupe ldap comme on fait avec le groupe normal [projet1:/project1/source] @group-ldap = rw [projet2:/project2/source] @projet1-developers = rw harry=r NGO Van Cong – Promotion 10 – IFI 46 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Conclusions Dans le cadre de stage, nous avons proposé des solutions pour intégrer le gestionnaire de versions dans le gestionnaire de fichiers La raison de choix de Subverison pour remplacer CVS Nous avons décidé de réutiliser des méthodes de WebDAV, qui est déjà inplémenté dans le gestionnaire de fichiers, en ajoutant des méthodes de protocole DeltaV pour supporter le fonction de gestion des révisions de document Chaque fois qu'on effectue des fonctions comme mis jour, modification ou création sur une ressource, la version de ce ressource change et la verison ancienne de celle est stocké dans l'historique Un nouveau module appelé DeltaV a été ajouté dans la nouvelle version 0.18 de l'APIs de phpGroupWare Nous avons aussi étudié sur les problèmes de sécurité entre Subverison et Apache Lorsqu'on introduit les ressources sur le Web, la sécurité devient la plus inportante, on doit faire face de nombre risque d'attaque Nous avons aussi changé le module mod_authz_svn[1] pour qu'il puisse travailler avec un serveur LDAP Dans un contexte d'utilisation de Subversion pour PicoLibre, on a ajouté l'application picolibre_svn pour intégrer Subversion dans PicoLibre(en détail dans l'annexe A) NGO Van Cong – Promotion 10 – IFI 47 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Bibliographie [1] Un livre de Subversion http://svnbook.red-bean.com [2] Site de projet WebDAV http://webdav.org [3] Site de projet SAX http://www.saxproject.org/ [4] Site de projet picolibre http://picolibre.enst-bretagne.fr/projects/pecores/ [5] http://coopx.eu.org [6] Un paquêtage d'un wrapper de libsvn_client http://pecl.php.net/package/svn [7] http://www.faqs.org/rfcs/rfc3744.html [8] http://www.linuxplanet.com/linuxplanet/tutorials/1527/2/ [9] Berger O., C Bac, and B Hamet, 2006, Integration of Libre Software Applications to Create a Collaborative Work Platform for Researchers at GET, International Journal of Information Technology and Web Engineering (3), 2006 [10] C Bac, Berger O., B Hamet, ProGET : Plate-forme de travail collaboratif destinée aux enseignants/chercheurs du GET [11] William Nagel, 2005, Using The Subversion Version Control System in Development Projects [12] Adriaan de Groot, 2006, Practical Subversion – an Activist Primer [13] Site de projet DeltaV http://webdav.org/deltav [14] Site de projet phpGroupWare http://phpgroupware.org [15] Site de projet XML http://xml.com [16] http://www.linux-france.org/article/serveur/ldap/ [17] Jail Chrooted Project, http://www.gsyc.inf.uc3m.es/~assman/jail/index.html [18] Site de protocole HTTP 1.1 http://asg.web.cmu.edu/rfc/rfc2068.html [19] Site de projet GNU http://www.gnu.org/ NGO Van Cong – Promotion 10 – IFI 48 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Annexe A: Intégration Subverison dans Picolibre Introduction Actuellement, PicoLibre utilise CVS comme un logiciel pour gérer source de code, mais avec le temps CVS a des limites, Subverison est un choix pour le remplacer donc nous avons décidé d'intégrer Subverison dans la version prochaine de Picolibre On ajoute une nouvelle application phpGroupWare appellée picolibre_svn qui gère les travails concernant au Subversion Quand un projet est créé dans Picolibre, cette application crée un répertoire de source dans le dépôt de Subversion et permet cet utilisateur de connecter et récupérer le source de projet Implémentation Subverison fonctionne comme un serveur indépendant, chaque fois l'utilisateur veut connecter au serveur, il utilise un protocole propriétaire qui peut passer par une connexion de SSH De coté serveur, les comptes et les droits d'accès est stocké dans un annuaire LDAP et contrôlé par le système d'exploitation L'authentification système par un annuaire LDAP permet d'unifier les bases de données utilisateur De plus le système de répartition et de réplication que procure ce type d'annuaire permet une meilleure tolérance aux pannes Enfin d'autres services peuvent tirer partie de cette base commune d'authentification (email, accès web, ftp, carnet d'adresse ) Configuration de serveur De côté serveur, un serveur LDAP doit être installé et configuré Le serveur LDAP utilisé est OpenLDAP En ce moment, il y a deux implémentation de LDAP: un V2 implémentation (OpenLDAP 1.2.x) et un V3 implémentation(OpenLDAP 1.3.x) Le svnserve doit aussi être installé, c'est le serveur de Subverison, svnserve est fonctionné dans l'environnement chrooted par jail[17] Configuration de client Name Service Switch(NSS) et nss_ldap.so NSS (Name Service Switch, commutateur de services de nommages), permet de fournir Unix non des services d'authentification, mais des services de correspondances entre noms, de toutes sortes (noms de machines et noms d'utilisateurs intelligibles par l'homme, par exemple), NGO Van Cong – Promotion 10 – IFI 49 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif et les identifiants de ces mêmes objets pour la machine (adresses IP et uid/gid dans notre exemple) NSS, comme PAM, est composé de greffons sous formes de bibliothèques dynamiques, Le paramétrage est plus limité, non unifié entre eux (au contraire de PAM), et se fait principalement dans /etc/nsswitch.conf passwd: shadow: group: Figure 16: Mécanisme de NSS Authentification:PAM et pam_ldap.so Les PAM (Pluggable Authentication Modules, modules d'authentification enfichables) permettent de paramétrer l'envi les procédures et sources d'authentification, mais aussi d'offrir des services supplémentaires aux programmes qui savent les utiliser C'est un premier pas pour la mise en place d'un SSO (Single Sign-On, authentification unique en franỗais) sur un systốme Unix/Linux Le paramétrage des greffons se fait dans les fichiers /etc/pam.conf ou /etc/pam.d/*, suivant les distributions #%PAM-1.0 auth auth auth sufficient required required account sufficient NGO Van Cong – Promotion 10 – IFI 50 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif account password password password session required required sufficient required sufficient session required Figure 17: Mécanisme de PAM NGO Van Cong – Promotion 10 – IFI 51 ... IFI 28 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Chapitre 3: Intégration de système de gestion de versions dans le gestionnaire de fichiers... IFI 41 Intégration d'un gestionnaire de versions pour les documents dans le portail de travail collaboratif Les modules de sộcuritộ reỗoivent les informations sur les bases de données d'authentification... de versions pour les documents dans le portail de travail collaboratif Conclusions Dans le cadre de stage, nous avons proposé des solutions pour intégrer le gestionnaire de versions dans le gestionnaire