Desbitácora de Envite

Buenos y malos

2012-01-18T22:20:00.000Z

Hasta ayer Internet se dividía en dos grupos: con ánimo de lucro (como Twitter) o sin (como identi.ca). La división no es clara, porque servicios como Twitter o Google no cobran a sus usuarios, pero son empresas con ánimo de lucro. Facebook, evidentemente, entre los primeros. Wikipedia entre los segundos. eBay entre los primeros, OpenStreetMap entre los segundos.

Básicamente era una división entre los "puntocom" y los "puntoorg".

Ya no. A partir de hoy Internet se divide entre buenos y malos: los que luchan, como pueden dentro de sus estrategias empresariales o de proyecto, contra SOPA y PIPA (como Google) y los que las apoyan (como Facebook).

Y digo hoy porque hoy los primeros han tenido la decencia de cerrar, en todo o en parte, sus páginas web en protesta.

Quiero que mis servicios me los den los buenos, y sólo en segundo lugar elegiré entre los sin ánimo de lucro.

Dos conexiones a internet

2011-07-25T17:39:00.000+01:00

Pues eso, como Ono me da 12 megas pero no me da IP fija, y Tele$ónica (ahora la llaman Movistar) me da 1 mega pero con IP estática, pues me he abonado a ambas y aprovecho las dos tarjetas de red de mi ordenador, una para navegar, etc. y la otra para mis servidores al exterior. Es bastante sencillo.

Para empezar, identifiquemos las tarjetas: eth0 es la de navegar, 12 megas con IP dinámica, eth1 es la de los servidores, 1 mega con IP fija.

Para seguir, identifiquemos las redes y asignemos direcciones IP internas: eth0 tiene la IP 192.168.2.25 con pasarela en 192.168.2.1, mientras que eth1 tiene la IP 192.168.1.25 con pasarela en 192.168.1.1.
Así los unos coinciden, y no hay pérdida: la red 1 en la tarjeta 1.

Ahora es cuando viene el problema: si pongo una pasarela (gateway) todos mis paquetes saldrán por ahí, así que los que hayan entrado por la otra tarjeta saldrán con una dirección IP errónea: o no navego, o no sirvo. Y si pongo dos pasarelas el núcleo hará salir cada paquete por donde le apetezca: ni navego ni sirvo.

Así que mirando la documentación y teniendo (esto es muy importante) una idea clara de lo que quería, descubrí la solución: necesitaba una tabla de enrutamiento distinta.

Manos a la obra:

ip permite tener más de una tabla de enrutamiento, y van por número, así que creé la tabla 1 (para no variar, los unos con los unos):

ip route add table 1 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.25 
ip route add table 1 default via 192.168.1.1 dev eth1

Ahora una regla que haga que todos los paquetes que salen de 192.168.1.25 usen esa tabla de enrutamiento y no otra:

ip rule add from 192.168.1.25 lookup 1

Pónganse las tres líneas juntas, hágase que se ejecuten al levantar eth1, y listo.

Redirigir el correo de root en Postfix

2011-01-23T18:49:00.000Z

Hoy he tenido que instalar Postfix para una máquina en la que el correo de root hay que entregarlo remotamente. Y es un problema, pero encontré la solución.

Se trata de convencer a Postfix de que su dominio principal es un dominio virtual tocando el /etc/postfix/main.cf:

virtual_alias_domains = midominioprincipal.org
virtual_alias_maps = hash:/etc/postfix/virtual

y luego decirle que determinado usuario de ese dominio debe ver su correo redirigido a una dirección externa:

root usuario@receptor.org

Luego basta con

postmap /etc/postfix/virtual && postfix reload

Comprar e instalar una impresora: elige siempre HP

2010-12-30T13:04:00.001Z

Hoy he tenido que devolver una impresora que compré para mi suegro, una Canon PIXMA MP252, porque no iba bien con Linux. Menos mal que eso lo descubrí foreando y no por experimentación propia, porque no hubiera podido devolverla. Por sólo 14 euros más, le compré una HP Photosmart C4600: en un cuarto de hora ya estaba imprimiendo, escaneando y copiando. Bastó con un apt-get install hplip y se autoinstaló solita.

Por eso me gusta apoyar a los fabricantes que apoyan a Linux.

Subir a 6Mb (y cuarto paso)

2010-12-07T11:41:00.000Z

Finalmente, tras tener ya la conexión de 6Mb y ver que mantenga la dirección IP estática de antes, todo ha sido cosa de volver a poner los servicios en casa y nuevamente sufrir a Nominalia para cambiar los DNS raíz de mi registro.

En fin, todo en orden.

Dejar KDE

2010-11-15T21:31:00.000Z

Al final ha ocurrido: me he cansado de que KDE se coma mi memoria y me he pasado a Gnome. Lo peor: que seguiré usando las aplicaciones de KDE, pues (en general) intentan hacerme quedar como estúpido menos veces.

Subir a 6Mb (tercer paso)

2010-11-13T14:59:00.001Z

Pues en fin, que tras un par de estupideces o incompetencias por parte de los repartidores, me llegó un módem ADSL nuevo (un SAGEM F@ST™ 2604 capado para que solamente se pueda utilizar con redes de Orange y socios) con cuatro puertos Ethernet y red wifi. Aunque no lo necesito, pues mi NETGEAR DG834v3 comprado a tocateja funciona perfectamente y coge la nueva velocidad, pero en fin. Como no tiene wifi, me quedaré el nuevo y el NETGEAR se lo dejaré a alguien que lo necesite.

Resumiendo: que ya tengo mi nuevo ADSL en marcha.

Montar un dispositivo FAT en modo shortname=lower

2010-11-12T20:32:00.000Z

Hace cierto tiempo el modo de montar los dispositivos de tipo vfat cambió en Linux: pasó de ser shortname=lower a shortname=mixed. Un cambio necesario, ya que con el anterior todos los nombres de fichero se mostraban en minúsculas, y los nuevos se escribían en minúsculas en el dispositivo, lo cual era ciertamente un problema a la hora de utilizar dispositivos con canciones. El problema viene porque quien utilizó rsync con el modo anterior, por ejemplo para hacer copias de seguridad de o en un disco duro vfat, se encuentra ahora conque los nombres que antes estaban siempre en minúsculas ahora están a veces en mayúsculas, con lo que al no ser ya los mismos nombres el programa de copias no hace lo que se esperaba.

El problema es que no hay manera de cambiar esto en HAL: se supone que se podía usando un fichero fdi como el siguiente:

<?xml version="1.0" encoding="UTF-8"?><!-- /etc/hal/fdi/policy/preferences.fdi -->
<deviceinfo version="0.2">
  <device>
    <match key="volume.fstype" string="vfat">
      <merge key="volume.policy.mount_option.shortname=lower" type="bool">true</merge>
    </match>
  </device>
</deviceinfo>

pero no funciona: el sistema de volume.policy.mount_option está desaconsejado por los propios desarrolladores de HAL, que dicen que este tipo de cosas (las opciones de montaje) las debería especificar el entorno de escritorio, y no una política.

Así que he tenido que irme al /etc/fstab a ponerlo allí, pero claro, nadie garantiza que un dispositivo vfat tenga un UUID, ¿no?

Finalmente ha quedado así:

/dev/disk/by-id/usb-OLYMPUS_D555Z_C315Z_000J03011507-0:0-part1 /media/olympus vfat users,rw,nosuid,nodev,uhelper=hal,utf8,shortname=lower,flush 0 0

y no sé si eso es bueno o malo: lo que sí sé es que he tenido que crear el punto de montaje, y que no se desmonta bien desde el escritorio.

Subir a 6Mb (interludio)

2010-10-27T20:56:00.000+01:00

Por alguna razón (que aún no comprendo del todo) mi nuevo servidor se caía repetidamente. Puede ser culpa (en parte) del hardware: viejo y lleno de polvo; puede ser también culpa de la línea ADSL de allí, cerca del límite de distancia; puede ser también cosa del enrutador ADSL, que es verdaderamente viejo (con decir que no tiene interfaz web sino tan solo telnet); puede que sea culpa de la instalación de cobre de la casa (oxidada en sitios, húmeda en otros, y mal mantenida); o puede, en fin, que sea cosa de todo lo anterior junto.

Pero sí ocurría que a veces el ordenador en cuestión (el factor 1, el «jargüar») se quedaba bloqueado (cosa que empezó a hacer allí). Quizá el viaje le echó un meneo al polvo, quiero decir, el viaje meneó el polvo.

Así que cogí un microportátil con una Debian recientita (una testing de hace un mes), le instalé el Bind, Postfix y el Courier, copié las configuraciones del polvoriento, y a correr.

De momento, funciona.

Seguiremos informando.

Subir a 6Mb (segundo paso)

2010-10-26T10:20:00.003+01:00

Pues bien, una vez que tengo los DNS correctamente apuntados a un servidor paralelo (aunque solamente funcionen bien allí los servidores de nombres (DNS) y de correo), ha llegado el segundo paso: llamar a mi ISP (Proveedor del Servicio de Internet) y decirle que ya puede pasar mi ADSL de 1Mb/150Kb a 6Mb/300Kb. Vamos a ver cuanto tarda Orange (la verdad que hoy han sido muy amables y, al parecer, eficientes) en efectuar el cambio, y vamos a ver si pierdo mi dirección IP estática por el camino.

Seguiremos informando.

Subir a 6Mb (primer paso)

2010-10-25T19:02:00.001+01:00

Estoy intentando subir mi conexión casera de 1Mb/150Kb a 6Mb/300Kb y, como supondrán, no quiero quedarme sin recibir correo durante el proceso. Y como en el cambio puede que tenga un corte de conexión o, incluso, pierda la IP fija durante un período de tiempo de hasta 15 días, pues el primer paso ha sido montar un servidor de correo en otro sitio por ahí con IP fija (gracias papi) y decirle a los DNS que manden el correo allí.

Y ese ha sido el problema: Nominalia ha tardado cinco días y medio en pasar a los servidores raíz para el primer nivel el cambio de servidores autorizados para mi dominio (de segundo nivel).

En fin... seguiremos informando.

Centralizar los datos de kstars

2010-09-13T18:22:00.006+01:00

Kstars es el proyecto de un planetario para KDE. Funciona bastante bien, pero hay un pequeño detalle que puede llegar a molestar: la opción "Obtener nuevos datos" está disponible para cada usuario, así que los catálogos e imágenes (algunos de los cuales ocupan 2GiB) corren el riesgo de ser descargados individualmente por cada usuario. Esto, en un ordenador de un aula de astronomía, por ejemplo, significa un montón de espacio desperdiciado, y un montón de ancho de banda gastado en descargar cosas que ya se tienen.

Tras una pequeña charla con gente de KDE, he encontrado el lugar y la manera de evitarlo, centralizando los datos y usando el kiosk mode de KDE para evitar que los usuarios puedan descargarse los datos.

Espero, ahora, ponerme a hacer un paquete Debian que centralice el caso. A ver si me sale bien.

El botón de apagado

2010-09-10T22:04:00.003+01:00

Ya he comentado alguna vez que no me gusta el polvo. El polvo en los ordenadores, se entiende. Y hoy, por tercera o cuarta vez, pasando una brocha (una simple brocha) por mi ordenador nuevo para quitarle el polvo ambiente, se apagó. Eso es lo que se llama tener un botón de encendido muy sensible, tanto que ahora lo llamo «botón de apagado».

Así que ni corto ni perezoso, y sabiendo que voy a seguir pasando la brocha o incluso un paño para limpiar el polvo externo de vez en cuando, me he metido en la carcasa y he tirado de los cables blanco y rojo, para desconectar de la placa base el susodicho interruptor.

Descargar enlaces ed2k:// desde Firefox (II)

2010-09-07T01:16:00.002+01:00

Hace aproximadamente un año y medio escribí este artículo sobre cómo registrar un nuevo protocolo en Iceweasel (más conocido por ahí como Firefox).

Pero con la llegada de Firefox 3 las cosas han cambiado y el método ya no funciona. Pero la solución es parecida: se trata de añadir a mano un a nueva clave booleana, network.protocol-handler.expose.ed2k, y darle como valor false. La siguiente vez que pulsemos un enlace ed2k:// nos preguntará la aplicación que queremos usar, y ahí buscaremos /usr/bin/ed2k en el árbol de directorios.

Y claro, lo mismo vale para cualquier otro protocolo que queramos.

Todo viene (más o menos) explicado en http://kb.mozillazine.org/Register_protocol.

Leer una base de datos Berkeley DB

2010-08-30T20:21:00.005+01:00

Muchísimas aplicaciones utilizan bases de datos BerkeleyDB, y no hay (que yo sepa) ninguna aplicación específicamente diseñada para ver el contenido de éstas. Así que busqué un lenguaje de programación que me permitiera trabajar rápidamente con ellas y encontré que la papeleta me la resolvió PHP:

error_reporting(E_ALL);
$id = dba_open("file", "r", "db4");
var_dump($id);
$key = dba_firstkey($id);

while ($key != false) {
    if (true) {          
        $handle_later[] = $key;
    }
    $key = dba_nextkey($id);
}
echo("\n");
foreach ($handle_later as $val) {
$string=dba_fetch($val,$id);
echo("$val||$string\n");
}

Sobre la posible responsabilidad de la Administración Pública en un programa desarrollado mediante un modelo libre (aspectos técnicos)

2010-08-25T08:48:00.002+01:00

El modelo de trabajo en dos fases, con repositorio a cargo de la comunidad de desarrolladores y versiones oficiales a cargo de la A. P. es fácilmente implementable en los sistemas de «forja» de código actuales, y con poca dificultad en cualquier otro que se desee. Por ejemplo, el sistema ya existe en la forja de OSOR.eu. A tal fin se distingue entre tres formas de obtener el código:

A través de los medios propios del repositorio o a través de su interfaz web

En forma de bola 'tar' o archivo comprimido generado automáticamente por la forja

En forma de bola 'tar', archivo comprimido o paquete (fuente o binario) creado por los desarrolladores propios de la A. P.

En los dos primeros casos el usuario obtiene una versión del código que se considera, a todos los efectos, como inestable o de desarrollo. En el tercero, el código obtenido se considera, a todos los efectos, código publicado por la A. P.

A modo de ejemplo, véase el proyecto SEXTANTE de la Junta de Andalucía alojado en OSOR.eu que nos proporciona los tres modos:

El acceso a través de

svn checkout https://svn.forge.osor.eu/svn/sextante

o a través de

http://forge.osor.eu/plugins/scmsvn/viewcvs.php/?root=sextante

La descarga de
```
http://forge.osor.eu/snapshots.php?group_id=13
```
enlazada desde http://forge.osor.eu/scm/?group_id=13 e identificada como «copia nocturna»

Los ficheros presentados en http://forge.osor.eu/projects/sextante/

Los casos a) y b) quedan claramente al alcance de cualquiera, pero sin embargo quien obtiene el código por dichas vías es plenamente consciente de que obtiene código no necesariamente comprobado, mientras que el caso c) es el resultado del esfuerzo consciente por parte de ciertos desarrolladores en empaquetar una versión determinada del código.

De esta manera, el flujo de trabajo comienza con desarrolladores que realizan cambios en el código y añaden tales cambios al repositorio. Según la confianza que se tenga en dichos desarrolladores, podrán añadirlos directamente a la rama «tronco» del repositorio o no, pero en cualquier caso dichos cambios son parte de la base de código desde ese mismo momento. Nótese que la responsabilidad es puramente personal del desarrollador que realiza el cambio, y que no se trata necesariamente de personas responsables ante la A. P.

El flujo continúa con la evaluación de dichos cambios por parte de dos grupos, los usuarios que decidan obtener esa versión del código y probarla, y con ello informar de posibles fallos o regresiones de código, y los restantes desarrolladores que decidan hacer una «revisión por iguales» del cambio y, en su caso, portarlo a otras ramas del repositorio.

El siguiente paso es que uno de los desarrolladores que sí tienen la responsabilidad ante la A. P. de seleccionar el código aceptable para su publicación haga una revisión de una serie de cambios al «tronco» del repositorio y publique una nueva versión oficial del programa. Es en este punto, y solamente en éste, donde aparece la responsabilidad de la A. P. ante los usuarios.

Queda el caso puntual de las versiones inestables oficiales, entendiendo por tales las versiones «candidatas para la liberación» que se publican por muchos proyectos, tanto libres como privativos. Dichas versiones son necesarias, casi imprescindibles, para probar el código antes de liberarlo, pero suelen publicarse de la misma manera que las versiones oficiales. Suelen contener una indicación clara de su estado no definitivo, como las letras 'rc' (Release Candidate) o el indicativo 'beta'. Sin embargo, el publicarlas de la misma manera que las versiones oficiales definitivas puede tomarse, con un poco de mala fe o de ineptitud, como indicativo de que se encuentras endosadas por la A. P.

