SVNBOOK Chap6 Supporting Multiple Repository Access Methods
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 |
Source : http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.multimethod
Supporting Multiple Repository Access Methods
Supporting Multiple Repository Access Methods
Autoriser plusieurs méthodes d'accès au dépôt
You've seen how a repository can be accessed in many different ways. But is it possible—or safe—for your repository to be accessed by multiple methods simultaneously? The answer is yes, provided you use a bit of foresight.
At any given time, these processes may require read and write access to your repository:
- Regular system users using a Subversion client (as themselves) to access the repository directly via file:// URLs
- Regular system users connecting to SSH-spawned private svnserve processes (running as themselves), which access the repository
- An svnserve process—either a daemon or one launched by inetd—running as a particular fixed user
- An Apache httpd process, running as a particular fixed user
The most common problem administrators run into is repository ownership and permissions. Does every process (or user) in the preceding list have the rights to read and write the repository's underlying data files? Assuming you have a Unix-like operating system, a straightforward approach might be to place every potential repository user into a new svn group, and make the repository wholly owned by that group. But even that's not enough, because a process may write to the database files using an unfriendly umask—one that prevents access by other users.
So the next step beyond setting up a common group for repository users is to force every repository-accessing process to use a sane umask. For users accessing the repository directly, you can make the svn program into a wrapper script that first runs umask 002 and then runs the real svn client program. You can write a similar wrapper script for the svnserve program, and add a umask 002 command to Apache's own startup script, apachectl. For example:
$ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/svn-real "$@"
Vous venez de voir différentes méthodes d'accès à un dépôt. Est-il possible - et sans danger - d'accéder simultanément à un dépôt par différentes méthodes ? La réponse est oui, à condition que vous soyez un petit peu prévoyant.
À un instant donné, les processus suivants peuvent avoir besoin de l'accès en lecture ou en écriture au dépôt :
- des utilisateurs classiques du système se connectant à l'aide d'un client Subversion à des URL file:// ;
- des utilisateurs classiques du système se connectant à des processus svnserve privés générés par SSH (dont le propriétaire est l'utilisateur lui-même), et accédant au dépôt ;
- un processus svnserve - soit un démon, soit un processus lancé par inetd - dont le propriétaire est un utilisateur dédié ;
- un processus httpd Apache, dont le propriétaire est un utilisateur dédié.
Les problèmes les plus courants rencontrés par les administrateurs sont des problèmes de droits et de propriété pour le dépôt. Chaque processus de la liste précédente a-t-il les droits de lecture et d'écriture sur les fichiers sous-jacents du dépôt ? En supposant que vous ayez un système d'exploitation de type Unix, une approche naïve de ce problème serait de placer chaque utilisateur potentiel du dépôt dans un groupe svn unique et de faire posséder le dépôt tout entier par ce groupe. Mais cela ne suffit même pas, car un processus risque de modifier les fichiers de la base de données en utilisant un umask inadapté qui va interdire l'accès aux autres utilisateurs.
L'étape suivante consiste donc, après avoir mis en place un groupe commun pour les utilisateurs du dépôt, à forcer tout processus qui accède au dépôt à utiliser un umask correct. Pour les utilisateurs qui accèdent directement au dépôt, vous pouvez "envelopper" le programme svnserve dans un script (wrapper en anglais) qui commencera par lancer la commande umask 002 et qui, seulement ensuite, appellera le véritable programme client. Vous pouvez également écrire un script similaire pour le programme svnserve et ajouter la commande umask 002 au script de démarrage d'Apache, apachectl. Par exemple :
$ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/le-vrai-svn "$@"
Another common problem is often encountered on Unix-like systems. If your repository is backed by Berkeley DB, for example, it occasionally creates new log files to journal its actions. Even if the Berkeley DB repository is wholly owned by the svn group, these newly created log files won't necessarily be owned by that same group, which then creates more permissions problems for your users. A good workaround is to set the group SUID bit on the repository's db directory. This causes all newly created log files to have the same group owner as the parent directory.
Once you've jumped through these hoops, your repository should be accessible by all the necessary processes. It may seem a bit messy and complicated, but the problems of having multiple users sharing write access to common files are classic ones that are not often elegantly solved.
Fortunately, most repository administrators will never need to have such a complex configuration. Users who wish to access repositories that live on the same machine are not limited to using file:// access URLs—they can typically contact the Apache HTTP server or svnserve using localhost for the server name in their http:// or svn:// URL. And maintaining multiple server processes for your Subversion repositories is likely to be more of a headache than necessary. We recommend that you choose a single server that best meets your needs and stick with it!
Un autre problème classique est souvent rencontré sur les systèmes de type Unix. Si vous avez un dépôt Berkeley DB, par exemple, il crée de temps en temps de nouveaux fichiers pour la journalisation. Même si le dépôt Berkeley DB est entièrement possédé par le groupe svn, ces nouveaux journaux ne seront pas nécessairement possédés par le même groupe, ce qui crée des problèmes de droits supplémentaires pour vos utilisateurs. Une bonne façon de contourner ce problème est d'activer le bit SUID du groupe sur le répertoire du dépôt, ce qui a pour résultat que tous les nouveaux fichiers journaux créés ont le même propriétaire que le répertoire parent.
Une fois ces manipulations effectuées, vos dépôts devraient être accessibles par tous les processus nécessaires. Tout ceci peut sembler un petit peu confus et compliqué, mais les problèmes d'accès en écriture par plusieurs utilisateurs à des fichiers partagés sont des problèmes très classiques, qui ne sont pas souvent résolus avec élégance.
Heureusement, la plupart des administrateurs n'auront jamais besoin d'une configuration aussi complexe. Les utilisateurs qui désirent accéder aux dépôts résidant sur une même machine ne sont pas limités aux URL d'accès file:// - ils peuvent généralement contacter le serveur http Apache ou le serveur svnserve en utilisant localhost comme nom de serveur dans leurs URL http:// ou svn://. Et assurer la maintenance de plusieurs processus serveurs pour vos dépôts Subversion vous créera plus de soucis qu'autre chose. Nous vous recommandons de choisir un seul serveur (celui qui correspond le mieux à vos besoins) et de vous y tenir !
POINT OF INTEREST: The svn+ssh:// Server Checklist
- The svn+ssh:// Server Checklist
- Serveur svn+ssh:// : les points à vérifier
- It can be quite tricky to get a bunch of users with existing SSH accounts to share a repository without permissions problems. If you're confused about all the things that you (as an administrator) need to do on a Unix-like system, here's a quick checklist that resummarizes some of the topics discussed in this section:
- All of your SSH users need to be able to read and write to the repository, so put all the SSH users into a single group.
- Make the repository wholly owned by that group.
- Set the group permissions to read/write.
- Your users need to use a sane umask when accessing the repository, so make sure svnserve (/usr/bin/svnserve, or wherever it lives in $PATH) is actually a wrapper script that runs umask 002 and executes the real svnserve binary.
- Take similar measures when using svnlook and svnadmin. Either run them with a sane umask or wrap them as just described.
- It can be quite tricky to get a bunch of users with existing SSH accounts to share a repository without permissions problems. If you're confused about all the things that you (as an administrator) need to do on a Unix-like system, here's a quick checklist that resummarizes some of the topics discussed in this section:
- Partager un dépôt entre des utilisateurs qui ont des comptes SSH sans avoir de problème de droits d'accès peut être assez épineux. Si l'ensemble des tâches à mener par l'administrateur d'un système de type Unix est encore un peu confus pour vous, voici la liste des choses à vérifier qui récapitule les points abordés dans ce paragraphe :
- Tous vos utilisateurs SSH doivent être capables de lire et d'écrire dans le dépôt, donc mettez tous les utilisateurs SSH dans un même groupe ;
- Faites de ce dépôt l'entière propriété de ce groupe ;
- Mettez les droits d'accès de ce groupe à lecture/écriture ;
- Vos utilisateurs doivent utiliser un umask correct quand ils accèdent au dépôt, donc assurez-vous que svnserve (/usr/bin/svnserve ou le chemin vers lequel $PATH pointe) est en fait un script qui exécute umask 002 avant de lancer le véritable exécutable svnserve ;
- Prenez des mesures similaires quand vous utilisez svnlook et svnadmin : soit vous les lancez avec un umask correct, soit vous les "enveloppez" dans un script comme nous venons de l'expliquer.
- Partager un dépôt entre des utilisateurs qui ont des comptes SSH sans avoir de problème de droits d'accès peut être assez épineux. Si l'ensemble des tâches à mener par l'administrateur d'un système de type Unix est encore un peu confus pour vous, voici la liste des choses à vérifier qui récapitule les points abordés dans ce paragraphe :
