Setting up an SVN server (y II)

En el post anterior configuramos nuestro servidor Subversion a través del servidor standalone svnserve. En esta ocasión habilitaremos nuestro servidor svn a través del protocolo WebDAV (una extensión del protocolo http). Vamos allá:

En primer lugar necesitaremos tener instalado en nuestro sistema un servidor http. De sobra es conocido por todos que Apache es el servidor http más extendido con lo que será el que utilicemos en esta sencilla guía (concretamente utilizaremos Apache 2). También es necesario el módulo mod_dav_svn.so. Ejecutamos la siguiente orden en una terminal:

sudo apt-get install apache2 libapache2-svn

Tras esta sencilla orden tendremos en nuestro sistema un servidor http con el soporte necesario para habilitar nuestro servidor subversion. Configuremos ahora nuestro repositorio:

Editamos con nuestro editor favorito el fichero dav_svn.conf (si habeis instalado apache2 con la orden indicada anteriormente lo encontrareis en la ruta /etc/apache2/mods-enabled/dav_svn.conf)

vim /etc/apache2/mods-enabled/dav_svn.conf

Deberemos descomentar una serie de líneas para habilitar y establecer una configuración básica
: vayamos por partes.

En primera instancia habilitaremos el repositorio con lo que descomentaremos las siguientes líneas:

# habilitamos el repositorio
DAV svn
# indicamos la ruta absoluta al mismo
SVNPath ruta_absoluta_repositorio

Configuremos ahora el control de acceso. Dicho control es realizado a tres niveles diferentes:

1. Autenticación facilitada por Apache.
2. Directivas "limit" y "limitexcept".
3. El módulo mod_authz_svn.

En este mini-tutorial habilitaremos una autenticación básica. Soy consciente de que no es demasiado seguro a no ser que se utilice a través de https pero no quiero complicar demasiado esta entrega; en futuras versiones configuraremos los distintos niveles de acceso.

Para llevar a cabo nuestra tarea necesitaremos descomentar las siguientes líneas en el fichero dav_svn.conf:

AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user

Creamos el fichero /etc/apache2/dav_svn.passwd con los usuarios a los que deseemos permitir el acceso a nuestro repositorio. Actuamos del siguiente modo:

htpasswd -cm /etc/apache2/dav_svn.passwd nombre_usuario

Se nos pedirá una contraseña para el usuario indicado.

En este momento dispondremos de una configuración básica de nuestro servidor svn a través de http. Si queremos comprobar el correcto funcionamiento podemos irnos a nuestro navegador (Firefox por supuesto ;) e intentar acceder al repositorio:

http://maquina/repositorio/

Nos solicitará nuestro usuario y contraseña, y en caso de que las claves introducidas sean correctas, se nos mostrará un listado con todos los proyectos registrados en el repositorio.

Tal y como os contaba en el post anterior establecer una configuración básico no es demasiado complicada. Espero que pueda serviros de utilidad.

Hasta pronto!

PD: en siguientes post cambiaremos un poquito de tema dejando a un lado la configuración de servidores. Hablaremos un poquito de Hibernate y puede que LINQ si tengo tiempo.

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!

Hacía tiempo que no dejabamos por aquí ningún post con alguna cosilla de programación, diseño o similares (esta última temporada he estado muy liado), así que vamos a retomarlo con un post ligero en el que indicaremos algunos "trucos" del mundo Unix para realizar algunas tareas. Realmente no son trucos ni nada que se les parezca sino una serie de comandos/configuraciones con las que podremos llevar a cabo acciones cotidianas. Manos a la obra.

En numerosas ocasiones necesitamos conectarnos a una máquina servidora para realizar una determinada tarea, y más aún, necesitaremos las X para alcanzar nuestro objetivo final. Desde un sistema windows tendríamos que configurar algún sevidor X como puede ser Exceed o Xming y conectarnos mediante un cliente ssh como bien puede ser Putty (supongamos que necesitamos conexión segura). ¿Y si nuestra estación de trabajo es una máquina Linux?
En el supuesto anterior tendremos que habilitar en nuestra máquina un puerto (habitualmente suele ser el 6000) para que el servidor X pueda dialogar con la máquina remota. En el caso de mi equipo Ubuntu, necesitaremos configurar el fichero /etc/X11/xinit/xserverrc que por defecto presenta un aspecto como el que se muestra a continuación:


Necesitamos indicarle al servidor X que acepte peticiones por un determinado puerto por lo que podríamos configurarlo de un modo parecido al que sigue:


Si reiniciamos nuestro servidor X estaríamos listos para conectarnos a otra máquina y poder trabajar con las X. Para conectarnos actuaríamos del siguiente modo:

ssh -X usuario@MaquinaRemota:puerto

La opción -X es la encarga de habilitar el "forwarding" (ojo a las consideraciones de seguridad que todo esto conlleva).

Siguiendo con las conexiones a máquinas remotas es muy común intentar abrir una conexión de Escritorio remoto. Imaginemos que la máquina servidora en la que intentamos abrir una sesión de Escritorio tiene corriendo un Tight VNC server; en este caso no tendremos más que utilizar el cliente de Tight VNC (o el que más nos guste) para conectarnos. ¿Y si la máquina servidora es un Windows 2003 Server en el que se está ejecutando un Terminal Server? Entonces el cliente de Tight VNC no nos será de gran ayuda. Dada esta situación, acudiremos a la aplicación rdesktop, la cual nos permitirá abrir un Escritorio Remoto aunque el servidor al que nos estamos intentando conectar esté corriendo un Terminal Server. Si tecleamos

rdesktop -f -u usuario maquinaRemota

nos aparecerá la ventana (ocupando toda la pantalla) de login en nuestra sesión windows (que es el caso que estamos contemplando ahora mismo). La combinación de teclas Ctrl + Alt + Enter nos permite alternar entre el modo pantalla completa o una simple ventana con el Escritorio.

Y ya para terminar, muchos de los usuarios de Windows, sobremanera los aficionados a los videojuegos ( y los que no también :) ), utilizan utilidades como las Daemon Tools para cargar sus imágenes (como pueden ser ISO9660). En un sistema Linux la utilidad mount nos permite cargar el contenido de la imagen en nuestro sistema de archivos como si se tratase de un directorio más. La única peculiaridad es que la imagen, por ejemplo iso9660, es un archivo montado en otro sistemas de ficheros por lo que dirigiremos el montaje a un dispositivo de loop. Creo que un ejemplo vale más que mil palabras:

En mi disco duro externo tengo una imagen ISO con el Visual Studio 2005, concretamente la ruta es: /datos/software/VisualStudio2005. Ahora imaginaros que queremos ver el contenido de la imagen, para ello tecleamos la siguiente orden (vamos a montar la imagen en el directorio /media):


Si ahora listamos el contenido del directorio media ...... ya tenemos el contenido de nuestra imagen en el directorio /media.


Espero que os sirva de algo (al menos para matar el tiempo jejeje)

Hasta pronto!
Un abrazo!