This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

httpd, le serveur HTTP Apache
Précédent  Chapitre 6. Configuration du serveur  Suivant

httpd, le serveur HTTP Apache

Le serveur HTTP Apache est un serveur réseau à tout faire que Subversion sait exploiter. ViaVia un module adapté, httpd rend les dépôts Subversion accessibles aux clients par le protocole WebDAV/DeltaV[64], qui est une extension de HTTP 1.1. Ce protocole se base sur HTTP, le protocole omniprésent à la base du World Wide Web, lui ajoute des fonctionnalités d'écriture et, en particulier, d'écriture avec gestion de versions. Le résultat est un système robuste et standardisé qui est inclus dans le logiciel Apache 2.0, supporté par de nombreux systèmes d'exploitation et outils tiers, et qui ne demande pas aux administrateurs réseaux d'ouvrir un port réseau supplémentaire[65]. Bien qu'un serveur Apache-Subversion ait plus de fonctionnalités que svnserve, il est aussi un peu plus difficile à mettre en place. La flexibilité a bien souvent pour contrepartie la complexité.

Une grande partie de ce qui va suivre fait référence à des directives de configuration d'Apache. Bien que l'utilisation de ces directives soit illustrée par quelques exemples, les décrire complètement va bien au-delà du sujet de ce chapitre. L'équipe Apache tient à jour une documentation excellente, disponible publiquement sur leur site web à l'adresse https://httpd.apache.org. Par exemple, le guide de référence complet des directives de configuration est situé à l'adresse https://httpd.apache.org/docs/current/mod/directives.html.

En outre, au fur et à mesure des changements que vous apporterez à votre configuration d'Apache, il est probable que vous commettrez des erreurs. Si vous n'êtes pas déjà familier avec le sous-système de journalisation d'Apache, vous devrez apprendre à le connaître. Dans votre fichier httpd.conf, des directives spécifient l'emplacement sur le disque des journaux d'accès et d'erreurs générés par Apache (les directives CustomLog et ErrorLog respectivement). Le module mod_dav_svn de Subversion utilise également l'interface de journalisation des erreurs d'Apache. Pensez à naviguer dans ces fichiers lorsque vous recherchez des informations susceptibles de vous aider à trouver l'origine d'un problème.

Prérequis

Pour mettre à disposition votre dépôt sur le réseau par HTTP, il vous faut quatre composants, disponibles dans deux paquets. Il vous faut Apache httpd 2.0 ou plus récent, le module DAV mod_dav fourni avec, Subversion et le module mod_dav_svn implémentant le système de fichiers, qui est fourni avec Subversion. Une fois que vous avez tous ces composants, la procédure de mise en réseau de votre dépôt est aussi simple que :

  • faire fonctionner httpd avec le module mod_dav ;

  • installer le module mod_dav_svn derrière mod_dav (mod_dav_svn utilise les bibliothèques Subversion pour accéder au dépôt) ;

  • configurer le fichier httpd.conf pour exporter (ou « exposer ») le dépôt.

Vous pouvez accomplir les deux premières tâches citées supra soit en compilant httpd et Subversion à partir du code source, soit en installant les paquets binaires précompilés correspondants sur votre système. Les informations les plus récentes sur la façon de compiler Subversion dans le cadre d'une utilisation en conjonction avec le serveur HTTP Apache, sur la compilation et sur la configuration d'Apache lui-même dans cet objectif, sont consultables dans le fichier INSTALL situé à la racine de l'arborescence du code source de Subversion.

Configuration Apache de base

Une fois que les composants requis sont installés sur votre système, il ne reste plus qu'à configurer Apache au moyen de son fichier httpd.conf. Indiquez à Apache de charger le module mod_dav_svn grâce à la directive LoadModule. Cette directive doit précéder tout autre élément de configuration lié à Subversion. Si votre serveur Apache a été installé avec la configuration par défaut, votre module mod_dav_svn devrait avoir été installé dans le sous-répertoire modules du répertoire d'installation d'Apache (souvent /usr/local/apache2). La directive LoadModule a une syntaxe très simple, faisant correspondre un nom de module à l'emplacement sur le disque d'une bibliothèque partagée :

LoadModule dav_svn_module     modules/mod_dav_svn.so

Apache interprète le chemin donné dans la directive LoadModule comme étant relatif à sa propre racine. Si vous l'avez configuré comme indiqué supra, Apache cherchera le module Subversion DAV dans son propre sous-dossier modules/. En fonction de la façon dont Subversion a été installé sur votre machine, vous aurez peut-être besoin de spécifier un chemin différent pour cette bibliothèque, voire un chemin absolu comme dans l'exemple suivant :

LoadModule dav_svn_module     C:/Subversion/libexec/mod_dav_svn.so

Notez que si mod_dav a aussi été compilé sous forme de bibliothèque partagée (et non par une édition de liens statiques qui le place alors directement dans l'exécutable httpd), il vous faudra une directive LoadModule pour celui-ci. Assurez-vous qu'elle est placée avant la ligne mod_dav_svn :

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so

Plus loin dans votre fichier de configuration, vous devez indiquer à Apache l'endroit où réside votre dépôt (ou vos dépôts) Subversion. La directive Location possède une syntaxe de type XML, qui commence par une balise de début, se termine par une balise de fin et contient diverses autres directives de configuration au milieu. Le sens de la directive Location est de faire faire à Apache quelque chose de spécial quand il traite les requêtes adressées à une URL donnée ou à une de ses filles. Dans le cas de Subversion, il faut qu'Apache fasse traiter par la couche DAV les URL pointant vers les ressources suivies en versions. Vous pouvez indiquer à Apache de déléguer le traitement de toutes les URL dont la partie chemin d'accès (la partie de l'URL qui suit le nom du serveur et le numéro de port optionnel) commence par /depot/ à un gestionnaire de DAV dont le dépôt est situé à l'adresse /var/svn/mon-depot en utilisant la syntaxe httpd.conf suivante :

<Location /repos>
  DAV svn
  SVNPath /var/svn/mon-depot
</Location>

Si vous avez l'intention de gérer plusieurs dépôts Subversion résidant dans le même répertoire parent sur votre disque local, vous pouvez utiliser une directive alternative, SVNParentPath, pour faire état de ce répertoire parent commun. Par exemple, si vous savez que vous allez créer plusieurs dépôts Subversion dans le répertoire /var/svn, auxquels on accédera par des URL telles que http://mon.serveur.com/svn/depot1, http://mon.serveur.com/svn/depot2, etc., vous pouvez utiliser la syntaxe de configuration de httpd.conf de l'exemple suivant :

<Location /svn>
  DAV svn

  # à toute URL "/svn/truc" correspond un dépôt /var/svn/truc
  SVNParentPath /var/svn
</Location>

Par cette syntaxe, Apache va déléguer le traitement de toutes les URL dont le chemin d'accès commence par /svn/ au gestionnaire DAV de Subversion, qui ensuite supposera que tous les éléments du répertoire spécifié dans la directive SVNParentPath sont en fait des dépôts Subversion. C'est une syntaxe particulièrement pratique dans le sens où, à la différence de celles utilisant la directive SVNPath, vous n'avez pas besoin de redémarrer Apache pour mettre à disposition ou enlever de nouveaux dépôts sur le réseau.

Vérifiez bien que, quand vous définissez votre nouvelle directive Location, elle n'interfère pas avec d'autres emplacements exportés. Par exemple, si votre DocumentRoot (c'est-à-dire le répertoire racine des fichiers qu'Apache expose sur le web) principal est exporté vers /www, n'exportez pas de dépôt Subversion vers <Location /www/depot>. Si une requête arrivait pour l'URI /www/depot/machin.c, Apache ne saurait pas s'il doit chercher un fichier depot/machin.c dans son DocumentRoot ou s'il doit déléguer à mod_dav_svn la tâche de renvoyer machin.c qui se trouve dans le dépôt Subversion. Ceci aboutit souvent à une erreur du serveur de la forme 301 Moved Permanently.

Noms de serveur et requêtes COPY

Subversion se sert du type de requête COPY pour effectuer des copies de fichiers et de répertoires côté serveur. Les modules Apache vérifient que la source de la copie est bien située sur la même machine que la destination. Pour satisfaire cette exigence, vous aurez peut-être besoin de déclarer à mod_dav le nom d'hôte de votre serveur. En général, la directive ServerName du fichier httpd.conf peut être utilisée à cette fin.

ServerName svn.exemple.com

Si vous faites usage du support des hôtes virtuels d'Apache via la directive NameVirtualHost, la directive ServerAlias vous permettra de spécifier des noms additionnels désignant votre serveur. Encore une fois, reportez-vous à la documentation Apache pour plus de détails.

À présent, il nous faut examiner sérieusement la question des droits d'accès. Si vous utilisez Apache depuis un certain temps en tant que serveur web principal, vous hébergez certainement pas mal de contenu : des pages web, des scripts, etc. Ces éléments ont déjà été configurés avec un ensemble de droits qui leur permet de fonctionner avec Apache, ou plus exactement qui permet à Apache de travailler avec ces fichiers. Apache, quand on l'utilise en tant que serveur Subversion, a aussi besoin de droits d'accès corrects pour lire et écrire dans votre dépôt.

Vous devez mettre en place les droits d'accès qui satisfont les besoins de Subversion sans mettre à mal l'installation des pages web et scripts pré-existants. Ceci implique peut-être de modifier les droits d'accès de votre dépôt Subversion pour qu'ils correspondent à ceux utilisés par les autres éléments qu'Apache gère, ou bien utiliser les directives User et Group du fichier httpd.conf pour spécifier qu'Apache doit fonctionner avec l'identifiant et le groupe qui est propriétaire de votre dépôt Subversion. Il n'y a pas une façon unique de mettre en place les droits d'accès et chaque administrateur a ses propres raisons pour faire les choses d'une manière ou d'une autre. Soyez juste conscient que les problèmes liés aux droits d'accès sont peut-être le point le plus négligé lors de la configuration d'un dépôt avec Apache.

Options d'authentification

À ce stade, si vous avez configuré httpd.conf avec quelque chose du style :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
</Location>