El caso con estas versiones es que efectivamente se trata de versiones publicadas oficialmente, ya que es código que ha sido comprobado por los desarrolladores de confianza. En ese sentido la A. P. es responsable de la publicación de una versión inestable, pero es el usuario el responsable de haber elegido esa versión para su descarga estando disponible una versión estable oficial aunque sea más antigua: ningún usuario puede aducir que descargó una versión 'rc', 'beta' o '0.x' sin saber que se trata de versiones de prueba. Para reforzar este punto, versiones tales no deben presentarse en la página principal del proyecto, pero sí en la página de versiones liberadas de la forja. No es un problema que aparezcan en la zona de noticias de la página principal del proyecto si se presentan como versiones de prueba.

La diferencia presentada entre código en el repositorio y código publicado oficialmente hace posible el modelo de comunidad en el que la única normativa para ser considerado como desarrollador es haber contribuido con código válido.

warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory

2010-08-24T01:59:00.004+01:00

Configurando la autenticación de mi servidor de correo Postfix con Cyrus SASL2 me encontré con que no funcionaba: el fichero /etc/sasldb2 estaba en su sitio y con los permisos correctos, pero no había manera.

Esta página de Matthew Chapman me dio la pista de lo que pasaba (y, consecuentemente, la solución): la biblioteca Cyrus SASL2 se mete en una jaula chroot en /var/spool/postfix antes de comprobar si /etc/sasldb2 existe, y por ello aunque exista correctamente, no lo encuentra.

La solución creando un enlace simbólico no funciona, ojo, porque desde dentro de la jaula chroot resulta que /etc/sasldb2 se apuntaría a si mismo. Por lo tanto, hay que copiar el fichero, o crear un enlace duro si quieres olvidarte de actualizar la copia en la jaula cada vez que cambies el original:

ln /etc/sasldb2 /var/spool/postfix/etc

Mover descargas entre instalaciones de aMule

2010-08-20T23:11:00.002+01:00

Tenía, en un disco duro que ya no uso para eso, un .aMule con su configuración y todo lo demás, incluido su Temp, que contiene los ficheros de las descargas parciales.

Hoy probé a mover esas descargas parciales (los ficheros *.part, *.part.met, *.part.met.bak y *.part.met.seeds, que contienen, respectivamente, los datos descargados, la información de la descarga, una copia de seguridad de ésta, y una lista de fuentes cuando son escasas.

He comprobado que simplemente moviendo estos ficheros al .aMule/Temp que uso ahora, renombrando aquellos cuyo número de serie coincidía con un grupo ya existente, la cosa funciona perfectamente.

Ojo, eso sí, hay que usar la misma numeración para los que tenían la misma numeración. Así, si tienes que mover 001.part, 001.part.met y 001.part.met.bak, y ya existen esos nombres en el Temp de destino, los puedes llamar 901.part, 901.part.met y 901.part.met.bak pero no 901.part, 902.part.met y 903.part.met.bak.

Sobre la posible responsabilidad de la Administración Pública en un programa desarrollado mediante un modelo libre

2010-08-17T17:59:00.002+01:00

Si una Administración Pública distribuye un programa libre, tiene cierta responsabilidad con los usuarios del mismo incluso en el caso de que la propia Licencia del programa indique lo contrario, ya que, al contrario que un distribuidor cualquiera, una A. P. sí tiene una obligación legal real de velar por los receptores del programa, que son sus ciudadanos. Dicha responsabilidad puede ser mayor aún en el caso de que el usuario del programa sea la propia A. P. de modo tal que un problema en el programa suponga para aquélla la pérdida de datos de los ciudadanos o cualquier otro resultado que les perjudique.

Al mismo tiempo, crear un programa al modo de los proyectos libres implica que varias personas (los desarrolladores en quienes se tiene confianza suficiente como para permitirles acceso de escritura al repositorio), algunas de las cuales no tendrán ningún tipo de relación contractual directa ni indirecta con la A. P. que promocione el programa, podrán realizar cambios al mismo, algunos de los cuales pueden ser perjudiciales, bona fide o maliciosamente.

Parece entonces que llegamos al dilema cruel de que una A. P. debe renunciar a liberar un programa y desarrollarlo a través de una comunidad o aceptar la responsabilidad de un programa que no se encuentra bajo su control.

Sin embargo, se trata de un falso dilema, ya que hay un paso intermedio entre el desarrollo y la publicación, que es el punto en el que la A. P. puede intervenir a fin de controlar el proceso conforme a su responsabilidad sin correr el riesgo de molestar a la comunidad de desarrolladores con injerencias. Dicho punto es la liberación de versiones oficiales del programa.

El flujo de trabajo correcto para bordear adecuadamente el problema es:

que los desarrolladores trabajen libremente, hasta el punto en que tal cosa sea posible para que el programa no se aleje de las especificaciones, en el repositorio de código

que un grupo seleccionado de desarrolladores, responsables ante la A. P. (funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.), seleccione regularmente el código de la rama «tronco» del repositorio, lo empaquete (a modo de paquete fuente o de paquetes fuente y binario) y lo publique

De este modo, los usuarios que lo deseen pueden obtener las versiones de desarrollo del código, lo cual es imprescindible para la detección de fallos en el mismo y su mejora, sin responsabilidad para la A. P., y ésta puede proporcionar versiones oficiales que hayan pasado el filtro de los desarrolladores contratados, con plena responsabilidad.

Es conveniente, pero no necesario, que la distinción entre estas dos maneras de proporcionar el código sea patente en la interfaz web del repositorio de código, con una mención del tipo «[La A. P.] no se hace responsable de los posibles fallos de estas versiones de desarrollo y niega toda responsabilidad sobre el mismo. Si no es usted un usuario avanzado, por favor utilice las versiones oficiales que puede encontrar en [sitio web].».

Ante un problema real que se produzca como consecuencia del uso del código, la estrategia de defensa de la A. P. debe variar en función de que dicho fallo se produzca en un código obtenido del repositorio o en un programa de la distribución oficial.

En el primer caso, la A. P. debe negar toda responsabilidad, indicando que el usuario sabía lo que hacía al descargar una versión de desarrollo, e indicando que el usuario asumió toda la responsabilidad al usar la interfaz web del repositorio de desarrollo del código (si lo hizo así) o indicando que el usuario era plenamente consciente del peligro de utilizar una versión de desarrollo, ya que es inconcebible que un usuario lo suficientemente avanzado como para utilizar el repositorio sin usar su interfaz web no lo sea.

En el segundo caso, la A. P. debe aceptar la plena responsabilidad por el perjuicio causado, ya que es, al menos, responsable civil subsidiario, pero al mismo tiempo debe averiguar qué desarrollador aceptó el cambio en el código que causó el problema e iniciar las acciones penales y, en su caso, disciplinarias adecuadas, ya que sin duda se trata de uno de los «desarrolladores de confianza» plenamente identificados por ser funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.

Usuario que reparte el correo

2010-08-13T21:47:00.003+01:00

Me ha costado un buen rato ver qué pasaba, pero lo he conseguido.

Tengo una máquina que recibe mi correo electrónico, y estaba tratando de configurar el servicio en una máquina nueva. Utilizo Postfix, y tiene la sana costumbre de que el usuario que reparte el correo, es decir, el usuario que el proceso local utiliza para escribir en los buzones, es el usuario nobody.

Pero yo necesitaba que fuera el usuario mail, ya que utilizo directorios Maildir, por fiabilidad. Me ha costado averiguar cómo hacerlo (estoy desentrenado), pero finalmente lo he conseguido: basta con añadir la línea

default_privs = mail

al fichero /etc/postfix/main.cf.

Pidgin no suena en KDE 4

2010-07-30T23:48:00.003+01:00

Bueno, por fin voy a trabajar de manera estable con KDE4.
Una de mis aplicaciones usuales es pidgin, un cliente de mensajería instantánea. Y es muy útil que suene cuando te llega un mensaje.

Pero en KDE 4 (al menos en Debian) no suena.

Menos mal que San Google Bendito lo sabe todo (no sé si demasiado) y me envió a http://mandrivausers.org/index.php?/topic/43987-help-pidgin-has-no-sound/ (aunque sea de Mandriva). La solución funciona.

Traducido:

Tuve el mismo problema con Pidgin en Ubuntu 7.10. Esto debería funcionar:

1 En Pidgin, selecciona Preferencias en el menú Herramientas (o pulsa Ctrl+P)
2 Pincha en la pestaña Sonidos
3 En la lista desplegable Método, selecciona Comando
4 En la caja de entrada Comando para sonido escribe lo siguente: aplay %s
5 Selecciona un evento con un sonido asignado en la lista Eventos de sonido
6 Pulsa el botón Previsualizar. Deberías oír ahora el sonido de notificación
7 Pulsa el botón Cerrar

¡Espero que te ayude! :D

Interprogramación de Fortran y C (II)

2010-07-17T13:32:00.004+01:00

Hace relativamente poco tiempo, un mes o dos, buscando cómo hacer funcionar la biblioteca libdl en Fortran, me tropecé con este artículo de Aleksandar Donev, en el que explica muy rápidamente cómo hacerlo, y además de un modo que facilita la interprogramación entre Fortran y C en general.

Básicamente, comienza creando las rutinas que usaremos para pasar cadenas de caracteres de C (terminadas en \0) a Fortran (con indicación de longitud) y viceversa. A continuación crea las interfaces Fortran para las principales funciones de libdl y luego muestra un ejemplo.

Sencillo, conciso y correcto.

Claro que no funciona «nada más sacarlo de la caja», por dos razones. Por un lado, utiliza punteros a funciones, algo que entró en Fortran 2003 (en C lo tenemos «de toda la vida»). Y por otro, los valores RTLD_LAZY, RTLD_NOW, RTLD_GLOBAL y RTLD_LOCAL hay que hallarlos a mano antes de empezar. Pero eso no cuesta nada.

Finalmente, lo mejor de todo es que el Sr. Donev me ha autorizado a usar no solamente su método sino el código que presenta en la página. En sus propias palabras:

The code is available with absolutely no restrictions: feel free to incorporate it into your software.

El código está disponible absolutamente sin restricciones. Siéntase libre de usarlo en su propio programa.

Truquitos de la shell

2010-06-26T18:53:00.004+01:00

Con la ayuda de dos pequeñas páginas, Bash Prompt HOWTO de Giles Orr y How to change the title of an xterm de Ric Lister, acabo de resolver un problemilla que me traía mal: saber dónde estoy trabajando:

export PS1='\[\033]0;\u@\h:\w\007\]\t \u@\h:\w\$ '

Expresión regular para CIDR

2010-05-03T10:47:00.004+01:00

Me ha dado por ahí, y he sacado la expresión regular para una dirección IPv4 en notación CIDR.

Hay mucha gente por ahí que usa

([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\/([0-9][1,3})

Pero no es correcta. La buena es ésta:

((0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])|[3-9][0-9]?)\.){3}(0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])|[3-9][0-9]?)/(0|[1-2][0-9]?|3[0-2]?)

Si la vas a compilar en C, no olvides doblar las barras invertidas.

Medias actualizaciones

2010-04-30T22:45:00.002+01:00

No es bueno tener un sistema estable y actualizarlo por partes, no señor.

Mi impresora estaba hoy tonta. No sé por qué, pero el CUPS y sus hijitos (hasta el ghostscript) se quedaban tontos, y no sacaban los trabajos.

Actualizar los paquetes correspondientes al cups, hpijs y sus dependencias lo ha solucionado.

Por la calle de la amargura

2010-04-28T10:35:00.000+01:00

El Fortran (en particular el programa que estoy haciendo) me trae por la calle de la amargura. En un sitio en particular, debería salirme algo cercano a 2, y me sale poco más de 1. Y se supone que lo tengo todo bien. Así que no sé, lo mismo soy idiota o no sé implementar métodos numéricos.

Polvo en la fuente

2010-04-06T22:39:00.002+01:00

Después de ¿Cuanto polvo cabe en un ordenador? tengo una segunda parte que contar: hoy he tenido que acudir de urgencia a un cliente porque se le había apagado y no le encendía el ordenador en que tiene todos los datos de la empresa.

Sí, lo adivinan: polvo en la fuente de alimentación. El ventilador se paró, la fuente se quemó, el lobo sopló y sopló y sopló y el servidor se cayó.

Unas horas más tarde, todas las piezas excepto fuente y carcasa habían sido transferidas a una carcasa nueva, con una fuente nueva.

Consejo: nunca pongan un ordenador con el ventilador hacia arriba.

Makefile para Fortran 95 cuando se usan módulos

2010-03-29T09:28:00.002+01:00

En mi trabajo tengo que usar módulos de Fortran 95, y no solamente usarlos, sino a veces crearlos. Vienen a ser como las bibliotecas compartidas de C, pero su gestión es distinta. Desde unos puntos de vista, más fea y engorrosa, y desde otros, más simple y clara.

En este caso, los ficheros .mod vienen a hacer el papel de los ficheros .h de C, solo que no se pueden escribir a mano, ya que no son ficheros de texto. Se generan al compilar los ficheros fuente de Fortran que contienen módulos.

Por esa razón me ha costado un poco hacerme a trabajar con ellos, en particular en los Makefiles, pero finalmente creo que ya tengo cómo tratarlos:


testprogram : testprogram.o testmodule.o
 gfortran -J. -o testprogram testprogram.o testmodule.o

%.o : %.F95
 gfortran -J. -c -o $@ $<

testprogram.o : testmodule.mod

%.mod : %.o
 @

Esa simple arroba hace el papel de línea de órdenes vacía que no causa errores, y, al depender el módulo del objeto, depende transitivamente de su fichero fuente, con lo que cambiar éste hace saltar la regla, se detecta que el objeto no está actualizado y se recompila, creando el módulo en el proceso. Poco importa que después la regla para el módulo vaya a ser invocada cuando ya no sea necesaria por tener ya el módulo, porque no hará nada.

Como no pueden ganar, intentan amenazar

2010-03-24T18:24:00.003Z

Artículo cruzado desde mi bitácora principal:

Como no pueden ganar, intentan amenazar

Por favor, los comentarios allí, gracias.

Hoy, en mi aMule, he encontrado este mensaje:

*** Sesión Chat Iniciada: CoPeerRight Agency (87.222.184.204:55511) - 2010-03-23 17:21:54
[17:21:54] *** Conectado al cliente ***
[17:21:54] CoPeerRight Agency: Le recordamos que la obra - Daybreakers - esta protegida por la ley Espanola de Propiedad Intelectual (LEY 23/2006, de 7 de julio) a titulo de derechos de autor y por Tratados Internacionales. Unicamente el titular de estos derechos puede decidir si la obra ha de ser divulgada y en que forma. La puesta a disposicion, distribucion sin autorizacion y en ciertos casos, la reproduccion son ilicitas.
[17:22:00] CoPeerRight Agency: Le instamos a abandonar la descarga y suprimir los ficheros ilegales de su lista de intercambio. En caso contrario, los titulares de los derechos podran adoptar medidas judiciales para la defensa de los mismos. Este mensaje no viola ningun derecho a la privacidad. Se limita a utilizar las caracteristicas comunes de los programas de intercambio de ficheros.

En primer lugar, ¿ha visualizado alguien de esa tal CoPeerAgency los archivos que comparto a fin de comprobar si se trata de la obra que dicen proteger?

En segundo lugar, ¿todavía no se enteran de que, caso de que efectivamente estuviera compartiendo tal obra, no cometería ningún delito sino un ilícito civil?

En tercer lugar, ¿tan mala es la susodicha película que quieren compensar su fracaso en taquilla con multas a los internautas?

En cuarto lugar, ¿qué derecho tienen a meterse en mi casa, en mi pantalla, a amenazarme?

Y para acabar, si tengo derecho a ver y probar un coche antes de comprarlo, ¿qué bula se creen que tienen los que contratan a esos, llamémosles, detectives para evitar que haga lo mismo antes de ir al cine?

Les aseguro que ahora sí que no iré a ver dicha película.

Por cierto, la red desde la que se conectan estos asaltantes de pantallas es la JAZZTEL-TRIPLEPLAY, propiedad de Jazz Telecom S.A. (red 87.222.0.0/16). Y lo siento por el resto de clientes de esa empresa, pero creo que los voy a bloquear por completo de acceder a mi sistema.

