Subversión para el control de Versiones (página 3)

@@ -1,4 +1,5 @@

Be kind to others

Freedom = Responsibility

Everything in moderation

-Chew with your mouth open

+Chew with your mouth closed

+Listen when others are speaking

$

Comparando copia de trabajo con repositorio

Si se pasa un único –revision (-r) número, entonces su copia de trabajo es comparada con la revisión especificada del repositorio.

$ svn diff –revision 3 rules.txt

Index: rules.txt

===================================================================

— rules.txt (revision 3)

+++ rules.txt (working copy)

@@ -1,4 +1,5 @@

Be kind to others

Freedom = Responsibility

Everything in moderation

-Chew with your mouth open

+Chew with your mouth closed

+Listen when others are speaking

$

Comparando repositorio con repositorio

Si dos números de revisión, separados por una coma, son pasados vía –revision (-r), entonces las dos revisiones son comparadas directamente.

$ svn diff –revision 2:3 rules.txt

Index: rules.txt

===================================================================

— rules.txt (revision 2)

+++ rules.txt (revision 3)

@@ -1,4 +1,4 @@

Be kind to others

-Freedom = Chocolate Ice Cream

+Freedom = Responsibility

Everything in moderation

Chew with your mouth closed

$

No solo puede usar svn diff para comparar ficheros en su copia de trabajo con el repositorio, sino que si suministra una URL como argumento, usted puede examinar las diferencias entre elementos en el repositorio incluso sin tener una copia de trabajo. Esto es especialmente útil si desea inspeccionar cambios en un fichero cuando no tiene una copia de trabajo en su máquina local:

$ svn diff –revision 4:5 http://svn.red-bean.com/repos/example/trunk/text/rules.txt

.

$

svn cat

Si desea examinar una versión anterior de un fichero y no necesariamente las diferencias entre dos ficheros, puede usar svn cat:

$ svn cat –revision 2 rules.txt

Be kind to others

Freedom = Chocolate Ice Cream

Everything in moderation

Chew with your mouth closed

$

También puede redireccionar la salida directamente a un fichero:

$ svn cat –revision 2 rules.txt > rules.txt.v2

$

Probablemente se esté preguntando por qué no usamos svn update –revision para actualizar el fichero a la revisión más antigua. Hay algunas razones por las que preferimos usar svn cat.

Primero, usted puede querer ver las diferencias entre dos revisiones de un fichero usando un programa diff externo (quizás uno gráfico, o quizás su fichero está en un formato que la salida de un diff unificado es absurdo). En este caso, necesitará coger una copia de la revisión antigua, redireccionarla a un fichero, y pasar este y el fichero de su copia de trabajo a su programa diff externo.

A veces es más fácil mirar una versión más antigua de un fichero en su totalidad en comparación con las diferencias entre esta y otra revisión.

svn list

El comando svn list le muestra qué ficheros están en un directorio de un repositorio sin realmente descargar los ficheros a su máquina local:

$ svn list http://svn.collab.net/repos/svn

README

branches/

clients/

tags/

trunk/

Si desea un listado más detallado, pase la opción –verbose (-v) para obtener una salida como esta.

$ svn list –verbose http://svn.collab.net/repos/svn

2755 harry 1331 Jul 28 02:07 README

2773 evelyn Jul 29 15:07 branches/

2769 evelyn Jul 29 12:07 clients/

2698 harry Jul 24 18:07 tags/

2785 evelyn Jul 29 19:07 trunk/

Las columnas le dicen la revisión en la cual el fichero o directorio fue modificado por última vez, el usuario qué lo modificó, el tamaño si este es un fichero, la fecha de la última modificación, y el nombre del objeto.

Una palabra final en el historial

Además de todos los comandos anteriores, usted puede usar svn update y svn checkout con la opción –revision para tomar una copia de trabajo entera "anterior en el tiempo":

$ svn checkout –revision 1729 # Checks out a new working copy at r1729

.

$ svn update –revision 1729 # Updates an existing working copy to r1729

.

Otros comandos útiles

Mientras que no son usados con tanta frecuencia como los comandos discutidos previamente en este capítulo, usted necesitará de vez en cuando estos comandos.

svn cleanup

Cuando Subversión modifica su copia de trabajo (o cualquier información en el interior de .svn), intenta hacerlo tan seguro como sea posible. Antes de cambiar cualquier cosa, escribe sus intenciones en un fichero de registro, ejecuta los comandos en el fichero de registro, entonces borra el fichero de registro (esto es similar en diseño a un sistema de ficheros transaccional). Si una operación de Subversión es interrumpida (si el proceso es matado, o si la máquina se cuelga, por ejemplo), los ficheros de registro permanecen en disco. Ejecutando de nuevo los ficheros de registro, Subversión puede completar la operación anteriormente empezada, y su copia de trabajo puede volver a estar en un estado consistente.

Y esto es exactamente lo que hace svn cleanup: busca en su copia de trabajo y ejecuta cualquier registro de sobra, eliminando bloqueos en el proceso. Si Subversión alguna vez le dice que alguna parte de su copia de trabajo está "bloqueada", entonces éste es el comando que debería ejecutar. También, svn status mostrará una L al lado de los objetos bloqueados:

$ svn status

L somedir

M somedir/foo.c

$ svn cleanup

$ svn status

M somedir/foo.c

svn import

El comando svn import es una manera rápida de copiar un árbol de ficheros sin versionar en el repositorio, creando directorios intermedios como sea necesario.

$ svnadmin create /usr/local/svn/newrepos

$ svn import mytree file:///usr/local/svn/newrepos/some/project

Adding mytree/foo.c

Adding mytree/bar.c

Adding mytree/subdir

Adding mytree/subdir/quux.h

Committed revision 1.

El ejemplo anterior copia el contenido del directorio mytree debajo del directorio some/project en el repositorio:

$ svn ls file:///usr/local/svn/newrepos/some/project

bar.c

foo.c

subdir/

Observe que después de que la importación esté acabada, el árbol original no se convierte en una copia de trabajo. Para empezar a trabajar, usted todavía necesita hacer svn checkout en una copia de trabajo fresca del árbol.

Instalación

Subversión está construido sobre una capa de portabilidad llamada APR (la biblioteca Apache Portable Runtime), lo cual significa que Subversión debería funcionar en cualquier sistema operativo donde lo haga el servidor httpd Apache: Windows, Linux, todos los sabores de BSD, Mac OS X, Netware y otros.

La manera más sencilla de obtener Subversión es descargando un paquete binario construido para su sistema operativo.

Alternativamente, usted puede compilar Subversión directamente a partir del código fuente.

Debian

Las versiones hasta la 1.0.5 (incluida) presentan una vulnerabilidad en el módulo mod_authz_svn. En la versión 1.0.5-1 ya esta solucionado.

La instalación unstable y testing requiere libc6.1 (2.3.2.ds1-11),
una biblioteca usada por multitud de programas del sistema. Dependiendo de lo
actualizado que este su sistema, podría requerir una actualización
masiva.

En cualquier caso, la instalación es la misma:

debian:/mnt# wajig install subversion

Reading Package Lists… Done

Building Dependency Tree… Done

The following extra packages will be installed:

db4.2-util libapr0 libneon24 libsvn0 libswig1.3.21

Suggested packages:

subversion-tools

The following NEW packages will be installed:

db4.2-util libapr0 libneon24 libsvn0 libswig1.3.21 subversion

0 upgraded, 6 newly installed, 0 to remove and 233 not upgraded.

Need to get 1304kB of archives.

