Le plus facile est de démarrer svnserve en tant que serveur autonome. Pour ce faire, utilisez l'option -d (d pour « daemon » qui est l'appellation consacrée pour les serveurs Unix) :

$ svnserve -d
$               # svnserve est maintenant actif, en écoute sur le port 3690

Lorsque vous lancez svnserve en serveur autonome, vous pouvez utiliser les options --listen-port et --listen-host pour spécifier le port et l'adresse voulus pour « écouter ».

Une fois le serveur démarré de cette manière, tous les dépôts présents sur votre machine seront accessibles par le réseau. Un client doit spécifier un chemin absolu dans l'URL du dépôt. Par exemple, si un dépôt est situé sous /var/svn/projet-1, un client l'atteindra par svn://hote.exemple.com/var/svn/projet-1. Pour renforcer la sécurité, vous pouvez passer l'option -r à svnserve afin de restreindre l'export aux dépôts situés sous le chemin indiqué. Par exemple :

$ svnserve -d -r /var/svn
…

L'utilisation de l'option -r modifie le chemin que le serveur considère comme la racine du système de fichiers à exporter. Les clients utiliseront alors des URL ne comportant pas cette portion du chemin (ce qui rend les URL plus courtes et plus discrètes) :

$ svn checkout svn://hote.exemple.com/projet-1
…

Si vous désirez que inetd lance le processus, il vous faudra passer l'option -i (--inetd). Dans l'exemple suivant, nous montrons le résultat de la commande svnserve -i, mais notez bien que ce c'est pas de cette manière que l'on démarre le serveur ; reportez-vous aux paragraphes qui suivent l'exemple pour savoir comment configurer inetd pour qu'il démarre svnserve.

$ svnserve -i
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )

Quand on l'invoque avec l'option --inetd, svnserve tente de communiquer avec un client Subversion via l'entrée et la sortie standards (stdin et stdout) en utilisant un protocole spécifique. C'est le comportement habituel de tout programme lancé par inetd. L'IANA a réservé le port 3690 pour le protocole Subversion ; sur un système Unix vous pouvez donc ajouter au fichier /etc/services les lignes suivantes (si elles n'existent pas déjà) :

svn           3690/tcp   # Subversion
svn           3690/udp   # Subversion

Si votre système utilise un serveur inetd classique de type Unix, vous pouvez ajouter la ligne suivante à /etc/inetd.conf :

svn stream tcp nowait proprio-svn /usr/bin/svnserve svnserve -i

Assurez-vous que l'utilisateur « proprio-svn » possède des droits d'accès appropriés pour vos dépôts. Dès lors, quand une connexion client arrive sur le port 3690, inetd va créer un processus svnserve pour lui répondre. Bien sûr, vous pouvez également ajouter l'option -r à cette ligne de configuration, pour préciser quels dépôts doivent être exportés.

Le mode tunnel est une troisième façon de lancer svnserve, via l'option -t. Ce mode présuppose qu'un programme de connexion à distance tel que rsh ou ssh a permis à un utilisateur de s'authentifier avec succès et lance alors un processus privé svnserve pour le compte de cet utilisateur (remarquez qu'en tant qu'utilisateur vous aurez rarement, sinon jamais, l'occasion de lancer svnserve avec l'option -t en ligne de commande ; c'est le serveur SSH qui le fait à votre place). Le programme svnserve se comporte alors normalement (utilisation des entrées/sorties stdin et stdout) et suppose que le trafic est redirigé automatiquement vers le client par un tunnel. Quand svnserve est lancé par un gestionnaire de tunnel comme ici, soyez sans crainte : l'utilisateur authentifié possédera les droits de lecture et d'écriture sur les fichiers de la base de données. C'est essentiellement la même chose que quand un utilisateur local accède au dépôt via des URL file://.

Cette option est décrite en détail plus loin dans ce chapitre, dans la section intitulée « Encapsulation de svnserve dans un tunnel SSH ».