Si quieren más información (sesgada, por supuesto) sobre estos invasores de intimidad, pueden leer este artículo de El País.

Bolas enfriadoras

2010-03-21T20:14:00.003Z

Hace un tiempo comenté que, para evitar el recalentamiento de mi portátil, lo levanto sobre trabas de la ropa.

Cuando eso no basta, por ejemplo, porque fuerzo al ordenador a trabajar al 100% durante horas, lo que hago es ponerle debajo de la entrada del ventilador unas bolas enfriadoras. Las mismas bolas plásticas rellenas de gel que se guardan en el congelador y que uso para enfriar los refrescos.

Disco duro externo (II)

2010-03-14T23:46:00.003Z

Mis problemas de espacio se han terminado (otra vez). He vuelto a comprar un disco duro externo.

Esta vez se trata de una caja Datastor de TVISTO. Al contrario de lo que dice la página, trae un disco SAMSUNG de 1TB que no he tardado ni un cuarto de hora en poner a formatear como ext3 (venía con NTFS y, aunque no es un mal sistema de ficheros, es un problema en Linux porque hay que asignarlo a un usuario o todos los ficheros quedan como propiedad de root).

Y luego, para completar la jugada, y porque no aguanto más ver esos ficheros llamados fsck.0000 y no hago mucho eso de dejarle mis discos a otros, pues el disco que tenía formateado con VFAT ha pasado también a ser ext3.

¿"name" no estaba fuera de servicio?

2010-02-27T12:22:00.002Z

Estaba creando un formulario para una aplicación de Facebook que estoy escribiendo, por puro placer de probar, y resulta que no funcionaba.

Y claro, estaba probando a poner en los campos el atributo id, pero no el atributo name, porque yo pensaba que name ya no se usa. Pero resulta que en los formularios es justamente lo que se usa.

Pues nada, una para ver y otra para aprender.

Enrutador inalámbrico (II)

2010-01-22T19:24:00.003Z

Pues bueno, aquí estamos otra vez.

Como escribí ayer, el enrutador inalámbrico WRT54GL de Linksys no permite asignar direcciones IP estáticas a clientes DHCP determinados. Además, su sistema de QoS (Calidad de Servicio) es bastante grosero, así que me he liado la manta a la cabeza y le he instalado un «firmware» nuevo: Tomato.

Tomato es un código interno de funcionamiento para el WRT54G. Es, digamos, el sistema operativo del enrutador, y sustituye al sistema operativo original de Linksys. En el caso de un WRT54GL, el sistema operativo que viene de fábrica es una versión especializada de Linux, adaptada por Linksys para el aparato. Tomato se basa en esta versión pero introduce un gran número de cambios. Algunos son visibles en la interfaz, pero otros son más profundos. Entre estos tenemos el acceso SSH, la posibilidad de asignar direcciones IP estáticas dentro o fuera del rango DHCP, un cortafuegos mejorado y un sistema de clasificación de tráfico y QoS muy superior al original.

De momento, he clasificado el tráfico de mi red casera en función de la máquina de origen y asignado anchos de banda fijos y, la verdad, todos los que compartimos esta conexión hemos notado una mejoría sustancial.

Por supuesto, no quiero desmerecer al enrutador anterior, un WGR614 de NETGEAR, que no pienso retirar, sino simplemente cambiar a otro sitio donde seguirá dándome un buen servicio inalámbrico.

Seguiremos informando...

Enrutador inalámbrico

2010-01-21T17:57:00.005Z

Pues sí, entre otras cosas, en estas Navidades ha caído un enrutador inalámbrico. Un bonito WRT54GL de Linksys. Es como el conocido WRT54G pero es un WRT54GL. Y sí, la «L» es de «Linux».

Este amiguito trae Linux por dentro. Y enseguida se hizo con mi red inalámbrica.

Parece duro como una piedra, y su historia dice que me va a hacer un buen servicio. No obstante, tiene (al menos) un grave defecto: no se pueden asignar direcciones DHCP estáticas a dispositivos predeterminados.

Ya les iré contando.

Concentrador USB (II)

2010-01-21T16:23:00.003Z

Pues los discos externos no me han vuelto a dar fallos, así que este concentrador se va a ir a la basura (o a un cajón, que nunca se sabe). Es un Slimline USB2.0 HUB de Point of View.

Que conste que no le echo la culpa a la empresa, no me disgustan particularmente. Puede que el problema no sea el concentrador sino el cable, o el polvo que hay en mi escritorio, pero en fin... el próximo concentrador creo que será de otra marca, solo por si acaso.

Concentrador USB

2010-01-16T21:37:00.001Z

Uno de mis discos duros externos se desconecta constantemente. Creo que sea cosa de mi concentrador USB externo.

Voy a probar a tenerlo enchufado directamente un par de días a ver qué pasa.

Linux en Compact Flash

2009-12-31T12:34:00.003Z

Para un cliente, al que ya le he realizado otros trabajos, tengo que preparar esta vez un servidor de copias de seguridad remoto.

Es bien sabido que las copias de seguridad son necesarias. Y por eso ya están haciendo copias de seguridad en un disco duro externo local. Si la máquina se estropea, se borran los datos accidentalmente, o cualquier cosa similar, recuperan los datos, que son imprescindibles para el negocio.

¿Y si un ladrón entra en la oficina y se lleva la máquina con el disco externo?

Ahí es donde entran las copias de seguridad remotas. Y este ordenador, que no va a tener otro trabajo que chupar datos remotos y guardarlos. Absolutamente nada más.

Por eso he elegido un ordenador pequeño, con una placa un poco más pequeña que una Nano-ITX, al que le he puesto una tarjeta Compact Flash de 2GiB como disco duro.

Y aquí viene lo bueno: instalar Linux en una tarjeta Compact Flash. Y la verdad es que no ha sido difícil.

La máquina es un Epatec eTC 2300. La verdad es que la empresa no me cae nada bien (por varias cosas), pero la maquinita es justo lo que necesitaba para este cliente. El arranque por PXE hizo la mitad del trabajo, y Debian el resto. Todo fue cosa de bajar el sistema netinst (instalación por red), poner un servidor DHCP y un servidor TFTP, y configurarlos para que mandaran el netinst como sistema operativo del eTC. Con eso, el eTC arrancó y empecé una instalación de una Debian normal y corriente. Lo único con lo que tuve un poco de cuidado fue al particionar (todas las particiones usan noatime) y luego poner particiones tmpfs para ciertas secciones muy variables como /tmp o /var/lock y /var/run. Ah, y por supuesto, /etc/mtab ya no es un fichero, es un enlace a /var/run/mtab.

Voy a tener un problema con /var/log. Se modifica bastante, pero no quiero perder los logs ni puedo enviarlos a otra máquina, precisamente porque si tengo que mirarlos es por un problema de red. Veremos cuanto aguanta la Compact Flash.

Pues eso... no es un Linux Embebido ni nada semejante, es una Debian normal y corriente, o casi.

Autoridad Certificadora OpenSSL

2009-11-18T11:00:00.008Z

Ya una vez hablé en esta desbitácora de cómo crear una Autoridad de Certificación. Hoy retomo el tema, habiendo ampliado mis conocimientos acerca de OpenSSL un poco más desde entonces.

Sin entrar en detalles de qué es y para qué sirve una Autoridad Certificadora, voy a exponer en breve los pasos a seguir para tener una CA casera propia.

Estos pasos hay que llevarlos a cabo en un directorio cualquiera, dentro del cual aparecerá un nuevo directorio llamado demoCA.

Generamos la clave privada de la CA con
```
openssl genrsa -des3 -out CA_key.pem 4096
```
que nos preguntará y verificará la contraseña con la que queremos proteger la clave.
Creamos el certificado autofirmado de la CA con
```
openssl req -x509 -key CA_key.pem -new -set_serial 0 -out CA_cert.pem
```
que nos preguntará varios datos. El CN no puede estar vacío.
Generamos la estructura de la CA con
```
/usr/lib/ssl/misc/CA.pl -newca
```
que nos preguntará por el certificado de la CA, a lo que responderemos
```
CA_cert.pem
```
Generamos el fichero de números de serie con
```
echo 01 > demoCA/serial
```

Movemos la clave de la CA y su certificado a los sitios previstos

mv CA_key.pem demoCA/private/cakey.pem
mv CA_cert.pem demoCA/cacert.pem

Extraemos (si queremos) la cave pública de la CA a partir de la privada con

openssl rsa -pubout -in demoCA/private/cakey.pem -out demoCA/cakey_public.pem

Y ya tenemos nuestra CA casera lista para trabajar.

Ojo: no pierdas nunca la contraseña que has introducido para cifrar la clave privada de la CA. Sin esa contraseña, toda la estructura de la CA queda inutilizada.

Harto de correo basura que pasa el filtro

2009-11-06T12:35:00.005Z

Pues eso, que me he hartado de ver que hay mensajes de correo basura que pasan el filtro de mi spamassasin. El problema no es el programa, que funciona muy bien, sino que hay mensajes que son emitidos correctamente, con reverse-DNS y todo eso, pero que sin embargo tienen un contenido que es pura carne en lata, o eso que los Monty Python dieron en llamar SPAM.

Pues nada, ni corto ni perezoso, y como ya me he hartado (y me fío del discriminado bayesiano del spamassasin) me he ido al /etc/spamassassin/local.cf y he añadido estas líneas al final:


score BAYES_80 4.0
score BAYES_95 4.5
score BAYES_99 5.0

Hala. Como mi umbral está en 5, arreglado.

Lanza, lanza, a ver cómo lo haces esta vez

2009-10-24T12:02:00.006+01:00

Más información en http://www.genbeta.com/actualidad/imagen-de-la-semana-linus-torvalds-es-un-cachondo.

No perder datos ni tiempo

2009-10-20T23:36:00.004+01:00

En el mundo empresarial los datos son dinero, y el tiempo también. Un estudio de arquitectura, por ejemplo, que pierda sus datos (planos, informes, fotografías, etc.) irá a la ruina o, como mínimo, pasará un muy mal trago. Así que hay que asegurarse de que los datos no se pierden, para lo que tenemos soluciones como RAID 1 para los fallos de los discos.

Pero los fallos de los discos no son la única causa de que se pierdan datos. De hecho, ni siquiera son la principal. Un error del usuario al borrar un fichero, o un fallo del programa, o cualquier otra causa que vaya al sistema RAID y corrompa el sistema de ficheros puede suponer un desastre casi tan grave, y mucho más probable. Así que hay que asegurarse de que los datos están en más de un sitio a la vez. RAID 1 solamente nos permite seguir trabajando si un disco se estropea mientras llega su recambio. Para las copias de seguridad, tenemos el maravilloso rsync y su intefaz dirvish.

Y como comentaba arriba, no se puede tampoco perder tiempo, así que los datos no solamente deben estar a salvo en la copia de seguridad, sino que en caso de que falle la máquina deben poder ser utilizados inmediatamente mientras el servidor de ficheros es reparado, con lo que las copias de seguridad deben realizarse en un disco externo que pueda enchufarse, provisionalmente, a otra máquina.

Este es el sistema que he montado para una empresa semejante a la que ponía de ejemplo: Un servidor dedicado, con dos discos duros iguales (pero de distintos lotes, para evitar que puedan tener los mismos microdefectos de fabricación que puedan causar su mortalidad infantil o senil a la vez) en RAID 1, salvo el sector de arranque y la partición /boot, que son idénticos en ambos. La zona RAID particionada a su vez mediante LVM, con una parte para el sistema y otra separada para los datos de los usuarios, que se sirven mediante SAMBA. Y finalmente, un disco duro externo, identificado mediante su número de serie, con formato FAT, donde se realizan las copias de seguridad mediante dirvish, que es montada justo antes de copiar y desmontada justo al terminar.

Este disco externo pueden los usuarios desenchufarlo en cualquier momento (aunque les recomiendo que no lo hagan a las horas de las copias ;) ) para disponer de las copias de seguridad en otra máquina, aunque debido a su formato se pierda una de las mejores características de dirvish, los enlaces duros entre copias de distintas fechas, y haya (además) habido que desactivar las opciones de copia de permisos y propietarios.

Así, sea cual sea el incidente (salvo un desastre mayor de la máquina, como un incendio), los usuarios podrán acceder a sus datos de trabajo.

Para alguien que levanta España, no los vamos a dejar sin trabajar, ¿no?

Volviendo al hogar

2009-09-11T21:03:00.003+01:00

Gracias a iarenaza, que confió en mí y en su propio buen criterio, ya estoy de vuelta en el lugar en que todo empezó, el sitio en que empecé a «bloguear» (yo prefiero decir «escribir») mis historias informáticas: la casa de la rubia.

Libertonia es, quizá, la mejor página sobre informática de España: los artículos no pasan a portada hasta que han sido revisados por los usuarios, y si las cosas son como eran, eso no ocurre si son tendenciosos, están mal escritos o cualquier otro defecto similar.

Realmente pensé que Libertonia estaba muerta, pero parece que no: no está muerta, simplemente yace eternamente.

RESHAPE es ineficiente

2009-09-01T11:46:00.003+01:00

Fortran es un lenguaje pensado para escribir en el ordenador fórmulas matemáticas, o más en general, cálculos científicos. Y es muy bueno trabajando con matrices multidimensionales: se puede escribir


real(4) :: a(64,64,64)
real(4) :: b(10,10,10)

[...]

b=a(1:10,1:10,1:10)

y así, sin necesidad de bucles, copiamos un trozo de una matriz en la otra. O también podemos, para rellenar de datos una matriz:


real(4) :: a(1:64,1:64,1:64)
integer :: i,j,k

a=RESHAPE( (/ ( (/ ( (/ ( REAL((i-1+(64/2))/64)+1.0 ,k=1,64) /) ,j=1,64) /) ,i=1,64) /) , (/64,64,64/) )

para rellenar un cubo de datos de 64*64*64 con los valores 1 y 2. Esto es lo mismo que


real(4) :: a(1:64,1:64,1:64)
integer :: i,j,k

do k=1,64
 do j=1,64
  do i=1,64
   a(i,j,k)=REAL((i-1+(64/2))/64)+1.0
  end do
 end do
end do

aunque la filosofía no es la misma. En el primer caso, creamos una ristra de 64*64*64 valores que después adaptamos a un cubo de lado 64. En el segundo caso calculamos los valores uno por uno y los vamos colocando en sus lugares de memoria. El segundo código parece más ineficiente, y puede que el compilador no lo sepa optimizar bien... pero el primero es el realmente ineficiente: compilarlo puede tardar muchísimo más, incluso hacerse eterno con valores mayores, mientras que el segundo se compila en un instante y se ejecuta en poco tiempo.

Recordemos, pues, que salvo en determinadas ocasiones, explícito es mejor que implícito, por mucho que les duela a los fortranistas de toda la vida.

StarCraft en Linux

2009-08-17T21:16:00.011+01:00

Acabo de volver a jugar a StarCraft, ese maravilloso juego de Blizzard ambientado en el espacio. Y por supuesto, lo he hecho en Linux, aunque se trata de un juego que tengo para otro sistema operativo. Y ello gracias a una capa de emulación del API llamada Wine.

El objetivo de Wine es precisamente que los programas creados para Windows puedan ser ejecutados en Linux. Para ello, pone una capa entre el programa y el sistema de tal manera que las peticiones a Windows del programa son capturadas por Wine, que las transforma en peticiones a Linux.

Volver a tener a los Zerg bajo mis órdenes ha sido una maravillosa experiencia. Ya no se hacen juegos como los de antes, con buena jugabilidad y un guión serio.

La pena es que Wine no destaca precisamente por su manejo del sonido. Tiene la mala costumbre de requerir acceso exclusivo al sistema de sonido, ya sea OSS o ALSA. Y eso en KDE es una mala idea: o juegas sin sonido, lo que no es agradable, o no tienes sonido en el sistema. Yo, la verdad, si me pongo a jugar, quiero el sonido. Así que uso el siguiente truco:

~/.wine/dosdevices/c:/Archivos de programa/Starcraft$ artsdsp sh wine StarCraft.exe

Copiar propiedades en Subversion

2009-07-27T14:05:00.002+01:00

Un pequeño truco que utilizo para asignar a un fichero versionado con Subversion una propiedad tal y como la tengo en otro fichero. Normalmente la utilizo para la propiedad svn:keywords que suele tener el mismo valor en todos los ficheros de cada uno de mis proyectos.

svn propset svn:keywords "`svn propget svn:keywords ficheroviejo.c`" ficheronuevo.c

Soporte 3D para una tarjeta nVidia