After unpacking 3711kB of additional disk space will be used.

Do you want to continue? [Y/n]

Get:1 http://ftp.us.debian.org unstable/main db4.2-util 4.2.52-16 [60,6kB]

Get:2 http://ftp.us.debian.org unstable/main libapr0 2.0.50-5 [124kB]

Get:3 http://ftp.us.debian.org unstable/main libneon24 0.24.6.dfsg-1 [80,4kB]

Get:4 http://ftp.us.debian.org unstable/main libswig1.3.21 1.3.21-5 [160kB]

wajig es un frontend simplificado para varios comandos apt-* y dpkg. Prueba apt-get install wajig y wajig help. O si no, use apt-get install.

Opcionalmente podemos instalar subversion-tools, unos scripts que facilitan la administración del repositorio:

debian:/# wajig install subversion-tools

Reading Package Lists… Done

Building Dependency Tree… Done

The following extra packages will be installed:

libconfig-inifiles-perl python2.3-subversion rcs

The following NEW packages will be installed:

libconfig-inifiles-perl python2.3-subversion rcs subversion-tools

0 upgraded, 4 newly installed, 0 to remove and 233 not upgraded.

Need to get 1095kB of archives.

After unpacking 3346kB of additional disk space will be used.

Windows

Básicamente hay dos versiones:

• "Windows installer with the basic Subversion Win32 binaries". Versión autoinstalable.

• svn-win32-x.x.x.zip. Para instalarla es necesario añadir el directorio bin al PATH, y establecer esta variable de entorno: APR_ICONV_PATH=D:programasSubversioniconv.

Si usa Windows XP necesitas el Service Pack 1.

Tras instalar debe poder abrir una consola y operar con Subversion en local:

D:>svn

Type 'svn help' for usage.

Crear un repositorio

Para crear un repositorio vacío usamos la herramienta de administración svnadmin:

• Debian:

mkdir -p /var/local/repos

svnadmin create /var/local/repos

# doy permisos al servidor web

chown -R www-data:www-data /var/local/repos

• Windows:

# en Windows quiero crearlo en d:repositorio, así que me pongo en d: y ejecuto:

svnadmin create repositorio

El repositorio tiene este aspecto en el sistema de ficheros de Debian:

debian:/# ls -la /var/local/repos

total 36

drwxr-sr-x 7 www-data www-data 4096 2004-07-27 20:00 .

drwxrwsr-x 3 root staff 4096 2004-07-27 20:00 ..

drwxr-sr-t 2 www-data www-data 4096 2004-07-27 20:00 conf

drwxr-sr-t 2 www-data www-data 4096 2004-07-27 20:00 dav

drwxr-sr-t 2 www-data www-data 4096 2004-07-27 20:00 db

-r–r–r– 1 www-data www-data 2 2004-07-27 20:00 format

drwxr-sr-t 2 www-data www-data 4096 2004-07-27 20:00 hooks

drwxr-sr-t 2 www-data www-data 4096 2004-07-27 20:00 locks

-rw-r–r– 1 www-data www-data 376 2004-07-27 20:00 README.txt

Lo que vemos son ficheros y directorios de una instancia de la base de datos Berkeley. Esta es una novedad frente al CVS: los proyectos no se guardan en el sistema de ficheros, sino en una base de datos. Esto asegura que cualquier transacción que realicemos.

Acceso remoto con Apache

Apache es un servidor web que podemos configurar para acceder al repositorio usando el protocolo HTTP. El acceso remoto con Apache ofrece mayor flexibilidad que svnserve, porque podemos usar todos los módulos y scripts para Apache, como por ejemplo ViewCVS.

debian:/# wajig install apache2-mpm-prefork

Reading Package Lists… Done

Building Dependency Tree… Done

The following extra packages will be installed:

apache2-common

Suggested packages:

apache2-doc

The following NEW packages will be installed:

apache2-common apache2-mpm-prefork

0 upgraded, 2 newly installed, 0 to remove and 233 not upgraded.

Need to get 1062kB of archives.

After unpacking 3830kB of additional disk space will be used.

Do you want to continue? [Y/n]

Para que apache transforme las operaciones HTTP de los clientes de Subversion, en operaciones sobre el repositorio, es necesario instalar el módulo libapache2-svn:

debian:/# wajig install libapache2-svn

Reading Package Lists… Done

Building Dependency Tree… Done

The following NEW packages will be installed:

libapache2-svn

0 upgraded, 1 newly installed, 0 to remove and 233 not upgraded.

Need to get 57.0kB of archives.

After unpacking 229kB of additional disk space will be used.

Windows

Para acceder al repositorio usando un cliente HTTP (por ejemplo
el plugin subclipse de Eclipse), necesitaremos instalar Apache2.0.48 (no valen
el 1.x ni el 2.0.46). La instalación es trivial, descarga y ejecuta apache_2.0.48-win32-x86-no_ssl.msi.
Siempre se instala en un directorio Apache2, por tanto, si lo quieres en d:httpdApache2,
indica c:httpd como directorio de instalación. Por defecto se añadirá
como servicio y al iniciar Windows veremos aparecer un monitor de Apache

Configurar Apache

Para configurar el módulo mod_dav_svn, edita /etc/apache2/mods-available/dav_svn.conf. Comenta estas líneas:

#

#

y añade estas otras:

DAV svn

SVNPath /var/local/repos

La directiva Location de Apache asocia el bloque que contiene
a una URL determinada. Aqui por ejemplo, la configuración del módulo
dav_svn queda asociado a la dirección http://localhost/repos. Perfectamente
podríamos haber usado Location /cualquier/otra/ruta, y dejar el repositorio
accesible en http://localhost/cualquier/otra/ruta.

Si acabas de instalar Apache, probablemente ya este en ejecución (prueba ps -A | grep apache2). Reinícialo para que lea los cambios:

debian:/# /etc/init.d/apache2 restart

Restarting web server: Apache2.

Vemos el repositorio:

Revision 0: /

Powered by Subversion version 1.0.5 (r9954).

Windows

Primero copiamos el fichero mod_dav_svn.so de la instalación de Subversion (C:Program FilesSubversionhttpdmod_dav_svn.so) al directorio modules de la instalación de apache (C:Program FilesApache2modules).

En el fichero httpd.conf de la instalación de Apache busca la siguiente línea:

#LoadModule dav_module modules/mod_dav.so

y cambiala por esto:

LoadModule dav_module modules/mod_dav.so

LoadModule dav_svn_module modules/mod_dav_svn.so

Suponiendo que nuestro repositorio este en d:repositorio ponemos esto al final de httpd.conf:

DAV svn

SVNPath d:/repositorio

# observa que hemos usado d:/ y no d:

La directiva Location de Apache asocia el bloque que contiene
a una URL determinada. Aqui por ejemplo, la configuración del módulo
dav_svn queda asociado a la dirección http://localhost/repos. Perfectamente
podríamos haber usado Location /cualquier/otra/ruta, y dejar el repositorio
accesible en http://localhost/cualquier/otra/ruta.

Reiniciamos apache usando el monitor. Si el monitor indica que la operación ha fallado, conviene abrir una consola en el directorio bin de la instalación de Apache (en mi ordenador es C:Program FilesApachebin) y ejecutar lo siguiente:

D:programasApache2bin>apache -e debug

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module access_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module actions_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module alias_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module asis_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module auth_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module autoindex_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module cgi_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module dav_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module dav_svn_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module dir_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module env_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module imap_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module include_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module isapi_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module log_config_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module mime_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module negotiation_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module setenvif_module

