La plus flexible de toutes les installations serveur possibles pour Subversion est basée sur Apache. Bien qu'un peu plus compliquée à mettre en place, elle offre des avantages que d'autres serveurs n'ont pas :

La première chose dont vous avez besoin avant d'installer Apache est d'un ordinateur avec Windows2000, WinXP+SP1, Windows 2003, Vista ou Windows Server 2008.

Vous avez maintenant mis en place Apache et Subversion, mais Apache ne sait pas encore comment gérer les clients Subversion comme TortoiseSVN. Pour qu'Apache sache quelle URL sera utilisée pour les référentiels Subversion vous devez éditer le fichier de configuration d'Apache (d'habitude placé dans c:\program files\apache group\apache2\conf\httpd.conf) avec votre éditeur de texte préféré (par exemple le Bloc-notes) :

Une courte explication sur ce que vous venez juste de saisir :

Mais ce n'est qu'un exemple. Il y a beaucoup, beaucoup plus de possibilités que vous pouvez faire avec le serveur web Apache.

Si vous avez utilisé la directive SVNParentPath alors vous n'avez pas à changer le fichier de configuration d'Apache chaque fois que vous ajoutez un nouveau référentiel Subversion. Créez simplement le nouveau référentiel au même emplacement que le premier référentiel et vous avez fini ! Dans ma société, j'ai un accès direct à ce dossier spécifique sur le serveur via SMB (accès Windows normal aux fichiers). Donc je crée juste un nouveau dossier là, j'exécute la commande de TortoiseSVN TortoiseSVN → Créer un référentiel ici... et un nouveau projet a un foyer...

Si vous utilisez Subversion 1.3 ou supérieur, vous pouvez utiliser la directive SVNListParentPath on pour permettre à Apache de produire une liste de tous les projets disponibles si vous allez avec votre navigateur sur le chemin parent plutôt qu'à un référentiel spécifique.

Le module mod_authz_svn permet un contrôle précis des autorisations d'accès basé sur les noms des utilisateurs et les chemins de référentiel. C'est possible avec le serveur Apache et, à partir de Subversion 1.3, c'est aussi disponible avec svnserve.

Un fichier d'exemple ressemblerait à ceci :

[groups]
admin = john, kate
devteam1 = john, rachel, sally
devteam2 = kate, peter, mark
docs = bob, jane, mike
training = zak
# Accès par défaut à TOUS les référentiels
# Tout le monde peut lire, les admins peuvent écrire, Dan German est exclus.
[/]
* = r
@admin = rw
dangerman =
# Permet aux développeurs un accès total aux référentiels de leurs projets
[proj1:/]
@devteam1 = rw
[proj2:/]
@devteam2 = rw
[bigproj:/]
@devteam1 = rw
@devteam2 = rw
trevor = rw
# Donne aux personnes en charge de la documentation un accès en écrite sur tous les répertoires de la documentation
[/trunk/doc]
@docs = rw
# Donne aux débutants un accès en écriture uniquement au référentiel d'entraînement
[TrainingRepos:/]
@training = rw

Notez que la vérification de chaque chemin peut être une opération couteuse, particulièrement dans le cas du journal de révision. Le serveur vérifie chaque chemin changé dans chaque révision et le vérifie pour la lisibilité, qui peut être consommatrice de temps sur les révisions qui affectent de grands nombres de fichiers.

L'authentification et l'autorisation sont des processus séparés. Si un utilisateur veut obtenir l'accès à un chemin de référentiel, il doit satisfaire tant les pré-requis habituels d'authentification que les pré-requis d'autorisation du fichier d'accès.

Comme vous l'avez peut-être remarqué vous devez faire une entrée nom d'utilisateur/mot de passe dans le fichier passwd pour chaque utilisateur séparément. Et si (pour des raisons de sécurité) vous voulez que vos utilisateurs changent périodiquement leurs mots de passe vous devez faire le changement manuellement.

Mais il y a une solution pour ce problème - du moins si vous avez accès au référentiel de l'intérieur d'un réseau local avec un contrôleur de domaine Windows : mod_auth_sspi !

Le module SSPI original a été offert par Syneapps en incluant le code source. Mais son développement a été arrêté. Mais ne désespérez pas, la communauté l'a récupéré et l'a amélioré. Il a un nouveau foyer sur SourceForge.

Notez que si vous vous authentifiez en utilisant SSPI, alors vous n'avez plus besoin de la ligne AuthUserFile pour définir un fichier de mot de passe. Apache authentifie votre nom d'utilisateur et votre mot de passe avec votre domaine Windows à la place. Vous devrez mettre à jour la liste d'utilisateurs dans votre svnaccessfile pour faire aussi référence au DOMAINE\nom d'utilisateur.

Il est aussi possible d'avoir plus d'une source d'authentification pour votre référentiel Subversion. Pour ce faire, vous devez rendre chaque type d'authentification non définitive, pour qu'Apache vérifie plusieurs sources pour la correspondance nom utilisateur/mot de passe.

Un scénario fréquent consiste à utiliser l'authentification par le domaine Windows et par fichier passwd, pour que vous puissiez fournir un accès SVN aux utilisateurs qui ne possèdent pas de login dans le domaine Windows.

Voici un exemple de configuration complète d'Apache pour une authentification combinant le domaine Windows et le fichier d'authentification passwd :

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\SVN

  AuthName "Subversion repositories"
  AuthzSVNAccessFile svnaccessfile.txt

# NT Domain Logins.
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative Off
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On

# Htpasswd Logins.
  AuthType Basic
  AuthBasicAuthoritative Off
  AuthUserFile passwd

  Require valid-user
</Location>

Même si Apache 2.2.x permet le support OpenSSL, ce n'est pas activé par défatu. Vous devez l'activer manuellement.

<Location /svn>
  DAV svn
  SVNParentPath D:\SVN
  SSLRequireSSL
  AuthType Basic
  AuthName "Subversion repositories"
  AuthUserFile passwd
  #AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

Envoyé à la liste de diffusion TortoiseSVN par Nigel Green. Merci !

Avec certaines configurations de serveur, vous pouvez avoir à mettre en place un seul serveur avec 2 hôtes SSL virtuels: Le premier pour les accès internet publics, ne nécessitant aucun certificat côté client. Et un second, sécurisé avec certificat côté client, où tourne le serveur Subversion.

Dans le fichier de configuration de Apache, ajouter une directive SSLVerifyClient Optional à la section per-server (i.e. en dehors de balises VirtualHost et Directory) force Apache à demander un certificat au client au moment d'établir la connexion SSL. A cause d'un bug dans le module mod_ssl il est crucial de demander le certificat à ce moment car sinon il ne fonctionnera plus en cas de tentative de re-connexion SSL.

La solution est d'ajouter la directive suivante dans le répertoire du virtual host que vous voulez réserver à Subversion:

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

Cette directive autorise l'accès au répertoire seulement si le certificat du client a été reçu et validé.

Pour résumer; les lignes utiles du fichier de configuration Apache sont:

SSLVerifyClient Optional

### Configuration du virtual host public 
### (ne nécessitant pas de certificat)

<VirtualHost 127.0.0.1:443>
  <Directory "chemin du repertoire racine public">
  </Directory>
</VirtualHost>

###  Configuration du virtual host pour SUBVERSION 
### (nécessitant une certificat)
<VirtualHost 127.0.0.1:443>
  <Directory "chemin du repertoire racine de subversion">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /chemin du referentiel
  </Location>
</VirtualHost>