2009-05-27T18:11:00.006+01:00

Comentaba ayer mis aventuras con Google Earth, cuyo resultado fue necesitar la aceleración 3D de mi tarjeta gráfica, una nVidia Quadro NVS 110M.

Desde que reinstalé la máquina, hace poco, con Lenny, había estado trabajando con el controlador libre nv, que fue automáticamente puesto en su sitio por la autoconfiguración de Xorg. Y la verdad, sin problemas.

Ahora bien, poner a funcionar la aceleración 3D tampoco ha sido demasiado complicado. En primer lugar, tuve que compilar el módulo del núcleo, cosa que module-assistant hizo por mí:

m-a a-i nvidia

En segundo lugar, añadir una línea a mi fichero /etc/X11/xorg.conf: cambiar

Section "Device"
        Identifier      "Configured Video Device"
EndSection

por

Section "Device"
        Identifier      "Configured Video Device"
        Driver          "nvidia"
EndSection

Y en tercer lugar, simplemente reiniciar la máquina. Nada del otro mundo, ¿verdad?

Lo que sí he notado es que, aparte de que la aceleración 3D ahora funciona, ha cambiado el tamaño de mis fuentes en la pantalla, con lo que, aparte de que he tenido que reordenar todos los iconos del escritorio, algunas aplicaciones que dependen del tamaño de la fuente dan mínimos problemas. Por ejemplo, gnumeric, que establece el alto de las líneas en función de la fuente.

Pero bueno, detalles menores que, en realidad, no molestan.

Google Earth en Debian

2009-05-27T00:02:00.005+01:00

La verdad, esperaba encontrarme el Google Earth empaquetadito y todo, es que Debian me tiene malacostumbrado, la verdad, pero bueno, tenemos un precioso paquete llamado googleearth-package que lo que hace es bajarse el instalador oficial de Google y crear un paquete a partir de él, muy al estilo Debian.

Y la verdad, googleearth-package se instaló sin problemas y make-googleearth-package hizo su trabajo: él solito se bajó el instalador, lo descomprimió, compiló y empaquetó, y me dejó un bonito paquete. O casi.

El casi viene por un par de detalles. El primero es que la versión de googleearth-package de Debian 5.0 (llamada Lenny) no está pensada para la versión actual (en mi caso, la 5.0.11733.9347) del instalador de Google Earth, así que no bastó con decir make-googleearth-package sino que en su lugar tuve que decir make-googleearth-package --force. El segundo es que make-googleearth-package no funciona bien en un directorio que tenga el bit SGID activado, y el directorio donde lo intenté las primeras veces (un subdirectorio de /usr/src) lo tiene.

Y así, prácticamente en dos patadas, tuve mi Google Earth funcionando. Eso sí, funcionando a pedales: no tenía aceleración 3D en el ordenador. Pero eso es otra historia, y deberá ser contada en otra ocasión (Ende).

Descargar enlaces ed2k:// desde Firefox

2009-05-18T22:20:00.004+01:00

La verdad es que he estado mucho tiempo sin poder hacerlo, pero tampoco me he puesto a buscarlo hasta hoy, y lo he resuelto en un par de minutos estando bastante cansado, con lo que quiero decir que la solución es bastante tonta.

Por un lado, aMule viene con un programa que se llama ed2k que se encarga, precisamente, de pasarle enlaces ed2k://.

Por otro lado, en el propio Iceweasel (o, para los que no usen Debian, Firefox), hay que cambiar la configuración a mano en esa página tan peligrosa y «no apta para manazas» llamada about:config. Ahí hay que añadir a mano un a nueva clave, network.protocol-handler.app.ed2k, y darle como valor /usr/bin/ed2k.

Y eso es todo. A partir de ese momento, basta pinchar en un enlace y ya el aMule se pondrá inmediatamente a bajarlo.

Instalar Lenny

2009-05-01T18:01:00.003+01:00

Con las copias de seguridad hechas (gracias a mi bienamado dirvish), voy a hacer una instalación desde cero de Debian 5.0 (antes conocida como Lenny). Ya después haré otras cosas feas como pasarme a testing (Squeeze) o incluso a unstable (Sid), con tal de que no se suban a la parra de KDE 4, que no quiero ni ver (al menos por ahora), pero quiero disfrutar de uno o dos días de estabilidad con mi portátil antes de lanzarme.

Disco duro externo

2009-05-01T10:37:00.005+01:00

Finalmente me he comprado un nuevo disco duro externo. En realidad no ha sido un disco externo, sino un disco normal y corriente y una de esas cajas externas para meter el disco dentro.

La caja es la que se ve en la foto: una «MADE IN CHINA» de padre desconocido cuya página web soy incapaz de encontrar. El disco, en cambio, es un Seagate Barracuda (el ST3 500 41 8AS), un disco con interfaz SATA en el que creo que puedo confiar.

Ya les iré contando. De momento, voy a ponerme a configurar el dirvish.

Servicio al cliente (II) - Refactored

2009-04-27T10:22:00.005+01:00

Comenté en mi bitácora usual hace unos minutos cómo me fue con el Servicio de Atención al cliente de Dell. Y quería comentarlo de nuevo aquí, con algunos detalle técnicos más de los que puedo permitirme poner allí.

Viene el caso de que mi portatil se estropeó este fin de semana, y hace un rato llamé al servicio de Atención al cliente de Dell, en particular al servicio técnico.

El síntoma inicial fue que la pantalla estaba en negro. Por completo. Inicialmente pensé que tenía un problema con el salvapantallas o el ahorro de energía (lo que no sería novedad ya que llevo con problemas de ese tipo varios meses y no me he decidido a arreglarlo, sobre todo porque aún no tengo un disco de copias de seguridad), así que cambié a una consola y me empecé a mosquear: seguía en negro.

A ciegas me identifiqué con la consola como superusuario y reinicié el ordenador (no es difícil, basta con ir a una consola que sepas o suponga que on está abierta y poner el nombre de usuario, esperar un poco, poner la contraseña, esperar dos pocos, y escribir poweroff). Ahí empezó mi susto: el reinicio continuaba con la pantalla completamente en negro, tanto para la BIOS como para el GRUB como posteriormente. Curiosamente, la pantalla respondía perfectamente a las órdenes de cambio de brillo, pasando de negro oscuro a negro brillante. Apagué de nuevo el ordenador (lo tuve que hacer a lo bruto porque no me podía identificar en la consola, y no sabía por qué).

Al rato conseguí una pantalla externa y la probé: el modo de vídeo del arranque era inadecuado (80x24), el texto en pantalla aparecía desdibujado y era imposible iniciar el servidor gráfico. La conclusión era evidente: el problema no era de la pantalla, sino de la tarjeta gráfica. Y en un portátil, es parte de la placa base.

Al llamar hoy a Dell les indiqué los síntomas del problema, y me obligaron a hacer la prueba de acceso directo a la pantalla: encender el ordenador con la tecla Fn pulsada, introducir n y comprobar la pantalla. Y efectivamente aparecieron en mi pantalla los colores blanco, rojo, verde y azul, confirmando mi diagnóstico de que no se trataba de la pantalla sino de la tarjeta gráfica.

No consideraba yo necesaria la prueba, pero entiendo que me hicieran comprobarlo dado que muchas veces los usuarios, que no tienen apenas conocimientos sobre la máquina que usan (si se tratara de un coche no aprobarían el examen del carnet de conducir), creen que falla una cosa cuando se trata de otra.

En resumen, mañana tendré un técnico en mi despacho cambiándome la placa base completa por una nueva. Así es como se cuida a los clientes: respuesta adecuada y en un tiempo adecuado.

Ping en Jabber

2009-04-15T16:53:00.001+01:00

Dear Lazyweb:

¿Alguien sabe cómo hacer un ping desde un programa de Jabber?

Gracias de antemano

Un pequeño truco

2009-04-12T00:16:00.004+01:00

A veces hay que trabajar en línea de comandos (o mejor, línea de órdenes) con nombres de ficheros con espacios. Y es un problema pasarlos por las tuberías (pipes), porque estas interpretan los espacios como separación entre argumentos.

Pongamos un ejemplo: hoy enchufé mi disco externo a un ordenador Windows y se me llenó de ficheros llamados Thumbs.db. Es un problema borrarlos uno a uno, así que lo más cómodo es usar find de una manera como ésta:

find . -name Thumbs.db | xargs rm -rf

Pero no funciona. Un fichero que se llame mountpoint/Mi Carpeta/Thumbs.db será entendido por xargs como dos ficheros distintos, mountpoint/Mi y Carpeta/Thumbs.db, que por supuesto no existen.

La solución es tan sencilla como:

find . -name Thumbs.db | sed '{s/ /\\ /g}'| xargs rm -rf

utilizando sed para escapar los espacios. Ojo, que no funcionará sin las comillas sencillas para escapar las barras invertidas.

Estas cosas pasan

2009-03-03T12:14:00.004Z

Lo mejor de tener un disco de copias de seguridad es que, si se te muere el disco duro, no pierdes la información.

Esto es cierto incluso si se muere el disco de las copias de seguridad, que es lo que me acaba de pasar. Hace un par de semanas vi que uno de mis discos externos de LaCie no funcionaba. Precisamente el disco de mis copias de seguridad.

Bueno, pues abrí la caja y vi que el disco interno era un Barracuda SATA de Seagate. No es en absoluto lo que entiendo por un mal disco.

Hoy he comprobado, enchufando el disco directamente a otro ordenador con SATA, que lo puedo dar por difunto. Pero en fin, no he perdido nada: todo lo que había eran copias de seguridad, así que lo único que me queda es rezar para que no se me estropee el disco de sistema antes de comprar otro disco externo para volver a empezar a hacer copias.

Trabas

2009-02-24T13:18:00.007Z

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

2009-02-24T12:03:00.002Z

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

2009-02-09T17:54:00.005Z

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

2009-01-21T09:46:00.003Z

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)

2009-01-12T09:19:00.003Z

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.

2009-01-07T18:23:00.005Z

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

2008-12-31T15:34:00.011Z

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.

Esas pequeñas herramientas (I)

2008-12-17T09:09:00.002Z

Hoy, UDP Cast.

UDP Cast es una herramienta que permite enviar un fichero a través de una red Ethernet a varios destinos a la vez. Para ello utiliza tramas Broadcast de Ethernet y direcciones multicast de IP.

Tiene dos usos principales, como programa instalado y como programa independiente. Como programa instalado, se puede utilizar en cualquier instalación de Unix (o de otros sistemas) para transmitir un fichero cualquiera. Así, el coste de distribuir un parche, por ejemplo, de un servidor a trescientos clientes es el mismo que el coste de distribuirlo a uno.

Como programa independiente, podemos arrancar varios ordenadores desde un disquete o un CD-ROM (o por PXE o por bootp o por...) y tras una configuración muy, muy sencilla, copiar discos completos o particiones entre sistemas, lo cual es enormemente útil para instalar aulas completas de ordenadores idénticos.

Por supuesto, en este caso hay que tener cuidado con las posibles diferencias en el hierro de los ordenadores, ya que discos o particiones de distinto tamaño o geometría, por ejemplo, pueden dar problemas.

En cualquier caso, siempre es bueno tener un par de discos de UDP Cast a mano.

Inestablemente estable

2008-12-02T20:05:00.006Z

A veces, en Debian, uno tiene que instalar un paquete de una rama diferente a la que está utilizando. Por ejemplo, uno tiene un servidor instalado con la rama estable y tiene que instalar un determinado paquete de la rama de pruebas o de la inestable porque es la única manera de conseguir determinada característica.

Para entendernos, Debian tiene cuatro ramas: la estable (stable), la de pruebas (testing), la inestable (unstable) y la experimental (experimental). Normalmente el trabajo de desarrollo se hace en la inestable, y los programas que después de diez días en inestable no dan problemas se pasan a la rama de pruebas. Así, si se quiere estar siempre a la última hay que instalar el sistema con la rama inestable, pero es perfectamente posible que el sistema quede inutilizable. La rama de pruebas es la preferida por mucha gente que quiere estar a la última con sus escritorios pero sin arriesgarse a que todo quede parado, mientras que la rama estable es ideal para servidores o para administrar grandes conjuntos de máquinas iguales.

Por su parte, la rama experimental tiene versiones demasiado inestables incluso para la rama inestable. De hecho no es una rama completa, uno no puede instalar un sistema complete utilizando solamente paquetes de esta rama.

Pues bien, se me ha dado el caso de que en un ordenador con la rama de pruebas instalada necesité instalar ImageMagick, pero resulta que la versión de este programa que viene en esta rama (la 6.3.7.9) utiliza como compresor MPEG el programa mpeg_encode, que no existe en Debian. En cambio, la versión de la rama experimental es la 6.4.5.4 que utiliza ffmpeg, que sí está disponible.

La primera opción es bajarse el imagemagick de experimental e instalarlo a mano. Esto se empieza a complicar cuando uno descubre que necesita dos librerías más, también de experimental, y cambiar la versión de otro paquete que también tiene dependencias.

Y claro, uno se pregunta "¿Para qué tengo que hacer todo esto si es justo el tipo de cosas que le encanta a apt?"

La solución:

Lo primero, hay que dejarle bien claro a apt qué rama queremos utilizar normalmente:

#/etc/apt/apt.conf

APT::Default-Release "testing";

Lo segundo, hay que tener las fuentes de la rama que necesitamos, aparte de las fuentes de la rama que tenemos normalmente:

#/etc/apt/sources.list

# Fuentes remotas de paquetes
deb http://ftp.es.debian.org/debian/ stable main contrib non-free
deb http://ftp.es.debian.org/debian/ testing main contrib non-free
deb http://ftp.es.debian.org/debian/ unstable main contrib non-free
deb http://ftp.es.debian.org/debian/ experimental main contrib non-free

# Actualizaciones de seguridad
deb http://security.debian.org/ stable/updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free

Y listo. Actualizamos las listas de paquetes con aptitude update o apt-get update (o dselect o Synaptic o lo que cada uno prefiera) y ya estamos preparados para indicarle al sistema lo que queremos:

# aptitude install imagemagick/experimental
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Leyendo la información de estado extendido
Inicializando el estado de los paquetes... Hecho
Leyendo las descripciones de las tareas... Hecho
Los siguientes paquetes están ROTOS:
  libmagickcore1
Se instalarán los siguiente paquetes NUEVOS:
  ghostscript{a} gsfonts{a} imagemagick imagemagick-doc{a} libcupsimage2{a} libgd2-noxpm{a} libgomp1{a} libgraphviz4{a}
  libgs8{a} libilmbase6{a} libjasper1{a} libltdl3{a} libmagickwand1{a} libopenexr6{a} libpaper-utils{a} libpaper1{a}
  libwmf0.2-7{a} psfontmgr{a}
0 paquetes actualizados, 19 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 13,7MB de ficheros. Después de desempaquetar se usarán 48,4MB.
No se satisfacen las dependencias de los siguientes paquetes:
  libmagickcore1: Depende: libdjvulibre21 (>= 3.5.21) pero no es instalable
Las acciones siguientes resolverán estas dependencias

Instalar los paquetes siguientes:
libdjvulibre-text [3.5.21-1 (unstable)]
libdjvulibre21 [3.5.21-1 (unstable)]

La puntuación es 12

¿Acepta esta solución? [Y/n/q/?]
Se instalarán los siguiente paquetes NUEVOS:
  ghostscript{a} gsfonts{a} imagemagick imagemagick-doc{a} libcupsimage2{a} libdjvulibre-text{a} libdjvulibre21{a}
  libgd2-noxpm{a} libgomp1{a} libgraphviz4{a} libgs8{a} libilmbase6{a} libjasper1{a} libltdl3{a} libmagickcore1{a}
  libmagickwand1{a} libopenexr6{a} libpaper-utils{a} libpaper1{a} libwmf0.2-7{a} psfontmgr{a}