votre dépôt est à présent accessible « anonymement » par tout le monde. Jusqu'à ce que configuriez des politiques d'authentification et de contrôle d'accès, les dépôts Subversion que vous rendez disponibles via la directive Location sont généralement accessibles à tous. En d'autres termes :

  • N'importe qui peut utiliser un client Subversion pour extraire une copie de travail d'une URL du dépôt (ou de n'importe lequel de ses sous-répertoires).

  • N'importe qui peut naviguer interactivement dans la dernière révision du dépôt rien qu'en allant avec un navigateur web à l'URL du dépôt.

  • N'importe qui peut effectuer des propagations vers le dépôt.

Bien sûr, vous avez peut-être déjà mis en place une procédure automatique pre-commit pour empêcher les propagations (voir la section intitulée « Mise en place des procédures automatiques »). Mais en progressant dans la lecture de ce chapitre, vous verrez qu'il est également possible d'utiliser les méthodes intégrées dans Apache pour restreindre les accès de façon spécifique.

[Astuce] Astuce

Demander une authentification vous protège contre les utilisateurs illégitimes qui accèdent au dépôt mais ne garantit la confidentialité des utilisateurs légitimes sur le réseau. Reportez-vous à la section intitulée « Encapsulation du trafic réseau avec SSL » pour savoir comment configurer votre serveur pour activer l'encapsulation SSL, ce qui apportera une couche supplémentaire de protection.

Mise en place de l'authentification HTTP basique

La manière la plus facile d'authentifier un client est le mécanisme d'authentification « Basic » de HTTP, qui utilise juste un nom d'utilisateur et un mot de passe pour vérifier que l'utilisateur est bien celui qu'il prétend être. Apache fournit l'utilitaire htpasswd[66] pour gérer la liste des noms d'utilisateurs et mots de passe acceptés.

[Avertissement] Avertissement

L'authentification basique est extrêmement peu sûre car elle envoie le mots de passe sur le réseau, pratiquement en clair. Lisez la section intitulée « Authentification par condensat (Digest) » pour obtenir des détails sur l'utilisation du mécanisme par condensat (digest en anglais) qui est beaucoup plus sûr.

Commençons par créer un fichier de mots de passe et donnons un accès à Sally et à Harry :

$ ### Première fois : utilisez -c pour créer le fichier
$ ### Ajoutez -m pour MD5 afin de chiffrer le mot de passe et ainsi le rendre plus sûr
$ htpasswd -cm /etc/auth-svn.htpasswd harry
New password: *****
Re-type new password: *****
Adding password for user harry
$ htpasswd -m /etc/auth-svn.htpasswd sally
New password: *******
Re-type new password: *******
Adding password for user sally
$

Ensuite, vous devez vérifier que Apache dispose des droits d'accès aux modules qui offrent l'authentification basique et les fonctionnalités afférentes : mod_auth_basic, mod_authn_file et mod_authz_user. Généralement, ces modules sont compilés dans httpd lui-même, mais si ce n'estpas le cas, vous devrez charger ceux qui ne le sont pas explicitement en utilisant la directive LoadModule :

LoadModule auth_basic_module   modules/mod_auth_basic.so
LoadModule authn_file_module   modules/mod_authn_file.so
LoadModule authz_user_module   moduels/mod_authz_user.so

Après vous être assuré que Apache a accès auxdites fonctionnalités, vous devrez ajouter quelques directives dans le bloc <Location> pour indiquer à Apache quel type d'authentification vous souhaitez utiliser et comment le faire :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentication: Basic 
  AuthName "Depot Subversion"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/auth-svn.htpasswd

</Location>

Ces directives fonctionnent ainsi :

  • AuthName est une chaîne de caractères arbitraire que vous choisissez pour définir le domaine d'authentification. La plupart des navigateurs affichent cette chaîne dans la boîte de dialogue au moment de demander le nom d'utilisateur et le mot de passe.

  • AuthType spécifie le type d'authentification à utiliser.

  • AuthBasicProvider spécifie le fournisseur de l'authentification basique pour cet emplacement. Dans notre exemple, nous consultons un fichier local de mots de passe.

  • AuthUserFile spécifie l'emplacement du fichier de mots de passe à utiliser.

Ce bloc <Location> n'est pas encore complet et il ne sert pas à grand chose pour l'instant. Il indique juste à Apache que, si un contrôle d'accès est requis, Apache doit demander un nom d'utilisateur et un mot de passe au client Subversion. En effet, dès qu'un contrôle d'accès est requis, Apache exige également l'authentification. Ce qui manque ici, cependant, ce sont les directives qui indiquent à Apache quelles sortes de requêtes client requièrent un contrôle d'accès ; pour l'instant, aucune requête n'en requiert. La chose la plus simple à faire alors est de spécifier que toutes les requêtes demandent un contrôle d'accès en ajoutant Require valid-user au bloc :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentification: basique
  AuthName "Depot Subversion"
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/auth-svn.htpasswd

  # contrôle d'accès : utilisateurs authentifiés seulement
  Require valid-user
</Location>

Prenez bien soin de lire la section intitulée « Contrôle d'accès » pour plus de détails sur la directive Require et sur les autres manières de mettre en œuvre des politiques de contrôle d'accès.

[Note] Note

La valeur par défaut pour l'option AuthBasicProvider est file, c'est pourquoi nous ne nous embêterons pas à la répéter dans les exemples futurs. Sachez seulement que si vous avez défini sa valeur à autre chose dans un contexte plus large, vous aurez à la redéfinir explicitement à file dans le bloc <Location> de Subversion pour obtenir le bon comportement.

Authentification par condensat (Digest)

La méthode d'authentification Digest, améliore la méthode basique dans le sens où elle permet au serveur de vérifier l'identité du client sans envoyer le mot de passe en clair sur le réseau. Chacun de leur côté, le client et le serveur calculent un condensat (hash ou digest en anglais) à partir de l'identifiant, du mot de passe, de l'URI demandée et d'un nonce (nombre utilisé une seule fois) fourni par le serveur et changé à chaque demande d'authentification. Le client envoie son condensat au serveur et celui-ci vérifie si le condensat correspond à ses attentes.

Configurer Apache pour la méthode d'authentification Digest est facile. En premier lieu, assurez-vous que le module mod_auth_digest est disponible (à la place de mod_auth_basic) et effectuez les petites variations suivantes par rapport à notre exemple précédent :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentification: condensat
  AuthName "Depot Subversion"
  AuthType Digest
  AuthDigestProvider file
  AuthUserFile /etc/auth-svn.htdigest

  # contrôle d'accès : utilisateurs authentifiés seulement
  Require valid-user
</Location>

Notez que AuthType vaut maintenant Digest et que nous avons spécifié un chemin différent pour AuthUserFile. L'authentification par condensat utilise un format de fichier différent de l'authentification basique, créé et géré par l'utilitaire htdigest [67] d'Apache, et non htpasswd. L'authentification par condensat utilise aussi le concept de realm (« domaine d'authentification » en français), dont la valeur est indiquée dans la directive AuthName.

[Note] Note

Pour l'authentification par condensat, le fournisseur d'authentification est choisi en utilisant la directive AuthDigestProvider comme indiqué dans l'exemple précédent. De même que pour la directive AuthBasicProvider, la valeur par défaut est file pour AuthDigestProvider. Cette ligne n'est donc pas strictement requise à moins que vous n'ayez à redéfinir une valeur différente de celle héritée par un contexte plus large de la configuration.

Le fichier des mots de passe peut être créé ainsi :

$ ### Première fois : utilisez -c pour créer le fichier
$ htdigest -c /etc/auth-svn.htdigest "Depot Subversion" harry
Adding password for harry in realm Depot Subversion.
New password: *****
Re-type new password: *****
$ htdigest /etc/auth-svn.htdigest "Depot Subversion" sally
Adding user sally in realm Depot Subversion.
New password: *******
Re-type new password: *******
$

Contrôle d'accès

À ce point, vous avez configuré l'authentification mais pas le contrôle d'accès. Apache est capable de vérifier les identités que proclament les clients mais on ne lui a pas encore indiqué quand autoriser ou interdire l'accès aux clients qui proclament ces identités. Cette section décrit deux stratégies pour contrôler les accès à vos dépôts.

Contrôle d'accès général

La méthode la plus simple de contrôle d'accès est d'autoriser certains utilisateurs pour un accès en lecture seule à un dépôt ou en lecture/écriture à un dépôt.

Vous pouvez restreindre les accès sur toutes les opérations d'un dépôt en ajoutant la directive Require valid-user directement dans le bloc <Location>. L'exemple fourni dans la section intitulée « Authentification par condensat (Digest) » autorise seulement les clients qui ont passé avec succès l'authentification et leur permet de tout faire avec le dépôt Subversion :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentification : condensat
  AuthName "Depot Subversion"
  AuthType Digest
  AuthUserFile /etc/auth-svn.htdigest

  # contrôle d'accès : utilisateurs authentifiés seulement
  Require valid-user
</Location>

Mais vous n'êtes pas obligé d'être aussi sévère. Par exemple, le serveur hébergeant le code source de Subversion à http://svn.apache.org/repos/asf/subversion permet à n'importe qui d'effectuer des accès en lecture seule (tels que des extractions de copies de travail ou parcourir le dépôt), mais il restreint les opérations d'écriture aux utilisateurs authentifiés. Les directives Limit et LimitExcept permettent ce type de comportement. À l'instar de Location, ces blocs possèdent une étiquette de début et une de fin, et vous pouvez les insérer dans des blocs <Location>.

Les paramètres inclus dans les directives Limit et LimitExcept sont les types de requêtes concernés par ces blocs. Ainsi, par exemple pour autoriser l'accès en lecture seule aux utilisateurs anonymes, vous utiliserez la directive LimitExcept (en lui donnant GET, PROPFIND, OPTIONS et REPORT comme types de requête autorisés) et vous placerez la directive Require valid-user citée précédemment dans le bloc <LimitExcept> au lieu de juste la placer dans le bloc <Location>.

<Location /svn>
  DAV svn
  SVNParentPath /var/svn

  # Authentification : condensat
  AuthName "Depot Subversion"
  AuthType Digest
  AuthUserFile /etc/auth-svn.htdigest

  # contrôle d'accès : utilisateurs authentifiés : écriture
  #                    anonymes : lecture seule
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

Ce ne sont là que quelques exemples simples. Pour des informations plus poussées sur le contrôle d'accès d'Apache et la directive Require, jetez un œil à la section Security du recueil des didacticiels de la documentation Apache à l'adresse https://httpd.apache.org/docs-2.0/misc/tutorials.html.

Contrôle d'accès par répertoire

Il est également possible de mettre en place des droits d'accès avec une granularité plus fine en utilisant le module mod_authz_svn. Ce module Apache se saisit des diverses URL opaques qui transitent entre le client et le serveur, demande à mod_dav_svn de les décoder et ensuite met éventuellement son veto à certaines requêtes en se basant sur les politiques d'accès définies dans un fichier de configuration.

