martes, noviembre 20, 2007

Setting up an SVN server (over SSL) (I)

Tenía ganas de retomar la parte técnica del blog y aprovechando que estos días he estado instalando Suvbersion y Artifactory (éste aún no lo tengo completamente configurado) he elaborado este mini artículo con los pasos a seguir. En esta primera entrega configuraremos svnserve (modo standalone) y dejaremos para un segundo artículo la posibilidad de que nuestro sistema controlador de versiones esté disponible a través del protocolo WebDAV (una extensión de http). Manos a la obra:

En primer lugar, y tal y como indica el título del post que nos ocupa, estableceremos un servidor SVN a través de una conexión SSL con lo que necesitaremos tener instalados en nuestro sistema dichos componentes. En el caso de mi Ubuntu Feisty podríamos ejecutar el siguiente comando:
sudo apt-get install subversion openssh-server
Tras la ejecución del comando anterior tendremos en nuestro equipo todos los elementos necesarios para realizar una configuración totalmente operativa de nuestro sistema de control de versiones.

A continuación creamos un nuevo grupo (en mi caso lo he llamado svnusers) para facilitar las labores de administración . Todos los usuarios que deseen tener acceso deberan ser miembros del grupo anterior (más adelante veremos el porqué). Además crearemos un nuevo usuario perteneciente al grupo anterior con nombre svnadm. Para llevar a cabo esta tarea ejecutaremos el siguiente conjunto de órdenes:

# creamos el grupo svnusers
addgroup svnusers

# creamos el usuario "test" perteneciente al grupo svnusers
adduser --ingroup svnusers test
Nota: por motivos de seguridad es una buena práctica que el usuario root no pueda realizar login a través de una conexión de ssh. Asimismo ninguno de los usuarios pertenecientes al grupo svnusers debería ser capaz de "hacer su hacia root".

Llegados a este punto necesitamos que los usuarios del grupo svnusers no inhabiliten, en el momento en que establecen una conexión a través del tunel ssh,los permisos establecidos a nivel de grupo; para ello establecemos la máscara al valor 002. Una manera sencilla de hacer ésto es editar el fichero .bashrc de cada uno de los usuarios pertenecientes al grupo svnsusers y añadir la siguiente línea:

# permitimos lectura/escritura al usuario y al grupo pero no al resto
umask 002
Reptimos los dos últimos pasos descritos anteriormente y creamos el usuario svnadm.

Nos logueamos como usuario root, en caso de que no lo estuviéramos, y creamos una ruta en nuestro sistema de archivos para contener nuestros repositorios. Suponiedo que path_to_repository contiene una ruta válida dentro de nuestro sistema de archivos podríamos ejecutar la siguiente orden:
mkdir -p path_to_repository
Además restringimos el acceso a los repositorios al root y los usuarios pertenecientes al grupo svnusers
chown -R root.svnusers path_to_repository
chmod -R u+wxr,+gwxr,o-wxr path_to_repository
El paso que a continuación se indica (lo encontré en una mini guía buscando cosas relativas a la seguridad) pretende "esconder" la ruta raíz del servidor donde estamos almacenando todos nuestros repositorios. Para ello sustituiremos nuestro ejecutable svnserve del modo que a continuación se indica:

Renombramos el comando svnserve (en mi caso lo tengo disponible en /usr/bin/) con el nombre svnserve.bin
mv /usr/bin/svnserve /usr/bin/svnserve.bin
Creamos un nuevo fichero /usr/bin/svnserve que contendrá el siguiente código:
#!/bin/sh
# wrap in order to put root in by default
# Script implemented by Adrian Robert <arobert@cogsci.ucsd.edu>

exec /usr/bin/svnserve.bin -r /path/to/repository/root "$@"
El fichero recién creado podrá ser ejecutado y leído por todo el mundo
chmod u+wrx,g+rx-w,o+xr-w /usr/bin/svnserve

Un vez llegados a este punto estamos en disposición de crear un nuevo proyecto en nuestro repositorio. Nos logueamos como usuario svnadm e introducimos la siguiente orden en una terminal:
svnadmin create path_to_repository/nombre_proyecto
No permitimos el acceso a ningún usuario no perteneciente al grupo svnusers (a excepción del root claro está)
chmod -R o-rwx path_to_repository/nombre_proyecto
Editamos el fichero de configuración del proyecto recientemente creado para no permitir accesos anónimos (sólo aquellos autenticados a través de ssh) y además permitimos la escritura (una vez autenticados). Esto se consigue editando el fichero svnserve.conf de un modo similar al que a continuación se indica:
# abrimos el fichero de configuración de nuestro nuevo proyecto
vi path_to_repository/nombre_proyecto/conf/svnserve.conf

# no se permite el acceso anónimo y si la escritura para usuarios autenticados
[general]
anon-access = none
auth-access = write

