SVNBOOK Chap6 Choosing a Server Configuration
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| SVF | Traduction | Fait | |
| Hotshot92 | 1ere Relecture | Fait | |
| Validation |
Sommaire |
Choosing a Server Configuration
Choosing a Server Configuration
Choisir une configuration serveur
So, which server should you use? Which is best?
Obviously, there's no right answer to that question. Every team has different needs, and the different servers all represent different sets of trade-offs. The Subversion project itself doesn't endorse one server or another, or consider either server more “official” than another.
Here are some reasons why you might choose one deployment over another, as well as reasons you might not choose one.
Et donc, 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 raisons qui vous aideront à choisir entre un déploiement et un autre ainsi que quelques raisons de ne pas choisir l'un d'entre eux.
The svnserve Server
The svnserve Server
Serveur svnserve
Why you might want to use it:
- Quick and easy to set up.
- Network protocol is stateful and noticeably faster than WebDAV.
- No need to create system accounts on server.
- Password is not passed over the network.
Why you might want to avoid it:
- By default, only one authentication method is available, the network protocol is not encrypted, and the server stores clear text passwords. (All these things can be changed by configuring SASL, but it's a bit more work to do.)
- No logging of any kind, not even errors.
- No built-in web browsing. (You'd have to install a separate web server and repository browsing software to add this.)
Pourquoi 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 ça requiert un peu plus de travail) ;
- aucune journalisation, de quelque sorte que ce soit, n'est disponible, ni même celle des erreurs ;
- pas de navigation web intégrée (il vous faudrait installer un serveur web séparé et un logiciel de navigation du dépôt pour ajouter cette fonctionnalité).
svnserve over SSH
svnserve over SSH
svnserve sur SSH
Why you might want to use it:
- The network protocol is stateful and noticeably faster than WebDAV.
- You can take advantage of existing SSH accounts and user infrastructure.
- All network traffic is encrypted.
Why you might want to avoid it:
- Only one choice of authentication method is available.
- There is no logging of any kind, not even errors.
- It requires users to be in the same system group, or use a shared SSH key.
- If used improperly, it can lead to file permission problems.
Pourquoi 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 ;
- aucune journalisation, de quelque sorte que ce soit, n'est disponible, ni même celle des erreurs ;
- il nécessite que les utilisateurs soient membres du même groupe système ou utilisent un clé SSH partagée ;
- mal utilisé, il peut aboutir à des problèmes de droits sur les fichiers.
The Apache HTTP Server
The Apache HTTP Server
Serveur HTTP Apache
Why you might want to use it:
- It allows Subversion to use any of the numerous authentication systems already integrated with Apache.
- There is no need to create system accounts on the server.
- Full Apache logging is available.
- Network traffic can be encrypted via SSL.
- HTTP(S) can usually go through corporate firewalls.
- Built-in repository browsing is available via web browser.
- The repository can be mounted as a network drive for transparent version control (see the section called “Autoversioning”).
Why you might want to avoid it:
- Noticeably slower than svnserve, because HTTP is a stateless protocol and requires more network turnarounds.
- Initial setup can be complex.
Pourquoi 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-feu d'entreprise ;
- la possibilité de parcourir le dépôt avec un navigateur web est disponible en natif ;
- le dépôt peut être monté en tant que lecteur réseau à des fins de gestion de versions transparente (voir le paragraphe intitulé "Auto-versionnement").
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.
Recommendations
Recommendations
Recommandations
In general, the authors of this book recommend a vanilla svnserve installation for small teams just trying to get started with a Subversion server; it's the simplest to set up and has the fewest maintenance issues. You can always switch to a more complex server deployment as your needs change.
Here are some general recommendations and tips, based on years of supporting users:
- If you're trying to set up the simplest possible server for your group, a vanilla svnserve installation is the easiest, fastest route. Note, however, that your repository data will be transmitted in the clear over the network. If your deployment is entirely within your company's LAN or VPN, this isn't an issue. If the repository is exposed to the wide-open Internet, you might want to make sure that either the repository's contents aren't sensitive (e.g., it contains only open source code), or that you go the extra mile in configuring SASL to encrypt network communications.
- If you need to integrate with existing legacy identity systems (LDAP, Active Directory, NTLM, X.509, etc.), you must use either the Apache-based server or svnserve configured with SASL. If you absolutely need server-side logs of either server errors or client activities, an Apache-based server is your only option.
- If you've decided to use either Apache or stock svnserve, create a single svn user on your system and run the server process as that user. Be sure to make the repository directory wholly owned by the svn user as well. From a security point of view, this keeps the repository data nicely siloed and protected by operating system filesystem permissions, changeable by only the Subversion server process itself.
- If you have an existing infrastructure that is heavily based on SSH accounts, and if your users already have system accounts on your server machine, it makes sense to deploy an svnserve-over-SSH solution. Otherwise, we don't widely recommend this option to the public. It's generally considered safer to have your users access the repository via (imaginary) accounts managed by svnserve or Apache, rather than by full-blown system accounts. If your deep desire for encrypted communication still draws you to this option, we recommend using Apache with SSL or svnserve with SASL encryption instead.
- Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful.
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 (c'est-à-dire qu'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. Si vous avez un besoin absolu de journaux des erreurs côté serveur ou de journaux des activités côté client, le serveur basé sur Apache est le seul choix possible ;
- 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 avez 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 un profond désir de chiffrement des communications vous attire vers cette option, 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 devient difficile de mettre le dépôt hors ligne pour inspection ou pour mise à niveau, et on risque d'aboutir à de graves problèmes de droits sur les fichiers (voir le paragraphe intitulé "Autoriser plusieurs méthodes d'accès au dépôt"). 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://, et peut entraîner exactement les mêmes problèmes si l'administrateur ne fait pas preuve de prudence.