Si votre système Windows est un descendant de Windows NT (2000, 2003, XP ou Vista), vous pouvez lancer svnserve en tant que service Windows. C'est généralement une méthode bien plus plaisante que de le lancer en démon indépendant via l'option (-d). Utiliser le mode démon nécessite de lancer une console, de taper une commande et ensuite de laisser la fenêtre de la console tourner indéfiniment. Un service Windows, au contraire, tourne à l'arrière-plan, peut être lancé automatiquement au démarrage et peut être démarré ou arrêté à l'aide de la même interface d'administration que les autres services Windows.

Vous devrez définir le nouveau service en utilisant l'outil en ligne de commande SC.EXE. De façon analogue à la ligne de configuration inetd, il vous faudra fournir la commande de lancement précise de svnserve pour que Windows le lance au démarrage :

C:\> sc create svn
        binpath= "C:\svn\bin\svnserve.exe --service -r C:\depot"
        displayname= "Serveur Subversion"
        depend= Tcpip
        start= auto

Ceci définit un nouveau service Windows nommé « svn », qui exécute une commande particulière svnserve.exe quand il démarre (dont la racine est, dans ce cas, C:\depot). Il y a toutefois un certain nombre de précautions à prendre avec cet exemple.

Premièrement, remarquez que le programme svnserve.exe doit toujours être lancé avec l'option --service. Toute autre option de svnserve doit ensuite être spécifiée sur la même ligne, mais vous ne pouvez pas ajouter d'options qui seraient en conflit avec celle-ci, telles que --daemon (-d), --tunnel, ou --inetd (-i). D'autres options, comme -r ou --listen-port ne posent pas de problème. Deuxièmement, faites attention aux espaces quand vous tapez la commande SC.EXE : les groupes clé= valeur ne doivent pas comporter d'espace dans clé= et doivent comporter exactement une espace avant valeur. Enfin, faites attention aux espaces présentes dans la ligne de commande que vous indiquez. Si le nom d'un répertoire contient des espaces (ou tout autre caractère qui ait besoin d'être banalisé), placez l'ensemble du contenu de binpath entre guillemets, qui doivent eux-mêmes être banalisés :

C:\> sc create svn
        binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\depot"
        displayname= "Serveur Subversion"
        depend= Tcpip
        start= auto

Notez aussi que le terme binpath prête à confusion : sa valeur est une ligne de commande, pas le chemin d'accès à un exécutable. C'est pourquoi vous devez l'entourer de guillemets s'il contient des espaces.

