Trabas

Uno de los culpables del calentamiento global es, sin duda, el cada vez más elevado consumo de energía por parte de los ordenadores. Y no solo por el CO₂ que se emite al generar esa energía, sino por el propio calor que los procesadores desprenden. Basta con entrar a una sala de servidores decentemente refrigerada y acercarse a los armarios de cálculo para comprobarlo.

Pero no solo de servidores vive el hombre, ni solo a ellos les afecta el calor. De hecho, a los ordenadores portátiles les afecta más. Es bastante común poner un portátil sobre una mesa (con lo cual sus patitas lo separan de ésta ligeramente). Y también ponérselo sobre las piernas en el sofá, delante de la tele, y cosas parecidas. Pero el detalle importante de estas actitudes es que los portátiles se refrigeran por debajo, y si bloqueamos esa entrada de aire, o es insuficiente, el portátil se recalentará.

Incluso un portátil colocado sobre una mesa, levantado por sus propias patas de goma, se recalienta si está trabajando en serio. Claro que mucha gente no lo nota porque sus portátiles no hacen cálculo numérico, solamente escribir cartas y leer correos, pero... ¿de verdad quieres ver tu portátil trabajando con el estrangulador al 12%? O peor, ¿quemado?

Si, como yo, pones tu portátil realmente a prueba, no necesitas comprar esos elevadores USB con ventilador tan monos que hay en muchos sitios a la venta... sobre todo porque aparte de costar dinero, el ventilador USB consume más aún la batería del portátil (o eleva la factura de la luz). No. Basta con cuatro trabas de la ropa.

Lo hemos hecho

Finalmente, lo conseguimos, y cumplimos con la fecha de San Valentín.

Debian 5.0 (antes conocida como «Lenny») ya está en la calle.

Ahora es tiempo de arreglar los fallos que surjan y trabajar en la siguiente versión, «Squeeze».

fam

Odio famd. Cada vez más.

famd es el «file alteration monitor», un demonio que se encarga de estar al tanto de las modificaciones que puedan sufrir los ficheros. Gracias a él, un proceso cualquiera, como puede ser un gestor de ficheros, no necesita preguntar constantemente al disco si han ocurrido cambios en un fichero, sino que simplemente puede encargarle a famd que le avise si dichos cambios se producen.

El problema es que a veces famd se vuelve loco y empieza a utilizar toda la CPU disponible, lo cual es, en general, un engorro, y en particular para un servidor, un problema.

He acabado por quitarlo.

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?

Servidor Subversion

Hace poco he instalado un servidor SVN para que distintas personas puedan alojar sus proyectos. Vamos a ver cómo lo he hecho.

El primer paso ha sido, evidentemente, instalar Subversion:

aptitude install subversion

Claro que, para que todos los colaboradores puedan contribuir, tienen que poder acceder a los repositorios. Para ello hay dos métodos, un servidor especializado (svnserve) y el bueno de nuestro querido Apache con web-DAV.

Dados los problemas que puede presentar el servidor especializado con respecto a cortafuegos, proxys y similares, y dado que de todos modos vamos a usar Apache, que además nos permitirá navegar por la versión más reciente de cada repositorio, o incluso descargarlo con herramientas del tipo de wget, hacemos:

aptitude install apache2

Y claro, necesitamos que Apache y Subversion se entiendan:

aptitude install libapache2-svn

El primer paso de decisión es colocar los repositorios. La elección obvia sería /var/svn pero también se pueden considerar otras opciones como /srv/svn o /usr/lib/svn o incluso /usr/local/lib/svn.

Así, dentro de /var/svn tendremos un subdirectorio para cada repositorio completo. Ahora hay que convencer a Apache de que nos los muestre. Para ello, en el mismo directorio creamos un fichero como éste:

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

<Location /svn/>
  # Repositorio Subversion vía WebDAV
  DAV svn

  # Cualquier petición "/svn/algo" corresponderá al repositorio /var/svn/algo
  SVNParentPath /var/svn

  # Permitimos el listado de repositorios
  SVNListParentPath on
</Location>

Con esta configuración ya podemos crear repositorios con

svnadmin create

y directamente los podremos utilizar desde otros ordenadores con órdenes del estilo de

svn co http://host/svn/repositorio

tanto para hacer checkout como commit.

¿O no?

Pues no. Hay dos detalles que se nos han quedado pendientes. El primero es que Apache no se entera de la existencia de ese fichero por arte de magia. Hay que decirle que hay un nuevo sitio disponible y que lo use:

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