0 paquetes actualizados, 21 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 14,4MB de ficheros. Después de desempaquetar se usarán 50,5MB.
¿Quiere continuar? [Y/n/?]
Escribiendo información de estado extendido... Hecho
Des:1 http://ftp.fr.debian.org testing/main libcupsimage2 1.3.8-1lenny2 [98,5kB]
Des:2 http://ftp.fr.debian.org testing/main libpaper1 1.1.23+nmu1 [20,6kB]
Des:3 http://ftp.fr.debian.org testing/main libgs8 8.62.dfsg.1-3.1 [2219kB]
Des:4 http://ftp.fr.debian.org testing/main gsfonts 1:8.11+urwcyr1.0.7~pre44-3 [3373kB]
Des:5 http://ftp.fr.debian.org testing/main ghostscript 8.62.dfsg.1-3.1 [766kB]
Des:6 http://ftp.fr.debian.org testing/main libgomp1 4.3.2-1 [13,2kB]
Des:7 http://ftp.fr.debian.org unstable/main libdjvulibre-text 3.5.21-1 [74,4kB]
Des:8 http://ftp.fr.debian.org unstable/main libdjvulibre21 3.5.21-1 [682kB]
Des:9 http://ftp.fr.debian.org testing/main libgd2-noxpm 2.0.36~rc1~dfsg-3 [221kB]
Des:10 http://ftp.fr.debian.org testing/main libltdl3 1.5.26-4 [177kB]
Des:11 http://ftp.fr.debian.org testing/main libgraphviz4 2.20.2-3 [536kB]
Des:12 http://ftp.fr.debian.org testing/main libilmbase6 1.0.1-2+nmu2 [118kB]
Des:13 http://ftp.fr.debian.org testing/main libjasper1 1.900.1-5.1 [145kB]
Des:14 http://ftp.fr.debian.org experimental/main libmagickwand1 7:6.4.5.4.dfsg1-1 [332kB]
Des:15 http://ftp.fr.debian.org testing/main libopenexr6 1.6.1-3 [262kB]
Des:16 http://ftp.fr.debian.org testing/main libwmf0.2-7 0.2.8.4-6 [174kB]
Des:17 http://ftp.fr.debian.org experimental/main libmagickcore1 7:6.4.5.4.dfsg1-1 [1667kB]
Des:18 http://ftp.fr.debian.org experimental/main imagemagick 7:6.4.5.4.dfsg1-1 [86,1kB]
Des:19 http://ftp.fr.debian.org experimental/main imagemagick-doc 7:6.4.5.4.dfsg1-1 [3410kB]
Des:20 http://ftp.fr.debian.org testing/main libpaper-utils 1.1.23+nmu1 [17,6kB]
Des:21 http://ftp.fr.debian.org testing/main psfontmgr 0.11.10-0.2 [22,2kB]
Descargados 14,4MB en 3min47s (63,5kB/s).
Preconfigurando paquetes ...
[...]
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Leyendo la información de estado extendido
Inicializando el estado de los paquetes... Hecho
Escribiendo información de estado extendido... Hecho
Leyendo las descripciones de las tareas... Hecho

Como se puede ver, la barra al final del nombre del paquete indica "quiero este paquete de esta rama", y el sistema ha bajado el paquete de experimental, y sus dependencias, mientras fue posible, de la rama actual, la de pruebas. Además, las actualizaciones del sistema no darán problemas diciendo siempre "hay nuevos paquetes disponibles" cuando esos paquetes no sean de la rama actual.

¿Cuanto polvo cabe en un ordenador?

2008-11-11T13:37:00.004Z

La respuesta es: mucho. Sobre todo si no se limpia.

El otro día me decidí a limpiar de polvo un ordenador que tengo en casa. Lleva años funcionando, y hace tiempo que no lo limpiaba. De hecho, había dejado de funcionar: ya sabemos que el polvo es conductor, y además tiene otro problema, y es que bloquea los ventiladores, con lo que las temperaturas suben.

El caso es que lo desmonté pieza a pieza. Se puede ver en la primera foto el estado del disipador del procesador cuando quité su ventilador. Y el ventilador andaba igual, así como el resto de la placa.

La tercera foto muestra todas las piezas y el total de polvo extraído: un montón.

Y eso que al ventilador de carcasa tuve incluso que darle aceite vegetal a ver si volvía a funcionar, porque tenía tanto polvo dentro del mecanismo, entre el rotor y el estator, que andaba a menos de la mitad de su velocidad normal.

Eso sí, una vez limpio y vuelto a montar, la máquina no ha vuelto a dar problemas.

SMART

2008-10-14T12:36:00.007+01:00

Este artículo es principalmente una traducción del que me han publicado en Debian Package of the Day y que llegó luego a DebianTimes.

Uno de los paquetes que instalo manualmente en toda nueva instalación es smartmontools. Tengo cierta experiencia administrando ordenadores y redes, y es un hecho que los piratas informáticos y los fallos de los programas (bugs) no son la mayor causa de problemas en instalaciones pequeñas y medianas. Lo es el hardware.

Luego tenemos aparatos que pueden fallar, y Murphy dice que si algo puede fallar, fallará. El asunto no es evitar los fallos físicos, lo que es imposible, sino detectarlos rápidamente o incluso prevenirlos.

Particularmente para los discos duros, la herramienta encargada es smartctl del paquete smartmontools. Los discos IDE (si no son de la era de los dinosaurios) tienen una herramienta integrada de autoanálisis llamada SMART que significa“Self-Monitoring, Analysis and Reporting Technology” (Tecnología de Auto-Monitorización, Análisis e Informe). Los discos SCSI modernos también la tienen si son SCSI 3 o más nuevos. Lo que ocurre es que en la circuitería del disco hay rutinas para controlar parámetros de salud del disco: tiempo de comienzo de rotación (spin-up time), número de fallos de lectura, temperatura, tiempo de vida… Y todos esos parámetros no son solamente controlados por el propio disco, sino que tienen asignados límites de seguridad, y tanto los parámetros como los límites pueden ser obtenidos por programas que accedan a los discos utilizando las instrucciones I/O apropiadas.

Y ese programa es smartctl, una pieza del paquete Debian smartmontools. Por supuesto, como accede al disco directamente, hay que ser superusuario (root) para usar estas órdenes.

smartctl puede preguntarle al disco por su identificación SMART:


# smartctl -i /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Fujitsu MHV series
Device Model:     FUJITSU MHV2060BH
Serial Number:    NW10T652991F
Firmware Version: 00850028
User Capacity:    60,011,642,880 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 4a
Local Time is:    Mon May 12 02:39:31 2008 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Más interesante, smartctl puede preguntarle al disco por los valores de sus parámetros:


# smartctl -A /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   046    Pre-fail  Always       -       124253
  2 Throughput_Performance  0x0004   100   100   000    Old_age   Offline      -       18284544
  3 Spin_Up_Time            0x0003   100   100   025    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1199
  5 Reallocated_Sector_Ct   0x0033   100   100   024    Pre-fail  Always       -       8589934592000
  7 Seek_Error_Rate         0x000e   100   087   000    Old_age   Always       -       1761
  8 Seek_Time_Performance   0x0004   100   100   000    Old_age   Offline      -       0
  9 Power_On_Seconds        0x0032   079   079   000    Old_age   Always       -       10866h+57m+47s
 10 Spin_Retry_Count        0x0012   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1199
192 Power-Off_Retract_Count 0x0032   099   099   000    Old_age   Always       -       283
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       6953
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       45 (Lifetime Min/Max 14/58)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       62
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       459276288
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000e   100   082   000    Old_age   Always       -       22371
203 Run_Out_Cancel          0x0002   100   100   000    Old_age   Always       -       1533257648465
240 Head_Flying_Hours       0x003e   200   200   000    Old_age   Always       -       0

Como se puede ver, algunos atributos están marcados como “Pre-fail”. Si cualquiera de estos atributos traspasa su límite, el disco está para fallar en cuestión de horas, quizá minutos.

Aunque hay más opciones para smartctl, las últimas que voy a comentar son -a y -t.

smartctl -t lanza una prueba automática de todo el disco. Necesita un parámetro indicando el tipo de prueba, y en el caso más largo puede durar varias decenas de minutos y comprobará el rendimiento eléctrico y mecánico del disco así como el rendimiento de lectura de las cabezas por toda la superficie. smartctl -a, por su parte, muestra toda la información disponible sobre el disco, incluidos los resultados de las pruebas automáticas. Como estas pruebas duran minutos, o decenas de minutos, no podemos observarlas. Todo lo que obtenemos al lanzar una de estas pruebas es:


# smartctl -t long /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in
off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in
off-line mode" successful.
Testing has begun.
Please wait 41 minutes for test to complete.
Test will complete after Mon May 12 05:44:03 2008

Use smartctl -X to abort test.

Aquí se nos informa de que (quizá) tengamos un rendimiento ligeramente menor del disco durante los próximos 41 minutos, porque la prueba ha comenzado. Se produce completamente en segundo plano, o sería mejor decir “fuera de plano”, ya que no ocurre bajo el control del Sistema Operativo en absoluto: todo ocurre internamente al disco, y lo único que vamos a obtener es el resultado.

smartctl -a, por su parte, muestra una enorme cantidad de información SMART sobre el disco: prácticamente toda la información SMART disponible. Normalmente es mejor utilizar una opción específica, como se puede ver en la página de manual (man).

Finalmente, quiero comentar que hay un demonio en el paquete smartmontools, llamado smartd, que se encarga de realizar las pruebas automáticas por uno. Funciona ejecutando smartctl de forma periódica (típicamente cada 30 minutos) y registrando todos los errores y los cambios de los valores de los parámetros en el registro del sistema (syslog). La configuración por defecto en Debian además enviará un mensaje al superusuario con cualquier problema detectado. No voy a explicarlo aquí porque quiero que se lean la documentación, que es concisa y clara, pero recuerden que para usarlo deben activarlo en /etc/default/smartmontools.

El paquete smartmontools ha estado disponible en Debian y Ubuntu desde hace mucho tiempo.

Hay quien ha preguntado por qué en los ejemplos todos los valores aparecen por encima de los límites. Es lo normal: los valores normalizados de los parámetros comienzan típicamente en 100 o 200, y a medida que el disco sufre van descendiendo. El problema lo tenemos cuando un parámetro desciende por debajo de su límite, no cuando está por encima. Aunque también hay que estar atento a las bajadas significativas de los parámetros aunque no leguen a los límites: son signos de que algo malo está pasando.

Como nota, los discos de Seagate tienen la costumbre de poner el parámetro de temperatura en su valor real, lo que lo convierte en uno de los pocos casos en los que un parámetro empeora cuando crece.

El escritorio que no cubría la pantalla

2008-09-22T16:47:00.008+01:00

NOTA: Actualizado con todos los datos y capturas de pantalla.

Hoy me tocó arreglar el sistema X-Window de un portátil, un Toshiba Satellite U300 13H. Ya lo había hecho una vez, pero no recordaba cómo. El caso es que el escritorio no cubría toda la pantalla: la barra del escritorio no tocaba el fondo ni llegaba completamente a la derecha.

Y claro, fueron unas cuantas horas tratando de averiguar lo que pasaba, en realidad de recordarlo, trasteando con el siempre servicial xrandr que acudió en mi ayuda y me dijo lo que pasaba: La tarjeta gráfica se confundía y pensaba que estaban activas a la vez la salida LDVS y la salida TV. Y trataba de mostrarlas ambas en el monitor. Como la salida TV tiene menos resolución que la LDVS, pues ahí estaba el problema:

crab:~> xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right)
LVDS connected 1280x800+0+0 (normal left inverted right) 286mm x 179mm
   1280x800       59.9*+   60.0
   1280x768       60.0
   1024x768       60.0
   800x600        60.3
   640x480        59.9
TV connected 1024x768+0+0 (normal left inverted right) 0mm x 0mm
   1024x768       30.0*
   800x600        30.0
   848x480        30.0
   640x480        30.0

La solución ya la había hallado, no recuerdo ahora dónde, cuando instalé este portátil por primera vez, cuando se compró. Esta vez, me lié con la opción Option "Enable" "false" cuando no es correcta, y la solución al final me la dió esta entrada de una bitácora que se llama, curiosamente, No pienso arreglar tu ordenador. Tenía que haber usado Option "Ignore" "true".

Para explicarlo un poco mejor, el fichero xorg.conf lleva una sección donde se configura el dispositivo (la tarjeta de vídeo), otra donde se configuran los monitores (porque puede haber varios), y otra donde se junta todo creando una "pantalla".

La solución es configurar dos monitores:

Section "Monitor"
        Identifier      "Configured Monitor"
        Option          "DPMS"
EndSection

Section "Monitor"
        Identifier      "Disabled Monitor"
        Option          "Ignore"        "true"
EndSection

y configurar la tarjeta para que ponga sus salidas en esos dos monitores, sacando así la molesta salida TV al monitor deshabilitado:

Section "Device"
        Identifier      "Intel Corporation Mobile GM965/GL960 Integrated Graphic
s Controller"
        Driver          "intel"
        BusID           "PCI:0:2:0"
        Option          "Monitor-LVDS" "Configured Monitor"
        Option          "Monitor-TV" "Disabled Monitor"
EndSection

Diseños de teclado (II)

2008-09-17T13:46:00.004+01:00

Siguiendo con lo escrito en "Diseños de teclado", esta vez he tenido que hacer algo semejante: que un teclado estadounidense pueda ser utilizado para escribir normalmente en castellano.

Gracias a la documentación que menciono allí ^[1] ^[2] ^[3] no tuve muchos problemas para conseguirlo. El modelo de teclado a utilizar era, evidentemente, el teclado estadounidense us, lo que, así solo, significa la variante basic, es decir us(basic). Pero el teclado us tiene otra variante, la internacional us(intl), que permite cosas como que las teclas con acentos se consideren teclas muertas: teclas que necesitan que se pulse otra después, como en el teclado castellano es normal.

Pero no quería poner el teclado us(intl) tal cual, porque redefine demasiadas teclas.

La solución ha sido elegir la variante de teclado compuesta us+us(intl), que utiliza como base el us(basic) y allí donde éste no llega le añade el us(intl).

Así, la sección correspondiente del fichero /etc/X11/xorg.conf la he modificado de

Section "InputDevice"

# keyboard added by rhpxl
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us+us(intl)"
EndSection

El estrangulador del procesador

2008-09-01T15:24:00.005+01:00

Los procesadores modernos (me refiero a la familia de los x86) tienen una característica muy interesante: el estrangulador (throttling) del procesador.

Muchas veces hemos oído hablar de características de los procesadores para portátiles como la de bajar la frecuencia de trabajo cuando se utiliza la batería, para que dure más. Pero el caso es que hay otras características que nos ayudan a hacer lo mismo, y mejor. Se trata de los estados de throttling del procesador, que fuerzan al mismo, independientemente de lo cargado que se encuentre, a <<echarse a dormir>> parte del tiempo. Estos estados se identifican con la letra T. El Intel Centrino Duo T2400 de mi portátil, por ejemplo, tiene 8 de estos estados de estrangulamiento, desde el T0 hasta el T7. Cuando está en el estado T0 el procesador no descansa: siempre está ejecutando algo, aunque sea el <<ciclo idle>>, y por lo mismo además siempre está gastando energía. En el estado T4, por ejemplo, el procesador estará dormido el 50% del tiempo: todas las operaciones que el usuario (o el sistema) trate de hacer, incluso a la máxima frecuencia, tardarán el doble de lo que tardarían en el estado T0.

Hoy en día, con núcleos Linux como el 2.6.26 que tengo funcionando, con las implementaciones modernas de ACPI, el estrangulador no es la vía preferida para cambiar la capacidad (ni el consumo) del procesador. Para eso están los cambios de frecuencia (los estados P del procesador), que son lo que normalmente podemos cambiar con herramientas de usuario como KPowersave. Otro día hablaré más profundamente sobre los estados P, los estados T, los estados S, los estados C, los estados G e incluso los estados D.

Antiguamente, cuando no se podía cambiar la frecuencia de los procesadores, los estados T eran la única manera de hacer que gastaran menos. Como expliqué arriba, esto se consigue poniendo el procesador a dormir por cortos períodos de tiempo, que en mi caso pueden llegar al 88% del tiempo total, dejando sólo el 12% del tiempo para ejecutar realmente instrucciones. Hoy, normalmente no se cambian estos estados salvo en caso de emergencia térmica: si el procesador está sobrecalentado por exceso de trabajo (y una ventilación o disipación deficiente), el sistema puede estrangular el procesador para obligarle a gastar menos energía (y así generar menos calor) incluso bajo las demandas más altas por parte del usuario.

Pero se pueden cambiar a mano para ver sus efectos.

Los núcleos Linux de hoy en día están cambiando sus interfaces ACPI del tradicional /proc al nuevo /sys, pero este cambio todavía no ha finalizado y nos las tenemos que ver con ambos. Para los estados T, en particular, vamos a requerir trastear con los ficheros de /proc/acpi/processor/. En este directorio veremos que hay un directorio por cada núcleo de procesador: /proc/acpi/processor/CPU0/, /proc/acpi/processor/CPU1/, etc. Utilicemos /proc/acpi/processor/CPU0/ como ejemplo. En su interior veremos varios ficheros, de los cuales nos va a interesar, en este caso, /proc/acpi/processor/CPU0/throttling. Este fichero nos indica qué estados de estrangulamiento soporta nuestro procesador (8 en el ejemplo inferior), qué tiempo duerme el procesador en cada uno de ellos y qué estado está en uso actualmente:

$ cat /proc/acpi/processor/CPU0/throttling
state count:             8
active state:            T0
state available: T0 to T7
states:
*T0:                  100%
T1:                  87%
T2:                  75%
T3:                  62%
T4:                  50%
T5:                  37%
T6:                  25%
T7:                  12%

En este ejemplo vemos que el sistema tiene 8 estados de estrangulamiento (state count), numerados de T0 a T7 (state available y la lista states), los tiempos de procesador activo de cada uno, del 100% activo (0% durmiendo) del T0 al 12% activo (88% durmiendo) del T7 (la lista states) y que el estado actual es el T0 (active state y el * en la lista states).

Se puede cambiar el estado a mano, siendo el superusuario, mediante una sencilla orden típica de /proc:

# echo 4 > /proc/acpi/processor/CPU0/throttling

o bien

# echo T4 > /proc/acpi/processor/CPU0/throttling

Si estás tratando de subirlo y no funciona, es que tu máquina está demasiado caliente y el sistema obliga al estrangulador a bajar el consumo para generar menos calor. Recuerda que cada watio gastado es un watio de calor que hay que sacar del sistema. Si sacas menos calor del que generas, el sistema se calienta y puede quemarse.

Un ejemplo: poner mi portátil sobre una esterilla aislante y poner la máquina a calcular hashes para el aMule pone la máquina en T7 independientemente de lo que yo haga. Simplemente levantarla 1cm de la esterilla aislante con unas pinzas de la ropa lleva al sistema a T4 casi inmediatamente y a T0 en unos 30 segundos. Y además en T0 el sistema responde mejor ;)

Información sobre la batería

2008-07-28T13:09:00.002+01:00

Recientemente los núcleos de Linux han dejado de proporcionar la información de la batería que antes se encontraba en /proc/acpi/battery/BAT0 y ahora se considera que utilizar /proc para esas cosas está desaconsejado, debiéndose utilizar /sys. Pero por ningún sitio encontré información sobre en qué sitio de /sys se encuentra ahora esa información.

Y positivamente no es en /sys/bus/acpi, /sys/firmware/acpi ni /sys/module/acpi.

Después de mucho buscar (incluso buceando en los parches de varias herramientas para adaptarse al cambio) lo he encontrado: /sys/class/power_supply.

My Review of Sun Fire X4600 Server

2008-07-03T19:03:00.002+01:00

Originally submitted at Sun Microsystems

The Sun Fire X4600 server, featuring AMD Opteron processors, packs the punch of two Xeon 4P servers in a more space-efficient and energy-efficient system for tremendous operating cost savings. Its modular design makes upgrading to future processor technologies simple and non-disruptive. The server'...

Insufficient disk space

By Noel "Envite" Torres from Valencia, Spain on 7/3/2008

Pros: Fast, Up to 8 Quad, Easy Set Up

Cons: Bulky, Small disk space

Best Uses: Science

Describe Yourself: Quality Oriented

At Universidad de Valencia we bought this machine for scientific simulations. We're very happy with it's ease of installation and configuration, and with it's calculating power with 8 Quad (that's 32 processors).
But the hard disk is absolutely insufficient. Best possible configuration is 576GiB which is by no means sufficient for a normal simulation in Physics.

I wrote a core complete review (in spanish) at my blog in http://denvite.blogspot.com/2008/07/maravilloso-sunfire.html

(legalese)

Maravilloso SunFire

2008-07-03T17:38:00.005+01:00

Hoy hemos instalado otra máquina con cuatro procesadores AMD Quad Core de 64 bits como los del TYAN que comentaba ayer. Esta vez, la máquina es una SunFire X4600 M2, de Sun Microsystems. Ha salido más cara por procesador, sin ninguna duda, pero a cambio me gusta más.

Una de las cosas que hacen, sin género de dudas, que esta máquina me guste más que la anterior es su procesador de servicio. Una pequeña tarjeta adicional integrada en la máquina que permite, incluso con la máquina apagada, con tal de que tenga corriente, ver el estado del hardware, encender la máquina, apagarla, reiniciarla, etc. No me cabe ninguna duda de que los fallos que ha estado teniendo la otra máquina, que tiene, repito, los mismo procesadores, caso de que se reprodujeran en esta máquina, hubieran sido más sencillos de atender. Con la otra máquina, cada vez que notábamos que la máquina no respondía, alguien tenía que acercarse a ver qué pasaba y darle al botón. Ahora, si notáramos lo mismo, podríamos conectar al procesador de servicio <<desde la playa>> y ver qué estaría ocurriendo, y en su caso, podríamos reiniciar la máquina sin tener que ir allí. Salvo, claro está, que el problema fuera un corte de luz para todo el armario. Todo eso gracias al sistema ILOM del procesador de servicio, que nos permite, además, acceder por red (HTTP, SNMP y SSH) o por consola serie.

Otra de las grandes ventajas, a mi entender, del SunFire X4600 M2 sobre el ordenador que comentaba ayer es la manera que tiene de organizar los procesadores y la memoria. Allí, cuatro procesadores iban en la placa base, y cuatro en una especie de <<placa base de expansión>>. Aquí los procesadores van, con su memoria asociada, en placas verticales, todas iguales (no cuatro preferentes y cuatro secundarios) que encajan en la placa base individualmente. Aparte de hacer más sencillo el cambio de un procesador (tan tonto como sacar una placa vertical, como se ve en la foto), encuentro el diseño más elegante y mejor pensado.

Otras ventajas, más secundarias desde mi punto de vista, son las cuatro tarjetas de red Gigabit, las cuatro fuentes de alimentación redundantes colocadas en vertical (el otro las tiene en horizontal), los cuatro ventiladores extraíbles (el otro tiene tres, y no forman túnel de aire) y el hecho de que la colocación de las placas de procesador evita una de las pesadillas de un administrador de sistemas en verano: que se estropee un ventilador de procesador. Al X4600 no se le pueden estropear porque no tiene: la ventilación frontal formando túnel de aire, con los procesadores (y sus disipadores de rejilla) justo detrás, hace todo el trabajo.

Entre lo malo está que, a consecuencia de lo anterior, se trata de una máquina que ocupa 4U.

Lo peor, los discos duros. Son discos SAS (eso es una <<Cosa Buena>> ®) pero de 2,5 pulgadas, lo que no permite tener los grandes discos propios de las máquinas de cálculo científico. El mayor disco soportado es de 146GiB, lo que nos da una capacidad total máxima de 576GiB, claramente insuficiente para cálculos científicos masivos, ya que una configuración normal para simulaciones científicas puede tener perfectamente seis discos de 500GiB cada uno. Y no es raro oír acerca de espacios de disco aún mayores. Total, que hemos acabado (gracias $DEITY por darnos RAID) con un espacio de disco de aproximadamente medio TiB para almacenar los resultados.

Eso sí, la instalación de la nueva OpenSuSE 11, recién salida del horno, con su flamante KDE 4, fue una delicia. En un ratito tuvimos la máquina completamente instalada, sin problemas de reconocimiento de <<hardware>> ni nada que se le pareciera. Ya está trabajando, y de momento no se ha caído.

Algo huele a podrido en OpenSuSE 10

2008-07-02T20:10:00.004+01:00

Una de las cosas que más ocupado me ha tenido estas últimas semanas es un ordenador que se quedaba bloqueado porque sí.

Se trata de una máquina TYAN (un Transport VX50), que venía del distribuidor (una pequeña empresa local, que lo montó en instaló el S. O.) con una placa base TYAN (la Thunder n4250QE (S4985-E)) para cuatro procesadores AMD Quad Core de 64 bits, y una placa de expansión de la placa base también TYAN (la M4985), para montar un total de 8 procesadores de núcleo cuádruple y 128GiB de memoria. Ah, y 8TB de disco.

¿A que mola? El caso es que la máquina, que venía del distribuidor con OpenSuSE 10 (la 11 no había salido aún), se quedaba bloqueada. Como suena. Simplemente estaba trabajando y de repente dejaba de responder. Todo. Ni contestaba al PING ni se veía nada en la pantalla. Y los leds del teclado, parpadeando.

Pensamos que era cosa de la temperatura, así que subimos la velocidad de los ventiladores en la BIOS. Se siguió cayendo.

Pensamos que era cosa del ECC, así que lo desactivamos en la BIOS. No estamos seguros, quizá se caía menos, pero se siguió cayendo.

Pensamos que era cosa de la memoria, así que le corrimos un memtest durante un fin de semana. Con 128GiB pues solamente le dió una vuelta a la memoria, pero estaba limpia. Otras pruebas en la que obligamos a la máquina a swapear de mala manera con cargas del orden de 400 no hicieron caerse la máquina.

Finalmente hemos pensado que fuera cosa del entorno gráfico. A fin de cuentas, ¿quién sabe? ¿Y qué falta hace un entorno gráfico en una máquina de cálculo científico? Hemos desactivado el entorno gráfico pasando el nivel de ejecución del 5 al 3. Y la máquina lleva dos días calculando sin parar.

¿Habremos acertado ya?

Lo peor es que si fuera eso, algo en OpenSuSE 10 (en su entorno gráfico, en particular) no está nada bien. Y de ser así, mi candidato a culpable es earlyxdm.

Pongamos un SAI al mundo

2008-06-27T12:27:00.006+01:00

Un ordenador.

Una subida de tensión.

¿Qué tenemos? Ordenador frito.

Y sabiendo el estado de la red eléctrica nacional, y más en estas fechas en que todo el mundo enciende el aire acondicionado, debería ser obligatorio que el dinero que salga de mis impuestos esté protegido, ¿no?

Me refiero a que debería ser obligatorio que los ordenadores de las instituciones públicas tuvieran SAIs (o mejor SS.A.I.) para evitar las pérdidas causadas por picos o apagones.

Pero bueno, el caso es que he conseguido 10 SSAI para proteger algunos de los ordenadores de quien ahora mismo hace como que paga mis facturas: el Departamento de Astronomía y Astrofísica de la Universidad de Valencia. Deberían haber sido prácticamente el doble, pero todavía hay gente que considera que el material de trabajo de <<su>> puesto de trabajo es suyo. Y se equivocan, pero yo no puedo obligarlos a hacer las cosas bien. Algunos me han dicho, incluso: <<¿SAI? Ni tengo ni quiero.>> Debería ser delito de malversación de caudales públicos.

Eso sí, cuando venga otro apagón generalizado, a mí que no vengan a quejárseme.

Bueno, a lo que íbamos. Ya he instalado el primero de esos SSAI. Un ordenador que antes estaba desprotegido, ahora está protegido.

El programa de elección para efectuar el apagado del ordenador ha sido Network UPS Tools (NUT), en su versión 2.2

El SAI elegido es un APC Back-UPS CS 500. No proporciona mucha autonomía a un ordenador grande con su pantalla, pero la idea no es proporcionar autonomía, sino evitar un casque por un mal apagado, de los que ya hemos tenido por aquí.

Me hubiera gustado elegir otra marca de SSAI. Las APC tienen buenas y malas costumbres. Entre las buenas, que son fiables como rocas y que tienen asegurado el suministro de baterías de recambio. Entre las malas, que no colaboran con los programadores de programas libres y tratan de obligarte a utilizar su pesado y patético programa PowerChute.

Gracias a $DEITY los SSAI de la serie CS se pueden enchufar por el puerto USB y responden aceptablemente al controlador usbhid-ups de NUT.

Así, tras bajar NUT y realizar los típicos ./configure, make y make install (lamentablemente el ordenador a proteger dispone de una distribución que no tiene paquetes para NUT), obtuve un precioso y funcional sistema. Luego fue cosa de tocar un poco los ficheros de configuración.

Como nota, el SAI informa de batería en estado crítico cuando se encuentra al 10% de su capacidad, lo que no da tiempo al ordenador para apagarse correctamente. Por ello, he tenido que utilizar la última pieza del conjunto, upssched, diseñada específicamente para apagar el sistema antes de que se alcance la condición de batería en estado crítico.

Algunas verdades

2008-06-24T20:34:00.003+01:00

Una imagen...

Diseños de teclado

2008-06-24T17:19:00.010+01:00

A consecuencia de una pregunta de un compañero, he pasado hoy buena parte de la tarde mirando documentación (ciertamente escasa) sobre el sistema XKB. Se trata de la capa que transforma las pulsaciones de teclas en símbolos que entienden las aplicaciones. Además, he mirado no solamente la propia documentación (sobre todo la muy completa de Ivan U. Pascal y la muy comprensible de Doug Palmer) sino los propios ficheros de definiciones y reglas de XKB. Allí me he dado cuenta de que existe un modelo de teclado llamado «latitude», equivalente en casi todos los aspectos al «pc105» que se supone que debería usar, solo que tiene correctamente asignadas las teclas 174, 176 y 160, es decir, <I2E>, <I30> e <I20> a las «pseudoteclas» XF86AudioLowerVolume, XF86AudioRaiseVolume y XF86AudioMute.
Así, sólo con haber cambiado el modelo de mi teclado en /etc/X11/xorg.conf de


Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "es"
EndSection


Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "latitude"
        Option          "XkbLayout"     "es"
EndSection

he conseguido que funcionen las teclas para subir o bajar el volumen.

Blog de Toscalix en castellano

2008-06-13T16:04:00.004+01:00

Bueno, hace mucho que no escribo en la desbitácora, al contrario que en la bitácora. Pero no ha sido por falta de trabajo, sino al contrario.

Pero en fin, al grano. He inaugurado la sección de Enlaces (quizá) interesantes (al fondo a la derecha, como el servicio) con la bitácora de un amigo y ex-jefe, Agustín Benito.

Él no es desarrollador, al contrario de lo que podría parecer ya que enlazo su bitácora en castellano (tiene otra en inglés) desde aquí. Es una cosa rara. Yo lo llamaría un intermediador. Busca gente que necesite programas libres, y tiene contacto con gente que hace o gestiona programas libres. Y gana dinero en el proceso. Bien es verdad que no demasiado: en ese plan tuvo una empresa en la que yo trabajaba. Éramos solamente nosotros dos, y la relación tenía una parte de jefe-empleado, obviamente, y otra parte de comercial-técnico. Yo a veces decía que él trabajaba para mí, como comercial de mis soluciones técnicas, y además me pagaba.

Finalmente yo me vine a la Universidad de Valencia a mantener sistemas y acabar de una vez mi doctorado, y él, dado que no se puede mantener una empresa técnica sin un técnico, cerró. Por el camino hicimos varias cosas interesantes, y a veces uno debe pararse y mirar atrás.

En colaboración con otras miniempresas como Neuroomante de Pedro Gracia (Lasarux) desarrollamos una solución de aula LTSP con UML para docencia informática que era un primor. O las soluciones de firma de discos duros que están en esta misma desbitácora. Pero no siempre había clientes, y había que comer todos los meses (él vivía de ello, y yo trabajaba a media jornada), y también nos tocó «pringar» con cuestiones de mantenimiento de sistemas Windows, casi siempre piratas, subcontratados para empresas de nuestro mismo estilo pero un poco más grandes, o instalar cableado.

En esa época aprendí mucho, no sólo como técnico (lo que debo agradecer sobre todo a Lasarux, Kuko y la gente más antigua de Fotón, ustedes saben quienes son, chicos, gracias por todo), sino sobre cómo llevar (y cómo no llevar) una empresa o un proyecto basados en programas libres. Toscalix, a su vez, creo que aprendió de mí algo de filosofía libre (no demasiado, porque interferiría en su trabajo, que es ganar dinero con ello), algo de sistemas, y sobre todo de cómo trabajar con programas libres y montar redes. O al menos eso quiero creer.

Bueno, la etapa ha acabado. Ahora yo, con todo lo que aprendí con él, mantengo ordenadores de cálculo científico en Valencia, y él, con todo lo que aprendió conmigo, trabaja en un proyecto de migración a programas libres en una comarca de Málaga. Y seguimos pensando diferente, y seguimos siendo amigos.

Como nos enseña la mecánica cuántica, quizá nuestros caminos (profesionales) nunca se vuelvan a cruzar, pero habernos cruzado ha alterado nuestras historias para siempre.

Gráficos en TeX

2008-01-17T12:10:00.000Z

Últimamente he tenido que escribir un trabajo académico. Lo he hecho en TeX porque me maravilla la capacidad tipográfica que tiene y la calidad del resultado final.