Une fois que le service a été crée, il peut être arrêté, démarré ou interrogé à l'aide des outils standards de l'interface graphique (le programme « Services » des outils d'administration) ou de la ligne de commande :

C:\> net stop svn
C:\> net start svn

Le service peut aussi être désinstallé (c'est-à-dire supprimé) en effaçant sa définition : sc delete svn. Prenez soin d'arrêter le service auparavant ! Le programme SC.EXE possède de nombreuses autres sous-commandes ; tapez sc /? en ligne de commande pour en savoir plus.

Pour ce qui suit, la section [general] de svnserve.conf contient toutes les variables dont vous avez besoin. Commencez par modifier les valeurs de toutes les variables : choisissez un nom pour le fichier qui contiendra vos noms d'utilisateur ainsi que vos mots de passe et choisissez un domaine d'authentification :

[general]
password-db = fichier-utilisateurs
realm = exemple de domaine

Le domaine (realm dans le fichier de configuration) est un nom que vous définissez. Il indique aux clients à quelle sorte d'« espace de noms » ils se connectent ; le client Subversion l'affiche dans l'invite d'authentification et l'utilise comme clé (en combinaison avec le nom de machine et le port du serveur) pour mettre en cache les éléments d'authentification sur le disque (voir la section intitulée « Mise en cache des éléments d'authentification du client »). La variable password-db pointe vers un fichier séparé qui contient une liste de noms d'utilisateurs et de mots de passe, utilisant le même format usuel. Par exemple :

[users]
harry = motdepassemachin
sally = motdepassebidule

La valeur de password-db peut correspondre à un chemin absolu ou à un chemin relatif pour le fichier des utilisateurs. Pour de nombreux administrateurs, conserver le fichier dans la zone conf/, aux côtés de svnserve.conf, est une solution simple et facile. D'un autre côté, il se pourrait que deux dépôts, voire plus, doivent partager le même fichier ; dans ce cas, le fichier devrait sans doute être situé dans un répertoire plus accessible. Les dépôts partageant le même fichier utilisateurs devraient aussi être configurés de sorte qu'ils soient dans le même domaine, puisque la liste des utilisateurs définit, par essence, un domaine d'authentification. Quel que soit l'emplacement du fichier, faites attention à positionner les droits en lecture/écriture de façon appropriée. Si vous savez sous quel nom d'utilisateur svnserve fonctionnera, restreignez l'accès au fichier utilisateurs en conséquence.

Il y a deux variables supplémentaires à définir dans le fichier svnserve.conf : elles déterminent ce que les utilisateurs non-authentifiés (anonymes) et les utilisateurs authentifiés ont le droit de faire. Les variables anon-access et auth-access peuvent contenir les valeurs none, read, ou write. Choisir la valeur none empêche à la fois lecture et écriture ; read autorise l'accès en lecture seule au dépôt et write autorise l'accès complet en lecture/écriture au dépôt. Par exemple :

[general]
password-db = fichier-utilisateurs
realm = exemple de domaine

# les utilisateurs anonymes ne peuvent accéder au dépôt qu'en lecture
anon-access = read

# les utilisateurs authentifiés peuvent à la fois lire et écrire
auth-access = write

Les lignes présentes dans le fichier contiennent en fait les valeurs par défaut des variables, au cas où vous oublieriez de les définir. Si vous voulez être encore plus prudent, vous pouvez complètement interdire les accès anonymes :

[general]
password-db = fichier-utilisateurs
realm = exemple de domaine

# les utilisateurs anonymes ne sont pas autorisés
anon-access = none

# les utilisateurs authentifiés peuvent à la fois lire et écrire
auth-access = write

Le processus serveur sait interpréter non seulement ce contrôle d'accès générique, mais aussi des restrictions d'accès plus fines associées à des fichiers et répertoires spécifiques du dépôt. Pour utiliser cette fonctionnalité, vous devez définir un fichier contenant des règles plus détaillées, puis faire pointer la variable authz-db vers ce fichier :

[general]
password-db = fichier-utilisateurs
realm = exemple de domaine

# Règles d'accès propres à certains emplacements
authz-db = fichier-authz

Nous étudions la syntaxe du fichier authz plus loin dans ce chapitre, dans la section intitulée « Contrôle d'accès basé sur les chemins ». Notez que la variable authz-db n'est pas mutuellement exclusive avec les variables anon-access et auth-access ; si toutes les variables sont définies en même temps, toutes les règles doivent être satisfaites pour que l'accès soit autorisé.

Pour activer les mécanismes spécifiques à SASL sur le serveur, il faut faire deux choses. D'abord, créez un paragraphe [sasl] dans le fichier svnserve.conf de votre dépôt avec le couple clé/valeur initial :

          [sasl]
          use-sasl = true

Ensuite, créez le fichier principal de configuration de SASL, appelé svn.conf, à un endroit où la bibliothèque SASL saura le trouver — généralement dans un répertoire où sont situés les greffons SASL. Vous devez localiser le répertoire des greffons de votre système, tel que /usr/lib/sasl2/ ou /etc/sasl2/ (notez qu'il ne s'agit pas là du fichier svnserve.conf qui réside dans votre dépôt !).

Sur un serveur Windows vous devez aussi éditer la base de registre (à l'aide d'un outil tel que regedit) pour indiquer à SASL les emplacements où chercher. Créez une clé nommée [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library] et placez-y deux clés : l'une appelée SearchPath (dont la valeur est le chemin du répertoire contenant les bibliothèques de greffons SASL sasl*.dll) et l'autre appelée ConfFile (dont la valeur est le chemin du répertoire parent contenant le fichier svn.conf que vous avez créé).

Parce que SASL fournit de très nombreux mécanismes d'authentification, il serait insensé (et bien au-delà du cadre de ce livre) d'essayer de décrire toutes les configurations serveurs possibles. Nous vous recommandons plutôt de lire la documentation fournie dans le sous-répertoire doc/ du code source de SASL. Elle décrit en détail chaque mécanisme, ainsi que la manière de configurer le serveur correctement pour chacun d'entre eux. Dans ce paragraphe, nous nous contentons de donner un exemple simple de configuration du mécanisme DIGEST-MD5. Par exemple, si votre fichier subversion.conf (ou svn.conf) contient ce qui suit :

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/ma_bdd_sasl
mech_list: DIGEST-MD5

vous demandez à SASL de proposer le mécanisme DIGEST-MD5 aux clients et de comparer les mots de passe des utilisateurs à une base de mots de passe privée située à l'emplacement /etc/ma_bdd_sasl. Un administrateur système pourra ensuite utiliser le programme saslpasswd2 pour ajouter ou modifier les noms d'utilisateurs et les mots de passe contenus dans cette base de données :

$ saslpasswd2 -c -f /etc/ma_bdd_sasl -u domaine utilisateur

Quelques consignes de prudence : tout d'abord, l'argument « domaine » qui est passé à saslpasswd2 doit correspondre au même domaine que celui que vous avez défini dans le fichier svnserve.conf ; s'ils ne correspondent pas, l'authentification échouera. En outre, à cause d'une limitation de SASL, ce domaine commun doit être une chaîne sans espace. Enfin, si vous décidez d'utiliser la base de données standard de mots de passe SASL, assurez-vous que le programme svnserve a accès en lecture à ce fichier (et éventuellement aussi en écriture, si vous utilisez un mécanisme tel que OTP).

Ceci est une manière simple de configurer SASL. De nombreux autres mécanismes d'authentification sont disponibles et les mots de passe peuvent être conservés dans des conteneurs différents, par exemple des annuaires LDAP ou des bases de données SQL. Reportez-vous à la documentation complète de SASL pour plus de détails.

Souvenez-vous que si vous configurez votre serveur pour qu'il n'autorise que certains mécanismes d'authentification SASL, tous les clients qui se connectent ont l'obligation de supporter SASL. Tout client Subversion compilé sans SASL (ce qui inclut tous les clients antérieurs à la version 1.5) est incapable de se connecter. D'un autre côté, ce type de restriction est peut-être exactement ce que vous recherchez (« Mes clients doivent tous utiliser Kerberos ! »). Néanmoins, si vous voulez permettre à des clients non-SASL de se connecter, pensez bien à inclure le mécanisme CRAM-MD5 dans les choix possibles. Tous les clients savent utiliser CRAM-MD5, qu'ils aient des fonctionnalités SASL ou pas.

SASL est également capable d'effectuer le chiffrement des données si un mécanisme particulier le supporte. Le mécanisme intégré CRAM-MD5 ne supporte pas le chiffrement, mais DIGEST-MD5 le supporte et d'autres mécanismes tels que SRP requièrent l'utilisation de la bibliothèque OpenSSL. Pour activer ou désactiver différents niveaux de chiffrement, vous pouvez définir deux variables dans le fichier svnserve.conf de votre dépôt :

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

Les variables min-encryption et max-encryption contrôlent le niveau de chiffrement exigé par le serveur. Pour désactiver complètement le chiffrement, mettez les deux valeurs à 0. Pour activer une simple somme de contrôle sur les données (par exemple pour empêcher toute manipulation douteuse et garantir l'intégrité des données sans chiffrement), mettez les deux valeurs à 1. Si vous voulez autoriser le chiffrement, sans que ce soit obligatoire, mettez 0 pour la valeur minimale et un nombre de bits donné pour la valeur maximale. Pour exiger un chiffrement inconditionnel, mettez les deux valeurs à un nombre plus grand que 1. Dans l'exemple précédent, nous obligeons les clients à utiliser au moins un chiffrement 128 bits et au plus un chiffrement 256 bits.

Pour commencer, localisez le répertoire « home » du compte utilisateur que vous utilisez pour lancer svnserve. Assurez-vous que ce compte possède un bi-clé de clés publique/privée et que l'utilisateur peut se connecter en s'authentifiant par la méthode à clé publique. L'authentification par mot de passe ne fonctionnera pas, puisque toutes les astuces SSH qui suivent consistent à utiliser le fichier authorized_keys.

S'il n'existe pas déjà, créez le fichier authorized_keys (sur Unix, c'est généralement ~/.ssh/authorized_keys). Chaque ligne de ce fichier décrit une clé publique autorisée à se connecter. Ces ligne sont généralement de la forme :

  ssh-dsa AAAABtce9euch… utilisateur@exemple.com

Le premier champ décrit le type de clé, le second champ est la clé elle-même, encodée en base 64, et le troisième champ est un commentaire. Cependant, c'est un fait moins connu que la ligne toute entière peut être précédée par un champ command :

  command="programme" ssh-dsa AAAABtce9euch… utilisateur@exemple.com

Quand le champ command est présent, le serveur SSH va lancer le programme indiqué en lieu et place de l'habituel svnserve en mode tunnel que le client Subversion a demandé. En découlent un certain nombre d'astuces côté serveur. Dans les exemples suivants, nous abrégeons les lignes du fichier par :

  command="programme" TYPE CLÉ COMMENTAIRE

Comme nous pouvons spécifier la commande exécutée côté serveur, il devient facile de désigner un exécutable svnserve spécifique et d'y passer des arguments supplémentaires :

  command="/chemin/vers/svnserve -t -r /racine/virtuelle" TYPE CLÉ COMMENTAIRE

Dans cet exemple, /chemin/vers/svnserve peut être un script personnalisé construit autour de svnserve qui spécifie le umask à utiliser (voir la section intitulée « Accès au dépôt par plusieurs méthodes »). Il indique aussi comment « ancrer » svnserve dans un répertoire racine virtuel, ce qui est aussi très souvent utilisé quand svnserve fonctionne en tant que démon. Le but est soit de restreindre l'accès à certaines parties du système, soit simplement d'éviter que l'utilisateur ait à taper un chemin absolu dans l'URL svn+ssh://.

Il est également possible d'avoir plusieurs utilisateurs partageant un compte utilisateur unique. Au lieu de créer un compte système distinct pour chaque utilisateur, générez plutôt un bi-clé de clés publique/privée pour chaque personne. Placez ensuite chaque clé publique dans le fichier authorized_users, une par ligne, et utilisez l'option --tunnel-user :

  command="svnserve -t --tunnel-user=harry" TYPE1 CLÉ1 harry@exemple.com
  command="svnserve -t --tunnel-user=sally" TYPE2 CLÉ2 sally@exemple.com

Cet exemple permet à la fois à Harry et à Sally de se connecter au même compte utilisateur avec l'authentification via leur clé publique. Chacun d'eux doit exécuter une commande qui lui est propre ; l'option --tunnel-user signale à svnserve que l'argument fourni doit être considéré comme le nom de l'utilisateur authentifié. Sans --tunnel-user, toutes les propagations sembleraient venir du même compte utilisateur partagé.

Finalement, un dernier avertissement : autoriser l'accès d'un utilisateur au serveur via une clé publique dans un compte partagé n'empêche pas forcément d'autres formes d'accès SSH, même si vous avez spécifié une valeur pour le champ command dans le fichier authorized_keys. Par exemple, l'utilisateur aura toujours accès au shell via SSH, il sera capable d'effectuer de la redirection X11 ou de la redirection d'un port quelconque de votre serveur. Pour accorder le moins de droits possibles à l'utilisateur, vous pouvez spécifier des options de restriction immédiatement après la commande du champ command :

  command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-for
warding,no-X11-forwarding,no-pty TYPE1 CLÉ1 harry@exemple.com

Notez bien que tout ceci doit tenir sur une seule ligne, vraiment sur une seule ligne, car les fichiers SSH authorized_keys n'autorisent même pas le caractère habituel de continuation de ligne (\). L'unique raison pour laquelle nous avons rajouté une coupure est pour que cela tienne dans le format physique d'un livre.