Le serveur HTTP Apache est un serveur réseau à tout faire que Subversion sait exploiter. Via un module adapté, httpd rend les dépôts Subversion accessibles aux clients par le protocole WebDAV/DeltaV, qui est une extension de HTTP 1.1 (voir http://www.webdav.org/ pour plus d'informations). 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[46]. Bien qu'un serveur Apache-Subversion ait plus de fonctionnalités que svnserve, il est aussi 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 http://httpd.apache.org. Par exemple, le guide de référence complet des directives de configuration est situé à l'adresse http://httpd.apache.org/docs-2.0/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.
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, 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 2.0 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 ci-dessus
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.
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
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 /depot> 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 créer et mettre à
disposition sur le réseau de nouveaux dépôts.
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.
À 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.
À 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 » au reste du 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.
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 un utilitaire htpasswd pour gérer la liste des noms d'utilisateurs et mots de passe acceptés. Accordons le droit de propager à Sally et à Harry. D'abord, il faut les ajouter au fichier des mots de passe :
$ ### 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/fichier-auth-svn harry New password: ***** Re-type new password: ***** Adding password for user harry $ htpasswd -m /etc/fichier-auth-svn sally New password: ******* Re-type new password: ******* Adding password for user sally $
Ensuite, vous devez ajouter des directives dans le bloc
Location du fichier
httpd.conf pour indiquer à Apache comment
se servir du nouveau fichier des mots de passe. La directive
AuthType spécifie le type d'authentification
que l'on veut utiliser. Dans notre cas, nous voulons utiliser
le mode « Basic ». La directive
AuthName permet de donner un nom arbitraire
au domaine d'authentification. La plupart des navigateurs
affichent ce nom dans la boîte de dialogue (pop-up)
qui demande le nom d'utilisateur et le mot de passe. Enfin,
utilisez la directive AuthUserFile pour
spécifier le chemin du fichier des mots de passe que vous venez
de créer avec la commande htpasswd.
Après avoir ajouté ces trois directives, votre bloc
<Location> devrait ressembler à
ceci :
<Location /svn> DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Depot Subversion" AuthUserFile /etc/fichier-auth-svn </Location>
Ce bloc <Location> n'est pas
encore complet et il ne sert pas à grand chose pour l'instant.
Il indique juste à Apache que, lorsqu'un contrôle d'accès est
requis, Apache doit demander un nom d'utilisateur et un mot de
passe au client Subversion. 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. Dès que le contrôle d'accès est demandé, Apache
exige également l'authentification. La chose la plus simple à
faire est de protéger toutes les requêtes. Ajouter
Require valid-user signale à Apache que,
pour toutes les requêtes, l'utilisateur doit être
authentifié :
<Location /svn> DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Depot Subversion" AuthUserFile /etc/fichier-auth-svn Require valid-user
Prenez bien soin de lire la section intitulée « Options de contrôle d'accès » qui suit 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.
Un petit avertissement : les mots de passe de la méthode HTTP Basic Auth circulent pratiquement en clair sur le réseau et ne sont donc pas du tout sécurisés.
Une autre possibilité est de ne pas utiliser la méthode
d'authentification Basic mais d'utiliser la
méthode d'authentification Digest à la
place. L'authentification Digest permet au
server de vérifier l'identité du client sans envoyer
le mot de passe en clair sur le réseau. En
supposant que le client et le serveur connaissent tous les
deux le mot de passe de l'utilisateur, ils peuvent vérifier
que le mot de passe est le même en l'utilisant pour appliquer
une fonction de hachage à une donnée créée pour l'occasion. Le
serveur envoie au client une chaîne plus ou moins aléatoire de
petite taille ; le client se sert du mot de passe de
l'utilisateur pour créer un condensat
(hash en anglais) de
cette chaîne ; le serveur examine ensuite si le condensat
correspond à ses attentes.
Configurer Apache pour la méthode d'authentification
Digest est également assez facile et ne
comporte qu'une petite variation par rapport à notre exemple
précédent. Prenez soin de consulter la documentation complète
d'Apache pour plus de détails.
<Location /svn> DAV svn SVNParentPath /var/svn AuthType Digest AuthName "Depot Subversion" AuthDigestDomain /svn/ AuthUserFile /etc/fichier-auth-svn Require valid-user </Location>
Si vous recherchez la sécurité maximale, la cryptographie
à clé publique est la meilleure solution. Il est sans doute
mieux d'utiliser du chiffrement SSL afin que les clients
s'authentifient via https:// au lieu de
http:// ; le minimum minimorum
consiste alors à configurer Apache pour qu'il utilise un
certificat serveur auto-signé[47].
Consultez la documentation Apache (et la documentation
OpenSSL) pour savoir comment faire.
Les entreprises qui ont besoin de rendre leur dépôts disponibles au-delà du pare-feu périmétrique de leur société doivent être conscientes que des entités non-autorisées auront la possibilité d'« écouter » leur trafic réseau. SSL permet de diminuer le risque que cette écoute conduise à des fuites de données sensibles.
Si un client Subversion est compilé pour utiliser OpenSSL,
il obtient la possibilité de communiquer avec le serveur
Apache via des URL https://. La
bibliothèque Neon utilisée par le client Subversion est non
seulement capable de vérifier les certificats du serveur, mais
aussi de renvoyer des certificats clients quand on le lui
demande. Une fois que le client et le serveur ont échangé des
certificats SSL et se sont authentifiés mutuellement avec
succès, tous les échanges qui s'ensuivent sont chiffrés par
une clé de session.
Expliquer comment générer des certificats clients et serveurs ou comment configurer Apache pour les utiliser s'éloigne trop du sujet de ce livre. De nombreux autres livres, dont la documentation Apache elle-même, expliquent comment le faire. Mais nous pouvons quand même traiter ici la question de la gestion des certificats clients et serveurs à partir d'un client Subversion ordinaire.
Quand il communique avec Apache via
https://, un client Subversion peut
recevoir deux types d'informations différentes :
un certificat serveur ;
une demande de certificat client.
Si le client reçoit un certificat serveur, il doit vérifier que ce certificat est digne de confiance : le serveur est-il bien celui qu'il prétend être ? La bibliothèque OpenSSL effectue cette vérification en examinant le signataire du certificat serveur, aussi nommé autorité de certification (AC, ou CA en anglais). Si OpenSSL n'est pas capable de faire confiance automatiquement à l'autorité de certification, ou si un autre problème apparaît (tel que l'expiration du certificat ou des noms d'hôtes divergents), le client en ligne de commande de Subversion vous demande si vous voulez faire confiance au certificat serveur malgré tout :
$ svn list https://hote.exemple.com/depot/projet Erreur de validation du certificat du serveur pour 'https://hote.exemple.com:443' : - Le certificat n'est pas signé pas une autorité de confiance. Valider le certificat manuellement ! Informations du certificat : - nom d'hôte : hote.exemple.com - valide de Jan 30 19:23:56 2004 GMT à Jan 30 19:23:56 2006 GMT - signataire : CA, exemple.com, Sometown, California, US - empreinte : 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b (R)ejet, acceptation (t)emporaire ou (p)ermanente ?
Cette question devrait vous être familière ; c'est
probablement la même que vous avez déjà dû voir posée par
votre navigateur web (qui n'est rien d'autre qu'un client HTTP
comme Subversion). Si vous choisissez l'option
(p)ermanente, le certificat du serveur sera
mis en cache dans votre zone privée auth/
de la même façon que le nom d'utilisateur et le mot de passe y
sont conservés (voir la section intitulée « Mise en cache des éléments d'authentification du client »). S'il est en
cache, Subversion fera automatiquement confiance à ce
certificat dans les échanges futurs.
Votre fichier servers dans la zone de
configuration vous permet également d'indiquer au client
Subversion qu'il doit automatiquement faire confiance à
certaines autorités de certification spécifiques, soit
globalement, soit en tenant compte de la machine hôte. Il
suffit d'attribuer à la variable
ssl-authority-files une liste de certificats
d'autorités de certification au format PEM, séparés par des
points-virgules :
[global] ssl-authority-files = /chemin/vers/certAC-1.pem;/chemin/vers/certAC-2.pem
De nombreuses installations d'OpenSSL possèdent par défaut
une liste prédéfinie d'autorités de certification auxquelles
il est fait confiance de manière quasi-universelle. Pour que
le client Subversion fasse confiance à ces autorités de
certification automatiquement, mettez la variable
ssl-trust-default-ca à
true.
Quand il communique avec Apache, un client Subversion peut également recevoir une demande (un défi) de certificat client. Apache demande au client de s'authentifier : le client est-il bien celui qu'il prétend être ? Si tout se passe bien, le client Subversion renvoie un certificat (public) signé par une autorité de certification en laquelle Apache a confiance ainsi qu'une preuve que le client possède bien la clé privée associée au certificat (la réponse au défi). La clé privée, ainsi que le certificat public, sont habituellement enregistrés dans un conteneur (un fichier « .p12 », fichier au format PKCS#12) sur le disque, la clé privée étant chiffrée à l'aide d'un mot de passe. Quand Subversion reçoit ce défi, il vous demande le chemin d'accès au conteneur ainsi que le mot de passe qui protège la clé privée :
$ svn list https://hote.exemple.com/depot/projet Domaine d'authentification : https://hote.exemple.com:443 Fichier du certificat client : /chemin/vers/mon/cert.p12 Phrase de passe pour '/chemin/vers/mon/cert.p12' : ******** …
Pour utiliser un certificat client avec Subversion, il doit être dans un conteneur au format PKCS#12, qui est un standard portable. La plupart des navigateurs web sont déjà capables d'importer et d'exporter des certificats dans ce format. Une autre option est d'utiliser les outils en ligne de commande d'OpenSSL pour convertir les certificats existants en PKCS#12.
Encore une fois, le fichier servers
de la zone de configuration vous permet d'automatiser la
réponse à ces demandes en tenant compte de la machine hôte.
L'une ou l'autre des informations, ou bien les deux, peuvent
être décrites dans les variables de configuration :
[groups] exemple-d-hote = hote.exemple.com [exemple-d-hote] ssl-client-cert-file = /chemin/vers/mon/cert.p12 ssl-client-cert-password = un-mot-de-passe
Une fois que vous avez défini les variables
ssl-client-cert-file et
ssl-client-cert-password, le client
Subversion peut répondre automatiquement à une demande de
certificat client sans la moindre interaction de votre
part[48].
À ce stade, vous avez configuré l'authentification mais pas le contrôle d'accès. Apache est capable d'envoyer des défis aux clients afin de confirmer leur identité mais on ne lui a pas encore dit comment autoriser ou restreindre les accès en fonction de l'utilisateur. Ce paragraphe décrit deux stratégies pour contrôler les accès au dépôt.
La forme la plus simple de contrôle d'accès est d'autoriser des utilisateurs donnés à accéder à un dépôt en lecture seule ou en lecture/écriture.
Vous pouvez restreindre l'accès à toutes les opérations du
dépôt en ajoutant la directive
Require valid-user à votre bloc
<Location>. Pour poursuivre dans la
veine de notre exemple précédent, cela signifie que seuls les
clients disant être harry ou
sally et qui ont fourni le bon mot de passe
pour leur nom d'utilisateur respectif ont l'autorisation
d'effectuer des actions sur le dépôt Subversion :
<Location /svn> DAV svn SVNParentPath /var/svn # comment authentifier un utilisateur AuthType Basic AuthName "Depot Subversion" AuthUserFile /chemin/vers/fichier/utilisateurs # seuls les utilisateurs authentifiés ont le droit d'accès au dépôt Require valid-user </Location>
Parfois vous n'aurez pas besoin d'être aussi strict. Par
exemple, le propre dépôt du code source de Subversion, situé à
l'adresse http://svn.apache.org/repos/asf/subversion/
autorise toute personne à effectuer des opérations de lecture
du dépôt (comme extraire des copies de travail ou naviguer
dans le dépôt avec un navigateur web) mais restreint toutes
les opérations d'écriture aux utilisateurs authentifiés. Pour
accomplir ce type de restriction sélective, vous pouvez
utiliser les directives de configuration
Limit et LimitExcept.
Tout comme la directive Location, ces blocs
doivent débuter et finir par des balises et vous devez les
imbriquer dans votre bloc <Location>.
Les paramètres présents dans les directives
Limit et LimitExcept
sont des types de requêtes HTTP qui sont concernés par ce
bloc. Par exemple, si voulez désactiver tout accès au dépôt
excepté pour les opérations de lecture déjà supportées,
utilisez la directive LimitExcept, en lui
passant les paramètres de type de requêtes
GET, PROPFIND,
OPTIONS et REPORT.
Ensuite placez la directive Require valid-user
mentionnée précédemment à l'intérieur du bloc
<LimitExcept> au lieu de la mettre
juste à l'intérieur du bloc
<Location>.
<Location /svn>
DAV svn
SVNParentPath /var/svn
# comment authentifier un utilisateur
AuthType Basic
AuthName "Depot Subversion"
AuthUserFile /chemin/vers/fichier/utilisateurs
# Pour toute autre opération que celles-ci, exiger un utilisateur authentifié.
<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 http://httpd.apache.org/docs-2.0/misc/tutorials.html
(site en anglais).
On peut également mettre en place des droits d'accès avec une granularité plus fine en utilisant un second module Apache httpd, mod_authz_svn. Ce module 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 qu'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 (nous allons étudier le format de ce
fichier).
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).
Le bloc le 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.1, « Exemple-type de configuration : accès anonyme »).
Exemple 6.1. Exemple-type de configuration : accès anonyme
<Location /depot>
DAV svn
SVNParentPath /var/svn
# notre politique de contrôle d'accès
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.2, « Exemple-type de configuration : accès authentifié »).
Exemple 6.2. Exemple-type de configuration : accès authentifié
<Location /depot>
DAV svn
SVNParentPath /var/svn
# notre politique de contrôle d'accès
AuthzSVNAccessFile /chemin/vers/fichier/acces
# seuls les utilisateurs authentifiés ont accès au dépôt
Require valid-user
# comment authentifier un utilisateur
AuthType Basic
AuthName "Depot Subversion"
AuthUserFile /chemin/vers/fichier/utilisateurs
</Location>
Une troisième méthode largement 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.3, « Exemple-type de configuration : accès mixte
authentifié/anonyme »).
Exemple 6.3. Exemple-type de configuration : accès mixte authentifié/anonyme
<Location /depot>
DAV svn
SVNParentPath /var/svn
# notre politique de contrôle d'accès
AuthzSVNAccessFile /chemin/vers/fichier/acces
# essayer d'abord un accès anonyme,
# ne demander une véritable authentification
# que si nécessaire
Satisfy Any
Require valid-user
# comment authentifier un utilisateur
AuthType Basic
AuthName "Depot Subversion"
AuthUserFile /chemin/vers/fichier/utilisateurs
</Location>
Une fois l'un de ces modèles mis en place dans votre
fichier httpd.conf, vous devez créer un
fichier contenant les règles d'accès particulières pour chaque
chemin de votre dépôt. Nous en parlons plus en détails
plus loin dans ce chapitre, à la section intitulée « Contrôle d'accès basé 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 message 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 qui ont été
installés, donc tout ce qu'il peut faire est de demander à
Apache de lancer n'importe quel contrôle qui soit présent.
D'un autre côté, il existe une sorte d'échappatoire qui
vous permet de faire un compromis entre les fonctions de
sécurité et 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.4, « Désactiver complètement les contrôles sur les
chemins ».
Exemple 6.4. 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 contrôler chaque chemin qu'il traite.
Nous avons traité la plupart des options d'authentification et de contrôle d'accès pour Apache et mod_dav_svn. Mais Apache fournit quelques autres fonctionnalités sympathiques.
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.
Comme les URL ne contiennent pas d'informations concernant 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.
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
justesse à 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.
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 "/index-svn.xsl" … </Location>
A 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
schémas de couleur et d'imagerie utilisés 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 au
répertoire SVNIndexXSLT est en fait une
URL — les navigateurs de chemins doivent être
capables de lire vos feuilles de style pour les
utiliser !
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.
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, 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 send-copyfrom-args [26/Jan/2007:22:25:29 -0600] - status /trunk/machin r1729 depth=infinity [26/Jan/2007:22:25:31 -0600] sally commit r1730
Pour une liste exhaustive de toutes les actions journalisées, reportez-vous à la section intitulée « Journalisation de haut niveau ».
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 ce paragraphe, 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).
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 ; s'ils ne peuvent plus se synchroniser, cela peut engendrer beaucoup d'ennuis.
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>
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 d'un dépôt » pour plus de
détails.
Tout d'abord, assurez-vous que chaque dépôt esclave a
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 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 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 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 que c'est 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 > /dev/null 2>&1 svnsync sync http://esclave2.exemple.com/svn-proxy-sync > /dev/null 2>&1 svnsync sync http://esclave3.exemple.com/svn-proxy-sync > /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 post-revprop-change
pour que, disons, quand un utilisateur modifie un message 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 ${REV} > /dev/null 2>&1
svnsync copy-revprops http://esclave2.exemple.com/svn-proxy-sync ${REV} > /dev/null 2>&1
svnsync copy-revprops http://esclave3.exemple.com/svn-proxy-sync ${REV} > /dev/null 2>&1
La seule chose que nous n'avons pas détaillé concerne
les verrous. Comme les verrous sont gérés strictement par le
serveur maître (le seul endroit où des propagations ont
lieu), nous n'avons en théorie pas besoin de faire quoi que
ce soit. 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. Cependant, si
les modifications de verrous ne sont pas répliquées du
maître vers les esclaves, cela signifie que les clients ne
seront pas capables d'interroger l'état des verrous (par
exemple, svn status -u ne donne
aucune information sur les verrous du dépôt). Si cela vous
embête, vous pouvez écrire des procédures automatiques
post-lock et
post-unlock qui lancent
svn lock et svn
unlock sur les serveurs esclaves,
vraisemblablement à l'aide d'une méthode de connexion à
distance telle que SSH. Nous laissons ceci au lecteur
en guise d'exercice !
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.
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 par exemple 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 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 ».
[46] C'est une chose qu'ils détestent faire.
[47] Bien que les certificats serveurs auto-signés soient vulnérables aux attaques du type man-in-the-middle (« attaque de l'homme du milieu » en français), une telle attaque est bien plus difficile à exécuter pour un observateur occasionnel que de juste espionner les mots de passe qui passent en clair sur le réseau.
[48] Les administrateurs qui attachent le plus
d'importance à la sécurité
peuvent ne pas vouloir stocker le mot de passe du
certificat client dans le fichier
servers de la zone de
configuration.
[49] A l'époque, il s'appelait ViewCVS.