Sí, ya sé que sites-available está para configuraciones de tipo VirtualHost, pero es que prefiero dejar las cosas limpitas.

El segundo detalle es que al crear un repositorio con

svnadmin create repositorio

no podremos realizar commit en él, ya que Apache no puede escribir en el directorio. Por ello, ejecutamos

chgrp -R www-data repositorio
chmod -R g+w repositorio

Claro que puede que a los colaboradores no les maraville que todas las versiones de todos los proyectos estén disponibles a todo el mundo, y menos aún con acceso de escritura. Así que hay que hacer algo con los permisos, pero ya no puede ser sobre los repositorios, porque quien accede a ellos es Apache. Así que lo que hacemos es decirle a él que se encargue de la autentificación de usuarios y de su autorización.

Para ello, cogemos el fichero /var/svn/repositorio_dav_svn.apache2.conf de antes y lo modificamos un poco:

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

# Esto es para evitar la incompatibilidad entre SVNListParentPath y AuthzSVNAccessFile
RedirectMatch ^(/svn)$ $1/

<Location /svn/>
  # Repositorio Subversion vía WebDAV
  DAV svn

  # Cualquier petición "/svn/algo" corresponderá al repositorio /var/svn/algo
  SVNParentPath /var/svn

  # Permitimos el listado de repositorios
  SVNListParentPath on

  # Fichero de control de acceso por repositorios y ramas
  AuthzSVNAccessFile /var/svn/authz

  # Orden de prueba de usuarios
  Satisfy Any
  Require valid-user

  # 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>

Hemos añadido cuatro piezas nuevas. La primera es para evitar un problema con las autentificaciones que puede surgir si se trata de ver el listado de repositorios, y las otras tres, ya dentro de la Location, configuran la autentificación y la autorización.

Ojo, que ese RedirectMatch está para algo, y es que AuthzSVNAccessFile da problemas si la barra final no está, así que es muy importante que la Location diga algo como <Location /svn/> y no <Location /svn> sin la barra final, aunque eso sea lo que viene en la documentación.

La autentificación es el último bloque. En él decimos que queremos que las contraseñas viajen cifradas (AuthType Digest), qué Reino de Autentificación (conjunto de dominios y subdirectorios en ellos) está en juego (es una manera de separar los accesos para distintos sitios con el mismo nombre de usuario, y también de agruparlos), que el cliente utiliza para no requerirnos cada vez el nombre de usuario y la contraseña (AuthDigestDomain http://miservidor/svn/), el nombre del Reino de Autentificación (para que el usuario sepa a qué corresponden el nombre de usuario y contraseña que debe introducir) que el cliente normalmente nos mostrará en el formulario (AuthName "Repositorio Subversion de miservidor") y, finalmente, en qué fichero almacenamos las parejas nombre de usuario-contraseña (AuthUserFile /var/svn/passwd-digest).

Este fichero hay que crearlo con la orden htdigest. Y ojo, que como vamos a utilizar autentificación por digest tenemos que activar el módulo correspondiente de Apache:

a2enmod auth_digest

Los otros dos bloques son el control de acceso. La parte

  # Orden de prueba de usuarios
  Satisfy Any
  Require valid-user

hace que el acceso sin identificarse sea posible allí donde esté permitido. Si no lo ponemos, será imposible incluso acceder a la lista de repositorios sin identificarse. La otra parte simplemente indica qué fichero tiene la lista de control de acceso, es decir, qué nombres de usuario tienen permitido el acceso de lectura o de escritura a cada repositorio y a cada directorio de cada repositorio (AuthzSVNAccessFile /var/svn/authz). Este fichero tiene aproximadamente este aspecto:

# Fichero /var/svn/authz

# Acceso de lectura libre a todos sitios
# (es decir, al listado de repositorios) para todos
# y acceso de escritura al administrador del sitio
[/]
administrador = rw
* = r

# Permisos particulares para el repositorio repo1
# Añadimos permiso de escritura para algunos usuarios
# y quitamos el permiso de lectura para el usuario sin identificar
[repo1:/]
repo1admin = rw
repo1colaborador = rw
* =

# Quitamos el permiso de lectura al colaborador en determinado directorio
[repo1:/privado]
repo1colaborador =

Por supuesto, esta estructura puede complicarse bastante, y además los usuarios se pueden organizar en grupos. Hay más información en http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html.

Y adelante, ya tenemos un servidor Subversion preparado para aguantar lo que le echen.