Cambiando de gestor de ventanas

Tan solo un rápido apunte. El gestor de ventanas es la parte del X Window System que se encarga de gestionar las ventanas, su posición y su decoración. Prácticamente siempre que tengas abierta una sesión de las X, tendrás un gestor de ventanas funcionando.

Y los gestores de ventanas se pueden sustituir unos a otros. Los gestores de ventanas decentes aceptan una opción --replace que les dice "si hay otro gestor de ventanas ejecutándose, ciérralo y ponte en su lugar, si puedes". Y también, los gestores de ventanas decentes reconocen que otro gestor de ventanas quiera reemplazarlos y saben quitarse limpiamente del camino y dejarle el sitio al nuevo.

Lamentablemente, no todos los gestores de ventanas son decentes.

Así que se planeta la pregunta de cómo, por ejemplo, ejecutar KDE con un gestor de ventanas que no sea kwin.

Y la respuesta es que hay que definir la variable de entorno KDEWM (por ejemplo en el .profile) con el nombre del gestor de ventanas que queramos ejecutar. Si la variable no está definida, se utilizará kwin.

Servidor Subversion (y II)

Si hace doce días indicaba cómo configurar un servidor Subversión mediante Apache, hoy redondeo la jugada.

Una de las ventajas de utilizar WebDAV como tecnología subyacente es que se puede acceder al repositorio Subversion con un navegador normal y corriente. De hecho, como se pueden incluso montar «carpetas» WebDAV como directorios locales, es posible tener un sistema de ficheros versionado con SVN de manera transparente al usuario.

Pero el navegador normal y corriente, al contrario que las herramienta especializadas en Subversion, no puede acceder a todas las revisiones del repositorio. Tan solo a la última. Así que para que el usuario pueda acceder al código utilizando su navegador, algo normal si queremos, por ejemplo, publicar el código, serán necesarias herramientas adicionales. En este caso, ViewVC, que es una aplicación CGI para mostrar mediante el servidor web repositorios CVS o SVN.

Así que el primer paso es, de manera harto natural, instalarlo con sus dependencias:

aptitude install viewvc

Y el segundo, de manera igualmente natural, decirle a Apache que utilice ViewVC como un CGI cuando se le soliciten determinadas rutas, las que utilizaremos para publicar el código. Esto lo haremos, igualmente, mediante un fichero de configuración específico que haremos residir también en /var/svn:

#Fichero /var/svn/repositorio_viewvc_svn.apache2.conf

# Esto es para evitar que los usuarios vean que ViewVC es un CGI
ScriptAliasMatch ^/viewsvn(.*) /usr/lib/cgi-bin/viewvc.cgi$1

Bastante sencillo, ¿no?

Claro, hay que tener en cuenta que, si habíamos preparado un sistema de control de acceso mediante SVN, no podemos ahora dejar que cualquiera vea cualquier revisión de cualquier fichero. Esto no nos preocupará si las limitaciones que habíamos puesto eran solamente para la escritura, pero sí deberá importarnos si pusimos restricciones de lectura. En ese caso el fichero crece un poco:

#Fichero /var/svn/repositorio_viewvc_svn.apache2.conf

# Esto es para evitar que los usuarios vean que ViewVC es un CGI
ScriptAliasMatch ^/viewsvn(.*) /usr/lib/cgi-bin/viewvc.cgi$1

<Location /viewsvn>
  # Repositorio Subversion vía ViewVC

  # Método de autenticación y fichero de contraseñas
  AuthType Digest
  AuthDigestDomain http://miservidor/svn/
  AuthName "Repositorio Subversion de miservidor"
  AuthUserFile /var/svn/passwd-digest
</Location>

Include /var/svn/auth-viewvc

Suena, ¿no? Bastante parecido (de hecho, idéntico) a la configuración de autenticación para DAV-SVN. Lo que cambia es la configuración de autorización, que ahora debe manejar el propio Apache, y estará en el fichero /var/svn/auth-viewvc, que acabamos de incluir, al estilo de Apache:

#Fichero /var/svn/auth-viewvc
<Location /viewsvn/repo1>
  Require user repo1admin repo1colaborador
</Location>

<Location /viewsvn/repo1/privado>
  Require user repo1admin
</Location>

Y bien, en dos pasos acabado. El primero es, como la otra vez, enlazar el fichero de configuración en el Apache y activarlo:

ln -s /var/svn/repositorio_viewvc_svn.apache2.conf /etc/apache2/sites-available/repositorio_viewvc_svn
a2ensite repositorio_viewvc_svn
apache2ctl graceful

Y ya funciona. El segundo paso final es configurar ViewVC para que acceda a nuestro repositorio. Para ello tenemos que editar el fichero /etc/viewvc/viewvc.conf y tocar algunas cosas.

No voy a poner el fichero completo, pero sí detallar los cambios mínimos necesarios para que funcione como deseamos:

cvs_roots =
#Hay que vaciarlo

root_parents = /var/svn : svn
#Éste hay que descomentarlo y completarlo

address = <a href="mailto:cvs-admin@insert.your.domain.here">No admin address has been configured</a>
#Se debería poner aquí la dirección del Administrador

root_as_url_component = 1
Hay que cambiarlo para que funcionen nuestro control de acceso y nuestras redirecciones

Y listo: ya tenemos un precioso servidor de ficheros SVN vía web.

Comprar nuevo no es necesario.

El ordenador que estuve limpiando en noviembre venía arrastrando otros fallos, que resultaron ser del procesador. Igual precisamente por exceso de polvo se sobrecalentó en parte.

El caso es que tuve que cambiar el procesador, y ya no es sencillo encontrar procesadores para un zócalo 462 (el «socket A») de AMD.

El problema es que mi placa base es una Asus A7V8X que admite procesadores de hasta 2,4GHz , pero en «la tienda de la esquina» conseguí un Athlon XP 2600+. Y éste tampoco fue bien.

Finalmente, conseguí también un Athlon XP 3000+, que en realidad va a 2,1 GHz (el número del modelo no son los GHz), y poniendo adecuadamente la pasta térmica, he conseguido una máquina que a día de hoy lleva un uptime de 30 días. Nada mal para un procesador de segunda mano en una placa usada 24x7, que es hoy mi servidor de correo y páginas web (y varias cosas más), aparte del ordenador de escritorio de mi esposa.

¿De verdad hace falta comprar un ordenador nuevo completo cada vez que cierta empresa de Redmond saca una nueva versión?