Changes between Version 3 and Version 4 of InsiaAdminSysSvn


Ignore:
Timestamp:
Mar 31, 2007, 1:11:23 AM (14 years ago)
Author:
Vincent Caron
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • InsiaAdminSysSvn

    v3 v4  
    7474Il est très simple de créer un repository, il prendra la forme d'un répertoire contenant un ensemble de fichiers variés. Il existe deux formats de repository, donc '''bdb''' qui devient obsolète (et ne fonctionne pas sur NFS). Exemple:
    7575{{{
    76 ~/repository$ svnadmin create --fs-type fsfs projet1
     76/tmp/repository$ svnadmin create --fs-type fsfs projet1
    7777}}}
    7878
     
    8181On peut se passer d'un serveur spécifique et utiliser directement les fichiers, y compris via NFS pourvu que le serveur gère correctement le ''locking'' (courant avec NFSv3). Dans ce cas un client peut obtenir une copie de travail très simplement:
    8282{{{
    83 ~/work$ svn checkout ~/repository/projet1
     83~/work$ svn checkout file:///tmp/repository/projet1
    8484~/work$ cd projet1
    8585~/work/projet1$
    8686}}}
     87
     88Les droits d'accès sont naturellement gérés par le système de fichiers et peuvent être exploités en tant que tel. Il est très classique de créer un groupe Unix correspondant à un projet et d'autoriser les utilisateurs à participer en les incluant (ou non) dans ce groupe. Côté administratif la solution est triviale:
     89{{{
     90/tmp/repository$ chgrp -R codeurs projet1
     91}}}
     92
     93=== Via svnserve ===
     94
     95Il s'agit du protocol réseau "natif" de Subversion, il peut être utilisé de deux façons:
     96 * en lançant explicitement le démon '''svnserve'''
     97 * en gérant le démon '''svnserve''' via le superdémon ''inetd'' (classique)
     98
     99Dans ce modèle, l'authentification et l'autorisation suit un modèle très simple, basé sur les informations contenues côté repository dans conf/svnserve.conf:
     100 * {{{anon-access = none}}} : aucun accès public, authentification requise en lecture '''et''' écriture
     101 * {{{anon-access = read}}} : on a un accès en lecture publique, les écritures doivent être authentifiées
     102 * {{{anon-access = write}}} : on a un accès lecture/écriture publique
     103
     104L'authentification se fait via un fichier de mot de passe contenant des identifiants et des mots de passe en clair (voir l'option {{{password-db}}}).
     105
     106Les autorisations sont plus simples car le serveur tourne sous une identité Unix prédéfinie, donc le système de fichiers n'est pas une solution praticable pour moduler les accès. Il est possible de gérer des accès basé sur le chemin (voir {{{authz-db}}}).
     107
     108Le client peut alors obtenir en copie de travail avec:
     109{{{
     110~/work$ svn checkout svn://serveur/projet1
     111}}}
     112
     113Le port standard de ''svnserve'' est '''TCP/3690'''.
     114
     115=== Via SSH ===
     116
     117Il s'agit de l'option la plus commune. Elle a l'avantage de combiner l'utilisation native des droits du système de fichier, le transport omniprésent et sécurisé de SSH et ses divers mécanismes d'authentification (notamment par clé publique, évitant la gestion de mot de passe).
     118
     119Si le serveur à un démon SSH opérationnel, le client peut obtenir une copie de travail simplement:
     120{{{
     121~/work$ svn checkout svn+ssh://serveur/tmp/repository/projet1
     122}}}
     123
     124On remarque qu'il s'agit tout simplement du tunneling du protocole ''svnserve'' via SSH (on voit effectivement des processus ''svnserve'' côté serveur).