Entradas etiquetadas ‘tutorial’
Servidor de proyectos con Subversion, Trac, Apache (y LDAP)
En esta entrada vamos a montar un servidor para la gestión de proyectos. Para ello utilizaremos un sistema de control de versiones (Subversion), un sistema de gestión de incidencias (Trac) y un sistema de autenticación compartido, para ello utilizaremos Apache y alguno de sus métodos de autenticación como por ejemplo LDAP (válido si es necesario utilizar las cuentas de un Directorio Activo).
Aunque existen soluciones más elaboradas y más integradas, como el software de SourceForge.net, este planteamiento permite montar un servidor a medida, pudiendo alterar cualquiera de sus elementos, y en mi opinión más sencillo de mantener.
Nos basaremos en una instalación mínima de Ubuntu Server 8.04 (por lo que no disponemos ni de Subversion 1.5 ni de Trac 0.11) con la idea de montar un servidor preparado para mantener varios proyectos.
Instalación y configuración de Subversion
Para empezar instalaremos subversion, también es recomendable subversion-tools por los scripts adicionales que incorpora, y preparamos un repositorio de prueba:
# apt-get install subversion subversion-tools # mkdir /srv/svn # svnadmin create /srv/svn/proyecto
Aprovechamos ahora para crear una estructura básica dentro del repositorio, esto nos servirá en las pruebas para ver si realmente podemos acceder al repositorio:
# svn co file:///srv/svn/proyecto
# svn mkdir proyecto/{branches,tags,trunk}
# svn ci -m 'Estructura Inicial' proyecto
Instalación y configuración de Trac
Instalaremos y configuraremos mínimamente un proyecto de Trac para el repositorio que acabamos de crear:
# apt-get install trac # mkdir /srv/trac # trac-admin /srv/trac/proyecto initenv (Opciones sugeridas) Path to repository [/path/to/repos]> /srv/svn/proyecto
Es el momento de comprobar que trac y su unión con el repositorio de subversion funcionan correctamente, para ello lanzaremos el servidor incluido en trac:
# tracd -p 80 /srv/trac/proyecto
Abriendo la URL http://localhost:80/ deberíamos ver disponible nuestro proyecto, “My Project“, y comprobamos que la función de “Browse Source” funciona correctamente.
Por el momento nada nuevo, paremos tracd y sigamos.
Instalación y configuración de Apache
Optamos por enganchar Trac con mod_python así que lo más sencillo es instalar el paquete de mod_python y que instale apache por sus dependencias:
# apt-get install libapache2-mod-python
Bien, ahora editamos la configuración para que Apache pase las peticiones que vayan a /trac a nuestro conjunto de proyectos en /srv/trac. Editando el fichero /etc/apache2/sites-available/default añadimos antes del cierre de </VirtualHost> lo siguiente:
<Location /trac> SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /srv/trac PythonOption TracUriRoot /trac </Location>
Forzamos la recarga de la configuración de Apache:
# /etc/init.d/apache2 reload
Hacemos una prueba con el navegador en http://localhost/trac/ que debería mostrarnos un error por falta de permisos de escritura. Como vamos a dejar a Apache como gestor de los proyectos es necesario darle los permisos que necesita:
# chown -R www-data.www-data /srv/trac/proyecto
Con esto todo debería funcionar exactamente igual que con la prueba realizada con tracd. Vamos ahora a mostrar el repositorio desde Apache.
Subversion trabaja con Apache haciendo uso de WebDAV así que instalamos el módulo necesario:
# apt-get install libapache2-svn
Añadimos la configuración necesaria en el fichero /etc/apache2/mods-available/dav_svn.conf, podéis descomentar las opciones si os resulta más cómodo. En cualquier caso la configuración debe quedar de la siguiente manera:
<Location /svn> DAV svn SVNParentPath /srv/svn </Location>
De nuevo, forzamos la recarga de la configuración de Apache y comprobamos que http://localhost/svn/proyecto muestra el proyecto y que podemos navegar dentro de él. Si probáis http://localhost/svn/ os dará un error, ya que en este caso no existe un listado de proyectos disponibles como hacía Trac.
Igualmente que en Trac, si Apache es el gestor del repositorio es necesario que tenga permisos de escritura. En este caso vamos a ceder completamente el control a Apache:
# chown -R www-data.www-data /srv/svn/proyecto
Ahora mismo disponemos de un sistema completamente funcional en el que no se exige ningún tipo de autenticación. En el caso de Trac no se puede hacer login y en el caso de Subversion ni siquiera se pide. Si queréis verlo en podéis hacer la siguiente prueba:
# svn co http://localhost/svn/proyecto/trunk # touch trunk/README.txt # svn add trunk/README.txt # svn ci -m "Fichero leame" trunk
Si comprobamos el historial, svn log trunk/README.txt, podremos ver que no hay ningún usuario responsable del commit. En ningún momento se nos ha pedido identificarnos, ya que hay permisos de lectura y escritura para todo el mundo, así que podemos bajarnos el contenido del repositorio y los commit son anónimos.
Autenticando usuarios
Empecemos con lo más sencillo, usuarios válidos de un fichero htpasswd, podéis leer algo más en otro de mis artículos sobre ficheros .htpasswd.
# htpasswd -c /etc/apache2/users.conf chernando
Editamos Trac para soportar un login centralizado añadiendo un nuevo location a default:
<Location /trac/*/login> AuthType Basic AuthName "Trac Projects" AuthUserFile /etc/apache2/users.conf Require valid-user </Location>
Forzando la recarga de Apache ya disponemos de la función “login” en Trac. Para el repositorio vamos a dejar el acceso de lectura para todo el mundo y limitar el acceso de escritura a los usuarios registrados añadiendo a la configuración de WebDAV:
AuthType Basic AuthName "Subversion Repository" AuthUserFile /etc/apache2/users.conf <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept>
Una vez más recargando Apache ahora podemos bajar y actualizar un repositorio pero necesitaremos identificarnos para subir cambios al repositorio. Probad a añadir un nuevo fichero y comprobaréis que ahora se exige un usuario y password válidos.
Rizando el rizo, autenticando contra un LDAP
En el caso de disponer de un sistema de autenticación centralizada, por ejemplo LDAP o un Directorio Activo con el servicio LDAP activo, podemos delegar toda la carga de la gestión de usuarios dejando nuestro servidor de proyectos completamente “inhabitado”.
Para ello lo único que necesitamos es cambiar ambas configuraciones. En primer lugar habilitamos los módulos necesarios:
# a2enmod authnz_ldap (esto debería habilitar el módulo ldap por dependencias)
Y configuramos ambas secciones de autenticación. Primero eliminamos AuthUserFile que ya no es necesaria y después añadimos:
AuthBasicProvider "ldap" AuthLDAPURL "ldap://127.0.0.1/dc=chernando,dc=eu?uid?sub?(objectClass=inetOrgPerson)" authzldapauthoritative Off
Podéis ver más detalles en http://trac.edgewall.org/wiki/TracModPython.
Ampliaciones que pueden hacerse a partir de aquí
En esta entrada he intentado introducir el menor ruido posible, tanto en comandos como software a instalar, por lo que hay ciertas mejoras que se han quedado en el tintero. Por ejemplo:
- Configurar Apache para hacer uso de SSL, muy necesario ya que hasta el momento todas las negociaciones con Apache van en texto claro.
- Establecer limitaciones en el acceso de los repositorios (y en secciones de los mismos) haciendo uso de authz.
- Configurar un sistema de correo, que permita notificar todo tipo de eventos: nuevos tickets, cambios en el repositorio…
- Integrar Subversion con Trac, por ejemplo permitir que un commit cierre o añada información a un ticket de Trac.
- Utilizar la última versión de Subversion, 1.5, por su mejora en la gestión de merge de ramas.
- Utilizar la última versión de Trac, 0.11, por las mejoras en el interfaz y en la gestión del flujo de trabajo asociado a un ticket.
- Ampliar el sistema incluyendo otros servicios: listas de correo, servidor de integración continua…
Apache Ant, primeros pasos creando un build.xml
Uno de los inconvenientes en la construcción de software con más de dos ficheros (cualquier cosa que se salga de un “Hello world!”) es el proceso de compilación: orden de compilación de ficheros, dependencias, rutas de librerías internas, etc… En esta entrada vamos a dar los primeros pasos en una de las soluciones más comunes para proyectos Java: Apache Ant.
Para los impacientes: al final de la entrada encontraréis el build.xml con todo lo explicado que seguramente os sirva tal cuál.
En primer lugar creamos un fichero build.xml en el raíz de nuestro proyecto y definimos su nombre:
<project name="Proyecto"> </project>
Ant, al igual que otras herramientas de construcción, se basa en el concepto de objetivos o targets cuya definición engloba tanto las dependencias previas como los pasos a seguir para conseguirlo.
Vamos a comenzar definiendo un objetivo de preparación llamado init que será el encargado de crear un directorio classes donde guardaremos los ficheros .class resultantes de la compilación y el directorio build para el .jar final. Para ello basta incluir dentro de <project> las siguientes líneas:
<target name="init"> <mkdir dir="classes" /> <mkdir dir="build" /> </target>
Como podemos ver los objetivos se delimitan con etiquetas <target> y un nombre. Dentro de ellos se enumeran los pasos que se han de seguir para alcanzar el objetivo, en este caso ha de crear directorios.
Si queremos alcanzar el objetivo init basta con realizar:
$ ant init
Buildfile: build.xml
init:
[mkdir] Created dir: /home/chernando/proyecto/classes
[mkdir] Created dir: /home/chernando/proyecto/build
BUILD SUCCESSFUL
Total time: 0 seconds
Es hora de compilar nuestro proyecto, vamos a definir el objetivo compile. Ahora bien, la compilación depende de la creación del directorio classes que se realiza objetivo anterior. Con esto en cuenta basta con incluir:
<target name="compile" depends="init"> <javac srcdir="src" destdir="classes" /> </target>
La dependencia se fija en la declaración del target de tal manera que se garantiza su cumplimiento antes de comenzarla. Nuestro código está en el directorio src y el resultado de la compilación se lleva al directorio classes.
Importante notar que esta vez estamos usando <javac> esto es lo que Ant se denomina tarea. Hay muchas tareas predefinidas, consultad el manual de ant.
Con nuestro proyecto compilado vamos a generar el .jar que distribuiremos haciendo uso de un nuevo objetivo llamado build.
<target name="build" depends="compile"> <jar destfile="build/proyecto.jar" basedir="classes" /> </target>
En este caso dependemos de los frutos de compile y utilizamos la tarea jar que se encarga de empaquetar todo el contenido del directorio classes en el fichero proyecto.jar.
Finalmente incluiremos un nuevo objetivo para limpiar todo el entorno, el objetivo clean:
<target name="clean"> <delete dir="classes" /> <delete dir="build" /> </target>
A estas alturas es fácil entender que lo único que realiza es eliminar los directorios de trabajo dejando el entorno limpio del proceso de compilación.
Resumiendo nuestro fichero build.xml es:
<project name="Proyecto">
<target name="init">
<mkdir dir="classes" />
<mkdir dir="build" />
</target>
<target name="compile" depends="init">
<javac srcdir="src" destdir="classes" />
</target>
<target name="build" depends="compile">
<jar destfile="build/proyecto.jar" basedir="classes" />
</target>
<target name="clean">
<delete dir="classes" />
<delete dir="build" />
</target>
</project>
Y hasta aquí este minitutorial sobre el uso de ant 
Cifrando una partición con cryptsetup
Disponemos de un ordenador portátil (en este caso concreto una Kubuntu Gutsy) con una partición destinada a /home que queremos cifrar.
Esta solución no es de las más seguras, quedando por tratar temas importantes como el cifrado de swap, controlar la integridad del sistema y el correcto manejo de los ficheros temporales.
Los pasos son los siguientes:
- Ciframos la partición física con crypsetup y LUKS:
# cryptsetup luksFormat /dev/sda6
- Mapeamos lógicamente el dispositivo descifrado:
# cryptsetup luksOpen /dev/sda6 home
- Trabajamos como si fuera una partición normal:
# mkfs.ext3 /dev/mapper/home # mount -t ext3 /dev/mapper/home /home
Para realizar el montaje automático de la partición en el arranque es necesario modificar los ficheros /etc/crypttab y /etc/fstab:
- crypttab:
# <target name> <source device> <key file> <options> home /dev/sda6 none luks
- fstab:
/dev/mapper/home /home ext3 defaults 0 2
Con la configuración mostrada se pedirá la contraseña en el momento del arranque.
Podéis encontrar ejemplos más interesantes en la documentación de LUKS o simplemente buscando por Google.
Trac, gestión de proyectos
Trac es una herramienta de gestión de proyectos, principalmente de software, que unifica un sistema wiki con un sistema de seguimiento (issue tracking) con claras ventajas a la hora de trabajar con un repositorio de subversion.
Esta entrada constituye una breve guía de iniciación a Trac.
CVS: Manejando ramas
Hace algunos años publiqué una breve guía práctica de CVS, incompleta. Aprovechando que tengo algo de tiempo he decidido tachar este punto de mi lista de tareas
Creando una nueva rama
Antes de nada hemos de recordar que necesitamos una versión etiquetada, por ejemplo ‘v1_2′, sobre la que vamos a trabajar. Comenzamos extrayendo la versión a nuestro entorno de trabajo:
$ cvs checkout -d proyecto-1.2 -r v1_2 proyecto
Procedamos a crear la rama propiamente dicha:
$ cd proyecto-1.2
$ cvs tag -b v1_2-branch
El nombre de la rama es un gusto personal, yo prefiero añadir -branch aunque he visto -bugfixes o combinaciones de ambos.
Con estos simples pasos ya disponemos de una rama de desarrollo a la que podemos acceder, por ejemplo para hacer un cambio a la rama:
$ pwd
/home/chernando/proyecto
$ cvs up -r v1_2-branch
Si revisamos el estado de ‘main.c’ podemos ver que está incluido en una rama:
$ cvs -q status main.c
==================================================================
Working revision: 1.1.2.1 2007-03-07 19:06:39 +0100
Repository revision: 1.1.2.1 /tmp/repositorio/proyecto/main.c,v
Commit Identifier: QwJwh9fAP56fxb9s
Sticky Tag: v1_2-branch (branch: 1.1.2)
Sticky Date: (none)
Sticky Options: (none)
Importante fijarse en el cambio en la numeración, a partir de ahora en vez de avanzar con 1.X, se avanza con 1.N.X, siendo N la numeración de la rama.
Mezclando dos ramas
Bien, supongamos que queremos traernos cambios realizados desde una rama,’v1_2-branch’, a la principal. Muy fácil, haremos como si forzáramos un cambio de una versión anterior pero especificando la rama en vez de la revisión:
$ cvs update -j v1_2-branch main.c
RCS file: /tmp/repositorio/proyecto/main.c,v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into main.c
$ cvs commit -m 'Cambios desde la rama v1.2' main.c
Hay un problema: no podemos hacer esta jugada dos veces seguidas sin dar conflictos
Supongamos que queremos volver a traernos un cambio desde la rama ‘v1_2-branch’ con el comando update. El diferencial de cambios para hacer la mezcla se hace desde la base de la derivación de la rama, si ya hemos aplicado parte de ese diferencial en una actualización anterior provocará irremediablemente un conflicto.
La solución para evitar el engorro de trabajar con conflictos es utilizar una referencia de la rama justo después de traer los cambios. Dos opciones principales:
- Etiquetar la rama cada vez que se traen cambios de ellas, ‘v1_2- branch-fixes-1′.
- Utilizar las nociones de tiempo de CVS, ‘v1_2-branch:3 days ago’.
La idea intuitiva es la de señalar en el historial de la rama dos marcas de tiempo, la última que se llevo a la principal y el actual de la rama, y aplicar los cambios que se realizaron entre esos dos instantes en la rama en la principal. Por ejemplo:
$ cvs update -j v1_2-branch-fixes-1 -j v1_2branch