[Wed Mar 03 22:22:54 2004] [debug] mod_so.c(290): loaded module userdir_module

Vemos que entre otros ha cargado el módulo dav_svn_module. En este punto la consola se queda bloqueada, Apache espera peticiones.

Restringir el acceso

Aquí se explica como configurar Apache para restringir el acceso usando autentificación básica (basic authentication) o SSL.

La autentificación básica no es segura porque envía los passwords a través de la red codificados en base64 (un algoritmo que proporciona muy poca protección). Estos passwords pueden capturarse con un sniffer y desencriptarse con paciencia. Por tanto:

• Si el servidor esta expuesto a Internet, convendrá usar SSL para operaciones de escritura y asegurar Apache contra ataques.

• Si lo vamos a usar en un entorno seguro (una intranet) y solo nos interesa identificar a los usuarios que realizan cada cambio en el repositorio, basta la autentificación básica.

Debian

Volvemos a editar la configuración del módulo (/etc/apache2/mods-available/dav_svn.conf):

DAV svn

SVNPath /var/local/repos

AuthType Basic

AuthName "Subversion repository"

# fichero de passwords

AuthUserFile /etc/subversion/passwd

# permito las opciones GET PROPFIND OPTIONS REPORT a usuarios anonimos

# pero requiero autentificación para el resto de operaciones (las de escritura)

Require valid-user

Luego crea un usuario, por ejemplo 'evelyn':

debian:/# htpasswd2 -c /etc/subversion/passwd evelyn

New password:

Re-type new password:

Adding password for user evelyn

Y reinicia:

debian:/# /etc/init.d/apache2 restart

Restarting web server: Apache2.

Windows con Autentificación básica

El procedimiento es casi el mismo que veíamos con Debian. Creamos el fichero de passwords:

D:programasApache2bin>htpasswd.exe -nb evelyn secreto > usuarios.txt

Automatically using MD5 format.

Añadimos la configuración necesaria a httpd.conf:

DAV svn

SVNPath d:/repositorio

# Autentificación básica.

AuthType Basic

AuthName "Repositorio Subversion"

AuthUserFile D:/programas/Apache2/bin/usuarios.txt

# Solo permitimos usuarios identificados en el fichero de passwords.

#require valid-user

# Solo permitimos usuarios identificados en el fichero de
passwords

# con nombre 'evelyn' o 'daniel'.

#require user evelyn daniel

# La lectura es libre pero solo permitimos usuarios identificados

# en el fichero de passwords para otras operaciones.

Require valid-user

Y reiniciamos:

net restart apache

Acceso remoto con svnserve

svnserve es un servidor incluido en Subversion cuya función es acceder al repositorio usando un protocolo TCP/IP propio. Las URLs son similares a las que usamos en Apache, pero comienzan por svn:// o svn+ssh://. svnserve consume menos recursos que Apache, pero es menos potente.

Instalar svnserve

Si ya has instalado Subversion, ya tienes el programa svnserve. El propio comando nos muestra las opciones de arranque:

$ svnserve –help

Usage: svnserve [options]

Valid options:

-d [–daemon] : daemon mode

–listen-port arg : listen port (for daemon mode)

–listen-host arg : listen hostname or IP address (for daemon mode)

–foreground : run in foreground (useful for debugging)

-h [–help] : display this help

-i [–inetd] : inetd mode

-r [–root] arg : root of directory to serve

-R [–read-only] : deprecated; use repository config file

-t [–tunnel] : tunnel mode

-X [–listen-once] : listen once (useful for debugging)

Windows

No es aconsejable usar svnserve en Windows porque necesita
fork para gestionar el acceso concurrente, pero Windows no lo implementa. En
Windows podemos usar este wrapper para instalarlo como servicio.

Si tenemos CygWin instalado, instalamos xinetd en la sección Net y hacemos:

/usr/sbin/inetd –install-as-service

net start inetd

También podemos arrancar inetd desde consola manualmente en depuración con:

/usr/sbin/inetd –d

Para SSH también necesitaremos OpenSSH y OpenSSL. Instalalos y comprueba que estan ahi:

$ ssh -version

OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004

Bad escape character 'rsion'.

Linux

Por defecto, el servidor escucha en el puerto 3690 reservado
por la IANA para el protocolo svn.

En modo independiente la consola queda bloqueada:

$ svnservce –d

Para lanzarlo con inetd:

$ svnserve -i

( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )

y añadimos esto a /etc/inetd.conf:

svn stream tcp nowait svnowner /path/to/subversion/bin/svnserve –i

Importar un proyecto

Ya tenemos el repositorio funcionando en red. Para iniciar un proyecto simplemente creamos un subdirectorio donde iremos añadiendo ficheros. Durante el resto del documento usare un miniproyecto casero llamado "awpool".

# Creo un proyecto llamado "awpool" en el repositorio

svn mkdir http://127.0.0.1:80/repos/awpool -m "Creo el proyecto"

Si ya tienes un proyecto y quieres importarlo necesitareis una copia libre de directorios CVS/ (si es que usábamos CVS). Lo más sencillo es eliminar los directorios e importar en el CVS.

Si vais a conservar el repositorio CVS convendrá etiquetar la versión a partir de la cual has migrado a Subversion. Por ejemplo, vamos a etiquetarlo como "release1":

# Suponiendo que aun no tengo en mi disco el CVS, lo hago ahora

mkdir /home/evelyn/tmp

cd /home/evelyn/tmp

cvs co awpool

# y lo etiqueto como 'release1'

cvs tag release1

En mi caso no quería perder mi copia local del CVS, así que me baje esa release exacta exportando. En CVS exportar significa bajarte el código sin control de versiones, o sea, sin los directorios CVS/:

mkdir /home/evelyn/release1

cvs export -r release1 awpool

De un modo u otro, deberíamos acabar con el código listo para ser importado.

# Creo un directorio para la versión principal del proyecto.

# A veces se hacen versiones (branches) de un proyecto, y lo principal se pone

# en un directorio que por convención se llama trunk.

svn mkdir http://127.0.0.1:80/repos/awpool/trunk -m "version principal"

# importo el código que copie (o exporte) antes en /home/evelyn/release1,

# o sea, el directorio con el código a importar, y lo meto en trunk

cd /home/evelyn/release1

svn import . http://127.0.0.1:80/repos/awpool/trunk -m "importacion inicial"

# en Windows me coloque dentro del directorio con el proyecto a importar y teclee

# svn import . http://127.0.0.1:80/repos/awpool/trunk -m "importacion inicial"

La operación anterior tarda un rato, veremos desfilar todos los ficheros que están importándose. Si olvidaste eliminar la versión compilada de tú programa también se añadirá y tendrás que borrarla luego. Cuando termina, puedes conectarte por web para ver el resultado, o hacer checkout (descargarlo) desde otro directorio:

mkdir /home/evelyn/awpool

cd /home/evelyn/awpool

svn checkout http://127.0.0.1:80/repos/awpool/trunk .

La copia local generada tiene un subdirectorio .svn junto a cada directorio. Es el equivalente a los antiguos CVS/, pero su contenido tiene un formato distinto.

Guardar la versión principal en un subdirectorio trunk no es obligatorio, pero ese y otros, son los elementos acostumbrados en un repositorio:

• trunk/ Por convención suele usarse para el código principal del proyecto.

• branches/ Ramas del desarrollo. Copias del código principal con cambios experimentales.

• tags/ Versiones del código listas para empaquetar como entregables.

Configuración