La mayor parte de los usuarios de TeX, en realidad, son usuarios de LaTeX. Si TeX hace el trabajo del cajista, LaTeX hace el del tipógrafo-compositor. En mi caso particular, prefiero utilizar TeX en vez de LaTeX (me gustan las cosas a bajo nivel).

Claro que TeX no está directamente preparado para soportar gráficos. Knuth, previendo la diversidad de dispositivos de salida y de tipos de gráficos, tan sólo diseñó la orden \special como una manera genérica de enviar datos a dispositivos de salida. LaTeX quedó mejor en ese sentido.

Fianlmente, la almendra del asunto es que los que usamos TeX, a pelo, también queremos poner gráficos en nuestros trabajos. Y no queremos lidiar con los \special. Esta semana he descubierto que la solución la aporta graphics-pln, gracias al cual podemos utilizar en TeX comandos de LaTeX como \includegraphics o \rotatebox.

La instalación de graphics-pln no merece siquiera tal nombre. Basta con descargar el fichero graphics.zip y descomprimirlo en el directorio de trabajo del documento. A partir de ahí, ya se pueden usar directamente las órdenes gráficas habituales.

En otra entrega hablaré de modos más generales de instalación.

Instrucciones de procesador (I)

2007-12-19T14:15:00.000Z

Uno de mis eternos proyectos, que retomo una y otra vez y que nunca termino, es diseñar y programar el emulador de un microprocesador.

El núcleo del proyecto de programación es el lector de instrucciones, y eso nos lleva a que una pieza fundamental del diseño es el juego de instrucciones.

Una de las operaciones fundamentales de un procesador es, evidentemente, leer un valor de la memoria y depositarlo en un registro o viceversa, escribir en la memoria un valor presente en un registro.

El diseño de procesador que he elegido implica que estas dos fundamentales operaciones se realicen únicamente desde el registro que he denominado A.

A estas operaciones les he asignado los mnemónicos LEE y SCR y los códigos binarios 0xc0 y 0xc1. Ambas operaciones necesitan como argumento una dirección de memoria.

Asumiendo que el procesador emulado es una estructura de datos que almacenamos en procesador, que la memoria es una matriz que almacenamos en memoria, y que el puntero de instrucción es el registro CI del procesador, el código de emulación para estas instrucciones lo he programado como sigue:

switch(memoria[chip->CI])
{
 case 0xc0 /* Instrucción LEE */
  chip->A=memoria[memoria[chip->CI+1]];
  break;
 case 0xc1 /* Instrucción SCR*/
  memoria[memoria[chip->CI+1]]=chip->A;
  break;
 /* Aquí el código para otras instrucciones */
}

Con este código, una instrucción de dos bytes como 0xc0 0x12 se desensambla como LEE 0x12, es decir, "coge el contenido de la posición de memoria 0x12 y cópialo en el registro A".

Continuaré más adelante...

Interprogramación de Fortran y C

2007-11-02T21:43:00.000Z

Estoy en Valencia encargado de mantener código.

Código en Fortran.

El problema de los códigos heredados, en general, es que son heredados. Uno no cuenta con sus propias costumbres de programación (indentado, nombrado de variables, comentarios en el código...) sino que tiene que adivinar sobre código ajeno.

Pero bueno, una cosa es eso, y otra Fortran. Fortran como lenguaje, tal y como se utiliza en Ciencia (códigos FORTRAN 77 heredados de estudiantes de doctorado en estudiantes de doctorado) es algo realmente asqueroso. A veces da la tentación de reprogramar en C, o de modernizar el código a Fortran 95.

La almendra de la cuestión es hacer esa reprogramación en C de rutinas que seguirán siendo llamadas desde Fortran, al estilo Fortran.

¿Funciones o subrutinas?

En C tenemos funciones. En Fortran tenemos funciones y subrutinas. Si tenemos que llamar a Fortran desde C, ¿cómo escribir en Fortran el código llamado?

Básicamente, si nuestra función en C retorna un valor, en Fortran usaremos una función. Si la función en C no retorna (void), en Fortran usaremos una subrutina.

Y viceversa, si en Fortran tenemos una llamada CALL, en C usaremos una función void, mientras que si en Fortran tenemos una llamada a función, en C usaremos una función del mismo tipo.

Nombres de funciones

Normalmente los compiladores de Fortran, en las tablas de símbolos de los ficheros objeto, cambian el nombre de los objetos a minúsculas (recordemos que en Fortran las mayúsculas y las minúsculas son equivalentes) y añaden un guión bajo al final del nombre.

Así, si desde C queremos llamar a una función o subrutina Fortran, debemos llamarla con su nombre escrito completamente en minúsculas y añadir un guión bajo al final.

Y si desde Fortran queremos llamar a una función C, ésta tiene que tener un nombre completamente en minúsculas y un guión al final, que en el código Fortran no pondremos. Si no es así, nos veremos obligados a programar en C un wrapper que siga esta convención y llame a la función C real.

Paso de variables

Es importante recordar que en Fortran las variables siempre se pasan por referencia, nunca por valor. Incluso si llamamos a una función con argumentos constantes.

Por ello, las funciones C que sean llamadas desde Fortran deben esperar que todos sus argumentos sean punteros, y las funciones o subrutinas Fortran que sean llamadas desde C deben ser llamadas proporcionándoles argumentos que sean punteros.

Hay que tener en cuenta, cuando se pasen matrices, que el nombre de la matriz, a secas, ya es un puntero en C, así que no hay que añadirle el asterisco delante.

Almacenamiento de matrices

En C las matrices se almacenan "por filas", o mejor expresado, el índice más a la derecha, el último, recorre secuencialmente los elementos de la matriz. En Fortran, en cambio, las matrices se almacenan "por columnas", es decir, el índice más a la izquierda, el primero, es el que recorre secuencialmente los elementos.

Por ello, cuando pasamos una matriz de Fortran a C o viceversa, debemos invertir el orden de todos sus índices.

También hay que tener en cuenta que mientras que en Fortran una matriz puede declararse con índices arbitrarios, que por defecto comienzan en 1, en C las matrices siempre comienzan con el índice 0.

Por la misma razón, todo programador decente de Fortran escribe bucles anidados en los que el bucle más interno recorre el primer índice, mientras que todo programador decente de C escribe bucles anidados en los que el bucle más interno recorre el último índice.

Bloques COMMON

En Fortran es común utilizar bloques COMMON como un modo de que todas las subrutinas y funciones puedan acceder a determinadas variables. Es posible hacer uso desde C de estos bloques COMMON, si tenemos en cuenta que se presentan como estructuras de datos cuyo contenido es el conjunto de variables que en C correspondan a las variables Fortran.

Es necesario tener en cuenta que lo mencionado acerca de los identificadores de funciones Fortran en C también se aplica a los nombres de estas estructuras y a los de las variables que las componen.

Es necesario fijarse con cuidado, si tenemos problemas de acceso a estas variables, en las direcciones resultantes para las variables flotantes de doble precisión. Los compiladores de C pueden añadir relleno en las estructuras de datos para que los límites de las variables se alineen correctamente, y los de Fortran no pueden hacerlo en sus bloques COMMON.

Conectarse a redes inalámbricas

2007-09-15T23:25:00.000+01:00

Acabo de conectarme por primera vez a una red inalámbrica con cifrado WPA. No es difícil, si sabes cómo hacerlo, y yo no sabía. Pero en cuanto miré en Internet desde otro ordenador que ya estaba conectado, vi que tenía que usa wpa_supplicant, que por suerte ya tenía instalado. Cosas de las distros modernas.

Bastaron luego 5 minutos de buceo en las páginas de manual correspondientes, y saqué un guión que me hace el trabajo.

Pero bueno, antes de hablar del guión para WPA, hablaré del guión para WEP, que es más sencillo.

El guión para WEP

Este guión supone que nos vamos a conectar a una red inalámbrica cifrada mediante WEP, usando una tarjeta de red inalámbrica que nuestro ordenador llama eth1 (también podía ser wlan0). También supone que tenemos un servidor de nombres instalado en el equipo, algo que yo siempre hago, salvo que necesite un servidor de la red local para resolver nombres locales.

La clave de la red WEP es 01:23:45:67:89:AB:CD:EF:01:23:45:67:89 (por ejemplo) y transmite en el canal 9 (por poner). Daremos a nuestro equipo la dirección IP 192.168.1.58 (por dar una) ya que la dirección IP del punto de acceso es 192.168.1.1 (como podía ser otra).

# /usr/local/sbin/conf_wep
#Configuración inalámbrica de la tarjeta
iwconfig eth1 key restricted 01:23:45:67:89:AB:CD:EF:01:23:45:67:89 channel 9 ap auto
#Configuración IP
ifconfig eth2 192.168.1.58
#Borramos la ruta por defecto, por si la tarjeta eth0 (la de cable) había establecido una y asignamos la que corresponde
route del default
route add default gw 192.168.1.1
#Configuramos el resolvedor de nombres para indicarle que es el equipo propio, y lo arrancamos si estaba parado.
echo nameserver 127.0.0.1 > /etc/resolv.conf
/etc/init.d/bind9 restart

El guión para WPA

El guión para WPA es muy parecido al de WEP, solo que además hay que configurar wpa_supplicant. Esto lo hacemos primero, en un fichero que podemos llamar, por ejemplo, /etc/wpa_supplicant.conf (aunque podemos tener varios, si solemos conectar el portátil a varias redes WPA distintas):

# /etc/wpa_supplicant.conf
network={
   ssid="Mi Red WPA"
   psk="La clave de mi red WPA"
}

Luego, la configuración de la tarjeta es muy similar, solo que en vez de proporcionar directamente los parámetros inalámbricos le dejamos ese trabajo a wpa_supplicant:

# /usr/local/sbin/conf_wpa
#Configuración inalámbrica de la tarjeta
wpa_supplicant -B -ieth1 -c/etc/wpa_supplicant.conf
ifconfig eth2 192.168.1.58
route del default
route add default gw 192.168.1.1
echo nameserver 127.0.0.1 > /etc/resolv.conf
/etc/init.d/bind9 restart

Y ya está, a trabajar.

Hotplug en Xen

2007-08-17T20:38:00.000+01:00

Xen es un sistema de paravirtualización (enlace en inglés), es decir, una manera de correr varios sistemas operativos en una máquina física, cada sistema creyendo que corre en una máquina real cuando lo hace en una máquina virtual con las características que hayamos definido.

Es paravirtualización, y no virtualización, porque los sistemas que van a correr en las máquinas virtuales deben ser modificados para correr sobre Xen. No obstante, las últimas versiones de Xen ofrecen virtualización real si se utilizan sobre procesadores de última generación, con instrucciones específicas.

El caso es que la máquina virtual no utiliza discos duros reales, sino elementos que desde la máquina real se le exportan como tales. Dichos elementos pueden ser un disco real, una partición o un fichero, y desde la máquina virtual se verán como un disco duro o una partición.

Entre las virtudes de Xen está la posibilidad de añadir o eliminar tales elementos de la máquina virtual en caliente, como si se enchufaran o desenchufaran de ella.

Y ahora, la almendra del asunto: Quiero que cuando enchufe un dispositivo en la máquina real (llamada "el hierro"), se enchufe automáticamente a la máquina virtual.

Esta solución la desarrollé yo, a partir de una idea de Kuko "Maestro Xen" Armas, cuando, teniendo otras cosas mejores que hacer en la empresa (Grupo CPD), me empeñé en sacar adelante la idea en vez de darlo por imposible.

El primer paso es detectar que se ha enchufado un dispositivo determinado al hierro. De eso se encarga udev. El segundo paso es introducir ese dispositivo en la máquina virtual. De eso se encarga xm, uno de los comandos de Xen.

Y en medio, hay que decidir a qué máquina virtual, de las varias que puede haber corriendo, se debe enchufar el dispositivo introducido. De esto se encarga XenHotplug, la solución que he desarrollado.

XenHotplug se compone de reglas de udev, guiones shell llamados desde esas reglas y un directorio de registro. Uno de esos guiones shell utiliza la firma de discos que presentaba en el artículo anterior.

Reglas de udev

Debemos crear un fichero de reglas de udev. Residirá en el directorio /etc/udev/rules.d y lo podemos llamar, por ejemplo, 10-local.rules. Ese nombre hará que se ejecute después de ciertas reglas fundamentales (las 5-early.rules) pero antes que el resto de reglas predefinidas.

En dicho fichero detectaremos la introducción o eliminación en el sistema de un dispositivo determinado y diremos qué hay que hacer con él:

SUBSYSTEM=="block", SYSFS{product}=="Mass Storage Device", \
 SYSFS{manufacturer}=="Prolific Technology Inc.", \
 SYSFS{start}=="63", ACTION=="add", \
 PROGRAM="/usr/local/sbin/identify.sh %P", \
 SYMLINK+="externalusbdisk%c", \
 RUN+="/usr/local/sbin/action.sh %c %k"

SUBSYSTEM=="block", ACTION=="remove", \
 RUN+="/usr/local/sbin/action.sh 0 %k"

La primera regla detecta la introducción en el sistema (ACTION=="add") de un dispositivo de bloque (SUBSYSTEM=="block") que puede ser cualquier cosa que se comporte como un disco duro externo o un disquete externo, que sea de la clase de dispositivos tipo disco (SYSFS{product}=="Mass Storage Device"), de una determinada marca (SYSFS{manufacturer}=="Prolific Technology Inc.").

Esto detectará la introducción de cualquier dispositivo de bloque, es decir, tanto el disco externo como sus particiones. Hay que tener en cuenta que al enchufar el disco, se genera un evento de introducción del disco completo, pero además el núcleo (kernel) del sistema revisa el disco y detecta sus particiones, que son añadidas al sistema, además del propio disco. Por eso, cuando enchufamos un disco particionado, aparecen los dispositivos correspondientes a las particiones, y no tenemos que crearlos a mano.

La regla, además, distingue si se trata del evento correspondiente al disco completo o a la partición, ya que la pieza SYSFS{start}=="63" sólo la cumple la primera partición. De esta manera la regla no casa con el disco completo, ni con las restantes particiones de un disco, sino sólo con la primera.

La siguiente pieza de la regla (PROGRAM="/usr/local/sbin/identify.sh %P") llama a un programa (guión de shell) de identificación del disco, que nos dirá de qué disco se trata exactamente. Así podremos distinguir los discos de esa marca y modelo que queremos que se enchufen a la máquina virtual de los que no. El programa se llama con un argumento (%P) que indica qué nombre de dispositivo se ha asignado al disco completo.

El programa proporciona un número de dispositivo, si se trata de un disco conocido (para lo que usamos la firma del disco) o la cadena NOID si se trata de un disco no identificado. En cualquiera de los dos casos, se crea un enlace simbólico /dev/externalusbdiskX (donde X es el número proporcionado antes), es decir, puede aparecer un enlace como /dev/externalusbdisk2 para el disco identificado como 2, o /dev/externalusbdiskNOID para un disco no identificado, gracias a la parte de la regla que dice SYMLINK+="externalusbdisk%c".

Finalmente, se ejecuta otro programa (guión de shell), con el dispositivo y el enlace simbólico ya creados, al que se pasan como argumentos el mismo número o NOID establecido antes y el nombre real del dispositivo (RUN+="/usr/local/sbin/action.sh %c %k"). Este programa borrará el enlace /dev/externalusbdiskNOID, si se trata de un dispositivo no identificado, o añadirá la partición a la máquina virtual y la registrará, si se trata de un dispositivo identificado.

La segunda regla detecta la retirada del sistema (ACTION=="remove") de cualquier (no podemos pedir mucha información acerca de un dispositivo ya retirado, ¿no?) dispositivo de bloque (SUBSYSTEM=="block"), y ejecuta el mismo programa que en el caso anterior, que en esta ocasión detectará si el dispositivo está registrado como insertado en la máquina virtual y, en tal caso, lo eliminará de la misma y lo desregistrará.

Guiones shell

Ahora veremos los programas que son llamados desde udev. El primero es identify.sh:

#!/bin/bash
# fichero /usr/local/sbin/identify.sh de XenHotplug

disp=$1
gen_id=`cat /usr/local/lib/identify.in`
disk_id=`dd if=/dev/$1 count=3 bs=1 skip=440 2> /dev/null`
disk_sn=`dd if=/dev/$1 count=1 bs=1 skip=443 2> /dev/null`
disk_sn_f=`echo -n $disk_sn|od -A n -N 1 --format=u`
if [ "$disk_id" = "$gen_id" ] ; then
        echo $disk_sn_f
