Le hemos enseñado a acceder a un repositorio de muchas maneras diferentes. Pero, ¿es posible—o seguro—acceder a su repositorio mediante múltiples métodos simultáneamente? La respuesta es afirmativa, siempre y cuando planifique un poco las cosas.
En cualquier instante, estos procesos pueden requerir acceso de lectura y escritura a su repositorio:
usuarios normales del sistema (que se identifican
como ellos mismos) usando un cliente de Subversion
para acceder a los repositorios directamente vía URLs
file:///;
usuarios normales del sistema (que se identifican como ellos mismos) conectándose a procesos svnserve privados mediante sesiones SSH, los cuales acceden al repositorio;
un proceso svnserve—ya sea un demonio o uno invocado por inetd—ejecutándose como un usuario particular invariable;
un proceso httpd de Apache, ejecutándose como un usuario particular invariable.
El problema más común que se encuentran los administradores
es con la propiedad y permisos del repositorio. ¿Tiene cada
proceso (o usuario) en la lista anterior permisos para leer y
escribir los ficheros de la base de datos Berkeley? Asumiendo
que tiene un sistema operativo tipo Unix, una opción simple
sería colocar a cada usuario potencial del repositorio
en un nuevo grupo svn, y hacer que el
repositorio al completo esté poseído por este grupo. Pero
ni si quiera eso es suficiente, porque un proceso puede
escribir los ficheros de la base de datos usando una máscara
de permisos hostil—aquella que impida el acceso a
otros usuarios.
Así que el siguiente paso tras el establecimiento de
un grupo común para los usuarios del repositorio es forzar
a todos los procesos que acceden al repositorio a usar una
máscara de permisos aceptable. Para los usuarios que acceden
al repositorio directamente, puede envolver el programa
svn en un script cuyo primer paso sea
ejecutar umask 002 y después ejecute
el programa cliente svn auténtico.
Puede escribir un script de envoltorio similar para el
programa svnserve, y añadir el comando
umask 002 al propio fichero de arranque
de Apache, apachectl. Por ejemplo:
$ cat /usr/local/bin/svn #!/bin/sh umask 002 /usr/local/subversion/bin/svn "$@"
Hay otro problema común en sistemas tipo Unix.
A medida que se usa un repositorio, la base de datos Berkeley
ocasionalmente crea nuevos ficheros de registro para sus
transacciones. Incluso si el repositorio completo pertenece
al grupo svn, estos nuevos ficheros no
pertenecerán necesariamente al mismo grupo, lo cual crea
de nuevo problemas de permisos para sus usuarios. Un buen
método para corregir esto es activar el bit de grupo SUID
en el directorio db del repositorio.
Esto causa que todos los ficheros de registros creados tengan
el mismo grupo que el directorio padre..
Una vez haya saltado por estos aros, su repositorio debería ser accesible por todos los procesos necesarios. Puede que parezca un poco lioso y complicado, pero los problemas de tener múltiples usuarios compartiendo acceso de escritura a ficheros comunes son clásicos, pocas veces solucionados de manera elegante.
Afortunadamente, la mayoría de los administradores de
repositorios no tendrán nunca la necesidad
de tener configuraciones tan complejas.
Los usuarios que desean acceder a repositorios que residen
en la misma máquina no están limitados a usar el las URLs
de acceso file://—típicamente
pueden contactar con el servidor HTTP de Apache
o svnserve usando el nombre de
servidor localhost en sus URLs
http:// o svn://.
Y mantener múltiples procesos servidores para sus repositorios
de Subversion es probablemente un dolo de cabeza más que
algo necesario. ¡Le recomendamos que escoja el servidor que
se ajuste mejor a sus necesidades y que se limite a él!