Elucubrando

Como parte de la gran campaña Nul Unu para la mejora de los procesos (hola, Daniel), acabo de instalar un depósito central de subversion y una instalación generica de Trac para los proyectos. La intención es

• Tener un control de los problemas y faltantes por cada proyecto.
• Tener un punto central para la documentación.
• Coordinar estas cosas con el control de versiones.

Ahora bien, como en cada proyecto participan diferentes personas, necesito tener controles de acceso más o menos finos. Y sería bueno que dichos controles estuvieran coordinados entre subversion y Trac. Entonces, documentando para la posteridad, a continuación mis elecciones de configuración para lograr eso:

1. Todo debe quedar, por supuesto, en un servidor público. Por razones de llevarse bien con el proveedor, nuestro servidor usa RedHat. Enterprise 4, creo.
2. Los controles de acceso finos requieren, o que use subversion via Apache, o svnserve pero con subversion 1.3. Usar apache significa darle permisos de leer y escribir en el depósito al usuario apache. En un servidor con mucho PHP. Eso es una muy mala idea, así que nos vamos por svn1.3. Como RHES4 tiene 1.1.algo, tenemos que instalarlo aparte. Afortunadamente para mi salud mental, alguien ya hizo paquetes de subversion, así que nada de andar compilando e instalando a mano.
3. El punto malo de svnserve es que el protocolo no tiene opción para cifrar la comunicación. Hay dos formas de darle la vuelta a esto. O usamos svn+ssh, o usamos stunnel para encapsular el protocolo. Por ahora me fuí con stunnel, pero los métodos no son exclusivos, así que si veo que eso causa problemas intentaré lo del ssh. (¿Problemas, se preguntan? Pues sí, por que usar stunnel requiere que se configure en ambos extremos. Mi experiencia me dice que pedirle a personas externas que lo hagan en sus propias máquinas puede ser complicado. Por otro lado, ssh requeriría que configuren el acceso usando llaves públicas.)
4. Hecho esto, genero un archivo de usuarios/contraseñas, lo pongo en un lugar accesible al svnserve y refiero la configuración de todos los depósitos a ese mismo. ¡Autenticación centralizada!
5. Lo cual nos lleva al “todos los depósitos”. En realidad, en vez de colocar un depósito central, coloqué infraestructura para poner fácilmente un depósito por proyecto, accesibles todos con URLs similares. Eso permite controlar más fácilmente el acceso si hay situaciones especiales. Permite también simplificar la creación de respaldos y permite eliminar depósitos que se dejen de usar.
6. Todos los depósitos se crearán usando fsfs y no db. Tiene un manejo más sencillo de los permisos.
7. Ahora, Trac. Para esto no hay RPMs, así que hay que instalar a mano. Afortunadamente checkinstall nos permite generar un paquete que enlista lo que fué instalado. Antonces, aunque queden paquetes medio feos, sin dependencias y sin adecuarse muy bien al sistema, por lo menos hay un registro de qué se instaló dónde y como quitarlo.
8. Usamos SQLite como base de datos. Más fácil de instalar y respaldar que usar PostgreSLQ. Y de cualquier forma, no creo que vayamos a tener en esta infraestructura proyectos con miles de bugs o algo así.
9. La comunicación de Trac con el mundo está por ahora, con FastCGI. Pero esto tiene el problema de que obliga a darle al usuario de apache permiso de lectura a los depósitos de svn y de escritura a los de trac. Para evitar eso, próximamente(MR), cambiaremos a usar tracd corriendo como un usuario con privilegios reducidos, y lo expondrémos al mundo via mod_proxy.
10. Trac no lo vamos a colocar tras https. Eso hace difícil colocar todo tras un dominio virtual. Entonces, para por lo menos no andar mandando contraseñas en claro, usamos autenticación ‘Digest’. Las contraseñas para este método se guardan cifradas con MD5, mientras que las de subversion están en texto claro. Entonces declaramos la lista de subversion como la maestra y generamos la de apache a partir de ahí.

Puntos a revisar:

1. Todavía no acabo de entender los puntos finos de la autorización en svnserve. Y al parecer hay algunos bugs extraños en la implementación. Sería bueno que se pudieran incluir secciones comúnes.
2. Hace falta diseñar e implementar un mecanismo para los respaldos. Hay que determinar la frecuencia y cuanto tiempo queremos guardarlos.