Para testear que todo marcha correctamente ejecutamos al siguiente orden:
svn list svn+ssh://@localhost/nombre_proyecto
Se nos pedirá un nombre y un password y en caso de que los datos introducidos sean correctos seremos devueltos al prompt donde tecleamos la orden (el proyecto que hemos creado unos pasos más arriba no contiene ningún tipo de información). Con ésto nos aseguramos que el servidor ssh está funcionando correctamente así como el tunel hacia el svnserve.

En este mismo instante dispondríamos de un repositorio Subversion totalmente funcional aunque cada vez que realizásemos una operación se nos pediría que introdujésemos nuestro usuario y contraseña correspondientes. Con el objetivo de evitarnos este pequeño incordio generaremos un par de claves públicas/privadas.
A continuación, y de manera rápida, se indica el modo en que llevaríamos a cabo esta tarea:
# generamos nuestro par de claves
ssh-keygen -t dsa

# copiamos nuestra clave pública a las claves autorizadas
cd $HOME/.ssh/
cp id_rsa.pub authorized_keys

# permisos adecuados
chmod 0700
$HOME/.ssh/
chmod 0600
$HOME/.ssh/authorized_keys
Esto ha sido todo. Como veis son un conjunto sencillo de pasos gracias a los cuales establecemos una configuración básica de un repositorio subversion a través de una conexión segura.

En el siguiente capítulo haremos que nuestro repositorio se encuentre accesible a través del protocolo WebDAV; (mucho más sencillo que ésto :) )

Espero que os haya gustado y que os sirva de ayuda.

Hasta pronto!

7 comentarios:

Andre dijo...

Pregunta I: qué es un servidor svn??? ;)

Pregunta II: No sabrás de algún motor de inferencias para trabajar con Java que no sea Jess (no es abierto) o JRuleEngine (que es na más que una librería...) De momento creo que puedo apañármelas con lo de JRuleEngine, pero quizá sea demasiado sencillo... Por la web ya encontré algunos pero claro, no tengo ni idea de pros/contras! El único requisito es que haga forward chaining!

Besos!

migue dijo...

Respuesta a la pregunta I:

Subversion es un sistema controlador de versiones. Es decir, un servicio que te permite versionar tus archivos (desde archivos código fuente hasta tu lista de películas en DivX). De este modo puedes recuperar elementos con una fecha determinada o comprobar la evolución de los cambios a lo largo del tiempo.

Para la pregunta II no tengo respuesta :). Ni me suena JRuleEngine ni me suena Jess así que ... jejejejej. El único contacto que he tenido con algo parecido a eso ha sido prolog dado que también podemos embeberlo en Java (aunque para ello, al menos hasta donde alcanzan mis conocimientos, debes hacer uso de la tencnologia JNI). De todos modos no creo que ésto sea un solución que se adapte a tus necesidades.

Suerte con la búsqueda!

Un beso.

PD: si encuentro algo interesante y no es demasiado tarde te llamo para contártelo.

Andre dijo...

Muchas gracias Migue!

Como siempre, yes un pozu de sabiduría :P

Cuando vengas pa aqui has de llamame y comemos/cenamos juntos!

Besinos

Anónimo dijo...

Miguel, estoy intentando instalar un svn server y lo que he leido aquí me fue de gran utilidada. Aún me resta lo mas importante, ponerlo en práctica. Pero lo pruebo y luego te comento.
Gracias por anticipado.
Andrés♦

migue dijo...

Me alegro que te haya servido de utilidad Andrés.

Si te surje alguna duda añade un comentario en intentaremos solucionarla.

Un saludo

Fran dijo...

No es sobre ssl, es sobre ssh. El "problema" de este tipo de configuración es que requiere dar acceso ssh a los usarios de subversion, lo cual muchas veces es indeseable. Por eso existen otras opciones de conexión.

Yo tengo un repositorio privado para mis cosas y las de mi socio al que se accede con ssh, y otro público para proyectos libres en el que pueden participar personas que apenas conozco, al que se accede con svnserve+sasl2, así va cifrado para evitar que terceros puedan capturar sus contraseñas, al tiempo que estos usuarios no pueden acceder al sistema por ssh porque no tienen una cuenta regular (el svnserve corre como usuario svn, cuyo shell es /sbin/nologin).

migue dijo...

Hola Fran,

Tienes razón, es sobre ssh y no sobre ssl, ha sido un error al escribirlo.

Respecto al "problema" tampoco es demasiado grande en nuestro caso porque habitualmente los repositorios que utilizamos están enmarcados en el ámbito de un grupo de desarrollo dentro de la empresa, por lo que conceder acceso ssh a los usuarios del repositorio no supone ningún quebradero de cabeza.

Ultimamente ofrecemos las conexiones a los repositorios a través del protocolo http integrado con Active Directory (es lo que han puesto en la empresa y nos hemos tenido que amoldar a ello :) )

Muchas gracias por tu comentario