Si vous avez compilé Subversion à partir du code source, mod_authz_svn est automatiquement inclus et installé aux côtés de mod_dav_svn. De nombreux exécutables distribués l'installent automatiquement aussi. Pour vérifier s'il est installé correctement, assurez-vous qu'il vient juste après la directive LoadModule de mod_dav_svn dans le fichier httpd.conf :

LoadModule dav_module         modules/mod_dav.so
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

Pour activer ce module, vous devez configurer votre bloc <Location> pour qu'il utilise la directive AuthzSVNAccessFile ; elle spécifie quel fichier contient les politiques de contrôle d'accès aux chemins de vos dépôts. À partir de Subversion 1.7, vous pouvez aussi utiliser la directive AuthzSVNReposRelativeAccessFile pour spécifier un fichier de contrôle d'accès spécifique par dépôt (nous allons étudier le format de ce fichier un peu plus tard).

Apache est flexible, vous avez donc la possibilité de configurer votre bloc selon une méthode à choisir parmi trois. Pour commencer, choisissez une des méthodes de configuration de base (les exemples suivants sont très simples ; reportez-vous à la documentation Apache qui contient beaucoup plus de détails sur les options d'authentification et de contrôle d'accès d'Apache).

L'approche la plus simple consiste à donner l'accès à tout le monde. Dans ce scénario, Apache n'envoie jamais de défi d'authentification, tous les utilisateurs sont donc traités en tant qu'« anonymes » (voir l'Exemple 6.2, « Exemple-type de configuration : accès anonyme »).

Exemple 6.2. Exemple-type de configuration : accès anonyme 

<Location /depot>
  DAV svn
  SVNParentPath /var/svn

  # Authentification : aucune

  # Contrôle d'accès : par répertoire
  AuthzSVNAccessFile /chemin/vers/fichier/acces
</Location>

À l'opposé sur l'échelle de la paranoïa, vous pouvez configurer votre bloc de telle sorte qu'il exige que tout le monde s'authentifie. Ici, tous les clients doivent fournir un mot de passe pour prouver leur identité. Votre bloc exige l'authentification inconditionnelle via la directive Require valid-user et définit le moyen de s'authentifier (voir l'Exemple 6.3, « Exemple-type de configuration : accès authentifié »).

Exemple 6.3. Exemple-type de configuration : accès authentifié 

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # Authentification : condensat
  AuthType Digest
  AuthName "Depot Subversion"
  AuthUserFile /etc/auth-svn.htdigest

  # Contrôle d'accès : par répertoire,
  #              seuls les utilisateurs authentifiés ont accès au dépôt
  AuthzSVNAccessFile /chemin/vers/fichier/acces
  Require valid-user
</Location>

Une troisième méthode très pratiquée consiste à autoriser à la fois des accès anonymes et des accès authentifiés. Par exemple, de nombreux administrateurs désirent autoriser les utilisateurs anonymes à lire certains répertoires dans les dépôts mais ne veulent voir que des utilisateurs authentifiés accéder en lecture (ou en écriture) dans des zones plus sensibles. Dans cette configuration, tous les utilisateurs commencent par accéder au dépôt de façon anonyme. Si votre politique de contrôle d'accès exige un véritable nom d'utilisateur à un moment ou à un autre, Apache demandera au client de s'authentifier. Pour ce faire, vous devez utiliser à la fois la directive Satisfy Any et la directive Require valid-user (voir l'Exemple 6.4, « Exemple-type de configuration : accès mixte authentifié/anonyme »).

Exemple 6.4. Exemple-type de configuration : accès mixte authentifié/anonyme 

<Location /repos>
  DAV svn
  SVNParentPath /var/svn

  # Authentification : Digest
  AuthName "Depot Subversion"
  AuthType Digest
  AuthUserFile /etc/auth-svn.htdigest

  # Contrôle d'accès : par répertoire
  #                    d'abord essayer l'accès anonyme
  #                    s'authentifier si nécessaire
  AuthzSVNAccessFile /chemin/vers/fichier/accès
  Satisfy Any
  Require valid-user
</Location>

L'étape suivante consiste à créer un fichier contenant les règles d'accès particulières pour chaque chemin de votre dépôt. Nous en parlons en détails plus loin dans ce chapitre, à la section intitulée « Contrôle d'accès basé sur les chemins ».

Désactivation du contrôle sur les chemins

Le module mod_dav_svn se donne beaucoup de peine pour assurer que les données que vous avez désignées comme « interdites » ne soient pas divulguées accidentellement. Cela veut dire qu'il doit surveiller étroitement tous les chemins d'accès et tous les contenus des fichiers renvoyés par des commandes telles que svn checkout et svn update. Si ces commandes tombent sur un chemin qui n'est pas lisible à cause d'une politique de contrôle d'accès, le chemin est généralement totalement omis. Dans le cas d'une recherche d'historique ou de renommage, par exemple une commande telle que svn cat -r ANCIENNE_REVISION truc.c sur un fichier qui a été renommé il y a longtemps, le suivi des renommages va simplement s'arrêter si un des anciens noms de l'objet se révèle être en accès restreint en lecture.

