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.

Choix d'une configuration serveur
Précédent  Chapitre 6. Configuration du serveur  Suivant

Choix d'une configuration serveur

Et alors, quel serveur vous faut-il ? Quel est le meilleur ?

Bien évidemment, il n'y a pas de bonne réponse à cette question. Chaque équipe a des besoins propres et les différents serveurs représentent des compromis différents. Le projet Subversion lui-même ne recommande pas un serveur plus qu'un autre, ni ne considère qu'un serveur est plus « officiel » qu'un autre.

Voici quelques argumentaires qui vous aideront à choisir entre un déploiement et un autre, ainsi que quelques raisons de ne pas choisir l'un d'entre eux.

Serveur svnserve

Les bonnes raisons de l'utiliser :

  • facile et rapide à mettre en place ;

  • le protocole réseau possède la notion d'états et est significativement plus rapide que WebDAV ;

  • pas besoin de créer des comptes utilisateurs système sur le serveur ;

  • le mot de passe ne circule pas sur le réseau.

Pourquoi l'éviter :

  • par défaut, seule une méthode d'authentification est disponible, le protocole réseau n'est pas chiffré et le serveur enregistre les mots de passe en clair (tous ces éléments peuvent être modifiés en configurant SASL, mais cela requiert un peu plus de travail) ;

  • Pas de journalisation avancée ;

  • pas de navigation web intégrée (il vous faut installer un serveur web séparé et un logiciel de navigation du dépôt pour ajouter cette fonctionnalité).

svnserve sur SSH

Les bonnes raisons de l'utiliser :

  • le protocole réseau possède la notion d'états et est significativement plus rapide que WebDAV ;

  • vous pouvez tirer parti des comptes SSH existants et de l'infrastructure déjà mise en place pour les utilisateurs ;

  • tout le trafic réseau est chiffré.

Pourquoi l'éviter :

  • il n'y a qu'un seul choix possible de méthode d'authentification ;

  • Les possibilités de journalisation sont limitées ;

  • les utilisateurs doivent être membres du même groupe système ou utiliser une clé SSH partagée ;

  • mal utilisé, il peut aboutir à des problèmes de droits sur les fichiers.

Serveur HTTP Apache

Les bonnes raisons de l'utiliser :

  • il permet à Subversion d'utiliser n'importe lequel des nombreux systèmes d'authentification déjà intégrés dans Apache ;

  • pas besoin de créer des comptes système sur le serveur ;

  • journalisation Apache complète disponible ;

  • le trafic réseau peut être chiffré par SSL ;

  • HTTP(S) fonctionne généralement même derrière des pare-feux d'entreprise ;

  • la possibilité de parcourir le dépôt avec un navigateur Web est disponible nativement ;

  • le dépôt peut être monté en tant que lecteur réseau à des fins de gestion de versionstransparente (voir la section intitulée « Gestion de versions automatique »).

Pourquoi l'éviter :

  • significativement plus lent que svnserve, car HTTP est un protocole sans état et nécessite plus d'allers et retours réseau ;

  • la mise en place initiale peut s'avérer complexe.

Recommandations

En général, les auteurs de ce livre recommandent une installation ordinaire de svnserve aux petites équipes qui débutent avec Subversion ; c'est le plus simple à installer et celui qui pose le moins de problèmes de maintenance. Vous pouvez toujours passer au déploiement d'un serveur plus complexe au fur et à mesure que vos besoins évoluent.

Voici quelques recommandations et astuces générales, basées sur des années de support aux utilisateurs :

  • si vous essayez de mettre en place le serveur le plus simple possible pour votre groupe, une installation ordinaire de svnserve est la voie la plus sûre et la plus rapide. Notez cependant que les données de votre dépôt circuleront en clair sur le réseau. Si votre déploiement se situe entièrement à l'intérieur du LAN ou du VPN de votre compagnie, ce n'est pas un problème. Si le dépôt est accessible sur Internet, il serait bon de vous assurer que son contenu n'est pas sensible (par exemple s'il ne contient que du code open source), ou alors de faire l'effort supplémentaire de configurer SASL pour chiffrer les communications réseau ;

  • si vous devez vous insérer au sein de systèmes d'authentification déjà en place (LDAP, Active Directory, NTLM, X.509, etc.), il vous faudra utiliser soit le serveur basé sur Apache, soit svnserve configuré avec SASL ;

  • que vous ayez décidé d'utiliser Apache ou un banal svnserve, créez un utilisateur svn unique sur votre système et utilisez-le pour faire tourner le processus serveur. Assurez-vous également que la totalité du répertoire du dépôt est la propriété de cet utilisateur. Du point de vue de la sécurité, les données du dépôt restent ainsi englobées et protégées par l'application des droits gérés par le système de fichiers du système d'exploitation et sont modifiables uniquement par le processus serveur Subversion lui-même ;

  • si vous disposez d'une infrastructure existante basée principalement sur des comptes SSH et si vos utilisateurs possèdent déjà des comptes système sur la machine qui sert de serveur, il est logique de déployer une solution svnserve sur SSH. Dans le cas contraire, nous ne recommandons généralement pas cette option au public. Il est considéré comme plus sûr de donner l'accès au dépôt à vos utilisateurs au moyen de comptes (imaginaires) gérés par svnserve ou Apache plutôt que par de véritables comptes système. Si vous voulez vraiment chiffrer les communications, nous vous recommandons d'utiliser Apache avec chiffrement SSL ou svnserve avec chiffrement SASL à la place ;

  • ne vous laissez pas séduire par l'idée très simple de donner l'accès à un dépôt à tous vos utilisateurs directement via des URL file://. Même si le dépôt est accessible à tous sur un lecteur réseau, c'est une mauvaise idée. Elle ôte toutes les couches de protection entre les utilisateurs et le dépôt : les utilisateurs peuvent corrompre accidentellement (ou intentionnellement) la base de données du dépôt, il est difficile de mettre le dépôt hors ligne pour inspection ou pour mise à niveau et vous risquez d'aboutir à de graves problèmes de droits sur les fichiers (voir la section intitulée « Accès au dépôt par plusieurs méthodes »). Remarquez que c'est aussi une des raisons pour laquelle nous déconseillons d'accéder aux dépôts via des URL svn+ssh:// : du point de vue de la sécurité, c'est en fait comme si les utilisateurs locaux y accédaient via file://, ce qui peut entraîner exactement les mêmes problèmes si l'administrateur ne fait pas preuve de prudence.

Précédent  Niveau supérieur  Suivant
Présentation générale  Sommaire  svnserve, un serveur sur mesure