else
        echo NOID
fi

Como se puede ver, el programa guarda en la variable $disp el nombre del dispositivo padre que la regla de udev le pasa como argumento, a continuación guarda en la variable $gen_id el contenido del fichero /usr/local/lib/identify.in, que es la firma de disco que empleamos para reconocerlos, y a continuación lee datos del propio disco.

Primero lee los bytes que deberían tener la firma de disco y los almacena en la variable $disk_id, y luego lee el byte de número de serie y lo almacena en la variable $disk_sn. Este número de serie, que es un byte con un valor entre 0 y 255 y que por lo tanto puede representar un carácter cualquiera, hemos de transformarlo en una cadena de texto para poderlo comparar, por eso lo formateamos como tal y lo almacenamos en la variable disk_sn_f.

Finalmente, si la firma del disco es la que esperamos, devolveremos el número de serie, que la regla udev empleará como ya hemos visto, y si el disco no es uno de los que buscamos, devolveremos la cadena NOID.

Obviamente, el contenido de /usr/local/lib/identify.in es la firma binaria que esperamos:

# hexdump /usr/local/lib/identify.in -e "\"%x\""
eeeeee

El segundo programa, action.sh, es el encargado de registrar y desregistrar los dispositivos, y de insertarlos y eliminarlos de la máquina virtual, así como de borrar el enlace simbólico /dev/externalusbdiskNOID en su caso:

#!/bin/bash
# fichero /usr/local/sbin/action.sh de XenHotplug

virt=mimaquinavirtual

if [ "$ACTION" = "add" ] ; then
  if [ "$1" = NOID ] ; then
    rm -f /dev/externalusbdisk$1 
  else
    mkdir /var/xenhotplug/$1
    echo $2 > /var/xenhotplug/$1/devname
    /usr/sbin/xm block-list $virt > /var/xenhotplug/$1/prelist
    /usr/sbin/xm block-attach $virt phy:externalusbdisk$1 hdb$1 \
      w 2>&1
    /usr/sbin/xm block-list $virt > /var/xenhotplug/$1/postlist
    diff -u /var/xenhotplug/$1/{pre,post}list > \
      /var/xenhotplug/$1/difflist
    cat /var/xenhotplug/$1/difflist | grep ^+ | tail -n -1 | \
      awk '{print \$1}'|awk -F + '{print \$2}' > \
      /var/xenhotplug/$1/vdev
  fi
else
  if [ "$ACTION" = "remove" ] ; then
    for file in /var/xenhotplug/* ; do
      filecont=`cat $file/devname`
      if [ "$filecont" = "$2" ] ; then
        vdev=`cat $file/vdev`
        /usr/local/sbin/assure-detach.sh $virt $vdev 2>&1
        rm -rf $file
      fi
    done
  fi
fi

El código actual no es exactamente ese, sino que incluye varias líneas de depurado y de registro que aquí no se muestran por simplicidad.

Es obvio que se trata de código aún no muy pulido, como en el guión shell anterior, no obstante hace su trabajo bastante bien. Eso sí: asume que la máquina virtual se llama mimaquinavirtual y que es la única máquina en la que insertamos dispositivos por esta vía, y asume que está permanentemente encendida.

Bueno, al grano. En primer lugar, vemos que hay dos grandes bloques de código, el primero se ejecuta si la variable de entorno $ACTION tiene el valor add y el segundo si tiene el valor remove. Esta variable de entorno la establece udev para el programa que ejecuta cuando se produce un evento.

El primer bloque, correspondiente a add, se subdivide en dos partes. Por un lado, si el programa se llama con un primer argumento de NOID, que recordemos es lo que ocurre cuando se introduce un disco no firmado, el programa borra el enlace simbólico espúreo y sale. Por otro lado, si el programa se llama con cualquier otro argumento supondremos que se trata del número de disco y entraremos en harina.

En primer lugar crearemos el directorio donde registramos este disco (mkdir /var/xenhotplug/$1), lo registramos en un fichero en ese directorio (echo $2 > /var/xenhotplug/$1/devname, hallamos la lista de dispositivos conectados a la máquina virtual (/usr/sbin/xm block-list $virt > /var/xenhotplug/$1/prelist), insertamos el disco en la máquina virtual (/usr/sbin/xm block-attach $virt phy:externalusbdisk$1 hdb$1 w 2>&1) y volvemos a hallar la lista de dispositivos conectados (/usr/sbin/xm block-list $virt > /var/xenhotplug/$1/postlist). Esto hay que hacerlo así porque no es posible determinar el número de dispositivo que Xen asigna a cada dispositivo insertado.

De hecho sí es posible, ya que el número asignado es una combinación de los números mayor y menor de dispositivo, pero aparte de complicado sólo vale cuando la máquina virtual es Linux.

Debido a ello debemos determinar el número de dispositivo asignado, para lo que hallamos la diferencia entre las dos listas de dispositivos (diff -u /var/xenhotplug/$1/{pre,post}list > /var/xenhotplug/$1/difflist), que es la línea correspondiente al dispositivo añadido, y extraemos de ella el citado número (cat /var/xenhotplug/$1/difflist |grep ^+|tail -n -1|awk '{print \$1}'|awk -F + '{print \$2}' > /var/xenhotplug/$1/vdev) y lo registramos también. Trabajo hecho.

Por otro lado, el segundo bloque, que se ejecuta cuando se retira un dispositivo, parece un poco más sencillo. Revisa a través de todos los dispositivos registrados en busca del que acaba de desaparecer (for file in /var/xenhotplug/* ; do ... done), poniendo temporalmente el nombre de cada uno en la variable $filecont (filecont=`cat $file/devname`) y comparándolo con el que buscamos (if [ "$filecont" = "$2" ] ; then ... fi). Cuando lo encuentra, registra temporalmente en la variable $vdev el número de dispositivo buscado (vdev=`cat $file/vdev`), llama a otro programa que se asegura de desconectar ese dispositivo de la máquina virtual (/usr/local/sbin/assure-detach.sh $virt $vdev 2>&1) y desregistra el dispositivo (rm -rf $file).

Directorio de registro

Bueno, el funcionamiento del directorio de registro quedó ya explicado arriba, con el fichero que lo usa, pero en resumen: el directorio /var/xenhotplug se llena con otros directorios, uno por cada dispositivo registrado. En el interior de estos se generan varios ficheros, de los cuales sólo son importantes dos, /var/xenhotplug/X/vdev, que contiene el número de dispositivo virtual Xen, y /var/xenhotplug/X/devname, que contiene el nombre de dispositivo del hierro que se utilizó para añadir a la máquina virtual. Crear uno de estos directorios con esos dos ficheros es lo que llamamos registrar un dispositivo, y borrarlo es lo que llamamos desregistrarlo.

assure-detach.sh

Estoooo... no lo voy a presentar. No está acabado. Y de hecho no funciona bien (aún). Pero básicamente lo que hace es llamar a /usr/sbin/xm block-detach $virt $vdev. El problema que tiene en este momento es que si el dispositivo está en uso en la máquina virtual, ésta ignora la orden de eliminarlo. Estoy trabajando en ello.

Firmar discos duros

2007-08-17T13:03:00.000+01:00

PUBLICADA, PERO PENDIENTE DE MEJORAR EL FORMATO (no habrá cambios de contenido, salvo correcciones)

¿Cómo distinguir entre sí dos discos duros?

Evidentemente, la pregunta no es cómo distinguirlos por fuera, para eso basta con una pegatina. Sino cómo distinguirlos desde el ordenador.

La respuesta típica sería usar el número de serie. Una aplicación sencilla como smartctl nos da tan interesante dato, que además es único para cada disco.

Vale. Pero es que tengo el disco en una de esas cajas USB tan monas, que me dejan usar como disco externo USB un disco IDE.

Pues la respuesta general sería que lo llevo chungo. No obstante, aquí viene la solución. La he desarrollado cuando me surgió la necesidad de distinguir entre sí discos externos que utilizamos en Grupo CPD (la empresa para la que trabajo) para hacer copias de seguridad con Espiral (un programa que no uso) o con Dirvish (que yo sí uso, es la base de Espiral, y está basado en el viejo y eficaz rsync).

Un disco particionable almacena su tabla de particiones en el sector de arranque, ese lugar tan conocido llamado a veces MBR, objetivo de virus y elementos indeseables semejantes.

El sector de arranque de un disco particionable cualquiera, independientemente de que se utilice en Windows o Linux (no me comprometo con otros sistemas), es el primer sector del disco duro, es decir, los primeros 512 bytes, y tiene una estructura muy definida.

Los primeros 440 bytes (del 0 al 439) contienen el cargador de arranque del sistema. Es un programa muy pequeño que se carga en memoria al arrancar el ordenador, y se encarga de arrancar el ordenador desde una de las particiones disponibles. Ejemplos de programas de este tipo son el MBR de MS-DOS, LILO y la primera etapa (stage 1) de GRUB.

Los 64 bytes del 446 a 509 contienen la tabla de particiones. Y los dos últimos (510 y 511) contienen una firma especial, los números 55h y AAh, que identifican el sector completo como un sector de arranque.

Y ¿qué pasa con los bytes 440 al 445 de los que no he hablado?

Algunos sistemas, como Windows NT y sus sucesores, los emplean como un modo de identificar cada disco. El fdisk de Linux, además, no los toca. No me comprometo con otros programas como LILO, GRUB o el fdisk de MS-DOS/Windows.

Así, los 4 bytes del 440 al 443 son llamados "Número de serie de disco de Windows NT", y los otros dos, 444 y 445, no se emplean.

Personalmente empleo esos 4 bytes para firmar los discos IDE en cajas USB en algunos de mis sistemas. El primer disco contiene los bytes EE EE EE 01 (hexadecimal, en orden de disco, no olvidemos que la arquitectura Intel x86 almacena las palabras de 2 bytes con el byte de menor peso delante). El segundo disco contiene los bytes EE EE EE 02, y así sucesivamente. Aún no he llegado a tener 255 discos externos...

¿Y cómo lo hago? Fácil de lo fácil. Me descargo el sector de arranque del disco que quiero tocar, por ejemplo con dd:

dd if=/dev/sdb of=sdb_mbr count=1 bs=512

lo edito con un editor hexadecimal:

khexedit sdb_mbr

y lo vuelvo a meter en el disco:

dd if=sdb_mbr of=/dev/sdb

Y ya tengo mi disco firmado.

Para beneficio de los usuarios del editor hexadecimal, y ya que las direcciones suelen venir en hexadecimal, las repito en ese formato:

Código	0 a 439	0000h a 01B7h
Número de serie de disco de Windows NT	440 a 443	01B8h a 01BBh
Sin uso	444 a 445	01BCh a 01BDh
Tabla de particiones	446 a 509	01BEh a 01FDh
Firma mágica AA55h	510 a 511	01FEh a 01FFh

Certificados X509 para Apache 2 (I): Clave de la Autoridad Certificadora

2007-08-13T20:51:00.002+01:00

PUBLICADA, PERO PENDIENTE DE MEJORAR EL FORMATO (no habrá cambios de contenido, salvo correcciones)

Bueno, a ver cómo van las cosas. Llegas un día y decides que quieres cambiar de protocolo: tu servidor Apache, con la costumbre de escuchar por el puerto 80 (HTTP), quieres que se ponga a escuchar en el puerto 443 (SSL) para usar eso que llaman el "protocolo HTTPS".

En una relación cifrada cliente-servidor como esa normalmente hay tres partes implicadas, no dos. Está el cliente, que no tiene motivos para confiar en el servidor, está el servidor, que no tiene motivos para confiar en el cliente, y está la Autoridad Certificadora. Así, con mayúsculas. Y la idea es que tanto el cliente como el servidor confían en la Autoridad Certificadora. Así, si el servidor presenta al cliente un documento de identidad certificado por la Autoridad Certificadora, el cliente puede estar seguro de que el servidor es quien realmente dice ser, y no un impostor.

Por eso, el papel de la Autoridad Certificadora es tan importante. Si he de meter mi número de tarjeta de crédito para hacer un pago en una página, quiero estar seguro de que el servidor que lo va a recibir es quien dice ser, y estoy seguro si mi navegador me dice que lo es.

Mi navegador me lo dice si el servidor se identifica mediante un certificado firmado por una Autoridad Certificadora en la que confíe. Y los navegadores confían en unas pocas Autoridades Certificadoras que tienen un negocio enorme con la venta de certificados. Evidentemente, los navegadores no confiarán en los certificados de cualquier autoridad certificadora, ya que cualquier ladrón informatizado que falsee una página puede falsear también su certificado creando una autoridad certificadora falsa.

Así que si no quieres pagar los 1500 (sí, mil quinientos) dólares que Verisign^[1] u otros piratas semejantes cobran por un certificado, o si simplemente tienes algún motivo para convertirte en tu propia CA (Certificating Authority - Autoridad Certificadora), puedes hacerlo sin demasiados problemas (igual que lo haría el falsificador). Ten en cuenta que un servidor con SSL no funcionará sin un certificado.

Sólo necesitas tener instalado el paquete openssl, que proporciona las piezas y programas necesarios.

Crear la clave maestra de la CA

Lo primero es pensar en dónde almacenaremos todos los ficheros sensibles que vamos a crear. Lo ideal sería que creáramos un directorio sólo para esas cosas, con permisos adecuados, y que nos metiéramos en él antes de empezar a trabajar.

EDITO: He mejorado estas órdenes en una nueva entrada.

Nota: los comandos introducidos a partir de ahora son válidos en un sistema operativo de tipo UNIX, en particular yo los he probado en Linux, en la distribución Debian.

Antes de crear la clave crearemos un directorio llamado private para almacenar en él la clave privada:

mkdir private

A continuación creamos la clave:

openssl genrsa -des3 -out private/cakey.pem 2048

El comando openssl es la base de todo nuestro trabajo. Tiene un buen número de subcomandos para diferentes tareas. En esta ocasión utilizamos el subcomando genrsa para, precisamente, generar una clave RSA. Las opciones indican, por ese orden, que la clave generada estará protegida mediante un cifrado 3DES con contraseña (-3des) y que se almacenará en el directorio private en el fichero cakey.pem (-out private/cakey.pem), mientras que el argumento 2048 indica que la clave generada tendrá 2048 bits de longitud. La clave se almacenará en formato PEM, por eso ponemos la extensión como .pem, mientras que el nombre cakey indica, literalmente, que se trata de la clave de la CA. Esa es, además, la razón (aparte de que lo recomienda la documentación) de que la guardemos en el directorio private.

En la documentación oficial de OpenSSL se detalla que el subcomando genrsa es obsoleto y se debería usar en su lugar el subcomando genpkey, en cuyo caso la línea de órdenes sería:

openssl genpkey -des3 -outform PEM -out private/cakey.pem -pkeyopt rsa_keygen_bits:2048

Ojo: No he probado esta línea.

Bueno, en cualquier caso, como hemos pedido que la clave quede protegida mediante contraseña, tendremos que introducir la contraseña elegida, y volverla a introducir para confirmar que la hemos escrito bien:

openssl genrsa -des3 -out private/cakey.pem 2048
Generating RSA private key, 2048 bit long modulus
..........................................+++
.............................................+++
e is 65537 (0x10001)
Enter pass phrase for private/cakey.pem:
Verifying - Enter pass phrase for private/cakey.pem:

Como se puede ver, el generador nos indica que está creando una clave privada RSA de 2048 bits, con el exponente 65537, lo que es un dato técnico que no nos importa ahora.

¿Y qué son todos esos puntitos y cruces? Pues muy sencillo: hay que encontrar dos números primos, y se prueban números al azar a ver si lo son. Cada puntito es un número probado que pasa una prueba de primalidad sencilla, y cada cruz es un número que pasa una prueba mayor. El salto de línea es un número que pasa todas las pruebas, es decir, que es uno de los dos números primos que estamos buscando.

Ojo: no pierdas nunca la contraseña que has introducido para cifrar la clave privada de la CA. Sin esa contraseña, toda la estructura de la CA queda inutilizada.

Seguiré en otro artículo con la creación del certificado raíz, la creación de la clave del servidor y la creación del certificado del servidor.

Comienza la desbitácora

2007-08-13T20:43:00.000+01:00

Bueno, aquí estamos.

He creado esta desbitácora (bitácora de desarrollo, igual que devlog de developer log) para ir apuntando todo lo que vaya descubriendo sobre la informática y el desarrollo de aplicaciones informáticas... y matemáticas.

No busquen aquí pensamientos ni cosas parecidas. Para eso está la bitácora madre: Envite.