Ces contrôles sur les chemins peuvent parfois être assez coûteux, tout particulièrement dans le cas de svn log. Quand il demande une liste de révisions, le serveur examine chaque chemin modifié dans chaque révision et vérifie qu'il a le droit d'être lu. Si un chemin interdit est découvert, il est omis de la liste des chemins modifiés par la révision (obtenue habituellement par l'option --verbose) et le commentaire de propagation est entièrement supprimé. Il va sans dire que ceci peut prendre un certain temps pour les révisions qui ont touché à un grand nombre de fichiers. C'est le coût de la sécurité : même si vous n'avez pas du tout configuré de module tel que mod_authz_svn, le module mod_dav_svn va quand même demander à httpd Apache de vérifier les droits d'accès pour chaque chemin. Le module mod_dav_svn n'est pas au courant de la liste des modules de contrôle d'accès qui ont été installés, donc tout ce qu'il peut faire est de demander à Apache de lancer les modules correspondants, quels qu'ils soient.

D'un autre côté, il existe une sorte d'échappatoire qui vous permet d'échanger la sécurité contre de la vitesse. Si vous ne mettez pas en œuvre de contrôle d'accès sur les chemins (c'est-à-dire, si vous n'utilisez ni mod_authz_svn ni un module similaire), vous pouvez désactiver tous ces contrôles sur les chemins. Dans votre fichier httpd.conf, utilisez la directive SVNPathAuthz comme illustré dans l'Exemple 6.5, « Désactiver complètement les contrôles sur les chemins ».

Exemple 6.5. Désactiver complètement les contrôles sur les chemins 

<Location /depot>
  DAV svn
  SVNParentPath /var/svn

  SVNPathAuthz off
</Location>

La directive SVNPathAuthz est activée (« on ») par défaut. Quand on la désactive (« off »), tous les contrôles d'accès basés sur les chemins sont désactivés ; mod_dav_svn arrête de demander un contrôle d'accès chaque chemin qu'il traite.

Fichier de contrôle d'accès suivi en versions dans le dépôt

À partir de Subversion 1.8, le fichier de contrôle d'accès peut être stocké dans un dépôt Subversion. Il est possible de stocker ce ficher dans le dépôt même pour lequel sont gérés les droits d'accès, ou dans un autre dépôt. Cette approche permet d'avoir les fonctionnalités de gestion de versions pour la configuration du contrôle d'accès aux chemins.

Les deux directives de configuration AuthzSVNAccessFile et AuthzSVNReposRelativeAccessFile permettent de spécifier l'emplacement du fichier de contrôle d'accès à l'intérieur d'un dépôt. Ces directives reconnaissent les URL absolues de type file:// et les URL relatives aux dépôts (celles qui commencent par ^/).

Par exemple, il est possible de spécifier une URL absolue pour un fichier de contrôle d'accès comme le montre Exemple 6.6, « Utilisation d'un fichier de contrôle d'accès unique suivi en versions à l'intérieur d'un dépôt ».

Exemple 6.6. Utilisation d'un fichier de contrôle d'accès unique suivi en versions à l'intérieur d'un dépôt 

<Location /dépôt>
  DAV svn
  SVNParentPath /var/svn
  AuthzSVNAccessFile file:///var/svn/dépôt-authz/authz
</Location>

Vous pouvez aussi spécifier une URL relative pointant vers un fichier à l'intérieur du dépôt lui-même, comme montré dans Exemple 6.7, « Utilisation d'un fichier de contrôle d'accès spécifique pour chaque dépôt ».

Exemple 6.7. Utilisation d'un fichier de contrôle d'accès spécifique pour chaque dépôt 

<Location /dépôt>
  DAV svn
  SVNParentPath /var/svn
  AuthzSVNReposRelativeAccessFile ^/authz
</Location>

Encapsulation du trafic réseau avec SSL

Lorsque vous vous connectez à un dépôt via http://, tout le trafic généré par Subversion est envoyé en clair sur le réseau. Cela veut dire que les extractions, les propagations et les mises à jour peuvent être interceptées par une entité non autorisée qui « écoute » le trafic réseau. Chiffrer le trafic en utilisant SSL vous permet de protéger l'envoi d'informations sensibles sur le réseau.

Si un client Subversion est compilé pour l'utilisation de SSL, il peut alors se connecter au serveur Apache en utilisant des URL de type https://, ce qui chiffrera tout le trafic avec une clé de session propre à chaque connexion. La bibliothèque WebDAV utilisée par le client Subversion n'est pas seulement capable de vérifier le certificat présenté par le serveur mais peut aussi utiliser des certificats clients au cas où le serveur le demande.

Configuration du certificat serveur SSL de Subversion

La création de certificats SSL clients et serveurs ainsi que la configuration d'Apache pour les utiliser sort du cadre de ce livre. Il existe beaucoup de références, y compris la propre documentation d'Apache (https://httpd.apache.org/docs/current/ssl/), qui décrivent comment faire.

[Astuce] Astuce

Les certificats SSL produits par des sociétés bien connues sont généralement payants mais vous pouvez, au minimum, configurer Apache pour utiliser un certificat auto-signé qui a été généré avec, par exemple, OpenSSL (https://www.openssl.org).[68]

Gestion des certificats clients SSL Subversion

Quand il se connecte à une serveur Apache en https://, un client Subversion peut recevoir deux types de réponse :

  • un certificat serveur ;

  • un défi pour un certificat client.

Certificat serveur

Quand le client reçoit un certificat serveur, il doit vérifier que le serveur est bien celui qu'il prétend être. OpenSSL réalise cette tâche en examinant le signataire du certificat serveur, appelé autorité de certification (AC en français, CA pour certificat authority en anglais). Si OpenSSL ne fait pas confiance à cette AC, ou si un autre problème apparaît (tel qu'un certificat ayant expiré ou alors le nom de la machine qui ne correspond pas à ce qui est indiqué dans le certificat), le client texte interactif Subversion vous demande si vous voulez quand même faire confiance à ce certificat serveur :

$ svn list https://hote.exemple.com/depot/projet

Error validating server certificate for 'https://hote.exemple.com:443':
 - The certificate is not issued by a trusted authority.  Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: hote.exemple.com
 - Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT
 - Issuer: CA, exemple.com, Sometown, California, US
 - Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

(R)eject, accept (t)emporarily or accept (p)ermanently?

Vous pourriez voir cette même question dans votre navigateur (car c'est aussi un client HTTP tout comme Subversion). Si vous choisissez l'option (p)permanent, Subversion placera le certificat serveur en cache dans votre zone privée de configuration (dossier auth/) ainsi que votre nom d'utilisateur et votre mot de passe (voir la section intitulée « Éléments d'authentification du client »). Il fera alors automatiquement confiance au certificat dans le futur.

Votre fichier servers de la zone de configuration vous permet aussi de spécifier des AC de confiance, que ce soit globalement ou hôte par hôte. Affectez simplement une liste (dont les éléments sont séparés par des points-virgules) de chemins vers des certificats d'AC encodés au format PEM à la variable ssl-authority-files :

[global]
ssl-authority-files = /chemin/vers/certificat-AC1.pem;/chemin/vers/certificat-AC2.pem

Beaucoup d'installations d'OpenSSL sont fournies avec une liste d'autorités « universellement de confiance ». Pour que le client Subversion fasse confiance à ces autorités, affectez la valeur true à la variable ssl-trust-default-ca .

Défi pour le certificat client

Quand le client reçoit un défi d'authentification, cela veut dire que le serveur demande au client de prouver son identité. Le client doit renvoyer un certificat signé par une AC qui a la confiance du serveur ainsi qu'une réponse de défi (Challenge Response en anglais) qui prouve que le client possède la clé privée associée au certificat. La clé privée et le certificat sont généralement stockés à l'intérieur d'un conteneur chiffré sur le disque et sont protégés par une phrase de passe. Quand Subversion reçoit le défi, il vous demande le chemin vers le conteneur et la phrase de passe qui protège son accès :

$ svn list https://hote.exemple.com/depot/projet

Authentication realm: https://hote.exemple.com:443
Client certificate filename: /chemin/vers/mon/conteneur.p12
Passphrase for '/chemin/vers/mon/conteneur.p12':  ********

Notez que les éléments d'authentification du client sont stockés dans un conteneur dont l'extension est .p12. Pour utiliser un certificat client avec Subversion, il doit être au format PKCS#12, ce qui est un standard. La plupart des navigateurs Web savent importer et exporter des certificats dans ce format. Une autre possibilité est d'utiliser les utilitaires en ligne de commande d'OpenSSL pour convertir des certificats existants au format PKCS#12.

Le fichier servers de la zone de configuration vous permet d'automatiser la phase de défi pour les hôtes que vous spécifiez. Si vous définissez les variables ssl-client-cert-file et ssl-client-cert-password, Subversion répond automatiquement aux défis demandés par les serveurs sans vous solliciter :

[groups]

serveur_exemple = hote.exemple.com

[serveur_exemple]
ssl-client-cert-file = /chemin/vers/mon/conteneur.p12
ssl-client-cert-password = maphrasedepasseestlongue

Les plus exigeants en matière de sécurité interdiront l'affectation des phrases de passe dans la variable ssl-client-cert-password car celles-ci sont alors stockées en clair sur le disque.

Amélioration des performances

Le serveur HTTP Apache a été conçu pour être performant mais vous pouvez modifier la configuration par défaut pour gagner encore en performances pour votre service Subversion. Dans cette section, nous allons vous proposer quelques modifications de configuration de httpd.conf. Comprenez cependant que certaines des modifications proposées affectent le comportement général du serveur, et pas seulement le service Subversion. Ainsi, vous devez prendre en compte l'ensemble de ces services pour décider s'il est opportun d'effectuer ou non les modifications proposées.

KeepAlive

Par défaut, le serveur HTTP Apache est configuré pour autoriser la réutilisation d'une même connexion serveur par plusieurs requêtes client. C'est particulièrement avantageux pour Subversion car, au contraire de beaucoup d'applications sur HTTP, Subversion peut générer très rapidement des centaines voire des milliers de requêtes vers un serveur pour une seule opération et le coût d'ouvrir une nouvelle connexion vers un serveur n'est pas négligeable. Subversion veut faire rentrer le maximum de requêtes dans une seule connexion avant que celle-ci ne soit fermée par le serveur. La directive KeepAlive est un booléen qui active ou désactive cette réutilisation de connexion et, comme indiqué précédemment, sa valeur par défaut est On.

Mais il existe une autre directive qui limite le nombre de requêtes qu'un client peut soumettre sur une seule connexion : la directive MaxKeepAliveRequests. La valeur par défaut pour cette option est 100. C'était probablement suffisant pour les vieilles versions de Subversion, mais Subversion 1.8 utilise une bibliothèque de communication différente (appelée Serf) qui préfère lancer plusieurs petites requêtes pour récupérer des informations bien précises plutôt que de demander au serveur de transmettre d'énormes quantités de données en une seule réponse. Nous vous recommandons d'augmenter la valeur affectée à l'option MaxKeepAliveRequests à au moins 1000.

#
# KeepAlive: autoriser ou pas les connexions persistantes (plus d'une
# requête par connexion). Mettre la valeur "Off" pour la désactiver.
#
KeepAlive On

#
# MaxKeepAliveRequests: nombre maximum de requêtes autorisées pour une
# connexion persistante. Mettre à 0 pour autoriser un nombre illimité.
# Nous recommandons de laisser ce nombre élevé pour améliorer les
# performances.
#
MaxKeepAliveRequests 1000

Mises à jour groupées

La plus grosse différence entre le client Subversion 1.8 et ses prédécesseurs concerne la manière dont il effectue les opérations de mises à jour (svn checkout, svn update, svn switch, etc.). Les vieux clients, qui utilisaient la bibliothèque HTTP Neon pour les communications, préféraient demander au serveur l'ensemble des informations dans une seule requête. Les administrateurs pouvaient alors voir, dans les journaux de connexions du serveur, la négociation initiale de la transaction puis une requête REPORT dont la réponse était énorme. Cette réponse contenait l'extraction ou la mise à jour dans son ensemble !

Les clients Subversion qui utilisent la bibliothèque HTTP Serf (ce qui inclut tous les clients basés sur Subversion 1.8) envoient toujours la requête REPORT mais avec des paramètres légèrement différents. Ces paramètres ne demandent pas au serveur d'envoyer toutes les données relatives à l'opération mais d'envoyer seulement une liste de vérifications des choses spécifiques que le client devra récupérer auprès du serveur pour accomplir l'opération. Dans le journal access_log du serveur, la ligne REPORT est suivie par beaucoup de petites requêtes (GET et, pour les vieilles versions de Subversion, PROPFIND).

Chacune des deux approches a ses avantages et ses inconvénients. Comme nous l'avons déjà mentionné, les mises à jour groupées (bulk updates en anglais) produisent beaucoup moins de lignes dans les journaux du serveur mais un processus fils du serveur Apache HTTP est entièrement dédié à cette opération, qui peut se révéler particulièrement longue, jusqu'à sa fin. Les mises à jour par petites touches permettent de mettre en place des caches (ce qui contribuera à améliorer les performances) mais vont générer dans les journaux un nombre de lignes sans commune mesure avec l'approche par mises à jour groupées. En conséquence, les administrateurs auront leur mot à dire sur la méthode utilisée par les clients pour se mettre à jour. Subversion 1.6 a ainsi introduit la directive SVNAllowBulkUpdates de mod_dav_svn : un simple booléen pour laisser aux administrateurs le choix de spécifier si le serveur accepte les requêtes de mises à jour groupées. Avec Subversion 1.8, cette directive s'est complétée avec la possibilité d'indiquer Prefer en plus de On et Off. Quand SVNAllowBulkUpdates vaut Prefer, les clients qui reconnaissent cette option (c'est-à-dire les versions 1.8 ou plus récentes) tenteront des mises à jour groupées à moins d'avoir été configurés autrement.

Fonctionnalités bonus

Nous avons couvert la plupart des options d'authentification et de contrôle d'accès pour Apache et mod_dav_svn. Mais il existe encore quelques autres directives d'Apache qui méritent d'être abordées.

Navigation dans les dépôts

Un des avantages les plus frappants d'avoir une configuration Apache/WebDAV pour votre dépôt Subversion est que les révisions les plus récentes de vos fichiers et répertoires suivis en versions sont immédiatement consultables à l'aide d'un navigateur web classique. Puisque Subversion utilise des URL pour identifier les ressources suivies en versions, ces URL utilisées pour accéder aux dépôts via HTTP peuvent être tapées directement dans un navigateur web. Votre navigateur enverra une requête HTTP GET pour cette URL ; selon que cette URL représente ou non un fichier ou un répertoire suivi en versions, mod_dav_svn renverra soit la liste des éléments du répertoire, soit le contenu du fichier.

Syntaxe des URL

Comme les URL ne contiennent pas d'informations relatives à la version de la ressource qui vous intéresse, mod_dav_svn renverra toujours la version la plus récente. Cette fonctionnalité a un merveilleux effet secondaire : vous pouvez partager avec vos pairs des URL Subversion en guise de références à des documents et ces URL pointeront toujours vers la dernière version des documents. Bien sûr, vous pouvez aussi utiliser ces URL en tant que liens hypertextes dans d'autres sites web.

Depuis Subversion 1.6, mod_dav_svn reconnait une syntaxe d'URI particulière pour examiner les vieilles révisions des fichiers et des répertoires. Cette syntaxe utilise la partie « requête » de l'URL pour spécifier une révision pivot ou une révision opérationnelle. Subversion utilisera ces arguments pour déterminer la version du fichier ou du répertoire que vous voulez afficher dans votre navigateur. Ajoutez la paire p=REV_PIVOT, où REV_PIVOT est un numéro de révision, pour spécifier la révision pivot que vous souhaitez appliquer à la requête. Utilisez r=REV, où REV est un numéro de révision, pour spécifier une révision opérationnelle.

Par exemple, si vous voulez voir la dernière version du fichier LISEZMOI.txt situé dans /trunk de votre projet, faites pointer votre navigateur vers l'URL de ce fichier, qui devrait ressembler à quelque chose comme ceci :

http://hote.exemple.com/depot/projet/trunk/LISEZMOI.txt

Si vous voulez voir une version plus ancienne de ce fichier, ajouter une révision opérationnelle à l'URL:

http://hote.exemple.com/depot/projet/trunk/LISEZMOI.txt?r=1234

Que se passe-t-il si ce que vous voulez voir n'existe plus dans la révision la plus récente du dépôt ? C'est maintenant qu'une révision pivot est utile :

http://hote.exemple.com/depot/projet/trunk/LISEZMOI.txt?p=321

Et bien sûr, vous pouvez combiner une révision pivot et une révision opérationnelle pour dénicher l'élément précis que vous souhaitez voir :

http://hote.exemple.com/depot/projet/trunk/LISEZMOI.txt?p=123&r=21

L'URL ci-dessus affichera la révision 21 de l'objet qui, dans la révision 123, se trouvait à /trunk/chose-renommée.txt dans le dépôt. Reportez-vous à la section intitulée « Révisions pivots et révisions opérationnelles » pour une explication détaillée des concepts de « révision pivot » et « révision opérationnelle », ils peuvent être relativement difficiles à appréhender.

À partir de Subversion 1.8, mod_dav_svn a acquis la capacité de substituer des mots-clés. Quand mod_dav_svn trouve dans l'URL de la requête un argument kw=1, il substitue les mots-clés au moment de renvoyer la réponse. Ne pas spécifier de paramètre kw ou lui affecter une valeur autre que 1 entraine le comportement par défaut, c'est-à-dire renvoyer le contenu du fichier sans avoir substitué les mots-clés.

Puisque la substitution des mots-clés est typiquement une opération réalisée par le client Subversion, dans le cadre de l'administration et la gestion des copies de travail, ce moyen de substituer les mots-clés par le serveur trouve toute son utilité dans le cas où vous n'utilisez pas de copie de travail.

Par exemple, si vous souhaitez voir la dernière version du fichier LISEZMOI.txt situé dans /trunk avec les mots-clés substitués, ajoutez l'argument kw=1 dans l'URL de votre requête :

http://hote.exemple.com/depot/projet/trunk/LISEZMOI.txt?kw=1

À l'instar de l'opération côté client, seuls les mots-clés qui sont explicitement désignés via la propriété svn:keywords du fichier concerné seront substitués. Lisez la section intitulée « Substitution de mots-clés » pour une description détaillée de la substitution de mots-clés.

Pour mémoire, mod_dav_svn n'offre qu'une capacité réduite de navigation dans le dépot. Vous pouvez visualiser la liste des fichiers d'un répertoire et le contenu des fichiers mais pas les propriétés de révision (telles que les commentaires de propagation) ou les propriétés des fichiers et répertoires. Pour ceux qui ont besoin de naviguer plus finement dans les dépôts et leurs historiques, un certain nombre de logiciels tiers répondent présent. Par exemple, nous pouvons citer ViewVC (https://viewvc.org), Trac (https://trac.edgewall.org) et WebSVN (https://websvnphp.github.io). Ces outils tiers ne touchent pas à la « navigabilité » native offerte par mod_dav_svn et proposent généralement tout un tas de fonctionnalités supplémentaires, y compris l'affichage des propriétés comme mentionné, l'affichage des différences entre plusieurs révisions, etc.

Types MIME appropriés

Quand il consulte un dépôt Subversion, le navigateur web obtient un indice pour savoir comment rendre le contenu d'un fichier en examinant l'entête Content-Type: qui fait partie de la réponse envoyée par Apache à la requête HTTP GET. La valeur de cet entête est en quelque sorte un type MIME. Par défaut, Apache va indiquer aux navigateurs web que tous les fichiers du dépôt sont du type MIME par défaut, en général text/plain. Cela peut s'avérer assez frustrant, si un utilisateur désire visualiser les fichiers du dépôt de manière plus appropriée — par exemple, un fichier truc.html du dépôt sera bien plus lisible s'il est rendu dans le navigateur en tant que fichier HTML.

Pour rendre ceci possible, il suffit de vous assurer que vos fichiers portent bien la propriété svn:mime-type. Plus de détails sur ce sujet sont disponibles dans la section intitulée « Type de contenu des fichiers » et vous pouvez même configurer votre dépôt pour qu'il associe automatiquement la valeur de svn:mime-type appropriée aux fichiers qui arrivent dans le dépôt pour la première fois ; reportez-vous à la section intitulée « Configuration automatique des propriétés ».

Donc, dans notre exemple, si quelqu'un attribuait la valeur text/html à la propriété svn:mime-type du fichier truc.html, Apache indiquerait avec raison à votre navigateur web de rendre le fichier comme une page HTML. On pourrait aussi associer des propriétés ayant des valeurs image/* appropriées aux fichiers d'images et, en fin de compte, faire qu'un site web entier soit consultable directement à travers un dépôt ! Ceci ne pose en général pas de problème, du moment que le site web ne possède pas de contenu généré dynamiquement.

Personnalisation de l'aspect

En général, vous utiliserez principalement des URL de fichiers suivis en versions ; après tout c'est là que le contenu intéressant réside. Mais vous aurez peut-être l'occasion de naviguer dans le contenu d'un répertoire Subversion et vous remarquerez rapidement que le code HTML généré pour afficher la liste des éléments du répertoire est très rudimentaire, et certainement pas conçu pour être agréable d'un point de vue esthétique (ni même intéressant). Afin d'activer la personnalisation de l'affichage de ces répertoires, Subversion fournit une fonctionnalité d'index XML. La présence d'une directive SVNIndexXSLT dans le bloc Location du fichier httpd.conf de votre dépôt conduira mod_dav_svn à générer un résultat en XML quand il affiche la liste des éléments d'un répertoire et à faire référence à la feuille de style XSLT de votre choix :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNIndexXSLT "/svnindex.xsl"
  …
</Location>

À l'aide de la directive SVNIndexXSLT et d'une feuille de style XSLT faisant preuve de créativité, vous pouvez adapter les listes de contenus de répertoires aux couleurs et illustrations utilisées dans d'autres parties de votre site web. Ou, si vous préférez, vous pouvez utiliser les exemples de feuilles de style fournis dans le répertoire tools/xslt/ du code source de Subversion. Gardez à l'esprit que le chemin d'accès fourni à la directive SVNIndexXSLT est en fait une URL — les navigateurs doivent être capables de lire vos feuilles de style pour les utiliser !

Affichage de la liste des dépôts

Si vous desservez un ensemble de dépôts à partir d'une URL unique via la directive SVNParentPath, il est possible de faire afficher par Apache tous les dépôts disponibles dans un navigateur web. Il suffit d'activer la directive SVNListParentPath :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNListParentPath on
  …
</Location>

Si un utilisateur pointe son navigateur web à l'URL http://hote.exemple.com/svn/, il verra une liste de tous les dépôts Subversion situés dans /var/svn. Évidemment, ceci peut poser des problèmes de sécurité ; cette fonctionnalité est donc désactivée par défaut.

Journalisation Apache

Comme Apache est avant tout un serveur HTTP, il contient des fonctionnalités de journalisation d'une flexibilité fantastique. Détailler toutes les façons dont la journalisation peut être configurée sort du cadre de ce livre, mais nous voulons quand même vous faire remarquer que même le fichier httpd.conf le plus générique conduit Apache à créer deux fichiers de journalisation : error_log et access_log. Ces journaux peuvent apparaître à différents endroits, mais sont en général créés dans la zone de journalisation de votre installation Apache (sur Unix, ils résident souvent dans /usr/local/apache2/logs/).

Le fichier error_log décrit toutes les erreurs internes qu'Apache rencontre au cours de son fonctionnement. Le fichier access_log enregistre toutes les requêtes HTTP reçues par Apache. Ceci permet de voir facilement, par exemple, à partir de quelles adresses IP les clients Subversion se connectent, à quelle fréquence un client donné utilise le serveur, quels utilisateurs se sont authentifiés correctement et quelles requêtes ont échoué ou réussi.

Malheureusement, parce qu'HTTP est un protocole sans notion d'état, même la plus simple opération du client Subversion génère plusieurs requêtes réseau. Il est donc très difficile d'examiner le fichier access_log et d'en déduire ce que le client faisait — la plupart des opérations se présentent sous la forme de séries de requêtes PROPPATCH, GET, PUT et REPORT énigmatiques. Pour couronner le tout, de nombreuses opérations du client envoient des séries de requêtes quasi-identiques, il est donc encore plus difficile de les distinguer.

Cependant, mod_dav_svn peut venir à votre rescousse. En activant la fonctionnalité de « journalisation opérationnelle », vous pouvez demander à mod_dav_svn de créer un fichier séparé décrivant quelles sortes d'opérations de haut niveau vos clients effectuent.

Pour ce faire, vous devez utiliser la directive CustomLog d'Apache (qui est expliquée en détail dans la documentation Apache). Prenez soin de placer cette directive en dehors de votre bloc Location de Subversion :

<Location /svn>
  DAV svn
  …
</Location>

CustomLog logs/journal-svn "%t %u %{SVN-ACTION}e" env=SVN-ACTION

Dans cet exemple, nous demandons à Apache de créer un fichier journal spécial, journal-svn, dans le répertoire habituel de journaux d'Apache (logs). Les variables %t et %u sont remplacées par l'horodatage et le nom d'utilisateur de la requête, respectivement. Les points importants sont les deux instances de SVN-ACTION. Quand Apache trouve cette variable, il lui substitue la valeur de la variable d'environnement SVN-ACTION, modifiée automatiquement par mod_dav_svn quand il détecte une action haut-niveau du client.

Ainsi, au lieu d'avoir à interpréter un fichier access_log traditionnel qui ressemble à :

[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/vcc/default HTTP/1.1" 207 398
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/bln/59 HTTP/1.1" 207 449
[26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc HTTP/1.1" 207 647
[26/Jan/2007:22:25:29 -0600] "REPORT /svn/calc/!svn/vcc/default HTTP/1.1" 200 607
[26/Jan/2007:22:25:31 -0600] "OPTIONS /svn/calc HTTP/1.1" 200 188
[26/Jan/2007:22:25:31 -0600] "MKACTIVITY /svn/calc/!svn/act/e6035ef7-5df0-4ac0-b811-4be7c823f998 HTTP/1.1" 201 227
…

vous pouvez vous contenter de parcourir le fichier journal-svn qui est bien plus intelligible :

[26/Jan/2007:22:24:20 -0600] - get-dir /tags r1729 props
[26/Jan/2007:22:24:27 -0600] - update /trunk r1729 depth=infinity
[26/Jan/2007:22:25:29 -0600] - status /trunk/foo r1729 depth=infinity
[26/Jan/2007:22:25:31 -0600] sally commit r1730

En complément de la variable d'environnement SVN-ACTION, mod_dav_svn définit aussi les variables SVN-REPOS et (resp.) SVN-REPOS-NAME, qui contiennent le chemin dans le système de fichiers vers le dépôt et (resp.) le nom simple. Vous voudrez peut-être inclure des références à ces variables dans la chaîne de caractères qui définit le format dans CustomLog, surtout si vous combinez dans ce fichier les journaux en provenance de plusieurs dépôts. Pour obtenir une liste exhaustive de toutes les actions journalisées, reportez-vous à la section intitulée « Journalisation du haut-niveau ».

Évidemment, plus Apache journalise d'informations relatives aux activités de Subversion, plus le journal prend de place sur le disque. Il n'est pas rare qu'un serveur Subversion à gros trafic génère plusieurs gigaoctets de journaux par jour. Tout aussi évidemment, les journaux ne sont utiles que si vous pouvez en extraire de l'information pertinente et les journaux gigantesques peuvent rapidement devenir difficiles à exploiter. Il existe diverses solutions pour gérer les journaux d'Apache qui sortent du cadre de ce livre. Nous préconisons aux administrateurs d'utiliser la rotation des journaux et l'archivage qui leur convient le mieux.

Mais que faire si Subversion génère simplement trop de journaux pour pouvoir les exploiter ? Par exemple, dans la section intitulée « Mises à jour groupées », nous avons indiqué que certaines approches que les clients Subversion utilisent pour leurs extractions ou d'autres opérations de mise à jour peuvent faire grandir rapidement la taille des journaux parce que chaque requête, pour chaque information élémentaire de la mise à jour, est journalisée (alors que ce n'était pas le cas pour les versions précédentes de Subversion). Dans ce cas, vous devriez envisager une configuration très particulière d'Apache pour ne pas journaliser, de manière sélective, l'ensemble des activités.

Le module mod_setenvif du serveur HTTP Apache propose une directive SetEnvIf qui est utile pour définir de manière conditionnelle des variables d'environnement. Ainsi, la directive CustomLog peut être configurée pour ne journaliser que certaines requêtes en fonction de la valeur de variables d'environnement. Vous trouverez un exemple de configuration qui demande au serveur de ne pas journaliser les requêtes GET et PROPFIND visant des URL Subversion privées.

# Correspondance pour tout, juste pour initialiser la variable 'dans_depot'.
SetEnvIf Request_URI "^" dans_depot=0

# Activer "dans_depot" si la requête pointe vers une URL Subversion privée.
SetEnvIf Request_URI "/!svn/" dans_depot=1

# Désactiver "ne_pas_journaliser" pour les types de requêtes que
# nous ne voulons pas journaliser
SetEnvIf Request_Method "GET" ne_pas_journaliser
SetEnvIf Request_Method "PROPFIND" ne_pas_journaliser

# Désactiver "ne_pas_journaliser" pour les URL Subversion qui ne sont pas privées.
SetEnvIf dans_depot 0 !ne_pas_journaliser

# Journaliser la requête, seulement si "ne_pas_journaliser" n'est pas activée
CustomLog logs/access_log env=!ne_pas_journaliser

En utilisant cette configuration,httpd journalisera toujours les requêtes GET qui pointent vers des URL Subversion publiques. Ce sont les types de requêtes émises par les navigateurs Web lorsqu'un utilisateur navigue dans le dépôt directement. Mais les requêtes GET et PROPFIND qui pointent vers des URL Subversion dites « privées » (ce sont les types de requêtes utilisées pour passer en revue individuellement chacun des fichiers lors d'une opération d'extraction) ne seront pas journalisées.

Mandataire en écriture

Un des avantages notables d'Apache comme serveur Subversion est qu'il peut être configuré pour effectuer de la réplication. Par exemple, imaginez que votre équipe soit répartie sur quatre sites dans différents coins du globe. Le dépôt Subversion ne peut exister que sur un de ces sites, ce qui signifie que les trois autres sites n'auront pas un accès très satisfaisant — ils devront sans doute faire avec un trafic plus lent et des temps de réponse plus longs lors des mises à jour et des propagations. Une solution très puissante est de mettre en place un système constitué d'un serveur Apache maître et de plusieurs serveurs Apache esclaves. Si vous placez un serveur esclave sur chacun des sites, les utilisateurs peuvent extraire une copie de travail de l'esclave qui est le plus proche d'eux. Toutes les requêtes de lecture vont au serveur esclave local. Les requêtes d'écriture sont automatiquement routées vers l'unique serveur maître. Lorsque la propagation se termine, le maître « pousse » la nouvelle révision vers chaque serveur esclave en utilisant l'outil de réplication svnsync.

Cette configuration permet une immense amélioration de la vitesse perçue par les utilisateurs, car le trafic d'un client Subversion est généralement constitué à 80 - 90 % de requêtes de lecture. Et ces requêtes étant traitées par un serveur local, le gain est énorme.

Dans cette section, nous vous accompagnons dans la mise en place standard de ce système comportant un maître unique et plusieurs esclaves. Cependant, gardez à l'esprit que vos serveurs doivent faire tourner au moins Apache 2.2.0 (avec le module mod_proxy chargé) et Subversion 1.5 (mod_dav_svn).

[Note] Note

Ceci est juste un exemple de la façon dont vous pouvez configurer un serveur mandataire Subversion. Il existe d'autres approches. Par exemple, plutôt que d'avoir un serveur maître qui pousse les modifications vers chaque serveur esclave, les esclaves pourraient aller chercher ces modifications périodiquement sur le serveur maître. Ou bien le serveur pourrait pousser les modifications vers un seul serveur esclave, charge à ce serveur esclave de les pousser vers un autre serveur esclave et ainsi de suite pour atteindre tous les serveurs esclaves. Nous conseillons aux administrateurs d'utiliser cette section comme point de départ pour comprendre les bases d'un déploiement d'un serveur mandataire WebDAV Subversion, puis d'implémenter l'approche qui convient le mieux à leur organisation.
Configuration des serveurs

Pour commencer, configurez le fichier httpd.conf de votre serveur maître de la façon habituelle. Mettez le dépôt à disposition à un certain emplacement URI et configurez l'authentification ainsi que le contrôle d'accès comme vous le souhaitez. Une fois que c'est fait, configurez chacun de vos serveurs « esclaves » exactement de la même manière, mais ajoutez la directive SVNMasterURI au bloc :

<Location /svn>
  DAV svn
  SVNPath /var/svn/depot
  SVNMasterURI http://maitre.exemple.com/svn
  …
</Location>

Cette nouvelle directive indique à un serveur esclave de rediriger toutes les requêtes d'écriture vers le maître (ce qui est accompli automatiquement par le module mod_proxy d'Apache). Les requêtes ordinaires de lecture, cependant, sont toujours traitées par les esclaves. Assurez-vous que vos serveurs maître et esclaves ont tous des configurations identiques d'authentification et de contrôle d'accès ; En cas de problème de synchronisation, cela peut vous amener à vous arracher les cheveux.

Ensuite nous devons nous occuper du problème de la récursion infinie. Avec la configuration actuelle, imaginez ce qui se va se passer quand un client Subversion va effectuer une propagation vers le serveur maître. Une fois la propagation terminée, le serveur utilise svnsync pour répliquer la nouvelle révision vers chaque esclave. Mais comme svnsync ne se présente que comme un simple client en train d'effectuer une propagation, l'esclave va immédiatement tenter d'envoyer vers le maître la requête d'écriture qui vient d'arriver ! Et là, patatras !

La solution consiste à s'arranger pour que le maître pousse les révisions vers un emplacement <Location> distinct au sein des dépôts esclaves. Cet emplacement est configuré non pas pour servir de mandataire pour les requêtes d'écriture mais pour accepter les propagations normales en provenance de l'adresse IP du maître (et seulement de lui) :

<Location /svn-proxy-sync>
  DAV svn
  SVNPath /var/svn/depot
  Order deny,allow
  Deny from all
  # Ne laisse que le serveur ayant l'adresse indiquée accéder à cet emplacement :
  Allow from 10.20.30.40
  …
</Location>
Mise en place de la réplication

Une fois que vous avez configuré les blocs Location du maître et des esclaves, vous devez configurer le maître pour que la réplication vers les esclaves fonctionne. Ceci se fait de la manière habituelle, en utilisant svnsync. Si vous n'êtes pas familier avec cet outil, reportez-vous à la section intitulée « Réplication avec svnsync » pour plus de détails.

Tout d'abord, assurez-vous que chaque dépôt esclave possède une procédure automatique pre-revprop-change qui autorise les modifications de propriétés de révisions à distance (cette étape fait partie de la procédure standard pour un serveur qui reçoit les révisions de svnsync). Ensuite, connectez-vous au serveur maître et configurez l'URI de chaque dépôt esclave pour qu'il reçoive les données en provenance du dépôt maître sur le disque local :

$ svnsync init http://esclave1.exemple.com/svn-proxy-sync \
               file://var/svn/depot
Propriétés copiées pour la révision 0.
$ svnsync init http://esclave2.exemple.com/svn-proxy-sync \
               file://var/svn/depot
Propriétés copiées pour la révision 0.
$ svnsync init http://esclave3.exemple.com/svn-proxy-sync \
               file://var/svn/depot
Propriétés copiées pour la révision 0.

# Effectue la réplication initiale

$ svnsync sync http://esclave1.exemple.com/svn-proxy-sync \
               file://var/svn/depot
Transmission des données ........................................
Révision 1 propagée.
Propriétés copiées pour la révision 1.
Transmission des données ..
Révision 2 propagée.
Propriétés copiées pour la révision 2.
…

$ svnsync sync http://esclave2.exemple.com/svn-proxy-sync \
               file://var/svn/depot
Transmission des données ........................................
Révision 1 propagée.
Propriétés copiées pour la révision 1.
Transmission des données ..
Révision 2 propagée.
Propriétés copiées pour la révision 2.
…

$ svnsync sync http://esclave3.exemple.com/svn-proxy-sync \
               file://var/svn/depot
Transmission des données ........................................
Révision 1 propagée.
Propriétés copiées pour la révision 1.
Transmission des données ..
Révision 2 propagée.
Propriétés copiées pour la révision 2.
…

Une fois ceci fait, nous configurons la procédure automatique post-propagation (post-commit) du serveur maître pour qu'elle lance svnsync sur chaque serveur esclave :

#!/bin/sh
# Procédure post-propagation pour répliquer les révisions
# nouvellement propagées vers les esclaves

svnsync sync http://esclave1.exemple.com/svn-proxy-sync \
             file:///var/svn/depot > /dev/null 2>&1 &
svnsync sync http://esclave2.exemple.com/svn-proxy-sync \
             file:///var/svn/depot > /dev/null 2>&1 &
svnsync sync http://esclave3.exemple.com/svn-proxy-sync \
             file:///var/svn/depot > /dev/null 2>&1 &

Les symboles en plus à la fin de chaque ligne ne sont pas nécessaires, mais constituent un moyen astucieux d'autoriser svnsync à lancer des commandes qui fonctionneront à l'arrière-plan, de telle sorte que le client Subversion ne se retrouvera pas à attendre indéfiniment que la propagation se termine. En plus de cette procédure post-propagation (post-commit), vous aurez également besoin d'une procédure automatique post-revprop-change pour que, disons, quand un utilisateur modifie un commentaire de propagation, les serveurs esclaves reçoivent aussi cette modification :

#!/bin/sh
# Procédure post-revprop-change pour répliquer les modifications
# des propriétés de révisions vers les esclaves

REV=${2}
svnsync copy-revprops http://esclave1.exemple.com/svn-proxy-sync \
                      file:///var/svn/depot \
                      -r ${REV} > /dev/null 2>&1 &
svnsync copy-revprops http://esclave2.exemple.com/svn-proxy-sync \
                      file:///var/svn/depot \
                      -r ${REV} > /dev/null 2>&1 &
svnsync copy-revprops http://esclave3.exemple.com/svn-proxy-sync \
                      file:///var/svn/depot \
                      -r ${REV} > /dev/null 2>&1 &

La seule chose que nous n'avons pas abordé concerne les verrous (ceux de la commande svn lock). Comme ces verrous sont gérés strictement par le serveur maître au moment des propagations ; mais toutes les informations relatives aux verrous sont distribuées au moment des opérations de lectures telles que svn updateet svn status par le serveur esclave. Ainsi, la configuration complète maître/esclaves se doit de répliquer les informations de verrouillage du maître vers les esclaves. Malheureusement, la plupart des mécanismes qui sont utilisés pour effectuer cette réplication sont confrontés à un problème à un moment ou à un autre[69]. De nombreuses équipes n'utilisent pas du tout les fonctionnalités de verrouillage de Subversion, il s'agit donc peut-être pour vous d'un faux problème. Pour ceux qui utilisent les verrous, nous n'avons malheureusement pas de solution simple et universelle pour combler cette lacune.

Pièges à éviter

Votre système de réplication maître/esclave doit à présent être prêt à l'emploi. Cependant, quelques consignes de prudence sont de mise. Souvenez-vous que la réplication n'est pas totalement robuste en ce qui concerne les plantages machine ou réseau. Par exemple, si l'une des commandes svnsync automatisées demeure inachevée, pour quelque raison que ce soit, les esclaves vont commencer à être décalés. Par exemple, vos utilisateurs distants verront qu'ils ont propagé la révision 100, mais quand ils exécuteront svn update, leur serveur local leur indiquera que la révision 100 n'existe pas encore ! Bien sûr, le problème se réglera automatiquement dès qu'une autre propagation aura lieu et que la commande svnsync qui s'ensuit aura fonctionné — cette synchronisation répliquera toutes les révisions en attente. Néanmoins, vous pouvez décider de mettre en place une surveillance des décalages, vérifiant le bon fonctionnement de la synchronisation et qui, en cas de problème, déclenche une nouvelle exécution de svnsync.

Une autre limitation de modèle de déploiement avec mandataires concerne ceux qui ont des versions différentes de Subversion installées sur les différents maîtres et esclaves. Chaque nouvelle version de Subversion peut (et c'est souvent le cas) ajouter des nouvelles fonctionnalités au protocole réseau utilisé entre le serveur et les clients. Comme la négociation des fonctionnalités possibles intervient à la connexion au serveur esclave, ce sont les capacités annoncées par le serveur esclaves qui sont utilisées. Mais les opérations d'écriture sont transmises au serveur maître pratiquement littéralement. En conséquence, Le risque est que le serveur esclave négocie avec le client l'utilisation de fonctionnalités qui sont possibles avec l'esclave mais que le serveur maître ne comprenne pas parce qu'il fait tourner une version plus ancienne de Subversion, ce qui fait échouer la transaction.

Subversion 1.8 prévient ce type de problème en introduisant une nouvelle directive de configuration Apache, SVNMasterVersion. En configurant chacun de vos serveurs esclaves avec SVNMasterVersion définie à la version de l'instance du serveur Subversion qui tourne sur votre maître, les serveurs esclaves peuvent négocier de manière adéquate le support des fonctionnalités avec le client.

Malheureusement, Subversion 1.7 ne reconnait pas la directive de configuration SVNMasterVersion et est réputé pour avoir des problèmes avec ces lignes.Si vous déployez un serveur esclave en Subversion 1.7 devant un maître en version antérieure à la 1.7, vous configurerez le bloc <Location> de votre serveur esclave avec la directive suivante : SVNAdvertiseV2Protocol Off.

[Astuce] Astuce

Pour obtenir le meilleur fonctionnement possible, essayez de faire tourner la même version de Subversion sur le maître et sur les esclaves.

Pouvons-nous mettre en place la réplication avec svnserve ?

Si vous utilisez svnserve au lieu d'Apache comme serveur, vous pouvez tout à fait configurer les procédures automatiques de votre dépôt pour qu'elles lancent svnsync comme nous l'avons expliqué ici, lançant ainsi la réplication automatique du maître vers les esclaves. Malheureusement, à l'heure où nous écrivons ces lignes, il n'y a pas moyen de s'assurer que des serveurs esclaves svnserve envoient automatiquement les requêtes d'écriture vers le serveur maître. Cela veut dire que vos utilisateurs ne pourraient extraire que des copies de travail en lecture seule des serveurs esclaves. Il vous faudrait donc configurer vos serveurs esclaves pour qu'ils refusent complètement tout accès en écriture. Cela peut être utile pour créer des « miroirs » en lecture seule de projets open source populaires, mais il ne s'agit alors plus d'un système de mandataire d'écriture transparent.

Autres fonctionnalités d'Apache

Il y a également plusieurs fonctionnalités fournies par Apache, en tant que serveur web robuste, dont on peut tirer profit pour améliorer les fonctionnalités ou la sécurité de Subversion. Le client Subversion est capable d'utiliser SSL (Secure Socket Layer, le protocole de sécurisation des échanges sur internet, présenté auparavant). Si votre client Subversion a été compilé en incluant le support de SSL, il peut accéder à votre serveur Apache en utilisant des URL https:// et bénéficier d'une session réseau avec un chiffrement de grande qualité.

D'autres fonctionnalités de la relation Apache/Subversion sont également tout aussi utiles, comme la possibilité de spécifier un port personnalisé (au lieu du port HTTP par défaut, 80) ou un nom de domaine virtuel par lequel accéder au dépôt Subversion ou encore la possibilité d'accéder au dépôt via un serveur mandataire HTTP.

Enfin, comme mod_dav_svn se sert d'un sous-ensemble du protocole WebDAV/DeltaV pour communiquer, il est possible d'accéder au dépôt depuis des clients DAV tiers. La possibilité de monter un serveur DAV en tant que « dossier partagé » réseau standard est intégrée dans la plupart des systèmes d'exploitation modernes (Win32, OS X et Linux). C'est un sujet compliqué, mais merveilleux une fois mis en place. Pour plus de détails, consultez l'Annexe C, WebDAV et la gestion de versions automatique.

Notez qu'il y a un certain nombre d'autres petits « bricolages » que l'on peut faire autour de mod_dav_svn qui sont trop obscurs pour être mentionnés dans ce chapitre. Pour voir la liste complète de toutes les directives httpd.conf auxquelles mod_dav_svn obéit, reportez-vous à la section intitulée « Directives de configuration de mod_dav_svn ».

Référence pour la configuration d'un serveur Subversion HTTP Apache

Dans les sections supra, nous avons mentionné de nombreuses directives que les administrateurs peuvent utiliser dans leurs fichiers httpd.conf pour activer des options et configurer leur « offre de service ». Chaque directive a fait l'objet d'une introduction et d'une brève présentation de la fonctionnalité qu'elle pilote. Dans cette section, nous allons rapidement résumer toutes les directives proposées par à la fois le serveur HTTP Apache et les modules Subversion qui sont livrés avec la distribution standard Subversion.

Directives de configuration de mod_dav_svn

Les directive de configuration infra sont reconnues et interprétées par le module Subversion du serveur HTTP Apache mod_dav_svn.

DAV svn

Doit être incluse dans tout bloc Directory ou Location d'un dépôt Subversion. Elle indique à httpd d'utiliser le module mod_dav pour répondre à toutes les requêtes.

SVNActivitiesDB chemin-vers-répertoire

Spécifie l'emplacement dans le système de fichiers de la base de données qui stocke les rapports d'activités. Par défaut, mod_dav_svn crée et utilise un répertoire dans le dépôt appelé dav/activities.d. Le chemin spécifié par cette option doit être un chemin absolu.

Si elle est incluse dans un bloc SVNParentPath, mod_dav_svn ajoute le nom du répertoire au chemin spécifié ici. Par exemple :

<Location /svn>
  DAV svn

  # toute URL "/svn/foo" correspond à un dépôt dans
  # /net/svn.nfs/depots/truc
  SVNParentPath         "/net/svn.nfs/depots"

  # toute URL "/svn/foo" correspond à un fichier d'activités dans
  #  /var/db/svn/activites/truc
  SVNActivitiesDB       "/var/db/svn/activites"
</Location>
SVNAdvertiseV2Protocol On|Off

Nouveau dans Subversion 1.7. Cette directive indique si mod_dav_svn annonce la compatibilité pour la nouvelle version du protocole HTTP qui a été introduite dans cette version. La plupart des administrateurs n'utilisent pas cette directive (dont la valeur par défaut est On) car elle préfère bénéficier des performances accrues offertes par le nouveau protocole. Cependant, si vous configurez un serveur en tant que mandataire en écriture devant un serveur qui n'est pas compatible avec le nouveau protocole, affectez la valeur Off à cette directive.

SVNAllowBulkUpdates On|Off|Prefer

Autorise la compatibilité avec les réponses « tout compris » pour les requêtes de mises à jour de type REPORT. Les clients Subversion utilisent des requêtes REPORT vers mod_dav_svn pour obtenir des informations lors des extractions et des mises à jour. Ils peuvent demander au serveur d'envoyer les informations soit sous la forme d'une seule réponse (groupée ou bulk en anglais) englobant les informations de toute l'arborescence, soit sous la forme de skeltas qui ne contiennent que l'information juste suffisante pour que le client sache quelles données supplémentaires il doit demander au serveur dans les requêtes suivantes. Quand cette directive est incluse avec la valeur Off, mod_dav_svn ne répond que par des skeltas aux requêtes de type REPORT, quel que soit le type de réponse demandé par le client.

La valeur par défaut pour cette directive est On, ce qui permet au serveur de répondre aux requêtes de mises-à-jour en utilisant le type de réponse (groupée ou skelta) demandé par le client. À partir de Subversion 1.8, cette directive reconnaît également la valeur Prefer. Son comportement est similaire à On sauf que le serveur annonce au client qu'il préfère traiter les requêtes groupées.

Beaucoup d'entre vous n'utiliseront pas du tout cette directive. Elle existe principalement pour les administrateurs qui souhaitent (pour des raisons de sécurité ou d'audit) forcer les clients Subversion à réclamer individuellement chaque fichier et répertoire dont il a besoin pour la mise à jour ou l'extraction, laissant toute une série de traces de requêtes GET et PROPFIND dans les journaux d'Apache.

SVNAutoversioning On|Off

Quand la valeur est On, autorise les requêtes en écriture depuis des clients WebDAV à créer automatiquement des propagations. Un commentaire de propagation générique est créé et joint à la révision. Si vous autorisez l'auto-versionnement, vous définirez certainement aussi ModMimeUsePathInfo On afin que mod_mime puisse affecter automatiquement le bon type MIME à la propriété svn:mime-type (dans la mesure où mod_mime en est capable, bien sûr). Pour plus d'informations, lisez Annexe C, WebDAV et la gestion de versions automatique. La valeur par défaut est Off.

SVNCacheFullTexts On|Off

Lorsque la valeur est On, cela demande à Subversion de mettre en cache, s'il y a suffisamment de place, le contenu textuel. Une amélioration significative des performances du serveur est prévisible (voir aussi la directive SVNInMemoryCacheSize). La valeur par défaut est Off.

SVNCacheTextDeltas On|Off

Quand la valeur est On, cela demande à Subversion de mettre en cache, s'il y a suffisamment de place, le contenu des deltas. Une amélioration significative des performances du serveur est prévisible (voir aussi la directive SVNInMemoryCacheSize). La valeur par défaut est Off.

SVNCompressionLevel niveau

Spécifie le niveau de compression utilisé lors de l'envoi des fichiers sur le réseau. Une valeur de 0 interdit la compression et 9 constitue la valeur maximale. 5 est la valeur par défaut.

SVNHooksEnv chemin-vers-fichier

Spécifie l'emplacement du fichier de configuration de l'environnement des procédures automatiques. Ce fichier est utilisé pour décrire l'environnement initial dans lequel sont exécutés les procédures automatiques. Pour davantage d'informations sur cette fonctionnalité, lisez la section intitulée « Configuration de l'environnement des procédures automatiques ».

SVNIndexXSLT directory-path

Spécifie l'URI d'une transformation XSL pour l'index d'un répertoire. Cette directive est optionnelle.

SVNInMemoryCacheSize taille

Spécifie la taille maximum (en kilooctets) de la mémoire cache par processus Subversion. La valeur par défaut est 16384 ; utilisez la valeur 0 pour ne pas avoir de cache.

SVNListParentPath On|Off

Si vous affectez la valeur On, une requête GET sur SVNParentPath listera tous les dépôts sous ce chemin. La valeur par défaut est Off.

SVNMasterURI url

Spécifie l'URI du dépôt du serveur maître Subversion (utilisée dans le cas d'un serveur mandataire en écriture).

SVNMasterVersion X.Y

Spécifie le numéro de version de l'instance Subversion qui héberge le dépôt maître (utilisé pour un mandataire en écriture).

SVNParentPath directory-path

Spécifie l'emplacement dans le système de fichiers d'un répertoire parent dont les dossiers enfants sont des dépôts Subversion. Dans un bloc de configuration pour un dépôt Subversion, ou bien cette directive est présente, ou bien c'est la variable SVNPath.

SVNPath chemin-vers-repertoire

Spécifie l'emplacement dans le système de fichiers des fichiers stockant le dépôt Subversion. Dans un bloc de configuration pour un dépôt Subversion, ou bien cette directive est présente, ou bien c'est la variable SVNParentPath.

SVNPathAuthz On|Off|short_circuit

Configure le contrôle d'accès sur les chemins en autorisant (On) les sous-requêtes, en les désactivant (Off ; reportez-vous à la section intitulée « Désactivation du contrôle sur les chemins ») ou en demandant directement à mod_authz_svn (short_circuit). La valeur par défaut est On.

SVNReposName nom

Spécifie le nom du dépôt Subversion à utiliser dans les réponses à des requêtes HTTP GET. Cette valeur sera ajoutée au début du titre dans tous les affichages de répertoires (qui sont transmis lorsque vous naviguez dans un dépôt Subversion avec un navigateur Web). Cette directive est optionnelle.

[Note] Note

Subversion n'utilise pas le nom du dépôt tel que configuré par cette directive lorsqu'il établit les correspondances dans les règles de contrôle d'accès. Les noms de dépôts utilisés dans ce fichier sont toujours pris à partir de l'URL du dépôt. Lisez la section intitulée « Introduction au contrôle d'accès basé sur les chemins » pour obtenir des détails.
SVNSpecialURI composant

Spécifie l'URI d'un composant (espace de noms) pour les ressources spéciales Subversion. La valeur par défaut est !svn et la majorité des administrateurs n'utilisera jamais cette directive. Définissez la uniquement si vous avez absolument besoin d'avoir un fichier dont le nom est !svn dans votre dépôt. Si vous changez cette valeur sur un serveur déjà en service, cela cassera toutes les copies de travail déjà extraites et vos utilisateurs vous pourchasseront avec des piques et des fers portés au rouge.

SVNUseUTF8 On|Off

Quand la valeur est On, mod_dav_svn communique avec les procédures automatiques en utilisant les chemins racines du dépôt encodés en UTF-8 et il s'attend à ce que les procédures automatiques génèrent des sorties (tels que les messages d'erreurs) aussi en UTF-8. La valeur par défaut est Off, ce qui signifie que mod_dav_svn suppose que les procédures automatiques interagissent en ASCII 7 bits. Cette option est disponible pour Subversion 1.8 et ultérieurs.

[Note] Note

Les administrateurs doivent s'assurer que l'encodage attendu par les procédures automatiques est bien conforme à celui utilisé pour toutes les façons dont elles peuvent être appelées. Par exemple, si un dépôt est accessible à la fois par httpd et par svnserve, svnserve doit être configuré aussi pour utiliser UTF-8 (en définissant correctement les « locales » dans l'environnement) si cette option est définie pour mod_dav_svn. Aussi, les chemins dans le système de fichiers local qui contiennent des caractères non ASCII et qui sont référencés par ces procédures (tels que les chemins racines des dépôts) doivent être proprement encodés dans le système de fichiers pour correspondre aux attendus des procédures automatiques.

Directives de configuration de mod_authz_svn

Les directives de configurations suivantes concernent mod_authz_svn, le module Subversion pour le contrôle d'accès basé sur les chemins du serveur HTTP Apache. Pour une description approfondie du contrôle d'accès basé sur les chemins dans Subversion, reportez-vous à la section intitulée « Contrôle d'accès basé sur les chemins ».

AuthzForceUsernameCase Upper|Lower

Définissez la valeur à Upper (resp. Lower) pour convertir l'identifiant en majuscules (resp. minuscules) avant de le soumettre au contrôle d'accès. Comme les identifiants sont comparés avec le fichier de contrôle d'accès en étant sensibles à la casse, cette directive permet au moins de normaliser des identifiants dont la casse varie vers un ensemble cohérent.

AuthzSVNAccessFile chemin-vers-fichier

Consulte le fichier chemin-vers-fichier pour le contrôle d'accès des chemins dans le dépôt Subversion. Dans un bloc de configuration d'un dépôt Subversion ou d'un ensemble de dépôts, soit cette directive, soit AuthzSVNReposRelativeAccessFile peuvent être présentes, mais pas les deux.

À partir de Subversion 1.8, AuthzSVNAccessFile accepte une URL qui pointe vers un fichier stocké dans un dépôt Subversion. Il est possible de stocker le fichier dans le même dépôt que celui où les règles de contrôle d'accès s'appliquent, ou dans un autre dépôt.

AuthzSVNAnonymous On|Off

Définissez à Off pour désactiver deux comportements particuliers de ce module : l'interaction avec la directive Satisfy Any et le forçage de la politique de contrôle d'accès même si aucune directive Require n'est présente. La valeur par défaut pour cette directive est On.

AuthzSVNAuthoritative On|Off

Définissez à Off pour déléguer le contrôle d'accès à des modules plus bas. La valeur par défaut pour cette directive est On.

AuthzSVNNoAuthWhenAnonymousAllowed On|Off

Définissez à On pour supprimer l'authentification et le contrôle d'accès pour les requêtes pour lesquelles les utiilisateurs anonymes sont autorisés. La valeur par défaut pour cette directive est On.

AuthzSVNReposRelativeAccessFile chemin-vers-fichier

Consulter chemin-vers-fichier pour les règles de contrôle d'accès relatives aux chemins dans le dépôt Subversion. Au contraire de AuthzSVNAccessFile, le chemin spécifié dans AuthzSVNReposRelativeAccessFile est relatif au répertoire conf/ dans le dépôt sur le système de fichiers. En d'autres termes, chemin-vers-fichier spécifie un fichier par dépôt qui doit être accessible par ce chemin relatif dans tous les dépôts. Dans un bloc du fichier de configuration, soit cette directive, soit AuthzSVNAccessFile doit être présente, mais pas les deux. Cette options est disponible à partir de Subversion 1.7.

À partir de Subversion 1.8, AuthzSVNReposRelativeAccessFile accepte une URL pointant vers un fichier situé à l'intérieur d'un dépôt Subversion. Il est possible que ce fichier soit à l'intérieur du même dépôt que celui dont on définit les règles de contrôle d'accès, ou à l'intérieur d'un autre dépôt.


[65] C'est une chose qu'ils détestent faire.

[68] Bien que les certificats auto-signés sont vulnérables à une attaque dite « Man-in-the-Middle » (homme du milieu en anglais) au moment où le client voit le certificat pour la première fois, une telle attaque reste beaucoup plus complexe à mettre en œuvre lors d'une écoute occasionnelle que le simple fait de récupérer des mots de passe qui passent en clair.

Précédent  Niveau supérieur  Suivant
svnserve, un serveur sur mesure  Sommaire  Contrôle d'accès basé sur les chemins