Un repositorio Subversion puede ser accedido simultáneamente por clientes que son ejecutados en la misma máquina en la que reside el repositorio usando el método file:///. Pero una típica configuración de Subversion implica a un servidor al que acceden clientes desde sus computadoras en el entorno de una oficina— o quizás, alrededor del mundo.

Esta sección describe como publicar su repositorio Subversion para ser accedido por clientes remotos. Cubriremos los tipos de mecanismos de servidor disponibles actualmente , debatiendo la configuración y uso de cada uno de éstos. Después de que haya leído está sección, usted debería estar capacitado para decidir que tipo de configuración de red es la apropiada para sus necesidades, y comprender como realizar la instalación en su computadora.

Subversion cuenta con un diseño de la capa de red abstracto. Esto significa que el repositorio puede ser accedido por cualquier clase de proceso de servidor y el API de "acceso al repositorio" cliente permite a los programadores escribir componentes que se comuniquen a través de su protocolo de red pertinente. En teoría, Subversion puede lucir una infinidad de implementaciones de red. En la práctica, sólo existen dos tipos de servidores.

Apache es un servidor web extremadamente popular; utilizando el módulo mod_dav_svn, Apache puede acceder a un repositorio y hacerlo disponible a los clientes a través del protocolo WebDAV/DeltaV, el cuál es una extensión del HTTP. En la otra esquina se encuentra svnserve: un pequeño programa servidor independiente que se comunica a través de un protocolo personalizado con los clientes. La tabla presenta una comparación de ambos tipos de servidores.

Observe que Subversion, siendo un proyecto de código abierto, no apoya oficialmente a ningún servidor como opción "primaria" u "oficial". Ninguna de las implementaciones de red es considerada como un ciudadano de segunda clase; cada servidor posee ventajas y desventajas distintivas. De hecho, es posible ejecutar los diferentes servidores en paralelo, cada uno accediendo a sus repositorios a su modo y sin obstaculizar al otro. A continuación una breve visión general y comparación de los servidores Subversion disponibles.

Comparación de tipos de servidores de red

Modelo de red

Solicitudes y Respuestas

El cliente Subversion insume la mayor parte de su tiempo manejando copias de trabajo. No obstante, cuando necesita información del repositorio efectúa una solicitud a través de la red, y el servidor responde apropiadamente. Los detalles del protocolo de red son ocultados por el usuario; el cliente intenta acceder a una URL, y dependiendo del esquema URL, utiliza un protocolo particular para contactar al servidor. Los usuarios pueden ejecutar svn –version para ver que esquemas URL y protocolos que comprende el cliente.

Cuando el proceso del servidor recibe una solicitud del cliente, típicamente demanda que el cliente se identifique. Este solicita la autenticación al cliente , y el cliente responde proporcionando las credenciales al servidor. Una vez completado ésto, el servidor responde con la información que el cliente solicitó originalmente. Observe que este método se diferencia de sistemas como CVS, dónde el cliente por cuenta propia ofrece las credenciales ("de acceso al sistema"), antes de realizar una solicitud. En Subversion, el servidor "exige tomar" las credenciales a través de la negociación con el cliente en el momento apropiado, en lugar de que el cliente las "impulse". Esto asegura operaciones más elegantes. Por ejemplo, si se configura un servidor para que permita acceso de lectura al repositorio a todo el mundo, nunca demandará a un cliente que se autentique cuando intente realizar un svn checkout.

Si la solicitud de red del cliente escribe datos nuevos en el repositorio (por ejemplo: svn commit), un nuevo árbol de revisión es creado. Si la solicitud del cliente fue autenticada, el nombre del usuario es guardado como valor de la propiedad svn:author en la nueva revisión. Si el cliente no fue autenticado (en otras palabras, si el servidor nunca promulgó la autenticación), la propiedad svn:author de la revisión está en blanco.

Client Credentials Caching

Muchos servidores son configurados para requerir autenticación por cada solicitud que reciban. Esto puede convertirse en una gran molestia para los usuarios, quienes son forzados a escribir sus contraseñas una y otra vez.

Afortunadamente, el cliente Subversion ha remediado ésto: un sistema incorporado para ocultar las credenciales en el disco. Por defecto, en el momento en que el cliente se autentica satisfactoriamente con un servidor, éste guarda las credenciales en el área de configuración de ejecución privada del usuario— en ~/.subversion/auth/ en los sistemas tipo Unix o %APPDATA%/Subversion/auth/ en Windows. Con éxito las credenciales son ocultadas en el disco, encerradas en una combinación de hostname, puerto y realm de autenticación.

Cuando el cliente recibe la solicitud para que se autentique, primero busca las credenciales apropiadas en el caché de disco; sino existen, o si las credenciales fallan en la autenticación, el cliente simplemente pregunta al usuario por la información.

Las personas que sufren de paranoia sobre asuntos de seguridad pueden estar pensando, "Contraseñas ocultas en el disco?. Primero, el área de caché auth/ se encuentra protegida por permisos a fin de que sólo el usuario (dueño) puede leer la información que se encuentra en ella, evitando que otros puedan acceder. Si eso no es lo suficientemente seguro para usted, puede deshabilitar el caché de credenciales. Para lograrlo, sólo basta con un único comando, pasando la opción –no-auth-cache:

$ svn commit -F log_msg.txt –no-auth-cache

Authentication realm: example realm

Username: joe

Password for 'joe':

Adding newfile

Transmitting file data .

Committed revision 2324.

# password was not cached, so a second commit still prompts us

$ svn rm newfile

$ svn commit -F new_msg.txt

Authentication realm: example realm

Username: joe

[…]

O, si usted desea deshabilitar el caché de credenciales en forma permanente, puede editar su archivo de configuración config (ubicado dentro del directorio auth/). Simplemente coloque no a store-auth-creds, y las credenciales no serán guardadas en el caché nunca más.

[auth]

store-auth-creds = no

Algunas veces los usuario desearán eliminar credenciales específicas del caché de disco. Para hacer ésto, necesitará navegar dentro del área auth/ y eliminar el archivo de caché apropiado en forma manual. Las credenciales son almacenadas en el área de caché en archivos individuales; si usted mira dentro de cada archivo, verá claves y valores. La clave svn:realmstreng describe el "realm" servidor particular con el que que el archivo es asociado:

$ ls ~/.subversion/auth/svn.simple/

5671adf2865e267db74f09ba6f872c28

3893ed123b39500bca8a0b382839198e

5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8

username

V 3

joe

K 8

password

V 4

blah

K 15

svn:realmstring

V 45

Joe's repository

END

Una vez que haya localizado el archivo de caché apropiado, sencillamente elimínelo.

Una última palabra acerca del comportamiento de autenticación del cliente: es necesaria una pequeña explicación respecto de las opciones –username y –pasword. Muchos sub-comandos del cliente aceptan estas opciones; sin embargo, es importante comprender que la utilización de las mismas no envía automáticamente las credenciales al servidor. Como se dijo anteriormente, el servidor "exige tomar" las credenciales del cliente cuando lo considera necesario; el cliente no puede "impulsarlas" a voluntad. Si un usuario y/o contraseña son pasados como opción, ellos serán presentados al servidor sólo si este así lo demanda. Típicamente, estas opciones son utilizadas cuando:

• el usuario desea autenticarse con un nombre diferente a su usuario de sistema, o

• un guión desea autenticarse sin utilizar las credenciales del caché.

Aquí hay un resumen final que describe como se comporta un cliente Subversion cuando recibe la demanda de autenticación:

• 1. Verifica si el usuario ha especificado algunas credenciales como opción de línea de comando, a través de la opción –username y/o –pasword. Sino, o si esas opciones no pertenecen a una autenticación válida, entonces

• 2. Busca en el "realm" del servidor en el área de ejecución auth/, para ver si el usuario ya dispone de credenciales apropiadas en el caché. Sino, o si las credenciales del caché fallan en la autenticación, entonces

• 3. Recurre a preguntarle al usuario.

Si el cliente se autentica correctamente a través de alguno de los métodos listados aquí arriba, éste intentará guardar en las credenciales en el caché de disco (a no ser que el usuario haya deshabilitado ese funcionamiento, como hemos mencionado anteriormente.)

svnserve, un servidor personalizado

El programa svnserve es un servidor ligero, capaz de hablar a clientes sobre TCP/IP utilizando un protocolo con estado personalizado. Los clientes contactan un servidor svnserve utilizando URLs que comienzan con el esquema svn:// o svn+ssh://.

Invocando el Servidor

Existen unas cuantas maneras diferentes de invocar el programa svnserve. Si se lo invoca sin argumentos, usted no verá nada más que un mensaje de ayuda. No obstante, si planea que inetd dispare el proceso, puede pasar la opción -i (–inetd):

$ svnserve -i

( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )

Cuando es invocado con la opción –inetd, svnserve intenta comunicarse con un cliente Subversion a través de stdin y stdout utilizando un protocolo personalizado. Este es un comportamiento estándar de los programas que son ejecutados a través de inetd. El IANA ha reservado el puerto 3690 para el protocolo Subversion, por lo tanto en un sistema tipo Unix usted puede agregar líneas a /etc/services como éstas (si es que no existen todavía):

svn 3690/tcp # Subversion

svn 3690/udp # Subversion

Y si su sistema utiliza un demonio inetd tipo Unix clásico, puede agregar esta línea a /etc/inetd.conf:

svn stream tcp nowait svnowner /usr/local/bin/svnserve svnserve -i

Asegúrese que "svnowner" es un usuario que posee permisos apropiados para acceder a su repositorio. Ahora, cuando una conexión cliente ingrese a su servidor en el puerto 3690, inetd disparará un proceso svnserve para servirlo.

Una segunda opción es ejecutar svnserve un proceso "demonio" independiente. Para esto, utilice la opción -d:

$ svnserve -d

$ # svnserve is now running, listening on port 3690

Cuando svnserve ejecute en modo demonio, usted puede utilizar las opciones –listen-port= y –listen-host= para personalizar el puerto y nombre exacto en el cual "escuchará".

Aún queda una tercera forma de invocar a svnserve, y esa es en "modo túnel", con la opción -t. Este modo supone que un programa de servicio remoto tal como RSH o SSH ha autenticado un cliente exitosamente y ahora está invocando un proceso privado svnserve como tal usuario. El programa svnserve se comporta normalmente (comunicándose a través de stdin y stdout), y asume que el tráfico está siendo redirigido automáticamente a través de algún tipo de túnel de vuelta al cliente. Cuando svnserve es invocado por un agente túnel como éste, está seguro que el usuario autenticado posee acceso total de lectura y escritura a los archivos de la base de datos del repositorio. Esencialmente es lo mismo que un usuario local accediendo al repositorio a través de las URLs file:///.

Una vez el programa svnserve se esté ejecutando, hace que cada repositorio en su sistema se encuentre disponibles a la red. Un cliente necesita especificar una ruta absoluta en la URL del repositorio. Por ejemplo, si un repositorio se encuentra ubicado en /usr/local/repositories/project1, el cliente accederá a través de svn://host.example.com/usr/local/repositories/project1 . Para incrementar la seguridad, usted puede pasar la opción -r a svnserve, que limita a exportar sólo los repositorios debajo de esa ruta:

$ svnserve -d -r /usr/local/repositories

.

En efecto, utilizando la opción -r modifica la ubicación que el programa tratará como raíz del espacio de sistema de archivos remoto. En consecuencia, los clientes utilizarán URLs que tengan la porción que le ha sido removida de la ruta, dejando URLs mucho más cortas (y mucho menos reveladoras):

$ svn checkout svn://host.example.com/project1

.

Autenticación y autorización integradas

Cuando un cliente se conecta a un proceso svnserve, las siguientes cosas suceden:

• El cliente selecciona un repositorio específico.

• El servidor procesa el archivo conf/svnserve.conf del repositorio, y comienza a poner en ejecución cualquier política de autenticación y autorización definida en éste.

• Dependiendo de la situación y las políticas de autorización,

• se le puede permitir al cliente realizar pedidos de forma anónima, y sin haber recibido la demanda de autenticación, O

• el cliente puede ser consultado por la autenticación en cualquier momento, O

• si opera en el "modo túnel", el cliente se anuncia a sí mismo que ya ha sido autenticado externamente.

En el momento de escribir estas líneas, el servidor sólo sabe cómo realizar la autenticación por CRAM-MD5. En esencia, el servidor envía unos pocos datos al cliente. El cliente usa el algoritmo hash MD5 para crear una huella digital de los datos y la palabra clave combinados, y envía la huella digital como respuesta. El servidor realiza el mismo cálculo con la palabra clave almacenada para verificar que el resultado es idéntico. En ningún momento el password real viaja a través de la red.

También es posible, por supuesto, que el cliente se autentifique externamente vía agente de túnel , como por ejemplo SSH. En este caso, el servidor simplemente examina el usuario bajo el cual se está ejecutando, y lo usa durante la autenticación.

Tal y como habrá imaginado, el fichero svnserve.conf es el mecanismo central de un repositorio para controlar las políticas de autenticación y autorización. El fichero sigue el mismo formato que otros ficheros de configuración, los nombres de sección están enmarcados por corchetes ([ y ]), los comentarios comienzan con almohadillas (#), y cada sección contiene variables específicas que pueden ser modificadas (variable = valor). Démonos un paseo por este fichero para aprender a usarlas.

Crear un fichero 'users' y realm

Por ahora, la sección [general] de svnserve.conf tiene todas las variables que usted necesita. Comencemos definiendo un fichero que contenga nombres de usuario y palabras clave, y una realm de autenticación:

[general]

password-db = userfile

realm = example realm

El nombre realm es algo que define usted. Le dice a los clientes a qué tipo de "espacio de nombres de autenticación" se están conectando; el cliente de Subversion lo muestra durante las preguntas de autenticación, y lo usa como palabra clave (junto con el nombre y puerto del servidor) para cachear las credenciales en disco. La variable password-db apunta a un fichero separado que contiene una lista de nombres de usuario y claves, usando el mismo formato familiar. Por ejemplo:

[users]

harry = foopassword

evelyn = barpassword

El valor de password-db puede ser una ruta absoluta o relativa al fichero de usuarios. Para muchos administradores, es sencillo guardar el fichero justo en el área conf/ del repositorio, junto a svnserve.conf. Por otra parte, es posible querer compartir el mismo fichero de usuarios entre dos o más repositorios; en este caso, el fichero probablemente debería ubicarse en un lugar más público. Los repositorios que compartan el fichero de usuarios también deberían estar configurados para usar la misma realm, dado que la lista de usuarios define esencialmente un realm de autenticación. Esté donde esté el fichero, asegúrese de ajustar apropiadamente los permisos de lectura y escritura. Si sabe bajo qué usuario(s) se ejecutará svnserve, restrinja el acceso de lectura al fichero correspondientemente.

Activar control de acceso

Hay dos variables más en el fichero svnserve.conf: determinan qué pueden hacer los usuarios autenticados y sin autenticar (anónimos). Las variables anon-access y auth-access pueden tener los valores none, read, o write. Poner el valor a none restringe el acceso de todo tipo; read permite únicamente el acceso de sólo lectura al repositorio, y write permite acceso completo de lectura y escritura. Por ejemplo:

[general]

password-db = userfile

realm = example realm

# anonymous users can only read the repository

anon-access = read

# authenticated users can both read and write

auth-access = write

Los parámetros del ejemplo, son de hecho los valores por defecto de las variables, en caso de que olvide definirlas. Si desea ser aun más conservativo, puede bloquear el acceso anónimo completamente:

[general]

password-db = userfile

realm = example realm

# anonymous users aren't allowed

anon-access = none

# authenticated users can both read and write

auth-access = write

Fíjese que svnserve sólo entiende de control de acceso "básico". Un usuario tiene acceso universal de lectura escritura, acceso universal de lectura, o ningún tipo de acceso. No hay control detallado del acceso a rutas específicas dentro del repositorio. Para muchos proyectos y equipos, este nivel de control de acceso es más que suficiente. No obstante, si necesita control de acceso por directorio, tendrá que usar Apache en lugar de svnserve como su proceso servidor.

Autenticación y autorización SSH

La autenticación de serie de svnserve puede ser muy útil, porque evita tener que crear cuentas de sistema reales. Por otro lado, algunos administradores ya tienen entornos de autenticación SSH bien establecidos y funcionando. En estas situaciones, todos los usuarios del proyecto tienen cuentas en el sistema y la habilidad para conectarse con SSH a la máquina servidora.

Es fácil usar SSH junto con svnserve. El cliente simplemente usa el esquema de URL svn+ssh:// para conectar:

$ whoami

harry

$ svn list svn+ssh://host.example.com/repos/project

harry[arroba]host.example.com's password: *****

foo

bar

baz

.

Lo que sucede en esta situación es que el cliente de Subversion invoca el proceso local ssh, conectándolo con host.example.com, autenticándose como el usuario juan, y entonces lanzando un proceso svnserve privado en la máquina remota, que se ejecuta como el usuario juan. El comando svnserve se invoca en modo túnel (-t) y todo el protocolo de red es canalizado a través "tunneled" de la conexión cifrada por ssh, el agente del túnel. svnserve se da cuenta de que se está ejecutando como el usuario juan, y si el cliente realiza cambios en el repositorio, el nombre de usuario autenticado será usado para atribuir la autoría de la nueva revisión.

Cuando se usa un túnel, la autorización es principalmente controlada por los permisos del sistema operativo a los ficheros de la base de datos del repositorio; es casi igual que si Juan estuviese accediendo al repositorio directamente vía URL file:///. Si necesita que múltiples usuarios del sistema accedan al repositorio directamente, podría ponerlos en un mismo grupo, y ajustar cuidadosamente sus umasks. Pero incluso en el caso de usar túneles, el fichero svnserve.conf todavía puede ser usado para bloquear el acceso, simplemente usando auth-access = read o auth-access = none.

Podría pensar que la historia del túnel por SSH acabaría aquí, pero no lo hace. Subversion le permite personalizar el comportamiento de los túneles en su fichero de configuración config. Por ejemplo, supongamos que desea usar RSH en lugar de SSH. En la sección [tunnels] de su fichero config, defina lo siguiente:

[tunnels]

rsh = rsh

Y ahora, usted puede usar esta nueva definición de túnel usando un esquema URL que concuerde con el nombre de su nueva variable: svn+rsh://host/path. Cuando use el nuevo esquema URL, el cliente Subversion estará ejecutando realmente el comando rsh host svnserve -t tras las cortinas. Si incluye un nombre de usuario en la URL (por ejemplo, svn+rsh://nombreusuario@host/path) el cliente también lo incluirá en su comando (rsh nombreusuario@host svnserve -t.) Pero puede definir nuevos esquemas de túneles mucho más elaborados que eso:

[tunnels]

joessh = $JOESSH /opt/alternate/ssh -p 29934

Este ejemplo muestra varias cosas. Primero, enseña cómo hacer que el cliente de Subversion lance un binario de túnel muy específico (uno ubicado en /opt/alternate/ssh) con opciones específicas. En este caso, acceder a la URL svn+joessh:// invocaría este particular binario de SSH con -p 29934 como parámetro—útil si desea que el programa de túnel se conecte a un puerto no estándar.

Segundo, enseña cómo definir una nueva variable de entorno personalizada que puede reemplazar el nombre de un programa de túnel. Modificar la variable de entorno SVN_SSH es un modo conveniente de reemplazar el agente de túneles SSH por defecto. Pero si necesita tener diferentes reemplazos para servidores diferentes, cada uno de ellos conectando quizás a un puerto diferente o usando un conjunto diferente de opciones, puede usar el mecanismo demostrado en este ejemplo. Ahora, si fuese a crear la variable de entorno JOESSH, su valor reemplazaría el valor completo de la variable del túnel—se ejecutaría $JOESSH en lugar de /opt/alternate/ssh -p 29934.

httpd, el servidor HTTP Apache

El servidor HTTP apache es un servidor de red "heavy duty" que Subversion puede aprovechar. A través de un módulo propio, httpd permite servir a clientes repositorios Subversion por el protocolo WebDAV/DeltaV, el cual es una extensión sobre HTTP 1.1 (vea http://www.webdav.org/ para más información.) Este protocolo coge el ubicuo protocolo HTTP, núcleo de la World Wide Web, y añade la capacidad de escritura—específicamente el versionado de la misma. El resultado es un sistema robusto, estandarizado, empaquetado convenientemente como parte del software Apache 2.0, soportado por numerosos sistemas operativos y productos de terceros, y no necesita que sus administradores de red abran otro puerto adicional. Si bien el servidor Apache-Subversion tiene más características que svnserve, también es más difícil de configurar. La flexibilidad a menudo se paga en complejidad.

Buena parte del texto siguiente incluye referencias a las directivas de configuración de Apache.

En su fichero httpd.conf hay directivas que especifican ubicaciones físicas de los archivos de registro de acceso y error generados por apache (las directivas CustomLog y ErrorLog respectivamente). El módulo mod_dav_svn de Subversion usa también la interfaz de registro de mensajes de error de Apache.

¿Por qué Apache 2?

Si usted es un administrador de sistemas, es muy probable que ya tenga funcionando un servidor web Apache y cuente con algo de experiencia con él. En el momento de escribir estas líneas, Apache 1.3 es de largo la versión más popular. El mundo ha sido algo lento en la actualización a las series 2.X por varias razones: algunas personas temen los cambios, especialmente cambiar algo tan crítico como un servidor web. Otras personas demandan los módulos plug-in que sólo funcionan con la API de Apache 1.3, y están esperando que sean portados a la 2.X. Sea la razón que sea, muchas personas comienzan a preocuparse cuando descubren por primera vez que el módulo Subversion de Apache está escrito para la API 2 de Apache.

La respuesta correcta a este problema es: no se preocupe por ello. Es fácil ejecutar Apache 1.3 y Apache 2 simultáneamente; simplemente instálelos en lugares diferentes, y use Apache 2 como un servidor dedicado a Subversion que se ejecuta en un puerto diferente al 80. Los clientes podrán acceder al repositorio indicando el puerto en la URL:

$ svn checkout

http://host.example.com:7382/repos/project

Requisitos previos

Para hacer disponible su repositorio por HTTP, básicamente necesita cuatro componentes disponibles en dos paquetes. Necesita el comando httpd de Apache 2.0, el módulo DAV mod_dav que viene con él, Subversion, y el módulo mod_dav_svn, que proporciona sistemas de ficheros, distribuido con Subversion. Una vez tenga todos estos componentes, el proceso para hacer disponible su repositorio es tan simple como:

• preparar y ejecutar httpd 2.0 con el módulo mod_dav,

• instalar el plug-in mod_dav_svn para mod_dav, el cual usa las librerías de Subversion para acceder a un repositorio, y

• configurar su fichero httpd.conf para exportar (o exponer) el repositorio.

Puede realizar los dos primeros pasos ya sea compilando httpd y Subversion a partir del código fuente, o instalando paquetes binarios precompilados en su sistema. Puede encontrar la información más actualizada sobre cómo compilar Subversion para su uso con el servidor HTTP Apache, al igual que cómo compilar y configurar Apache para este propósito, en el fichero INSTALL en el directorio raíz del código fuente de Subversion.

Configuración básica de Apache

Una vez tenga todos los componentes necesarios instalados en su sistema, todo lo que queda por hacer es configurar Apache mediante su fichero httpd.conf. Ordene a Apache que cargue el módulo mod_dav_svn module usando la directiva LoadModule. La directiva debe preceder cualquier otro elemento de configuración relacionado con Subversion. Si su Apache fue instalado usando el esquema por defecto, su módulo mod_dav_svn debería haber sido instalado en el subdirectorio modules de la instalación (a menudo /usr/local/apache2). La directiva LoadModule tiene una sintaxis sencilla, relacionando el nombre de un módulo con la ubicación de una librería dinámica en disco: disk:

LoadModule dav_svn_module modules/mod_dav_svn.so

Tenga en cuenta que si mod_dav fue compilado como un objeto compartido (en lugar de haber sido enlazado de manera estática con el binario httpd), necesitará también una línea LoadModule similar para él. Asegúrese de que aparece antes de la línea mod_dav_svn:

LoadModule dav_module modules/mod_dav.so

LoadModule dav_svn_module modules/mod_dav_svn.so

En un lugar posterior de su fichero de configuración, necesita indicarle a Apache dónde guardará su repositorio (o repositorios) de Subversion. La directiva Location sigue una notación tipo XML, comenzando con una etiqueta de apertura y terminando con una de cierre, con varias otras directivas de configuración en medio. El propósito de la directiva Location es indicar a Apache que debe realizar algo especial cuando tenga que procesar peticiones dirigidas a una URL determinada o a una hija suya. En el caso de Subversion, quiere que Apache simplemente le pase el control a la capa DAV de todas las URLs que apunten a recursos versionados. Puede ordenar a Apache que delegue el control de todas las URLs cuyas porciones de rutas (aquella parte de la URL que sigue el nombre del servidor y número de puerto opcional) empiecen con /repos/ a un proveedor DAV cuyo repositorio se encuentre en /ruta/absoluta/al/repositorio usando la siguiente sintaxis de httpd.conf:

DAV svn

SVNPath /ruta/absoluta/al/repositorio

Si planea soportar múltiples repositorios de Subversion que residirán en el mismo directorio padre de su disco local, puede usar una directiva alternativa, la directiva SVNParentPath, para indicar ese directorio padre común. Por ejemplo, si sabe que creará múltiples repositorios Subversion en el directorio /usr/local/svn que sería accesible mediante URLs como http://my.server.com/svn/repos1, http://my.server.com/svn/repos2, y así en adelante, podría usar la sintaxis de configuración httpd.conf del siguiente ejemplo:

DAV svn

# any "/svn/foo" URL will map to a repository /usr/local/svn/foo

SVNParentPath /usr/local/svn

Usando la sintaxis anterior, Apache delegará el control de todas las URLs cuyas porciones comiencen con /svn/ al proveedor DAV de Subversion, quien asumirá que todos los elementos en el directorio especificado por la directiva SVNParentPath son en realidad repositorios de Subversion. Esta es una sintaxis particularmente conveniente, ya que a diferencia de la directiva SVNPath, no necesita reiniciar Apache para crear y hacer disponibles nuevos repositorios.

Asegúrese de que cuando defina su nuevo Location, no se solapa con otras ubicaciones exportadas. Por ejemplo, si su DocumentRoot principal es /www, no exporte ningún repositorio Subversion en . En caso de recibir una petición para la URI /www/repos/foo.c, Apache no sabrá si tiene que buscar el fichero repos/foo.c en DocumentRoot, o si debe delegar en mod_dav_svn para que devuelva foo.c del repositorio Subversion.

Nombres de servidor y peticiones COPY

Subversion hace uso del tipo de petición COPY para realizar copias de ficheros y directorios en el lado del servidor. Como parte de los chequeos de seguridad realizados por los módulos Apache, se espera que el origen de la copia esté ubicado en la misma máquina que el destino. Para satisfacer este requisito, podría necesitar decirle a mod_dav el nombre de servidor que usa para su máquina. En general, puede usar la directiva ServerName de httpd.conf para lograr esto.

ServerName svn.example.com

Si está usando el soporte de hosting virtual de Apache por medio de la directiva NameVirtualHost, puede que necesite usar la directiva ServerAlias para especificar nombres adicionales bajo los cuales es conocido su servidor. De nuevo, busque en la documentación de Apache los detalles de la misma.

En este punto, debería considerar seriamente el tema de los permisos. Si ha estado ejecutando Apache durante algún tiempo como su servidor de web habitual, probablemente ya tenga una colección de contenido—páginas web, scripts y demás. Estos elementos ya han sido configurados con un conjunto de permisos que les permite funcionar con Apache, o de manera más apropiada, le permite a Apache funcionar con esos ficheros. Apache, cuando es usado como servidor de Subversion, también necesitará los permisos adecuados de lectura y escritura a su repositorio Subversion.

Tendrá que encontrar una configuración de permisos de sistema que satisfaga los requisitos de Subversion sin estropear instalaciones ya existentes de páginas web o scripts. Esto podría significar cambiar los permisos de su repositorio Subversion para que encajen con aquellos usados por otras elementos servidos por Apache, o podría significar usar las directivas User y Group del fichero httpd.conf para especificar que Apache debe ejecutarse con el usuario y grupo a quien pertenece su repositorio Subversion. No hay una única manera correcta de configurar sus permisos, y cada administrador tendrá diferentes razones para hacer las cosas a su manera. Sólo tenga presente que los problemas relacionados con los permisos son quizás el fallo más común cuando se configura un repositorio Subversion para ser usado con Apache.

Opciones de autenticación

En este punto, si ha configurado httpd.conf para que contenga algo como

DAV svn

SVNParentPath /usr/local/svn

…entonces su repositorio es accesible al mundo de manera "anónima". Hasta que configure algunas políticas de autenticación y autorización, los repositorios Subversion que haga disponibles con la directiva Location serán generalmente accesibles por cualquiera. En otras palabras,

• cualquiera puede usar su cliente de Subversion para obtener una copia local de la URL de un repositorio (o cualquiera de sus subdirectorios),

• cualquiera puede navegar de manera interactiva las últimas revisiones del repositorio simplemente usando la URL del repositorio con su navegador web, y

• cualquiera puede enviar cambios al repositorio.

Autenticación HTTP básica

La forma más sencilla de autenticar a un cliente es mediante el mecanismo de autenticación HTTP básico, que simplemente usa un nombre de usuario y clave para verificar que el usuario es quien dice ser. Apache proporciona la utilidad htpasswd para gestionar la lista de nombres de usuarios y claves aceptables, aquellos a quienes desea proporcionar acceso especial a su repositorio Subversion. Permitamos el acceso de escritura a Juan y Carmen. Primero, necesitamos añadirlos al fichero de claves.

$ ### First time: use -c to create the file

$ ### Use -m to use MD5 encryption of the password, which is more secure

$ htpasswd -cm /etc/svn-auth-file harry

New password: *****

Re-type new password: *****

Adding password for user harry

$ htpasswd /etc/svn-auth-file -m evelyn

New password: *******

Re-type new password: *******

Adding password for user evelyn

$

Ahora, necesitamos añadir algunas directivas httpd.conf más dentro del bloque Location para decirle a Apache qué hacer con su nuevo fichero de claves. La directiva AuthType especifica el tipo del sistema de autenticación que va a usar. En este caso, queremos especificar el sistema de autenticación Basic. AuthName es un nombre arbitrario que usted proporciona para el dominio de autenticación. La mayoría de los navegadores mostrarán este nombre en una ventana de diálogo emergente cuando el navegador le pregunte su nombre y clave. Finalmente, use la directiva AuthUserFile para especificar la ubicación del fichero de claves creado usando htpasswd.

Tras añadir estas tres directivas, su bloque debería tener un aspecto similar a este:

DAV svn

SVNParentPath /usr/local/svn

AuthType Basic

AuthName "Subversion repository"

AuthUserFile /etc/svn-auth-file

Este bloque todavía no está completo, y no hará nada útil. Meramente indica a Apache que cuando requiera autorización, Apache debe obtener el nombre de usuario y clave del cliente Subversion. Lo que falta aquí, no obstante, son las directivas que le dicen a Apache qué tipos de solicitudes por parte de los clientes requieren autorización. Donde se requiera autorización, Apache demandará también autenticación. Lo mas sencillo es proteger todas las peticiones. Añadir Require valid-user indica a Apache que todas las peticiones requieren un usuario autenticado:

DAV svn

SVNParentPath /usr/local/svn

AuthType Basic

AuthName "Subversion repository"

AuthUserFile /etc/svn-auth-file

Require valid-user

Una advertencia: en la autenticación básica por HTTP las palabras claves viajan por la red casi como texto simple, y son por lo tanto extremadamente inseguras. Si está preocupado por la existencia de un rastreador de claves, lo mejor sería usar algún tipo de cifrado SSL, para que los clientes se autentiquen vía https:// en lugar de http://; como mínimo podrá configurar Apache para que use use un certificado firmado por sí mismo. Consulte la documentación de Apache (y la de OpenSSL) para saber cómo hacer esto.

Gestión de certificados SSL

Las empresas que necesitan exponer sus repositorios a un acceso externo al firewall de la compañía deberían ser conscientes de que grupos no autorizados podrían estar "rastreando" su tráfico de red. SSL consigue que ese tipo de atención no deseada desemboque con menor probabilidad en fugas de datos sensitivos.

Si se compila un cliente de Subversion para que use OpenSSL, entonces ganará la habilidad de hablar con un servidor Apache vía URLs https://. La librería Neon usada por el cliente Subversion no solo es capaz de verificar los certificados de servidor, sino que también puede proporcionar certificados de cliente cuando sean solicitados. Una vez el cliente y servidor hayan intercambiado sus certificados SSL y realizado una autenticación mutua con éxito, todas sus comunicaciones siguientes serán cifradas con una clave de sesión.

Cómo gestionar los certificados de cliente y servidor desde un cliente Subversion ordinario.

Cuando un cliente Subversion se comunica con Apache vía https://, puede recibir dos tipos diferentes de información:

• un certificado de servidor

• una demanda de un certificado de cliente

Si el cliente recibe un certificado de servidor, necesita verificar que confía en el certificado: ¿es realmente el servidor quien dice ser? La librería OpenSSL realiza esto examinando al firmante del certificado de servidor o la autoridad certificadora (CA). Si OpenSSL no es capaz de confiar automáticamente en la CA, o bien ocurre algún otro problema (como que el certificado expiró o no concuerda con el nombre del servidor), el cliente de línea de comando de Subversion le preguntará si quiere confiar en el certificado del servidor de todas maneras:

$ svn list https://host.example.com/repos/project

Error validating server certificate for 'https://home.example.com:443':

– The certificate is not issued by a trusted authority. Use the

fingerprint to validate the certificate manually!

Certificate information:

– Hostname: host.example.com

– Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT

– Issuer: CA, example.com, Sometown, California, US

– Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

(R)eject, accept (t)emporarily or accept (p)ermanently?

Este diálogo debería parecerle familiar; es esencialmente la misma pregunta que ha observado proveniente de su navegador web (¡que es meramente otro cliente HTTP como Subversion!). Si elige la opción (p)ermanente, el certificado de servidor será guardado en el área auth/ de su fichero privado de configuración de parámetros de ejecución, del mismo modo que es guardado su nombre de usuario y clave. Si se cachea, Subversion recordará confiar de manera automática en este certificado en futuras negociaciones.

Su fichero servers del área de la configuración de parámetros de ejecución también le permite a su cliente de Subversion confiar de manera automática en CAs específicos, ya sea de manera global o individual. Simplemente modifique la variable ssl-authority-files para que sea una lista de certificados de CA con codificación PEM separados por punto y coma:

[global]

ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem

Muchas instalaciones de OpenSSL confían "por defecto" de manera casi universal en un conjunto predefinido de CAs. para hacer que el cliente Subversion confíe de manera automática en estas autoridades estándar, cambie la variable ssl-trust-default-ca a true.

Cuando dialoga con Apache, un cliente de Subversion también podría recibir una petición de certificado de cliente. Apache está solicitando al cliente que se identifique: ¿es el cliente realmente quien dice ser? Si todo va bien, el cliente de Subversion devuelve un certificado privado firmado por la CA en quien confía Apache. El certificado de cliente habitualmente se almacena cifrado en el disco, protegido por una palabra clave local. Cuando Subversion recibe esta petición, le preguntará tanto por la ruta al certificado como por la palabra clave que lo protege:

$ svn list https://host.example.com/repos/project

Authentication realm: https://host.example.com:443

Client certificate filename: /path/to/my/cert.p12

Passphrase for '/path/to/my/cert.p12': ********

.

Tenga que el certificado de un cliente es un fichero "p12". Para usar un certificado de cliente con Subversion, debe estar en el formato PKCS#12, que es un estándar portable. La mayoría de los navegadores son capaces de importar y exportar certificados en este formato. Otra opción es usar las herramientas de línea de comando de OpenSSL para convertir certificados existentes a PKCS#12.

De nuevo, el fichero servers del área de configuración de parámetros de ejecución le permite automatizar este proceso por cada máquina. Una o ambas informaciones pueden ser descritas en variables de ejecución:

[groups]

examplehost = host.example.com

[examplehost]

ssl-client-cert-file = /path/to/my/cert.p12

ssl-client-cert-password = somepassword

Una vez creadas las variables ssl-client-cert-file y ssl-client-cert-password, el cliente Subversion responderá automáticamente a peticiones de certificado de cliente sin tener que preguntarle.

Opciones de autorización

En este punto, ya ha configurado la autenticación, pero no la autorización. Apache es capaz de cuestionar a los clientes y confirmar sus identidades, pero todavía no sabe cómo permitir o restringir el acceso a los clientes con esas identidades. Esta sección describe dos estrategias para controlar el acceso a sus repositorios.

Control de acceso simple