Bitacora de mi sistema Linux

Cierre

2009-12-02T15:52:00.001+01:00

Aprovecho para cerrar oficialmente este blog.

Ya he aprendido lo suficiente, y los sistemas Linux son cada vez más fáciles y sencillos, de forma que ya no necesito documentar mis avances o soluciones por ser triviales.

Manifiesto en defensa de los derechos fundamentales en internet

2009-12-02T15:51:00.001+01:00

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que...

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Este manifiesto, elaborado de forma conjunta por varios autores, es de todos y de ninguno. Si quieres sumarte a él, difúndelo por Internet.

Jugando con la carga de módulos del kernel: rtc y rtc_cmos

2007-12-04T13:56:00.000+01:00

Desde hace un tiempo vengo observando que al arrancar el sistema se trata de iniciar el servicio mplayer, devolviendo un error:

MPlayer: loading module rtc
FATAL: Error inserting rtc (/lib/modules/2.6.22-2-k7/kernel/drivers/char/rtc.ko): Input/output error Failed! ....
creating /dev/rtc, Error! cannot find /proc interface for max-us er-freq.

Investigando un poco parece que trata de cargar el módulo rtc y después hacer modificaciones en max-user-freq. Se supone que esto mejora la respuesta en tiempo real, cosa que beneficia a mplayer a la hora de reproducir el contenido multimedia sin saltos ni cortes.

El problema es el módulo rtc_cmos, que se carga antes de iniciarse el servicio mplayer. Este módulo impide la carga del módulo rtc por ser incompatibles (no pueden estar ambos cargados).

Tras iniciarse el sistema puedo descargar el módulo rtc_cmos mediante:

# rmmod rtc_cmos

Y cargar el módulo rtc:

# modprobe rtc

Tras esto, trato de iniciar el servicio mplayer, está vez con éxito:

/etc/init.d/mplayer start
MPlayer: raising max-user-freq of RTC from 64 to 1024

Efectivamente, parece tener un mejor comportamiento a la hora de reproducir vídeo y audio. Vamos a intentar hacer que cargue rtc al iniciarse el sistema.

modconf es un programa de Debian que permite configurar los módulos que se cargan al inicio. El módulo rtc_cmos (PC-style 'CMOS') se encuentra bajo la rama /kernel/drivers/rtc, y el módulo rtc (Enhanced Real Time Clock Support) se encuentra bajo la rama kernel/drivers/char.

Ninguno está seleccionado para ser cargado. Si selecciono rtc para ser cargado falla la carga por que durante el arranque se carga antes rtc_cmos.

Bien, probemos otra cosa. El fichero /etc/modprobe.d/blacklist contiene una lista de módulos que no se deben cargar. Se puede poner ahí el módulo rtc_cmos a ver si evitamos su carga. Pero en dicho archivo pone:

# This file lists modules which will not be loaded as the result of
# alias expansion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.
# This file is provided by the udev package.

Mala pinta, no creo que funcione... y efectivamente no funciona.

Última solución, el fichero /etc/rc.local. Este fichero se ejecuta al final del arranque multiusuario y sirve para especificar órdenes que se quieran ejecutar al final del arranque (se entiende que para hacer algún ajuste fino del sistema). No me gusta mucho, pero ahí se pueden añadir las siguientes líneas:

rmmod rtc_cmos
modprobe rtc
/etc/init.d/mplayer start

Así se descarga el módulo rtc_cmos, se carga el módulo rtc y se inicia el servicio mplayer que modifica el max-user-freq de 64 a 1024 y que aparentemente mejora la respuesta en tiempo real (esperemos que no provoque otros efectos no deseados).

Copias de seguridad con Rsync

2007-12-03T18:53:00.001+01:00

Actualmente se guarda demasiada información en los ordenadores personales como para arriesgarse a una pérdida de datos debido a un falló del disco duro, subidas de tensión y otros desastres varios.

Es posible ir haciendo copias de seguridad en DVD, pero es lento, tedioso, y los DVD son ya algo pequeños comparado con la capacidad de los discos duros. Además, la durabilidad de un DVD no está especialmente asegurada. Personalmente, creo que es un medio muy poco fiable.

También es posible usar RAID, pero es quizá una solución no demasiado adecuada para este problema. Ciertas configuraciones de RAID permiten tener dos discos duros con la información duplicada en ambos de forma transparente al usuario. Sin embargo, exige dos discos duros iguales, copia toda la información sin posibilidad de discriminar la que es interesante de la que no, y además puede tener ciertos efectos secundarios no deseados (la velocidad de escritura puede ralentizarse, aunque bien es cierto a cambio puede incrementar la velocidad de lectura). También hay que tener en cuenta que mediante RAID un error humano o de software que borre o sobreescriba datos y ficheros no es recuperable ya que el sistema operativo se encargará transparentemente de hacerlo en ambos discos duros a la vez.

La solución escogida aquí es hacer una copia de seguridad mediante rsync a otro disco duro. Rsync se encarga de hacer el trabajo sucio de copiar el contenido de los datos originales a la copia de seguridad. Es inteligente, por lo que sólo copia los ficheros que han sido alterados y es capaz de enviar solamente aquellas partes de cada ficehro que han sido modificadas, ahorrando mucho tiempo, especialmente si la copia se hace a través de la red.

En Kriptópolis hay un excelente artículo al respecto que permite realizar cuatro copias incrementales al día más una completa, guardando las 3 últimas copias de seguridad. Dado que ahí esta muy explicado el asunto de hacer copias de seguridad en local, me centraré en la copia vía red.

Opciones rápidas de rsync:

a: copiar para archivar. Es un atajo que combina otras opciones que básicamente produce que se haga una copia exacta (archivos, enlazes simbólicos, permisos, etc).
v: indica que se debe mostrar información de la ejecución (el conocido modo verboso).
z: comprime los datos antes de enviarlos al destino (sólo es realmente útil en copias vía red).
e rsh: sirve para transmitir los datos vía red por ssh.
n: ejecución de prueba, muestra lo que haría pero realmente no hace nada.
exclude-from=FICHERO: se deben excluir los directorios y rutas contenidos en el fichero indicado (se pueden usar caracteres comodín).

Así, para realizar una copia remota se debería usar el comando:

rsync -e ssh -azv ORIGEN DESTINO

Suponiendo, como yo, que se quiera copiar el directorio del usuario pepe de un sistema a un directorio de copias de seguridad del servidor llamado Sancho, el comando sería:

rsync -e ssh -azv /home/pepe sancho:/var/backups/pepe

Dado que estamos accediendo a un sistema remoto se debe tener permiso para acceder a dicho sistema. En principio (imagino) se pedirá usuario y contraseña. Dado que se pretende automatizar la tarea lo suyo es configurar una autentificación mediante clave privada/clave pública tal y como permite SSH.

Nota: Comentarios cerrados debido a la continua avalancha de spam chino en esta y solo en esta entrada. Misterios de internet.

Error de glibc en todas las aplicaciones GTK

2007-05-01T19:56:00.000+02:00

Desde hace unas semanas todas mis aplicaciones GTK fallan al iniciarse. El error, visto desde la consola, viene a ser algo así como:

*** glibc detected *** double free or corruption (fasttop): 0x081e35a0 ***

Buscando en Google encuentro un mensaje en el que comentan que se debe a que glibc ha detectado un error en el programa y por tanto éste ha sido abortado. Eso ya se podía deducir del error, pero también cuenta que se puede establecer un comportamiento determinado en caso de encontrar estos errores mediante la variable de entorno MALLOC_CHECK_:

By default, the program that generated this error will also be
killed; however, this (and whether or not an error message is
generated) can be controlled via the MALLOC_CHECK_ environment
variable. The following settings are supported:

0 -- Do not generate an error message, and do not kill the program
1 -- Generate an error message, but do not kill the program
2 -- Do not generate an error message, but kill the program
3 -- Generate an error message and kill the program

Probando a poner 0 ó 1 consigo que algún programa sencillo se ejecute, pero siguen fallando, como por otro lado cabría esperar.

Tras un rato hablando en #debian en freenode me dicen que debe haber por ahí algún follón de versiones de paquetes, versiones en testing con versiones en experimental. Me recomiendan confiar en la sabiduría de aptitude, ya que apt no es capaz de solucionar nada (simplemente no encuentra ningún problema). Una vez me aseguro de que sólo tengo repositorios en lenny confio en aptitude. Me indica que va a desinstalar medio KDE y parte de GNOME. Se supone que si elimina paquetes es porque hay algún tipo de problema con ellos.

Tras desinstalar las aplicaciones GTK vuelven a funcionar. Punto para aptitude. Vuelvo a instalar los paquetes que he desinstalado, y vuelven a fallar. Raro, raro. Finalmente, aislo 6 paquetes que si están instalados impiden a las aplicaciones GTk (y no sólo a las de GNOME) iniciarse:

tk2-engines-pixbuf
industrial-cursor-theme
gtk2-engines-spherecrystal
gnome-themes
gnome-themes-extras
gnome2-user-guide

Es posible que alguno no sea responsable, pero no he querido afinar más. He probado a desinstalarlos usando la opción de purgado de ficheros de configuración por si era un problema de una determinada configuración extraña, pero no ha funcionado. Es algo que hay en esos 6 paquetes.

Dado que uso KDE no me preocupa el aspecto de GTK, siempre y cuando funcionen las aplicaciones.

Se admiten sugerencias.

Solución para el problema de Flash sin sonido para Debian Sarge

2006-09-25T22:33:00.000+02:00

En este blog cuentan como solucionar el asunto del flash sin sonido para Ubuntu, pero como bien dicen en algún comentario más abajo funciona también para Debian Sarge, al menos a mí me funcionó.

La solución la reproduzco aquí por ser muy corta. Sólo se necesita:

Tener instalado el paquete alsa-oss
Tener la línea FIREFOX_DSP="aoss" en el fichero /etc/firefox/firefoxrc.

Después basta con arrancar o reiniciar Firefox para que funcione.

Jugando con Apache 2

2006-07-25T21:24:00.000+02:00

Comprensión básica de la configuración de Apache. Este envío se basa la lectura rápida de documentación en la web, ensayo y error y deducciones un tanto a la ligera de los resultados obtenidos. No se fie.

Apache soporta servidores virtuales, que es como decir que una sóla máquina da la impresión ser varios servidores web. La mayor implicación de ello es que cada servidor virtual tendrá su propia configuración y comportamiento independiente del resto.

No sé muy bien como va, pero desde luego mi servidor Apache que por el momento sólo neceisto que haga de un solo servidor viene configurado con servidores virtuales. Claro que sólo tengo un servidor virtual, así que en la práctica es como si tuviese un sólo servidor web sin virtualizar.

Después de este aparente juego de palabras, pasamos a cosas más interesantes.

La configuración se situa, normalmente, en /etc/apache2. Cuando digo configuración no me refiero a un fichero, sino a toda la configuración del servidor que no se reduce a un solo archivo. En todo caso se debe comprobar la directiva ServerRoot que indica a Apache a partir de que directorio debe de entender que se situa toda la configuración.

Existe un fichero de configuración general, pese a que en todas las páginas aparece httpd.conf en mi caso es apache2.conf. ¿Serán cosas de Debian?

Aparte, por cada servidor virtual existe otro fichero de configuración. Supongo que podrá no existir y se tomarán los valores del fichero general. De hecho Apache define una jerarquia de configuraciones, de manera que se pueda decidir que valor se aplica cuando hay configuraciones cotnrarias. Temo que no puedo explicar cuál es esa jerarqui por temor a equivocarme.

En el directorio de configuración (ServerRoot) hay dos directorios, sites-enabled y sites-available. Parece ser que sites-available contiene la configuración de cada servidor virtual en un fichero lamado default (lo cuál me hace pensar que probablemente pueda haber más ficheros de configuración en ese directorio, o más configuraciones alternativas o vaya usted a saber que festival de configuraciones, ficheros y bytes revenidos podría uno encontrar allí), pero es en sites-enabled desde dónde están enalzadas. Por ejemplo, mi servidor está así:

#ll sites-available/
total 4
-rw-r--r-- 1 root root 1153 2006-07-26 00:08 default
# ll sites-enabled/
total 0
lrwxrwxrwx 1 root root 36 2005-05-25 05:56 000-default -> /etc/apache2/sites-available/default

Por lo cuál deduzco que en sites-enabled deberá haber un enlace simbólico a sites-available para activar dicho servidor. Los nombres lo dicen; sites-available son los servidores disponibles, que pueden usarse; sites-enabled son los servidores activos.

Así, si queremos tocar la configuración de un servidor virtual, o como en mi caso, del único servidor virtual (que es como decir del único servidor) hay que tocar la configuración bajo sites-available. Parecerá tonto, pero ya estuve bastante tiempo haciendo el canelo editando el fichero de configuración general y viendo resultados rarísimos. Lógico, sólo conseguía cambiar las opciones que no estaban definidas en la configuración particular del servidor virtual.

Una vez no situamos en el fichero de configuración adecuado podemos centrarnos en las directivas. Como ya dije, las directivas establecen la configuración del servidor. Algunas se refieren al servidor en general y otras son una manera de agrupar directivas para un conjunto de elementos. Sin asustarse; los elementos pueden ser ficheros que respondan a un patrón en el nombre, o directorios, o ficheros que cuelgan en un directorio (a grandes rasgos).

Y llegamos a dónde quería llegar yo cuando investigué todo esto. Como evitar que Apache liste el contenido de los directorios a los visitantes. Es decir, que si la URL a mi servidor es un directorio no muestre los contenidos como venía haciendo hasta hoy. Pues basta con poner en la directiva Directory del directorio correspondiente (en el padre si quiero aplicarlo a todos) lo siguiente:

Options -Indexes

Que obviamente indica como opción no (-) indexar el contenido de los directorios (Indexes).

Cabe decir que Apache sólo mostaría el contenido del directorio si se indica una URL a un directorio de mi servidor y en dicho directorio Apache no encuentra ninguno de los archivos mencionados en la directiva DirectoryIndex, directiva que le indica a Apache que ficheros mostrar por defecto cuando se le indica una URL que es un directorio.

En fin, ahí quedan unos enlaces:

Documentación oficial de Apache 2.
Descripción de las directivas principales.
Breve descripción de opciones principales de un manual de SUSE (habrá mejores pero yo he llegado aquí).

Relacionandose con la A.E.A.T usando Linux

2006-06-17T18:19:00.000+02:00

Parece que nuestra querida A.E.A.T. aún no ha sacado el programa P.A.D.R.E. en una versión compatible con Linux, aunque se comenta que el próximo año será en Java con lo cual será utilizable desde Linux.

Lo que si hay es el cáluclo de retenciones para el ejercicio de 2005 en versión Java. A falta de pan buenas son tortas.

Para usarlo se debe ir uno a la página de programas de ayuda para el ejercicio 2005 y descargar la versión 1.01 para Linux de las retenciones 2005. Es un script Bash que realiza la instalación del programa.

La primera ejecución como usuario normal genera el siguiente error:

$ ./ret5101.bin
Preparing to install...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...

Launching installer...

Unable to locate the application's 'main' class. The class 'com.zerog.ia.installer.Main' must be public and have a 'public static void main(String[])' method. (LAX)
GUI-

No es problema del usuario, con root sucedería lo mismo. El problema es que el programa instalador trata de usar la maquina virtual de Java que hay en /usr/bin/java, que en mi caso a punta a gij (GNU Interpreter Java), la implementación GNU de Java. Por lo que se ve aún le quedan algunos flecos :-(.

Así, yo tengo lo siguiente:

lrwxrwxrwx 1 root root 22 2006-02-04 22:55 /usr/bin/java -> /etc/alternatives/java

Y asu vez:

lrwxrwxrwx 1 root root 34 2006-06-04 00:29 /etc/alternatives/java -> /usr/lib/jvm/java-gcj/jre/bin/java

Mi instalación de Java está en /opt/j2re1.4.2_06/bin/java. Como he tenido que surfear por la red un rato hasta encontrar el error, decido poner la JVM de SUN como máquina virtual por defecto. Basta con crear un enalce simbólico desde /usr/bin/java hasta el ejecutable de SUN:

# ln -s /opt/j2re1.4.2_06/bin/java /usr/bin/

Una vez hecho eso vuelvo a ejecutar el instalador, que se abre correctamente. Pide seleccionar la máquina virtual a usar, basta con dejarle /usr/bin/java para que use la de SUN. Después pide un directorio de instalación y uno de vínculos. Los vínculos son simplemente los enlaces para arrancar el programa y para desinstalarlo, junto con un Leame.txt.

Kopete 0.12 alpha 1 con soprte Jingle (voz de GoogleTalk)

2006-03-12T17:14:00.000+01:00

El protocolo Jingle presentado por Google junto a Jabber (comentado en Dirson y Barrapunto) para Jabber que fue acompañado de la libreria Jingle de Google bajo licencia BSD comienza a dar sus frutos. Kopete 0.12 Alpha 1 dispone de soporte experimental para dicho protocolo de voz y vídeo, aunque Kopete por el momento sólo ofrece voz.

Voy a compilarlo y probarlo sobre mi Debian Etch. Descargo y descomprimo el paquete fuente. Consulto la página de dependecias de Kopete para usar Jingle que se resumen en lo siguiente:

Introduction of libjingle require new dependencies to Kopete. Here the list:
-oRTP 0.7.1 http://www.linphone.org/ortp/sources/ (no more, no less, just 0.7.1)
-expat
-glib-2.0 (if you don't have it already for MSN webcam)
-speex (>=1.1.6 or 1.0.5 (the versions that have speex_encode_int ))

Ejecuto ./configure --enable-jingle (esta opción es necesaria para activar el soporte para conversaciones de voz usando libjingle) de cuya salida me fijo en lo siguiente:

[...]
checking for XML_ParserCreate in -lexpat... yes
[...]
checking for ortp... configure: WARNING: oRTP is required to build Jabber Jingle voice support. You can get it from http://www.linphone.org/ortp/
[...]
checking for glib-2.0 gmodule-2.0... yes
checking GLIB_CFLAGS... -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking GLIB_LIBS... -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0
[...]
checking for speex... checking speex.h usability... no
checking speex.h presence... no
checking for speex.h... no
checking speex/speex.h usability... no
checking speex/speex.h presence... no
checking for speex/speex.h... no
configure: WARNING: Could not find a libspeex version that have the speex_encode_int() function. Please install libspeex=1.0.5 or libspeex>=1.1.6 from http://www.speex.org/
[...]
You have disabled or you are missing required librairies required to compile Jabber Jingle voice support.
Jingle is a new Jabber standard that define a signaling protocol via XMPP for peer-to-peer applications.
Jingle audio is compatible with Google Talk voice offering.

Required Jingle dependencies are listed on this page:
http://wiki.kde.org/tiki-index.php?page=Kopete+Jabber+Jingle

Muy bien, consulto la página de dependecias de Kopete para usar Jingle que se resumen en lo siguiente:

Introduction of libjingle require new dependencies to Kopete. Here the list:
-oRTP 0.7.1 http://www.linphone.org/ortp/sources/ (no more, no less, just 0.7.1)
-expat
-glib-2.0 (if you don't have it already for MSN webcam)
-speex (>=1.1.6 or 1.0.5 (the versions that have speex_encode_int ))

Veamos paso a paso las dependencias:

oRTP 0.7.1: No está disponible en mi sistema. Descargo el código fuente de la libreria de la página indicada, ejecuto ./configure, make y creo un paquete con checkinstall que procedo a instalar en mi sistema, todo sin problemas.
expat

./configure

glib-2.0

./configure

speex

libspeex

Vuelvo a ejecutar ./configure y obtengo el siguiente mensaje:

[...]
You have disabled or you are missing required librairies required to compile Jabber Jingle voice support.
Jingle is a new Jabber standard that define a signaling protocol via XMPP for peer-to-peer applications.
Jingle audio is compatible with Google Talk voice offering.

Required Jingle dependencies are listed on this page:
http://wiki.kde.org/tiki-index.php?page=Kopete+Jabber+Jingle

Vaya vaya. Reviso la salida del script y encuentro:

[...]
checking iLBC_decode.h usability... no
checking iLBC_decode.h presence... no
checking for iLBC_decode.h... no
configure: WARNING: Could not find ilbc headers or libs. Please install ilbc package from http://www.linphone.org if you want iLBC codec support in Kopete Jabber plugin.
[...]

Así que falta iLBC, sin embargo no se menciona en la página de dependencias. Rebusco por linphone.org pero no hay un paquete instalable o un fuente compilable. Sin embargo hay un enlace a www.ilbcfreeware.org dónde comenta que se puede obtener el código de la siguiente manera: se descarga uno el RFC 3951 (Internet Low Bit Rate Codec) y un script awk; después se ejecuta el script awk mediante el comando:

awk -f extract-cfile.awk rfc3951.txt

El resultado es un monton de archivos .c y .h, de manera que se podría generar una librería a partir de ellos, pero no hay ni makefile ni nada similar. Al fin y al cabio lo se hace es extraer directamente del RFC el código propuesto para implementar el protocolo iLBC, de manera que no se incluye código accesorio, por ejemplo, para crear una libreria. Quizá baste con que el script ./configure tenga acceso a las cabeceras y al código objeto, pero no me veo yo creandome los scripts de compilación.
¿Que hacer? Calmo mi inquietud navengando mediante Google y al rato descubró la información que buscaba. Como comentan en este mensaje del foro de KDE la libreria iLBC es opcional:

iLBC is an optional dependency, so you could just not install it (it's not required for jingle support)

Me alegro, lo dejaré para otro día. Vuelvo a ejecutar ./configure y finalmente me dice:

Supported Jabber Jingle voice Codecs for Kopete:
Speex: yes
iLBC: no
MULAW: yes

Good - your configure finished. Start make now

Como comentaban efectivamente en el foro iLBC parece no ser obligatoria.

Lanzo make, pero obtengo lo siguiente:

[...]
if /bin/sh ../../../../../../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I./../.. -DPOSIX -I./../.. -DQT_THREAD_SUPPORT -D_REENTRANT -D_FILE_OFFSET_BITS=64 -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT network.lo -MD -MP -MF ".deps/network.Tpo" -c -o network.lo network.cc; then mv -f ".deps/network.Tpo" ".deps/network.Plo"; else rm -f ".deps/network.Tpo"; exit 1; fi
In file included from network.cc:33:
./../../talk/base/basicdefs.h:32:20: error: config.h: No such file or directory
make[8]: *** [network.lo] Error 1
make[8]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle/talk/base'
make[7]: *** [all-recursive] Error 1
make[7]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle/talk'
make[6]: *** [all-recursive] Error 1
make[6]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle'
make[5]: *** [all-recursive] Error 1
make[5]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber/jingle'
make[4]: *** [all-recursive] Error 1
make[4]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols/jabber'
make[3]: *** [all-recursive] Error 1
make[3]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete/protocols'
make[2]: *** [all-recursive] Error 1
make[2]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1/kopete'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/temp/compilandoFuentes/kopete-0.12-alpha1'
make: *** [all] Error 2

¡Diablos! Parece que no encuentra un fichero config.h. Vuelvo a relajarme navegando a tavés de Google. Buscando encuentro el Bug 121856 en que se comenta que "apunte libjingle al config.h generado durante el proceso de configuración de Kopete".

Así, edito el fichero basicdefs.h que hay en kopete-0.12-alpha1/kopete/protocols/jabber/jingle/libjingle/talk/base/ y cambio la línea que incluye el fichero basicdefs.h por:

#include "../../../../../../../config.h"

De esta manera apunta al fichero generado por el proceso de configuración. El estatus del BUG es RESOLVED, por lo que es posible que actualmente no suceda.

Finalmente vuelvo a ejecutar make y compila sin problemas tras un buen rato. He usado el siguiente gcc:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)

Creo un paquete debian mediante checkinstall, e instalo Kopete 0.12 Alpha 1. Funciona sin problemas. Ahora al tener una charla con alguién de de GTalk aparece la opción de voice call, aunque supongo que debería dar la opción con cualquier contacto que soporte esta libreria. Sin embargo, no consigo comunicar. Si llamo desde GTalk Kopete no parece entararse, y si llamo desde Kopete GTalk parece enterarse pero tras aceptar la comunicación esta nunca se produce.

Tendré que echar un ojo a ver que pasa, probar con una versión de CVS algo más actual o compilar con depuración a ver si veo algún mensaje interesante.

Actualizacion 1/Abril/2006: Hace tiempo que salió la Beta 1, y Beta 2. Probé con la Beta 1 pero tampoco conseguí hacerlo funcionar, y probé con la Beta2 pero con muchas menos ganas. El caso es que hoy he vuelto a probar fortuitamente y me ha funcionado con la Beta 2 que tenía instalado. Al menos yo oia a mi contertulio, aunque el a mi no, básicamente por no tenía ocnfigurado el microfono. A este respecto, en la sección de dispositivos de la configuración de Kopete sólo aparece una pestaña de vídeo, pero no veo ninguna configuración para audio. En cualquier caso trataré de configurar em microfono en KDE y espero que valga para Kopete, por que lo cierto es que KDE si provee de una infraestructura para el audio, pero parece ser que no está tan integrado en el caso del vídeo.

Paso de Sarge a Etch

2006-02-05T23:10:00.000+01:00

Me he decidido a pasarme de Sarge a Etch. En parte por tener paquetes más actuales, en parte por trastear un poco. Debería buscarme un ordenador alternativo para hacer de laboratorio...

El funcionamiento de testing puede leerse ne la página de Debian sobre la dsitribución "testing". En Bulma hay un artículo que comenta los cambios que se iban a producir en el modelo de desarrollo tras el cambio de SArge de testing a stable.

Para cambiar basta con poner los repositorios de testing/Etch en el lugar de los stable/Sarge (es conveniente poner el nombre, así el día que se produce un cambio en la distribución no se intenta actualizar de golpe y uno puede controlar en que momento quiere hacerlo, aunque sea una cosa que pase cada años), y hacer apt-get-update y apt-get dist-upgrade. Cuanto más limpio sea nuestro sistema menos problemas tendremos.

En mi caso no hay paquetes ni para K3b ni para amaroK, lo cuál me resulta molesto pero siempre puedo descargarlos y compilarlos. Parece ser que el problema es que los paquetes binarios de K3b y amarok están compilados paraKDE 3.5, por lo que hasta que éste no pase de Sid a Etch no habrá paquetes en Etch.

AmaroK
Se puede descargar e instalar directamente la versión 1.3.7-1 como comentan en la sección de Debian del wiki de amaroK.

K3B
Para K3b no he encontrado paquetes, asi que he tenido que descargarlo y compilarlo. Parece que no es psoible compilarlo con soporte para flacc y ffmpeg, lo que implica, si no me equivoco, que no será capaz de usar estas librerias para decodificar archivos. El primero afecta al formato flacc, mientras que el segundo puede ser grave, ya que afecta seguro a wma, pero sospecho que también a Asf, Ogg Vorbis. Tendré que comprobarlo. En xualquier caso si quiero un disco a partir de uno de estos formatos deberé pasarlo primero a un formato entendible mediante otro programa.

vlc
En su página no hay binarios o fuentes específicas para a Etch, asi que toca descargar y compilar. Sim embargo, obtengo un error por no disponer de libmpeg2. Ya le echaré un ojo.

MPlayer
Bueno, mplayer tampoco estaba disponible en Sarge, asi que no me extraña no tenerlo en Etch. Para instalarlo la solución más sencilla es usar los respositorios no oficiales de Marillat, sección Etch. Para ello, basta con añadir al soruces list:

deb ftp://ftp.nerim.net/debian-marillat/ etch main

Junto a MPlayer conviene instalar AcidRip y KPlayer. AcidRip permite volcar DVDs al disco duro y codificarlos como DivX, XviD y otros formatos, Báscamente es un envltorio de las funcionalidades de MPlayer y Mencoder. KPlayer es un un MPlayer envuelto en un interfaz KDE.

Plugin de Flash para navegadores web.
Tras el paso a Etch tanto Firefox como Konqueror se colgaban al tratar de mosntrar un Flash. La solución pasó por desintalar todo lo que tenía de Flash, revisar los directorios de plugins de los navegadores y eliminar todo lo que fuese sospechoso (más que eliminar mover de sitio; siempre es conveniente poder recuperar el estado anterior no sea que nos carguemos algo).

Actualizacion 12-Febrero-2006: Hoy me ha dado cuenta de que mi apt quiere actualizarme mi KDE de 3.4 a 3.5.1, lo cuál implica instalar también tanto amaroK como k3B, que estaban bloqueados por que estar compilados para KDE 3.5. Ahora toca desinstalar ls paquetes que he compilado de k3b y amaroK y usar los oficiales.

Reproducir DVD cifrados mediante DeCSS

2005-12-11T18:33:00.000+01:00

DeCSS permite descifrar el contenido de los DVD protegidos para ser copiados o simplemente visualizados.

Dado que hay problemas legales con esta libreria, no es distribuible oficialmente como binario, por lo que hay que obtener las fuentes y compilarlas o usar un repositorio alternativo.

En mi caso he optado por usar un repositorio que mencionan en
Debian Manual - DeCSS and Playing a DVD Under Debian.

Así, se añade ésta línea al fichero sources.list:

deb ftp://ftp.nerim.net/debian-marillat/ sarge main

Para usar repositorios no oficiales lo mejor es añadirlos a la lista de repositorios, realizar un update, instalar el paquete necesitado comprobando que no nos instale o actualice otros paquetes no relacionados en nuestro sistema, y después descomentar el repositorio. Así nos aseguramos de que en un futuro no tengamos problemas con l ainstaalciń de nuestros paquete por conflictos entre los diferentes repositorios.

Así, una vez configurado el repositorio, basta con:

# apt-get install libdecss2

Listo, ya es posible ver un DVD cifrado.

Dar y KDar: copias de seguridad (Backups)

2005-11-27T22:34:00.000+01:00

Para la realización de copias de seguridad existe una magnifica herramienta llamada dar. dar permite hacer copias de seguridad completas e incrementales, (una copia de seguridad incrementeal sólo alamcena los ficheros que han cambiado respecto a una copia incremental o completa anterior, de manera que se ahorra mucho espacio). También permite divir la copia de seguridad en ficheros de tamaño determinado, para, por ejemplo, volcar nuestra copia de seguridad en CDs o DVDs.

Hay un muy buen howto en español sobre dar escrito y traducido por Grzegorz Adam Hankiewicz.

dar es un programa de línea de comandos, pero existe KDar, un programa que sirve para manejar de manera gráfica dar. La creación de backups es algo incómoda, pero la recuperación se hace fácil y rápida.

Un pequeño ejemplo de uso de dar:

dar -v -c "~/Almacen/Backups/copia.seguridad"
-R "~"
-s 4500M
-y
-m 150
-g "Almacen/Correo/"
-g "Almacen/Fotos/"

Siendo:
-v : Modo verbose
-R: Raiz de la copia de seguridad
-s: Tamaño de los slices o trozos de la copia. Si la copia es de un tamaño mayor que el número dado, dar la divide en tantos archivos del tamaño indicado como sean necesarios. En este caso se indica el tamaño de un DVD de 4'5 Gb.
-y: Usar compresión bzip. Los ficheros, antes de arlamcenados en la copia, son comprimidos.
-m 150: No comprimir ficheros menores del tamaño indicado (150 en este caso). Los ficheros pequeños suelen comportarse muy mal al ser comprimidos, ocupando incluso más espacio del original.
-g: Directorios a incluir en la copia. Si no hay ninguna opción g se incluyen todos los archivos y subdirectorios que cuelguen de la raiz indicada por R, pero si se inlcuye alguna copión g sólo se incluyen los especificados por dicha opción. Obviamente puede haber tantas ocpiones g como sean necesarias.

Así, en el ejemplo se hace una copia de seguridad completa de los directorios ~/Almacen/Fotos y ~/Almacen/Correo en trozos de 4'5 Gb que serán dejados en~/Almacen/Backups.

No me extiendo más por que en el manual indicado al inicio hay ejemplos mucho más interesantes, incluyendo copias de seguridad incrementales e incluso se pueden encontrar scripts enviados al autor del manual que automatizan la copia de seguridad (por el momento sólo hay uno, pero realiza automáticamente una copia completa al inicio de mes y una copia incremental cada dia, permitiendo enviar via scp el resultado a unamáquina remota).

Seguimiento de instalaciones desde fuentes mediante checkinstall

2005-10-01T14:44:00.000+02:00

Checkinstall permite el seguimiento de la instalación de programas a partir de sus fuentes.

Habitualmente cada distribución tiene un sistema de gestión de paquetes que facilita la instalación y desinstalación de programas. Sin embargo, aquellos programas que son distribuidos como código fuente caen fuera del ámbito de estos gestores de paquetes, precisamente por no estar empaquetados.

Checkinstall crea, a partir del script de instalación del programa (usualmente make install), un paquete que podrá ser deb, rpm o Slackware, con los binarios resultantes de la compilación del código. De esta manera es posible a continuación instalar el programa mediante el gestor de paquetes del sistema, con las posibilidades que ello conlleva (listado de archivos usados por el programa, desintalación rápida y sencilla, información del apquete, etc,...).

Además resulta muy cómodo ya que se puede guardar el paquete generado por si es necesario en futuras instalaciones.

Para usarlo normalmente basta con sustituir la tradicional llamada a make install por checkinstall.

Se puede encontrar una explicación detallada del programa en un artículo de Mario M. Knopf traducido por guadapeich

Flash sin texto

2005-08-15T20:08:00.000+02:00

Es posible que tras instalar el plugin de Macromedia Flash en algún navegador web de Linux (como Firefox o Konqueror) se tengan problemas a la hora de visualizar ciertos textos de las animaciones Flash. La animación se ve correctamente pero ciertos textos en vez de mostarse quedan sin dibujarse.
Esto se debe a que faltan los paquetes gsfonts-x11 y gsfonts, así que la solución es bien fácil:

apt-get install gsfonts-x11 gsfonts

Listo, tras reiniciar el navegador deberían verse correctamente los textos que daban problemas.

Sacado de #debian-es de los servidores irc de Debian (que son los de Freenode).

Preservando los datos EXIF

2005-08-15T13:15:00.000+02:00

Gimp es un excelente programa de manejo de imágenes, pero parece que el soporte para datos EXIF no está muy avanzado, al menos en Debian Sarge/Stable.

Los datos EXIF (Exchangeable Image File) son usados por las cámaras digitales para guardar información extra sobre la fotografía que toman como la velocidad de obturación, apertura del diafragma o fecha y hora en que fue tomada la foto. Estos datos añaden a la información de la fotografia en el mismo archivo de la imagen.

Sin embargo, no todos los programas de edición conservan esos datos. Algunas vrsiones de Gimp, como por ejemplo la mía, al guardar la imagen elimina dichos datos.

Para conservarlos se puede usar jhead, programa de consola para manipualr datos EXIF.

Sólo es necesario meter todas las fotos en un directorio, por ejemplo ~/editando y copiarlas a un subdirectorio que se llame, por ejemplo, originales (~/editando/originales). Después se editan normalmente las fotos del directorio ~/editando, sin cambiar el nombre. Una vez finalizada la edición se ejecuta en el directorio ~/editando el comando:

$ jhead -te originales/"&i" *.jpg

Dicho comando transplanta los datos EXIF de las fotos del directorio originales a las fotos del directorio superior (dónde se ha ejectuado el comando), recuperando las fotos modificadas sus datos EXIF. Es importante no cambiar los nombres de las fotos uesto que el comando transplanta la información en función del nombre, si el nombre cambía la operación fallará.

SSH y autentificación mediante clave pública/privada

2005-08-13T13:45:00.000+02:00

Para dar un poco más de seguridad y comodidad al acceso por SSH a mis servidores, he decidido utilizar autentificación mediante clave pública/privada junto a SSH.

El esquema es el siguiente: un servidor SSH posee una lista de claves públicas cada una asociada a un usuario. Cuando uno de dichos usuarios trata de conectarse al servidor SSH, el servidor comprueba que efectivamente el cliente es quién dice ser mediante un algoritmo de clave privada/pública, de manera que solo el cliente legítimo que posea la correspndiente clave privada podrá autentificarse.

Así, para ponerlo en marcha es necesario generar un par de claves (privada y pública) en el cliente, y enviar la clave pública al servidor.

Por otro lado el cliente almacena la clave pública del servidor, de manera que cuando el cliente se conecta al servidor puede comprobar que el servidor es efectivamente quién dice ser.

A ello:

La generación de la pareja de claves en el cliente se realiza mediante ssh-keygen:

$ ssh-keygen  -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/NaSz/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/NaSz/.ssh/id_rsa.
Your public key has been saved in /home/NaSz/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx NaSz@quijote

Es posible proteger el uso de las claves mediante una clave, de manear que cuando se vayan a usar ésta sea solicitada. Si se deja en blanco no se pide contraseña.

Las claves se alamcenan por defecto en ~/.ssh/, quedando el directorio así:

$ ls -l
total 12
-rw-------  1 NaSz NaSz  883 2005-08-13 14:16 id_rsa
-rw-r--r--  1 NaSz NaSz  223 2005-08-13 14:16 id_rsa.pub
-rw-r--r--  1 NaSz NaSz 1344 2005-08-04 02:14 known_hosts

id_rsa es la clave privada, id_rsa.pub es la clave pública, y known_hosts son las claves públicas de los servidores conocidos.

Ahora se debe copiar la clave pública al servidor, al fichero ~/.ssh/authorized_keys. Para ello se utiliza el comando ssh-copy-id:

$ssh-copy-id -i ~/.ssh/id_rsa.pub NaSz@igor
$ssh-copy-id -i ~/.ssh/id_rsa.pub NaSz@sancho

ssh-copy-id es un script que se conecta al servidor ssh indicado mediante ssh, hace login y copia el archivo indicado por la opción -i en el fichero ~/.ssh/authorized_keys, además de tocar los permisos para dar seguridad (como impedir el acceso a miembros del grupo).

La primera vez que tratemos de conectar al servidor mediante ssh se nos pedira que confirmemos la clave pública del mismo (como hemos dicho, el cliente guarda también una copia de la clave pública del servidor para comprobar que efectivamente es el servidor que el cliente busca), de manera que ésta queda guardada, normalmente, en ~/.ssh/known_hosts.

Notas:

Se trabaja con usuarios y servidores. Es decir, para el servidor SSH un cliente es un usuario de una maquina concreta, por lo que para el servidor igor no será lo mismo NaSz@sancho que NaSz@quijote.

Ademas de claves RSA, se pueden usar claves DSA. Ámbas son válidas para usarse con ssh versión 2 (no es recomendavle usar ssh versión 1 dado que es vulnerable).

Existe la posibilidad de usar ssh-agent que se encarga de gestionar el uso de las claves. Mediante ssh-agent y si se ha usado una clave para proteger el uso de las claves privadas (ver explicación de como generar las claves), el usuario sólo tiene que introducir la clave o palabra de paso una vez. ssh-agent se encarga de permitirle el uso de las claves privadas la próxima que lo necesite sin tener que volver a introducir la contraseña. Es útil para dar un toque mayor de seguridad sin la incomodidad de tener que usar una contraseña cada vez que se quiere conectar a un servidor conocido mediante SSH.

Notar que este sistema permite el acceso sin contraseña en todos los servidores que confien en el sistema del cliente, de manera que por un lado introduce seguridad, pero si un sistema se ve comprometido también se podrán ver comprometidos aquellos servidores que confien en el sistema atacado. Por ello es un mecanismo a usar con inteligencia y moderación.

La mayor parte de ésta información ha sido sacada del Blog de Laura Cedrán (aparte de éste artículo hayun par más que profundizan en SSH), del artículo "ssh sustituye a rsh" (desconozco el autor), así como del artículo de Bulma "SSH con contraseña pública/privada".

Discos duros mayores de 32Gb en Linux

2005-07-28T12:22:00.000+02:00

A mis servidores necesito ponerles un buen disco duro, entre otras cosas por que van a guardar toda la multimedia que tengo, y por que serán los encargados de descargar de internet, así sus pauperrimos discos de 4 Gb se quedan bastante cortos.

El problema es que son de esos hardwares que en principio no aceptan discos duros de más de 32 Gb (de hecho los discos duros modernos tienen un jumper para limitar sus capacidad a 32 Gb para evitar problemas).

Sin embargo, con Linux el problema es de fácil solución, al menos si el disco de más de 32 Gb no se usa para arracnar el sistema. Basta con poner modo LBA en la BIOS y conectar el disco duro. Linux ya se encarga de acceder a cualquier parte del disco duro sea o no por encima de los 32 Gb.

El problema viene cuando se necesita que el sistema arranque desde uno de esos discos duros, ya que la BIOS es la que tiene problemas para acceder a datos por encima de los 32 Gb (debido a una limitación en las direcciones que maneja). Temo que la solución no es tan sencilla, pero si es posible. Para éste tipo de operaciones lo suyo es consultar el HDs grandes: mini-COMO Andries Brouwertratraducido por Fco. J. Montilla. Hay también un interesante hilo de discusión en las listas de Linux Cantabria de un caso práctico.

En mi caso Sancho arranca desde su disco duro antiguo mientras el secundario, de 120 Gb, se utilzia como almacén.

Nuevos controladores para mi wirelss Ralink

2005-07-27T22:36:00.000+02:00

Hace días que había visto que los del proyecto de controlador para tarjetas inalámbricas basadas en el chip de Ralink habían empezado con una versión con soporte para las tarjetas USB. Igor es la excusa perfecta para probarlos ya que lo pondré enun cuarto lejos del router.

Por el momento sólo tienen la versión del CVS del controlador 2570.

La descargo y descomprimo en /usr/src/modules. El primer intento de compilación falla por que falta el enlace desde /lib/modules/2.6.8-2-686/build hasta las las cabeceras (o las fuentes, que incluyen las cabeceras).

Cargo el móudlo y trato de hacer funcionar la antena. No furula, por que no la he activado, con ifconfig:

ifconfig rausb0 up

Configuro la red wireless pero tengo problemas de conexión a través del interfaz wireless. Cuando desconecto el cable ehternet, dejo de poder comunicarme con Igor, pese a que si pongo el cable ethernet parece que puedo acceder a través del interfaz inalámbrico.

Tras un largo rato de pruebas, Google, lecturas y más pruebas, deduzco que es un problema con la tabla de rutas.

Como ando algo justo de tiempo, toco /etc/network/interfaces para que el interfaz rausb0 sea inicializado primero, de manera que las rutas se configuran para usar ese interfaz como principal. De ésta manera parece que solucion el problema de acceder a través del interfaz inalámbrico, pero si eth0 está activo (que conviene, por falla el wireless y accedo a él por ethernet) no tengo salida a internet.

Veamos las rutas:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 rausb0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         mygateway.ar7   0.0.0.0         UG    0      0        0 eth0
default         mygateway.ar7   0.0.0.0         UG    0      0        0 rausb0

El problema es la tercera línea, que indica que la ruta por defecto es por el interfaz etho0. Pues elimino de la tabla y listo:

route del default dev eth0

Tras varios días en marcha, la antena deja de funcionar. No sé a que se debe, imagino que será un asunto de los controladores que están en desarrollo.

Deberé probar a usar un controlador algo más nuevo, por el momento a Igor hay que reiniciarlo de vez en cuando.

Igor y Sancho, presentación de mis servidores

2005-07-26T22:57:00.000+02:00

Igor y Sancho son los dos servidores que he acogido bajo mi seno, administro con cariño y mimo con mis comandos de consola.

Igor es un Pentium II al que tuve que hacer una repración de emergencia a su lector de CDs por que no había manera de que leyese correctamente el CD de instalación por red de Sarge. Lleva una Debian Sarge con kernel oficial 2.6.8, unos cuantos servicios de red y parece que va a sustituir a mi ordenador como servidor de la casa para Internet. En breve será Igor quién se encargue del trabajo duro, como ejecutar el mldonkey todo el día.

Sancho es otro Pentium II localizado en casa mis familiares que aloja una página web con dominio propio, aparte de ser también el encargado hacer el trabajo de servidor de la casa. Lleva también una Debian Sarge con kernel oficial.

Accesibles mediante SSH, ninguno tiene pantalla, los administro remótamente. Por supuesto, están protegidos con contraseñas de calidad, cambiado el puerto del sshd (aunque esta es un protección menor) y autorizados únicamente los usuarios justos.

Rápida introducción a RSA y PGP/GPG

2005-07-20T17:20:00.000+02:00

Teoría

RSA es un método de cifrado válido tanto para transmisiones seguras de datos, almacenado de información cifrada y para certificar que la información no ha sido manipulada por terceros.

PGP (Pretty Good Privacy) es el programa, diseñado y desarrollado por Phil Zimmermann en 1991, más conocido que implementaba RSA. El estandar OpenPGP del IETF fue desarrollado basandose en PGP. En el entorno Linux, GnuPG (Gnu Privacy Guard) es la implementación de dicho estándar.

Cada usuario dispone de dos claves, una clave privada y otra clave pública. Dichas claves son generadas por el usuario y nunca se generarán dos parejas de claves iguales. Normalmente cada pareja de claves pública-privada se asocia a una dirección de correo electrónico, aunque no es imprescindible. Mediante éstas claves se pueden realizar las siguientes operaciones:

Cifrado: La clave pública del usuario permite cifrar los datos de un archivo (o cualquier otro conjunto de datos) de manera que sólo la clave privada es capaz de descifrar la información a su estado original. De ésta manera es posible guardar datos cifrados sólo accesibles por el usuario, ya que será el único poseedor de su clave privada, o enviar datos al usuario a través de un medio inseguro como el correo electrónico de manera que sólo el usuario poseedor de la correspondiente clave privada pueda leerlos correctamente.
Firma digital: Mediante la clave privada del usuario es posible firmar un conjunto de datos (un correo electrónico, un fichero, etc.). La firma digital es un pequeño anexo de datos a la información original que, mediante el uso de la correspondiente clave pública del usuario, certifica que los dichos datos originales no han sido alterados y que quién los firmó utilizo la clave privada del usuario. De ésta manera es posible que un usuario envíe datos a través de un canal inseguro y se asegure que el contenido es recibido por el destinatario sin haber sido alterado. Si dichos datos son modificados de alguna manera el destinatario será avisado ya que al usar la clave pública del usuario para comprobar la firma digital, ésta no será correcta. Así, también es posible certificar que, por ejemplo, un usuario escribió un mensaje de correo electrónico que después firmó, ya que sólo él podría usar su clave privada para generar una firma válida.
Firma y cifrado: Es posible combinar ambas acciones, pudiendo así enviar datos a través de un canal inseguro de manera que sólo el destinatario final los pueda leer y se asegure de que dichos datos no han sido alterados.
Descifrado: Mediante la clave privada de una pareja de claves es posible descifrar los datos codificados usando la clave pública.
Comprobación de la firma digital: Se verifica, usando la clave pública, que un conjunto de datos no ha sido alterado. La firma digital es añade a los datos originales, pero no forma parte de estos. Cualquier cambio en la firma o en los datos implicará que la firma digital no será válida al comprobarla con la clave pública.

Cada usuario, tras generarse su par de claves, guarda celosamente su clave privada, y comunica abiertamente su clave pública.

Uno de los puntos flacos del sistema es el intercambio de claves. El sistema no dispone de un protocolo para la comunicación de las claves públicas que sea absolutamente inmune a engaños. Sólo es posible asegurarse de que una persona nos ha entregado su llave pública si las conocemos y es ella misma la que personalmente nos entrega la llave pública en un medio de almacenamiento físico que él mismo haya escrito, y aún así podrían hacerle dado el cambiazo. Por ello el usuario ha de asegurarse de que cuando recibe una clave pública, ésta pertenece a quién dice. Dado que las claves son bastante largas, se usa una huella digital o fingerprint, que es un resumen de la clave lo suficientemente largo como para que sea única y lo suficientemente corta como para que pueda ser comunicada mediante medios humanos (por ejemplo, por teléfono o escrita a mano). Así, una vez recibida una clave pública, es posible confirmarla recibiendo del dueño la huella digital, y asegurando que la clave que tenemos corresponde con la huella recibida. Por supuesto, hemos de asegurarnos que dicha huella digital nos la da el dueño de la clave que queremos comprobar, pero al ser la huella digital más corta y más fácil de comunicar, esto resulta más sencillo.

Por otro lado existen los servidores de claves públicas. Son ordenadores que almacenan las claves públicas de los usuarios y algunos datos (huella, correo electrónico del usuario, etc.). Un usuario que quiera hacer pública su clave pública puede subirla a uno de estos servidores. Normalmente los servidores de claves están interconectados de manera que periódicamente se informan de las novedades, por lo que sólo es necesario subir la clave pública a uno de los servidores, que en poco tiempo ésta figurará también en el resto de servidores.

Un usuario puede validar una clave pública de otro usuario firmando ésta con su propia clave privada. De ésta manera afirma o certifica que él confía en dicha clave pública. Así, cuando se inserta una clave pública recibida en gpg, ésta en principio no esta avalada. Si el usuario confía en que ha recibido la clave correctamente, firmará (avalará) dicha clave, indicando a gpg que confía en ella. La única diferencia es que cuando gpg usa una clave no avalada, dará un aviso de que, aunque descifre o valide correctamente firmas digitales, no es de confianza.

Éste sistema de firma de claves permite establecer anillos de confianza. Así, si yo recibo una clave pública firmada por un usuario en el que yo confío, se interpreta que la clave recibida es de confianza. De ésta manera, además de poder confiar en las claves que uno mismo valida, es posible confiar en las claves en las que otros usuarios bien conocidos confían. Por supuesto es responsabilidad de cada uno decidir en quién se confía. Así, es posible subir a un servidor de claves una clave pública de un usuario firmada por otros, de manera que dicha clave pública estará avalada por las firmas de los otros usuarios. Conviene tener en cuenta que aunque un usuario puede coger la clave pública de otro usuario, firmarla y subirla a un servidor de claves normalmente es el dueño de la clave quién decide que otros usuarios la avalarán, por lo que se suele enviar la clave pública firmada por otro usuario a su dueño, y será éste el que decida si sube o no su firma avalada por el otro usuario.

Dado que los servidores de claves no permiten el borrado de las claves que almacenan, ha de existir un método para anular una clave. Dicho anulación puede ser por que la correspondiente clave privada ha sido comprometida (robada o publicada), no va a ser usada más, ha sido sustituida por otra o por la razón que fuere. El usuario ha de generar un certificado de revocación, generado mediante su clave privada, que es enviado el servidor. Notar también que las claves pueden generarse con un período de validez concreto, superado el cuál son revocadas automáticamente. También hay que tener en cuenta que una clave revocada o caducada ya no podrá usarse para cifrar ni para firmar datos así como tampoco podrá emplearse para descifrar los datos codificados durante el período de validez de la clave.

gpg permite crear confianza localmente. Es decir, asignar a las claves públicas recibidas un grado de confianza. El nivel de confianza en una clave se establece una vez ésta ha sido avalada por el usuario (mientras no se firme no se podrá establecer el grado de confianza). Así, si recibo una clave pública avalada por alguno de los usuarios de los que ya tengo su clave pública firmada, gpg asignará a dicha nueva clave la confianza que tenemos en dicho usuario.

Por último mencionar que gpg almacena las claves privadas cifradas mediante una clave (cifrado simétrico: una sola clave permite cifrar y descifrar) que será pedida normalmente cada vez que se quiera hacer uso de la clave privada. Esto hace más difícil el robo claves privadas.

Las fuentes para éste artículo ha sido la web de Antonio Caravantes, concretamente su sección sobre PGP. Es una larga explicación de PGP, muy entendible y que profundiza sobre todo en aspectos prácticos y útiles. Del taller de criptografía de Arturo Quirantes Sierra se puede obtener mucha información de carácter más técnico en su sencillo curso de PGP.

Práctica

Para poner a funcionar un sistema de claves en mi sistema Linux he optado por instalar gpg, KGpg para manejar gpg desde KDE de una manera fácil y sencilla, y los plugins enigmail y enigmime para Thunderbird. En el artículo de Kriptopolis Pinguino en salsa de bits se explica como echarlo a andar.

Yo ya tengo mi par de claves generadas y funcionando sin problemas en Thuderbird, así como en los menús contextuales de KDE para cifrar archivos.

A vueltas con el Router D-Link G604T de Jazztel

2005-07-14T17:06:00.000+02:00

Después de un tiempo de sin demasiados problemas, el router módem ADSL inalámbrico D-Link G604T ha decidido aguarme la fiesta.

Hace unas dos semanas dejo de realizar el enlace IP con Jazztel, pese a que conexión en la capa ADSL había. Consultando en el teléfono de resolución de problemas técnicos de Jazztel, me explicaron como hacer un reset del dispositivo más fuerte que simplemente desenchufarlo (como yo había probado varías veces). Consiste en pulsar el botón de reset durante 20 segundos, los 10 primeros con el cacharro encendido, y los 10 últimos habiendo desenchufado al aparato. Por supuesto , se pierde la configuración.

Después de hacer esto, el router volvió a conectar sin problemas. Pero hoy a vuelto a incordiar. Se resetea en un tiempo corto de tiempo, apenas 20 minutos en el caso más extremo, pero es que no es sólo que se reinicie, sino que además pierde toda la configuración, con lo que ni siquiera vuelve a conectar por que le falta la configuración del enlace con Jazztel.

Aparentemente es un problema del mldonkey, según comentan en foros y demás el router no limpia con la suficiente frecuencia sus listas de conexiones, y dado que el mldonkey (como todos los clientes de la red eDonkey) hacen un uso intensivo de las red, éstas acaban desbordándose haciendo reiniciar al router.

Circulaba por Internet un script que cambiada la frecuencia de limpieza de dichas tablas, pero ahora no los encuentro, y además había que ejecutarlos cada vez que se arrancaba el router.

En el FTP de D-Link Italia se puede encontrar el último firmware así como un firmware experimental que se supone soluciona los problemas con los programas P2P, aunque D-Link no se responsabiliza del correcto funcionamiento de dicho firmware.

He comprobado que tengo dicho firmware.

Por otro lado, en Jazztel me comentaron que podría deberse a no tener los puertos del eMule abiertos. La razón me parece bastante surrealista.

Por suerte, he encontrado en el router la manera de salvar y cargar la configuración (pese a que en Jazztel me dijeron que no se podía). No es fácil encontrar la opción; está en Tools, Update Gateway.

Ahora que he encontrado la opción de guardar la configuración el router parece haberse estabilizado, y funciona sin problemas. Vaya usted a saber.

La última sospecha que me queda, y por ausencia de otra coherente parece que va a ser cierta, es que el mldonkey ha debido de tener un fallo. Intentando arrancar a media mañana el mldonkey después de varios cortes seguidos, me daba error con los temporales. Forzando un poco las cosas, he conseguido que los cargue, pero en realidad parecía sólo tener el identificador del archivo, por que todos estaban al 0% de completados, cuando muchos iban por más de la mitad. He borrado finalmente todos los temporales, sin molestarme en buscar una manera de recuperarlos. Creo que no tenía gran cosa.

Así, sospecho que algún problema con los temporales hacía al mldonkey desbordar las tablas de conexiones de mi router en breves minutos. Eliminados los temporales, eliminado el problema.

Veremos a ver si aguanta el día entero...

Actualización:
Una semana después parece que el router sigue sin dar problemas. ¡Óle!

Las fuentes del kernel y su parches en kernel.org

2005-07-06T15:29:00.000+02:00

He estado mirando kernel.org, y decidido clarificar un poco como se organizan actualmente las versiones del kernel en desarrollo y los parches.

Así, tenemos la versión oficial o estable del kernel, sobre la que se pueden aplicar un serie de parches oficiales que "transforman" el kernel a una versión más experimental. Los diferentes tipos de parches, sobre qué aplicarlos y qué momento del desarrollo represetan puede entenderse a través de la siguiente explicación:

Prepatches: Son básicamente versiones alfa de Linux. Se deben aplicar, mediante patch, a las fuentes con versión de 3 números, es decir, el preparche 2.6.12-rc4 deberá ser aplicado a las fuentes 2.6.11, no, por ejemplo, a la versión 2.6.11.10. Los preparches que contienen rc en su nombre se consideran versiones candidatas y prodrán llegar a ser la nueva vesión (esto es importante por que es conveniente que estén muy probadas).
Snapshots: Son las fuentes actualmente en desarrollo, tomadas directamente de los repositorios de los desarrolladores. Son generados atuomáticamente sin ninguna supervisión humana, por lo que es probable que contengan errores o incluso que ni siquiera compilen en un momento dado. Usando patch, la obtención del snapshot 2.6.1-rc1-git5 se haría aplicando a las fuentes 2.6.0 el parche 2.6.1-rc1 seguido del parche 2.6.1-rc1-git5.
-ac patches: Son parches pertenecientes a Alan Cox sobre las versiones oficiales del kernel. Habitualmente son más experimentales que la serie oficial.
-mm patches: Son parches pertenecientes a Andrew Morton sobre las versiones oficiales del kernel. Al igual que los de Alan Cox, suelen ser más experimantales que la serie oficial.

Probando el kernel 2.6.12.1

2005-06-28T00:35:00.000+02:00

Pues como desde hace unos días está disponible el kernel 2.6.12.1 en kernel.org he decidio descargarlo y probarlo.

Descargo y descomprimo la última versión estable de kernel.org, y los descomprimo quedando las nuevas fuentes en /usr/src/kernel-source-2.6.12.1.

Parece ser que el archivo de configuración del 2.6.8 es válido para ésta nueva versión (en principio todos los de la serie 2.6 con compatibles), así que lo copio al directorio de las nuevas fuentes.

Esta vez uso opciones ligeramente diferentes pero cuyo resultado es el mismo:

make-kpkg buildpackage -rev MiKernel.v1 kernel_image

La versión es la 1, puesto que es la primera versión propia del kernel personalizado a partir de las fuentes del 2.6.12.1.

Tras la ejecución de make-kpkg los directorios relacionados con el kernel 2.6.12.1 son:

Documentación del kernel
-rw-r--r-- 1 root src 2,8M 2005-06-28 01:40 kernel-doc-2.6.12.1_MiKernel.v1_all.deb

Cabeceras del kernel
-rw-r--r-- 1 root src 4,9M 2005-06-28 01:41 kernel-headers-2.6.12.1_MiKernel.v1_i386.deb

Imagen del kernel para 386 (386!)
-rw-r--r-- 1 root src 5,6M 2005-06-28 01:42 kernel-image-2.6.12.1_MiKernel.v1_i386.deb

Directorio con las fuentes
drwxr-xr-x 20 root root 4,0K 2005-06-28 01:41 kernel-source-2.6.12.1

Paquete con las fuentes MiKernel.v1
-rw-r--r-- 1 root src 36M 2005-06-28 01:40 kernel-source-2.6.12.1_MiKernel.v1_all.deb

Información sobre el proceso realizadop por make-kpkg
-rw-r--r-- 1 root src 1,4K 2005-06-28 01:41 kernel-source-2.6.12.1_MiKernel.v1_i386.changes

Fuentes originales del kernel 2.6.12.1
-rw-r--r-- 1 nasz nasz 36M 2005-06-26 12:52 linux-2.6.12.1.tar.bz2

Archivo de firma de las fuentes originales del kernel 2.6.12.1 (linux-2.6.12.1.tar.bz2)
-rw-r--r-- 1 nasz nasz 248 2005-06-26 12:38 linux-2.6.12.1.tar.bz2.sign

Tras instalar los correspondientes paquetes, reinicio y recompilo los módulos extras sin problemas. Arranco y todo parece funcionar correctamente.

Los controladores de nVidia empiezan a ser algo molestos, ya que al reinstalarlos para el nuevo núcleo desinstala los controladores para el núcleo anterior, por lo que si quiero volver a usar el kernel anterior debo reinstalar nVidia para poder tener sistema gráfico. Lo lógico sería poder tener instalados varias versiones de los controladores de nVidia, una para cada núcleo, pero dado que son propietarios y que ellos deciden como hacerlo, no es posible. Fáciles de instalar si, y funcionan bien, si, pero si te quieres salir del camino marcado hay problemas.... en fin, quizá haya una manera de bajarse las fuentes o hacer una instalación manual múltiple, vaya usted a saber...

MiKernel.v6b a MiKernelV7b (ALSA)

2005-06-23T16:31:00.000+02:00

Vengo usando OSS desde que instalé el sistema. Sin embargo OSS está obsoleto, sustituido por ALSA (Advanced Linux Sound Architecture), y ya iba siendo hora de cambiar. Sé que si no funciona no se debe de tocar, pero tenía ganas de tocar el tema del sonido.

ALSA, así como OSS, se colocan ente el hardware y los demonios, como aRts, que sirven a los programas para reproducir sónido. ALSA y OSS son una especie de controlador genérico de hardware (puesto que entre el hardware y ASLA ú OSS está el controlador específico para cada hardware).

Tras cacharrear un poco, y tirando de #debian-es de Freenode, me doy cuenta de que tengo tanto OSS como ALSA compilados en el kernel. Grave error, puesto que ámbos controlan el hardware de sonido directamente, y no pueden convivir ámbos juntos. En mi caso era OSS quién se apoderaba del hardware.

Para verlo, y en genreal para cualquier problema de detección de hardware y similar, nada mejor que echar un ojo a dmesg. Ahí se ve los dispositivos detectados y si se ha producido algún error en su inicialización.

Una vez visto el problema genero un nuevo kernel, MiKernel.v7, dejando OSS como módulo y ALSAcompilado dentro del kernel. Ya de paso activo el soprote para la consola framebuffer y el logo de carga (ese Tux que sale en la esquina superior izquierda) que, si no me equivovo, es configurable.

Dado que aún no he escrito explícitamente los pasos claro para recompilar e instalar un nuevo kernel, aquí los pongo:

Hacer una copia de /usr/src/linux/.config para guardar la configuración actual del kernel (si no está hecha ya).

Editar la configuración del kernel, yo lo hago mediante make menuconfig dentro de /usr/src/linux
Renombrar el directorio /lib/modules/2.6.8 si estoy voy a instalar un kernel 2.6.8. Si fuese otra versión del kernel no haría falta puesto que se usaría otro directorio (/lib/modules/). De esa manera guardo los módulo del kernel antiguo por si hubiese algún problema poder volver a él sin dificultades.

Ejecutar make-kpkg clean en /usr/src/linux para limpiar los restos de la última compilación.

Ejecutar make-kpkg --revision=MiKernel.v kernel_image kernel_headers kernel_source para crear los paquetes .deb con la imagen binaria del kernel, las cabeceras y las fuentes.

Una vez compilado el kernel y creado los correspondientes paquetes, que se make-kpkg los deja en /usr/src, se instalan los paquetes de imagen y fuentes. Las cabeceras no hace falta instalarlas ya que están incluidas en las fuentes (yo antes instalaba las fuentes y las cabeceras, método erróneo).

Reininicar

Recompilar el módulo de nVidia, más que nada para poder tener las X. Baasta con ejecutar el script de instalación que tengo en mi almace de software dde están controladores de nVidia que descargué de su web.

Recompilar el resto de módulos no oficiales (los que he compilado yo, como el spca5xx de la webcam, que no vienen en el kernel oficial y por tanto no se compilan automáticamente).

Después de compialr e instalar MiKernel.v7 pruebo ALSA mediante alsaconf. Sin embargo, me avisa de que no encunetra tarjetas válidas.

Trato de ver si se ha reconocido la tarjeta:

# cat /proc/asound/cards
0 [VirMIDI ]: VirMIDI - VirMIDI
Virtual MIDI Card 1
1 [Live ]: EMU10K1 - Sound Blaster Live!
Sound Blaster Live! (rev.10) at 0xd000, irq 16

Pues parece que si. Veamos los dispositivos:

# cat /proc/asound/devices
1: : sequencer
0: [0- 0]: ctl
11: [0- 3]: raw midi
10: [0- 2]: raw midi
9: [0- 1]: raw midi
8: [0- 0]: raw midi
33: : timer
32: [1- 0]: ctl
36: [1- 0]: hardware dependent
40: [1- 0]: raw midi
51: [1- 3]: digital audio playback
58: [1- 2]: digital audio capture
57: [1- 1]: digital audio capture
48: [1- 0]: digital audio playback
56: [1- 0]: digital audio capture
38: [1- 2]: hardware dependent
41: [1- 1]: raw midi
42: [1- 2]: raw midi

Parece que también están ahí. Sin embargo, no reproduce:

# aplay /home/NaSz/ping.wav
aplay: main:508: audio open error: No such device

Me vuelvo a quedar sin ideas. Momento de recurrir al IRC, Freenode, canal #alsa:
Now talking on #alsa
* Topic for #alsa is: Advanced Linux Sound Architecture || Unprofessional, unofficial support, see WIKI at http://alsa.opensrc.org/
* Topic for #alsa set by jcdutton at Mon Aug 23 00:38:12 2004
NaSz: hi
NaSz: I'm trying to get alsa working on Debian 2.6.8 kernel
NaSz: I've compiled the kernel with alsa built in and oss as modules
NaSz: now /proc/asound/cards and /proc/asound/devices show me my SoundBlaster Live! using emu10k1
NaSz: but when I test it with aplay I get "aplay: main:508: audio open error: No such device"
pzad: NaSz: look at /dev/snd/* if there are device files
NaSz: yes, a lot of files
pzad: what is in /proc/asound/cards
NaSz: # cat /proc/asound/cards
NaSz: 0 [VirMIDI ]: VirMIDI - VirMIDI
NaSz: Virtual MIDI Card 1
NaSz: 1 [Live ]: EMU10K1 - Sound Blaster Live!
NaSz: Sound Blaster Live! (rev.10) at 0xd000, irq 16
pzad: try
pzad: aplay -D plughw:1 some.wav
pzad: and alsamixer -c 1
NaSz: hey! it sounds!
pzad: did you compile alsa as modules or in to kernel
NaSz: in to kernel
pzad: your problem is virtual midi module - it is as first card and sb live is second
pzad: you can specify order of soundcards in kernel command line at oot time
pzad: for example snd-intel8x0.index=0 snd-emu10k1.index=1
NaSz: wich names I must use?
pzad: I think for you snd-emu10k1.index=0 snd-virmidi.index=1

Es decir, que el primer dispositivo de sonido es el MIDI virtual, que evidentemente no tiene las capcacidades de una tarjeta de sonido, por lo que alsaconf falla, ya que debe de usar el primer dispositivo que encuentra.

Es similar a lo que me pasaba con el soporte UltraDMA: se cargaban primero los controladores IDE genéricos que no tenían soporte para UltraDMA, y después los específicos para mi hardware, pero el núcleo usaba los primeros, por lo que no tenía UltraDMA.

Para solucionarlo se puede, como comenta pzad, pasarle unos parámetros al kernel de manera que coloque los dispositivos en un orden determinado, o recompilar el kernel eliminando el dispositivo MIDI virtual.

Decido que lo mejor es recompilar el kernel eliminado el soporte para el MIDI. Reconfiguro, recompilo, instalo, reinicio y compilo los módulos necesarios. Ejecuto alsaconf y ésta vez funciona. Abro el KDE y el sonido de bienvenida me indica que también funciona, como era de esperar, en KDE.

Nota: Dado que ya no uso ndiswrapper para la conexión inalámbrica, podría recompilar el kernel de nuevo con pilas de 4K en vez de 8K (los controladores de Windows que usaba ndiswrapper gustan de las pilas de 8K, pero con 4K se obtiene un rendimiento mayor del sistema).

Archivos Musepack (MPC) en XMMS

2005-06-18T03:23:00.000+02:00

Para reproducir archivos MPC con xmms basta con instalar la extensión (plugin) xmms-musepack.

Descargar, compilar como usuario, copiar el fichero xmms-musepack-1.00.so en el directorio ~/.xmms/Plugins y reiniciar el XMMS.

Lo más extraño es que el archivo de instalación que acompaña a la extensión parece corresponder a una versión para Windows; habla delWinAmp, de copiar el fichero xmms-musepack-*.dll, pero funciona.

Para otros programas se puede instalar directamente el paquete libmpdev3.

Videconferencia con aMSN: probado y funcionando

2005-06-17T21:33:00.000+02:00

Había probado la webcam con el aMSN un par de veces, pero no había funcionado. No sabía si era una ceustión d epuertos abiertos, de que el aMSN no reconocía la cámara o de que la alineación planetaria no era la correcta.

Asi que fui meticulosamente.

La primer fuente de información interesante para éstas cosas es el wiki del aMSN. Ahí hay información actualizada sobre el aMSN. Especialmente interesante es la página sobre webcam con aMSN. En ella se comenta, aparte de otros problemas, como probarla cámara con aMSN:

Now you can go to your /msn/utils/linux/capture/ directory and type "./test.tcl" in a console.

Efectivamente a mi me funciona (está en /usr/share/amsn/utils/linux/capture).

Ahora los puertos. Es necesario abrir los puertos TCP y UDP desde el 6890 hasta 6900. Por lo que he podido leer, éstos sirven para enviar y recibir ficheros, siendo el número de dichos puertos abiertos el límite al número de transferencias que se pueden realizar, hsat un máximo de 10. Sin embargo, en la página del wiki de aMSN parecen querer decir que también son necesarios para la videoconferencia.

Por otro lado he leído que se deben abrir desde el puerto 5000 UDP hasta el 65535 para videoconferencia. No me agrada abrir semejante rango de puertos, pero al ser UDP, y al no haber servicios detrás, acepto. Tendré que estudiar si realmente es necesario.

Hoy por fin he vuelto a probar, y está vez ha funcionado perfectamente. Va un poco lento, pero va. He probado aque me visen amigos con ADSL sin webcam y ellos me veian. Luego he probado con una amiga que si tenía webcam y nos veíamos ambos, pero iba muy lento, incluso el sistema estaba ralentizado. Vaya usted a saber por qué.

Webcam con clientes de MSN Messenger

2005-06-14T13:56:00.000+02:00

Las pijaditas siempre dan vidilla, y el poder ver a mi colega PeZeta que está al otro lado del charco siempre siente bien. Comentando en #debian-es de los servidores debian, me dicen que al menos la última versión (0.95) del amsn (Alvaro's Messegner) admite videoconferencia con clientes de MSN Messenger. Además, compila no hace falta tener paquetes de la distribución en desarrollo.. ¡una ganga!

También se comenta que gaim-vv permite videoconferencia, pero creo recordar que era sólo con yahoo.

En la página oficial de aMSN figura hasta la 0.94, así que me pasan el enlace, que no es más que la versión CVS. Descargo, y trato de ejecutar (viene con un binario). Error. En los ficheros de ayuda se comenta que me hace falta tcl y tk. Bien. Instalo ambos, incluida la versión de desarrollo por si quiero compilar.

Compilo y ejecuto. Funciona.

Jugando con él, experimentaba culegues aleatorios, muy molestos, sabía que usaba una versión de desarrollo, pero aquello era un desfase. Buscando mucho, econtré la página de problemas conocidos del wiki de amsn. En ella comentan:

Description: Some people is experimenting random hangs when using AMSN on Debian and Linux Kernel 2.6 It looks like the problem is caused because of the new threads model in the 2.6 kernel.

Workaround: You can stick to kernel 2.4 until this is fixed, probably not in the kernel, but in AMSN or in the new versions of the Tcl interpreter. We're working with the tcl/tk team to have this fixed.

It looks like these hangs only happen with Linux Debian using Kernel 2.6 and TCL 8.4, so downgrading to TCL 8.3 fixes this.

Also, you can download tcl/tk 8.4 sources from http://tcl.sourceforge.net, and build them yourself, making sure you DON'T enable the --enable-threads option when running the configure script. Without this option, amsn will run just fine.

Another possible solution is to launch amsn with:

export LD_ASSUME_KERNEL=2.2.5 && msn/amsn

to tell the dinamic linker to use the old thread model.

Así, por el momento lo ejecuto con el comando export LD_ASSUME_KERNEL=2.2.5 && amsn. Mientras me he entretenido bajandome unas pieles y echando un vistazo a la página web del amsn.

Mi cámara. Reviso mis envíos...vaya, debía de haber explicitado más, no queda claro como lo hice. Bueno, son necesarios dos módulos, videodev y spca5xx para que funcione.

modprobe videodev
modprobe spca5xx

El primero va fino, pero el segundo parece que no lo encuentra. Lógico, pués al haber recompilado el kernel los módulos adiconales que he añadido yo los tengo que volver a compilar. No estaría de más hacerse un script que los compilase junto al kernel. Basta con ir a /usr/src/modules/spca5xx-20050407/ y hacer make clean, make y make install.

Sólo queda probarla después de cargar el módulo de la cámara y probarla con spcaview. A la primera lo probé como root, se pusó en pantalla completa y no salió de ahí, se me colgó. Mientras arreglaba el desaguisado mi único contacto conectado se ha ido a dormir. No lo puedo probar, tendré que esperar a mañana.

Notas sobre posibles bugs:
Casca si se abre el programa con la cámara concetada y encendida como webcam.
No abre me abre un fichero como avatar, sospecho que por que lleva ñ. Quito la ñ y ya va.

El encumbramiento y la caida del D-Link DWL-G122

2005-06-07T13:37:00.000+02:00

Esta es la triste historia del interfaz de red inalámbrico D-Link DWL-G122.

Una vez compilado el kernel, me dispuse a usarlo. Hice un bonito envío con todos los detalles pero se perdió (los de blogger tienen que depurar su sistema de edición, a veces falla se pierde lo escrito), así que ahora estoy vago y con pocas ganas de volver hacerlo.

En resumidas cuentas, una vez compilado el ndisWrapper se debe instalar el controlador de Windows, y luego configurar el acceso de red inalámbrico. Dejo un enlace a un artículo en badopi que comenta todo esto, ya que yo he perdido las ganas de hacerlo.

Tuve unos días felices en los que accedía a mi router de manera inalámbrica, sin problemas, pero era un espejismo. En seguida empezaroin los problemas, las desconexiónes, respuestas extrañas, cuelgues aparentes del router y demás paranoias. Quisé achacarlo al router, a Jazztel, pero cuando empezaron los cuelgues del sistema me convencí de era el controlador de la red inalámbrica.

Por suerte tengo el rotuer cerca del ordenador y puedo tirar de cable. Como no es un portatil no importa, no lo voy a mover.

Una pena, habrá que esperar a que ndisWrapper madure, o ver otras opciones. Tengo que preguntar a ver si hay una manera razonable de depurar mi sistema para ver si puedo ver por qué se cuelga, y así echar una mano al desarrollo de ndiswrapper.

Por el momento sigo tirando de cable ethernet.

Volcando CDs al disco duro

2005-06-07T13:07:00.000+02:00

Ahora que tengo el ordenador definitivamente instalado en casa es momento de ir pasando a MP3 unos cuantos de mis discos. Usaría Ogg Vorbis, pero mi reproductor MuVo no lo admite. Según he oído, aducen que decodificar el formato Ogg exige un mayor consumo de energía por lo que las baterías durarían mucho menos. Yo, por mi parte, preferiría que me durase menos la batería y poder tener mi colección de música en Ogg, pero por el momento no va a ser posible.

Hay un manual de grabación digital de música hecho por acs en el que comenta las nociones básicas.

Yo por mi parte voy directamente a lo mío.

Para extraer uso cdparanoia, que bien con grip. La codificación la hago con lame. Debido a liíos de licencias y demás historias, lame no pude ser distribuido como binario, por lo que no está disponible mediante apt. Desde la página de lame descargo la última versión (3.96.1). Descomprimo, compilo e instalo (./configure, make, make install). Al principio obtengo un error debido, aparentemente, a que el script de compilación no soporta espacios en la ruta o rutas muy largas. El hecho es que moviendo todo a /tmp me compiló sin problemas.

A grip hay que pasarle los parámetros que usará con los programas auxiliares que le ayudan a ahcer su trabajo. En el caso de cdparanoia nohace muhca falta ya que está muy integrado con grip, pero para el lame hay que especificarlos. Pretendo codificar en MP3 a ratio de bits varaible (VBR), con Joint Stereo y con bastante calidad. Así, el comando será:

lame -V 2 %w %m

%w indica a grip que debe ser sutituido por el nombre del archivo wav en proceso.
%m indica a grip que debe ser sutituido por el nombre del archivo codificado en proceso.
-V 2 indica a lame que debe codificar usando ratio de bits variable con calidad 2 (entre 9 y 0, siendo 9 la peor y 0 la mejor). Eso implica, viendo el manual, que usará joint stereo.

Hay que especficiar también como se llamarán los ficheros. Para eso se usan esas 'variables' de grip que contienen el nombre del wav o el nombre del fichero codificado. Éstas variables son:

b — The bitrate that files are being encoded at.
c — The CDrom device being used.
C — The generic scsi device being used (note that this will be substituted with the CDrom device if no generic scsi device has been specified).
w — The filename of the wave file being ripped.
m — The filename of the file being encoded.
t — The track number,beginning at 1, and zero-filled (ie: '03' for the third track).
s — The start sector of the track.
e — The end sector of the track.
n — The name of the track.
a — The artist name for the track.
A — The artist name for the disc.
d — The name of the disc.
i — The disc database id (in hex) for the disc.
y — The year of the disc.
g — The ID3 genre id of the disc.
G — The ID3 genre string of the disc.
r — The recommended replay gain for the track (in dB). Note that this is only applicable if you have enabled gain calculation. You can find more information on this gain adjustment at www.replaygain.org
R — The recommended replay gain for the entire album (in dB). This value is only valide after an entire disc has been ripped (it is designed to be used with the disc filter command).
x — The encoded file extension (ie "mp3")

Así, mis ficheros mp3 finales serán:

~/rips/mp3/%A - %d (%y)/%t - %n.%x

De manera que quedan organizados en discos, con el año de grabación indicado.

Por último quisiera aplicarles normalización. Según lo entiendo yo lo que quiero es subir el volumen de las pistas hasta el máximo posible pero sin altera la relación entre los diferentes volúmenes de las partes de la canción. Para ello usaré la normalización mediante picos, es decir, calcular el máximo nero de decibelios que puede ser subido el sample má alto (el mayor pico) y subir todos los samples esa cantidad. Para ello se utilza el programa normalize (apt-get install normalize) al que llamo mediante grip en la opción 'comando de filtro wav' de la pestaña extraer, que llama a un comando después de cada extración. Quedaría así:

/usr/bin/normalize %w --peak

Ah, y no olvidar activar la opción de las etiquetas ID3 para que el fichero lleve los datos de la canción, que serán obtenidas a través un servidor cddb.

Por último, un enlace que muestra las opciones de ejecución de lame.

El USB se niega a desmontarse

2005-05-24T14:09:00.000+02:00

A veces tengo problemas para desmontar dispositivos, especialmente mi bonito reproductor de MP3 portatil MUVO que funciona como USB Mass Storage. No me deja desontarlo, y me ponga como me ponga se niega a desmontarse alegando que está ocupado. No tengo ningún programa que tenga abierto algún archivo o directorio del USB.

Forzando el desmontaje sólo he conseguido que se me corrompa el sistema de archivos, por que el reproductor se vuelve loco: se apaga a mitad de la reproducción, o directamente no se enciende.

Hoy vamos a solucionarlo. Tengo el USB metido y se niega a desmontarse. Muy bien, vamos a ver.

Empezamos por lo típico, fuser, que identifica procesos que están usando ficheros y sockets. El USB está montado en /dev/sda1:

# fuser /dev/sda1

Nada, no responde nada.

Buscando un poco por la web encuentro una referencia al comando lsof. Parece ser que lista los ficheros abiertos, con un conveniente grep se pueden localizar los ficheros abiertos de mi USB. Probemos:

# lsof | grep USB
famd 1657 ****** 100r DIR 8,1 16384 14 /mnt/USBDrive/Sonic Youth EP

Los ****** son el nombre usuario que he ocultado.
Joder, ¿eso de famd que puñetas es? Pues parece responder al nombre de File Alteration Monitor, y la d es daemon, claro. Así que debe ser un proceso que monitoriza cambios en los ficheros, y se ha debido de empeñar en monitorizar la unidad que quiero desmontar. Muy bien, pues quizá deba pensar en eliminar es proceso... antes habrá que informarse de a quién quiero eliminar, no sea que sea imprescindible o muy necesario. A golpe de Google, encuentro un artículo en el Wiki del LUGFI sobre problemas con mount en el que se comenta:

Problema: el Nautilus no me desmonta los dispositivos, y tengo que cerrar el X y desmontar desde consola.

Solución: desde Gnome 2.4 y continúa en 2.6 se agregó un daemon llamado FAM (File Alteration Monitor) que básicamente lo que hace es avisar a cualquier aplicación que se lo requiera de cuando ocurre un cambio en el sistema de archivos para que la aplicación pueda mostrar el cambio al instante. Una forma de probarlo en abrir el Nautilus en un directorio y desde una consola crear o borrar un archivo, verás como al instante el cambio se refleja en el Nautilus por arte de magia.

El problema (y es un bug documentado y sin solución hasta el momento) es que cuando montás un dispositivo, el FAM se queda leyendo el directorio todo el tiempo (/mnt/cdrom en el caso del CD) entonces cuando lo querés desmontar el kernel no te deja porque alguien (el FAM) está utilizando el dispositivo.

Lo que podés hacer es matar el demonio y todo se soluciona. Si borrás el script de /etc/rc2.d mejor aún, así no arranca más.

Vaya, no me lo podían haber dejado más claro. Me cargo del servicio del apmd mediante:

# /etc/init.d/fam stop
Stopping file alteration monitor: FAM.

Ahora desmonta mi USB perfectamente. Asunto arreglado. Tendré que ocuparme de los scripts de inicio para que no se lance de nuevo el apmd al arrancar el sistema. Aunque... ¿si uso KDE que hace ese demonio de Gnome ejecutandose? ¿Será por tener ambos instalados? Lo suyo sería que cada uno arrancase sus servicios cuando se inicien, para así no tener servicios inncesearios (y jodones como en éste caso), ¿no?. Esto habría que revisarlo.

Bien a gusto me he quedado después de arreglar uno de esos comportamientos que no se entienden, que parecen aleatorios y que sólo dan mala imagen, recordando lejánamente a los absurdos comportamientos que tiene Windows, sólo que en éste caso el problema es identificable y solucionable.

Actualización: Días después he tenido el mismo problema, borré un directorio de mi unidad USB y se negaba a desmontar. Tirando de lsof encuentro:

$ lsof | grep USB
kdeinit 2522 **** 145r DIR 8,1 16384 23 /mnt/USBDrive/barry adamson - the king of nothing hill (deleted)

Vaya, kdeinit, suena mal, ¿voy a tener que matar todo el KDE? Mirando el árbol de procesos veo que el PID (segunda columna) corresponde a Konqueror. Sin embargo no tengo ninguna ventana de Konqueror abierta. Pensando pensando, llego a la conclusión de que KDE precarga Konqueror, de manera que figura como lanzado por kdeinit y permanece en memoria aunque se cierren todas las ventanas. Como debe de tener alguna funcionalidad de monitorización de archivos, queda abierta la unidad USB, de manera que no me deja desmontarla. Muerto el perro, se acabó la rabia, así que elimino el proceso Konqueror y ya puedo desmontar con tranquilidad.

Comentando el asunto en los servidores Debian de IRC en el canal #debian-es me apuntan que mi problema tiene un bug oficial abierto:
Debian Bug report logs - #252571 konqueror doesn't end process, so CD won't unmount
Ahí se explica el problema y se proponen algunas soluciones, que básicamente se reducen a limitar el número de instancias de Konqueror precargadas a cero (con lo cuál se incrementa bastante el tiempo de carga de Konqueror) o localizar la instancia oculta de Konqueror y matarla. En el canal #debian un tipo me comentaba que él había hecho un script que localizaba y mataba los procesos que tenían ficheros abiertos en su unidad USB y lo llamaba mediante una opción del menu contextual del icono de su unidad USB. Ésta solución, aunque es un parche mientras se arregla el bug, parece buena y además es limpia en el sentido de que no hay que tirar de consola, no da mala imagen (no queda nada bonito tener que soltar unos comandos para poder sacar la unidad USB, aquellos que lo vean pensarán que Linux es un infierno de comandos para todo) y lo pueden usar hasta los usuarios más desconocedores del sistema (puesto que se realiza a golpe de clic).

D-Link DWL-G122, red wireless USB y ndisWrapper II

2005-05-21T15:34:00.000+02:00

Compilado mi nuevo y flamante kernel, estoy en disposición de seguir adelante con mi red inalámbrica.

Ejecuto make distclean, make y make install sobre las fuentes de ndiswrapper y esta vez compila sin problemas.

El siguiente paso es instalar el controlador para Windows de mi tarjeta de red inalámbrica.

# ndiswrapper -i netrtusb.inf

Puede comprobarse que controladores hay instalados y que hardware está presente mediante el comando:

# ndiswrapper -l
Installed ndis drivers:
netrtusb driver present, hardware present

En mi caso figura el controlador como presente por que lo tengo instalado.

Veamos que redes están a disponibles:

# iwlist wlan0 scan
Warning: Driver for device wlan0 recommend version 18 of Wireless Extension,
but has been compiled with version 16, therefore some driver features
may not be available...

wlan0 Scan completed :
Cell 01 - Address: 00:A0:C5:C2:11:52
ESSID:"Wireless"
Protocol:IEEE 802.11b
Mode:Managed
Frequency:2.412 GHz (Channel 1)
Quality:0/100 Signal level:-63 dBm Noise level:-256 dBm
Encryption key:off
Bit Rate:1 Mb/s
Bit Rate:2 Mb/s
Bit Rate:5.5 Mb/s
Bit Rate:11 Mb/s
Bit Rate:6 Mb/s
Bit Rate:9 Mb/s
Bit Rate:12 Mb/s
Bit Rate:18 Mb/s
Bit Rate:24 Mb/s
Bit Rate:36 Mb/s
Bit Rate:48 Mb/s
Bit Rate:54 Mb/s
Extra:bcn_int=200
Extra:atim=0
Cell 02 - Address: 00:0F:3D:B2:3F:54
ESSID:"G604T_WIRELESS"
Protocol:IEEE 802.11b
Mode:Managed
Frequency:2.437 GHz (Channel 6)
Quality:0/100 Signal level:-39 dBm Noise level:-256 dBm
Encryption key:off
Bit Rate:1 Mb/s
Bit Rate:2 Mb/s
Bit Rate:5.5 Mb/s
Bit Rate:11 Mb/s
Bit Rate:6 Mb/s
Bit Rate:9 Mb/s
Bit Rate:12 Mb/s
Bit Rate:18 Mb/s
Bit Rate:24 Mb/s
Bit Rate:36 Mb/s
Bit Rate:48 Mb/s
Bit Rate:54 Mb/s
Extra:bcn_int=200
Extra:atim=0

Mmm... dos redes a tiro. La G604T_WIRELESS es la mía por que es mi modelo de router, la otra es la red del vecino que también me vino para algunas cosillas mientras me traian mi ADSL.

Nos conectamos a mi red:

# iwconfig wlan0 essid "G604T_WIRELESS"

Ahora se necesita una dirección IP. EL router viene configurado con DCHP, así que por el momento lo voy a dejar así. Para ello uso dhclient, que si bienno me lo he estudiado si sé que me servirá para obtener una dirección IP.

# dhclient
Internet Software Consortium DHCP Client 2.0pl5
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.

Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html

sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/wlan0/00:11:95:d0:38:ec
Sending on LPF/wlan0/00:11:95:d0:38:ec
Listening on LPF/sit0/
Sending on LPF/sit0/
Listening on LPF/dummy0/1a:60:19:07:1a:f0
Sending on LPF/dummy0/1a:60:19:07:1a:f0
Listening on LPF/lo/
Sending on LPF/lo/
Listening on LPF/eth0/00:0d:61:36:fb:25
Sending on LPF/eth0/00:0d:61:36:fb:25
Sending on Socket/fallback/fallback-net
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on sit0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on dummy0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
receive_packet failed on wlan0: Network is down
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on dummy0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on sit0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on lo to 255.255.255.255 port 67 interval 13
DHCPOFFER from 192.168.1.1
DHCPOFFER from 192.168.1.1
DHCPOFFER already seen.
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
/usr/sbin/postconf: fatal: open /etc/postfix/main.cf: No such file or directory
cp: `/etc/resolv.conf' and `/etc/resolv.conf' are the same file
run-parts: /etc/resolvconf/update-libc.d/postfix exited with return code 1
run-parts: /etc/resolvconf/update.d/libc exited with return code 1
bound to 192.168.1.3 -- renewal in 1800 seconds.

Es probable que haya una manera más sencilla, más que nada que no busque en todos los interfaces de red sino sólo en el wlan0. Mirando la ayuda de dhclient.conf no parece tan sencillo, y además comenta que muchas veces bastará con crear un dhclient.conf vacío y punto. Vale, pues punto pelota, así se queda.

También veo que postfix se queja. Bueno, en realidad sus restos por que postfix lo desintalé hace tiempo, así que se ha debido de quedar algo pillado. Una cosa para revisar.

Haciendo ping a Google el amigo de los niños veo que tengo red....¡olé!. Bien, no ha sido difícil. Más adelante a ver si miro el asunto de la protección de la red, por el momento la dejo abierta, además, puede ser de lo más divertido si algún vecino incauto se me conecta... :-P

MiKernel.v 5 a MiKernel.v6 (Soporte Wireless)

2005-05-21T14:52:00.000+02:00

He creado dos nuevos kernels, el v6 y v6b. El primero con pilas de 4K y el segundo con pilas de 8K.
El primero me dió problemas, tantos que lo deseché y usé el v6b. Sospecho que qizá fue culpa mía, ya que intenté compilar el módulo de nVidia sin haber instalado las fuentes del correspondiente kernel. Pensaba que al no haber cambiado la versión del kernel (aunque si la configuración del mismo) no hacía falta instalar las fuentes pero éstas deben de cambiar en función dela configuración. Imagino que será debido a las variables de compilación y código condicional, pero el caso es que parece ser necesario instalar tanto la imagen y las cabeceras del kernel como las fuentes, aunque sea la misma versión del kernel.

Por el momento tiraré con las pilas de 8K, más adelante quizá vuelva a probar con las pilas de 4K, si es que mi controlador de windows de la tarjeta inalámbrica lo soporta.

Traducción al estilo Babylon

2005-05-16T14:18:00.000+02:00

Siempre me gustó el Babylon: rápido, sencillo, muy muy cómodo, y aparentemente con bastante calidad. Pero en mi renovada condición de linuxero de pro no hay cabida para programas propietarios de pago, ni por supuesto para versiones crackedas.

La solución en el mundo el software libre es wordtrans. Es un interfaz para varios diccionarios, servidores dict y diccionarios Babylon. Dispone de versiones para X (QT), KDE y consulta mediante navegador web.

Para usarlo lo primero es instalar wordtrans:

apt-get install wordtrans kde-wordtrans

kde-wordtrans es el paquete con la versión específica para KDE, por lo que apt instalará el resto de paquetes base requeridos para que funcione wordtrans.

Ahora se necesitan los diccionarios. Una opción es usar servidores dict. Estos servidores dan un servicio de diccionario; dada una palabra responden con una definición, o, en su caso, con una traducción. sin embargo, he sido incapaz de hallar un servidor dict inglés-español, aunque si un diccionario de definiciones en inglés que parece que etá bastante bien. Para acceder los diccionarios dict es necesario el paquete dict que contiene el programa cliente:

apt-get install dict

¿Fácil, no?.

Sin embargo, seguimos sin tener traducción de español a inglés. Podemos usar i2e, paquete que contiene un diccionario inglés-español (y viceversa) y consultarlo mediante kwordtrans. Para ello basta con instalar elpaquete i2e, abrir kwordtrans, pulsar en Dictionaries > New y seleccionar 'plain text'. En la siguiente ventana se configura el diccionario. En mi caso kwordtrans es bastante listo y ha puesto la configuración básica de i2e, que no es más indicar ':' como separador y apuntar al fichero de texto que contiene el diciconario, que en mi Debian está en /usr/share/i2e/i2e.dict. El cuadro de texto llamado 'Personal' es el archivo dónde se guardarán palabras extras añadidas por el usuario.

Otra opción es usar los archivo de diccionario de Babylon. La manera es muiy similar. Primero se obtiene el archivo diccionaro que queramos (.dic). Temo no estar seguro de como obtuve el mío, pero si no recuerdo mal lo descargué de la web de Babylon. Después se indica a kwordtrans, de la manera anterior, que disponemos de un nuevo diccinario, especificando que es de tipo Babylon. En la ventana de configruación del diccionario se le indica el archivo .dic obtenido y listo.

Por cierto, para pasar el archivo de Babylon a otra persona, es necesario enviarle 3 archivos: english2.dic, english.dic y EngtoSpa.dic.

Una vez ejecutandose, kwordtrans puede espiar el portapapeles y traducir cualquier palabra (o primera palabra de un texto) que llegue al portapapeles. Se puede observar su funcionamiento en la siguiente imagen:

La pega, y no es baladí, es que si dejas activo el espionaje del portapapeles la ventana amarilla del kwordtrans salta siempre que copies texto al portapapeles, lo cuál puede ser algo incómodo. Se se deja desactivado, hay que activarlo cuándo se esté uno documentando y quiera la traducción a mano, o abrir directamente la ventanana del programa e introducir la palabra a consultar. Pero se pierde la ultracomodidad del Babylon de seleccionar una palabra, pulsar un rápida combinación de teclas y obtener el resutlado, todo en menos de un segundo.

Dado que kwordtrans soporta dcop intenté currarme, mediante las teclas globales de acceso rápido de KDE (KHotKeys) la funcionalidad que buscaba. Desgraciadamente el servicio dcop deja de responder cuando se usa kwordtrans. Decidido a seguir adelante me puse en contacto con su autor y él me respondió que el soporte para dcop fue programado para KDE 2, razón por la cuál no funciona, y que ahora está falto de documentación para KDE 3, por lo que por el momento la cosa está un poco difícil.

Bueno, lo usaré acitvando el espionaje del portapapeles cuando vaya a usarlo intensivamente y más adelanta, si arrgeglan el problema con dcop, intentaré configurar las KHotKeys para que funcione a golpe de ratón ( y tecla).

Aunque si le echase valentía y horas podría echar un vistazo a eso de programar interaces dcop...

Por cierto, la mayor parte de la información está obtenida del artículo de Bulma 'Wordtrans: un Babylon para Linux'.

Ficheros .Desktop en KDE - Menús contextuales y demás

2005-05-13T11:21:00.000+02:00

Cuando ya pensaba que iba a tener que aprender a usar los ficheros .desktop por ciencia infusa e iluminación binaria, acabé por descubrir éste bonito tutorial para crear Service Menus en Konqueror (pues ese es el nombre que reciben estas cosas, Service Menus).

Básicamente es como había comentado anterioremente. Los directorios dónde guiardarlos pueden ser:

/opt/kde3/share/apps/konqueror/servicemenus/
/usr/share/apps/konqueror/servicemenus/
/home/aaron/.kde3/share/apps/konqueror/servicemenus/

Respecto a los mymetypes, se comenta lo siguiente:

Para crear service menus para directorios usar inode/directory.
Para crear service menus para todos los ficheros usar all/all.
Para crear service menus para todos los ficheros pero no para directorios usar all/allfiles.
Para crear service menus para toda una categoria, por ejemplo imágenes, usar image/* (Apartir de KDE 3.2).

Por último, para crear submenús, se usa X-KDE-Submenu. Éste es el ejemplo que del tutorial (service menu para poner una imagen como fondo de pantalla):

[Desktop Entry]
ServiceTypes=image/*
Actions=setAsWallpaper;tileAsWallpaper
X-KDE-Submenu=Use As Wallpaper

[Desktop Action setAsWallpaper]
Name=Scaled
Icon=background
Exec=dcop kdesktop KBackgroundIface setWallpaper %U 6

[Desktop Action tileAsWallpaper]
Name=Tiled
Icon=background
Exec=dcop kdesktop KBackgroundIface setWallpaper %U 2

Como puede verse, es sencillito, basta con usar dicha claúsula dandole el nombre del submenú.

Lo que es muy intersante es la línea de ejecución de éste service menu, ya usa dcop. Dcop es un sistema de KDE para que los programas interaccionen entre sí, también accesible por el usuario. Basicamente los porgramas exportan una interfaz que es accesible tanto desde otros programas como desde la línea de comandos.

Dcop merce un envío a parte.

D-Link DWL-G122, red wireless USB y ndisWrapper

2005-05-06T03:59:00.000+02:00

Nueva sorpresa, el router inalámbrico D-Link G604T viene con un adaptador de red wireless USB (D-Link DWL-G122). Vemos a ver si funciona con Linux.

En Debian.org comentan la existencia de NdisWrapper. La descripción del programa es la siguiente:

User space tools for ndiswrapper. Some wireless network cards don't have native Linux drivers. NdisWrapper allows you to use such cards by loading Windows drivers and emulating NDIS (Windows network driver) API.

Es decir, que aprovecha los controladores escritos para Windows, emulando la interfaz NDIS (interfaz de programación de dispositvos de red) que ese sistema operativo implementa. Lamentablemente, como comentan en su página de preguntas frecuentas, mediante este sistema sólo se puede ofrecer una funcionalidad limitada, sin incluir, por ejemplo, los modos monitor o promiscuo. Es debido a que muchas de estas funciones las realiza el controlador sin usar NDIS mediante comandos propios no documentados.

Como eso último no me ha gustado, investigo algo más. Como comenta un maquero en Macuario.com, mi modelo de adaptador lleva en su interior un chip de Ralink del cúal existe un controlador (entre otras cosas gracias a Ralink). Esa página enlaza con el proyecto de código abierto los chipset 2400 y 2500 de Ralink. Desafortunadamente pone bien claro en la página de descargas que no se soportan los dispositivos USB.

Se comenta por el foro que estaría bien que soportase USB, pero parece que la cosa va a tardar, están rescriendo el código y centrados en otras cosas. Dado que no estoy yo muy puesto en programación de controladores para linux y ni en el manejo del USB, no me veo haciendolo yo.

Volvemos a NdisWrapper; apt-get install ndiswrapper me descarga e instala la versión 1.1.4. Extraigo el tar.bz en /usr/src/modules para compilarlo. Siguiendo las instrucciones del wiki de instalación hago un make distclean, make y... ¡mierda!

*** WARNING: Kernel is compiled with 4K stack size option (CONFIG_4KSTACKS); many Windows drivers will notwork with this option enabled. Disable CONFIG_4KSTACKS option, recompile and install kernel

Recuerdo esa jodida opción. ¿Por qué puñetas la puse? Se comenta por los foros que puede funcionar con pilas de 4K. Pues yo me la juego.

Pues eso no es todo. compilando también obtengo el siguiente aviso:

*** Warning: "wireless_send_event" [/usr/src/modules/ndiswrapper/ndiswrapper.ko] undefined!

No hay suerte hoy. Consultada la página de preguntas frecuentes, se comenta que se debe a que no tengo activada la opción de Wireless LAN en el kernel. ¡Agghhh! ¿No querías ir construyendo tu kernel poco a poco? Pues toma, dos tazas.

¿Lo compilo con pilas de 4 u 8 kilobyes?

Ya se verá, por el momento a dormir, que ya toca.

Menús contextuales en KDE

2005-04-28T17:04:00.000+02:00

Andaba yo tan contento con mi XMMS vestido con las pieles del Winamp, y regocijandome de haber podido corrgir el problema de las fuentes pequeñas en GTK, pero no podía reprimir un gesto de disgusto cuando navegaba por mis archivos de música y no tenía la opción en el menú contextual de Konqueror para encolar o reproducir las canciones sin tener que arrastrarlas hasta el interfaz gráfica del XMMS.

Como siempre, un poco de investigación da sus frutos.

Parece ser que existen unos archivos .desktop que le indican a KDE éste tipo de cosas. Pertenecen a una especificación abierta de FreeDesktop a la que parece que tanto Gnome como KDE están adscritos, con mayor o menor grado de implementación, llamado Desktop Entry Specification. Gracias a ésta especificación se pueden describir acciones a realizar sobre cada tipo de archivo. No es la única utilidad que tiene, ya que su propósito es más amplio; como comentan en su sitio web, los ficheros .desktop describen información sobre aplicaciones, como el nombre, icono y descripción. Presumo que entre estas informaciones se incluye el como tratan las aplicaciones cada tipo de archivo.

En el caso del manejo de archivos, se trata de crear un nuevo archivo .desktop en el direcotrio '/usr/share/apps/konqueror/servicemenus' si queremos que la acción del menú contextual esté disponible para todos los usuarios o en '$HOME/.kde/share/apps/konqueror/servicemenus' si lo que queremos es que sólo lo vea un usuario determinado.

Creamos, por tanto, en el directorio deseado, el archivo accionesXMMS.desktop, con el siguiente contenido:

[Desktop Entry]
Actions=encolar_en_XMMS;encolar_en_XMMS_inmediato;reproducir_en_XMMS
Icon=
ServiceTypes=audio/x-mp3,audio/x-vorbis,audio/vorbis,audio/x-wav,audio/wav,audio/mpegurl,audio/x-ms-wma,inode/directory

[Desktop Action encolar_en_XMMS]
Exec=xmms -e %F
Icon=sound
Name=Enqueue in XMMS
Name[es]=Encolar en XMMS

[Desktop Action encolar_en_XMMS_inmediato]
Exec=xmms -Q %F
Icon=sound
Name=Enqueue in XMMS inmediatly
Name[es]=Encolar en XMMS inmdediatamente

[Desktop Action reproducir_en_XMMS]
Exec=xmms %F
Icon=sound
Name=Play in XMMS
Name[es]=Reproducir en XMMS

Veamos la utilidad de cada sección y parte:

[Desktop Entry]: Nodo principal del archivo, indica que en que consiste la entrada.

Actions: Son cada una de las acciones que vamos a describir. Cada acción nombrada tendrá su propia sección más adelante
Icon: Me temo que aún no sé para que vale. Evidentemente, especifica un icono.
ServiceTypes: Indica sobre que tipo de archivos, especificados mediante MIME-Types, se aplica .

[Desktop Action [nombre acción]: Nodo con la información de las acciones que se han descrito anterioremente.

Exec: Comando a ejecutar cuando se selecciona ésta opción.
Icon: Esta si la sé ;-P. Indica el icono que mostrará en el menú contextual. Sospecho que se indican nombres de iconos de manera que el sistema tendrá una lista y buscara el nobre en dicha lista. No sé muy bien dónde está esa lista, ni como añadir iconos, ni como saber como se llaman.
Name: Texto que se mostrará en el menú contextual para representar ésta acción.
Name[es]: Sospecho que es la versión traducida del campo anterior (es de español). Digo yo que si se tiene seleccionado el lenguaje español se mostrará éste texto, en vez del anterior (que debe ser el genérico).

Respecto a los MIME-Types, he de reconocer que no los manejo muy bien. La lista que he puesto no es en absoluto exhaustiva, y probablemente se pueda especificar mejor. He intenado con audio/all pero no parecía funcionar. Por cierto, notar que se ha añadido el tipo inode/directory para poder realizar las acciones anteriores sobre directorios.

Por último, unos enlaces de dónde ha salido ésta información. Tanto suy como melenas, de KDE-Hispano.org, tienen artículos al respecto:

Añadir comandos al menú contextual de Konqueror (para rotar imagenes desde Konqueror) [suy]
MD5 de forma gráfica con KDE [melenas]
Comprobación de MD5 en botón derecho [melenas]

Acabo de encontrar otro artículo muy interesante, enviado por [agarfu], en el que se explica como añadir al menú contextual la opción de ordenar la vista de archivos por fecha, tamaño, nombre, etc.., usando un archivo .dektop (bueno, y un pequeño script al que llama el archivo .desktop).

Una mejora de usabilidad en konqueror, ordenar por ... [agarfu]

En BlogDRAKE también hablan al respecto, concretamente NeOnsKuLL retoma el artículo de melenas añadiendole funcionalidad:

Comprobación de md5sum en el menú contextual de Konqueror

Por cierto, existe otra especificación para la descripción de los menús: menu-spec.

Y por último, un enlace a la lista de parámetros (en realidad variables) que se pueden usar en la parte de Exec. En mi caso he usado %F, es decir, lista de ficheros seleccionados.

Instalando la Máquina Virtual de Java y los plugins Java para los navegadores

2005-04-27T17:15:00.000+02:00

Hace tiempo instalé el entorno de ejecucion de Java (JRE), tanto para el sistema como para los navegadores que uso. Desafortunadamente, parece ser que había un problema con el plugin Java para Firefox y creo recordar que también afectaba a Konqueror, que hacía que no se iniciasen los navegadores si estaba instalado el plugin de Java. Hablando en plata, que no tengo soporte Java para mis navegadores, lo cuál me incomoda en extremo.

Como no recuerdo como fue todo aquello (ese el motivo principal de ésta bitácora, recordarme como he ido haciendo las cosas), voy a comenzar de nuevo.

Primero, ¿tengo acaso instalado la JRE y es razonablemente actual?

Observando el directorio /opt, veo que tengo instalada la versión 1.4.2_06 del entorno de ejecución.

Mirando un poco los foros, veo como configurar Java en Konqueror. Es tan sencillo como indicarle dónde esta el ejecutable java en el sistema dentro de la pestaña de configuración de Java & JavaScript. Yo tenía como ruta al ejecutable simplemente java, y dado que en la variable $PATH no se halla la ruta al ejecutable java (en mi caso /opt/j2re1.4.2_06/bin), Konqueror no lo encontraba. Indicandole la ruta completa hasta el binario java, tengo los applets Java funcionando en mi Konqueror. Para probarlo, se puede visitar la página de prueba de Sun para Java. Va perfecto.

Encuentro un artículo en Bulma, así como un interesante hilo en las listas de debian.org hablando sobre el tema. Parece ser que hay una versión más actual de Java, la 1.5, que puede corregir estos problemas con los plugins. Además, explican como instalar el plugin.

Consultando en Sun, veo que efectivamente hay una versión de Java 1.5.0_02.

Puede que sea más actual, pero voy a ver por qué cascaba la versión anterior en Mozilla y Firefox.

Para instalar los plugin basta con crear un enlace simbólico desde el directorio plugins de la instalación de Mozilla o Firefox hacia el plugin de la instalación de Java. En mi caso, para Mozilla, la orden sería:

#ln -s /opt/j2re1.4.2_06/plugin/i386/ns610-gcc32/libjavaplugin_oji.so /usr/lib/mozilla/plugins/.

Existen tres plugins en mi instalación de Java: ns4, ns610 y ns610-gcc32. Sospecho que deben ser para Netscape 4.x, Netscape 6.1o y superiores y Netscape 6.10 superiores compilado con extensiones para 32 bits. El último es el que me gusta, lógicamente.

Sorpresa, inicio Mozilla, cargo la página de prueba de Sun y el applet se ejecuta sin problemas. Vaya, ¿que es lo que haría mal anteriormente?

Bueno, probemos con Firefox, que es mi navegador estrella. Basta con un enlace simbólico al mismo plugin que usa Mozilla, es decir:

#ln -s /opt/j2re1.4.2_06/plugin/i386/ns610-gcc32/libjavaplugin_oji.so /usr/lib/mozilla-firefox/plugins/.

Sorpresa de nuevo, al reiniciar Firefox la página de prueba de Sun se ejecuta a la perfección.

¿Por qué no me funcionó anteriormente?

La única diferencia es que he instalado el paquete java-common, ya que he leído por ahí que es conveniente tenerlo, pero leyendo su descripción:

This package must be installed in the system if a Java environment is desired. It covers useful information for Java users in Debian GNU/Linux, including:

The Java policy document which describes the layout of Java support in Debian and how Java packages should behave.

The Debian-Java-FAQ which provides information on the status of Java support in Debian, available compilers, virtual machines, Java programs and libraries as well as on legal issues.

Information on how to create dummy packages to fullfill java2 requirements.

... no parece instalar nada esencial para que se ejcute el plugin, pués sólo parece incluir documentación. Sospecho que probé con alguna distribución anterior, quizá con la Knoppix que tuvé antes.

Nunca hay que pensar en que se ha hecho un esfuerzo inútil. Por el momento me quedo con la 1.4.2_06, más adelante veré si instalo la 1.5.0, en cuyo caso ya tendré las cosas bastante claritas.

Jugando con hdparm: rendimiento de los discos duros

2005-04-26T16:15:00.000+02:00

Sorpresa, tras arrancar con mi flamante nuevo soporte para el chipset VIA 82CXXX y pedir información sobre mis discos duros, me encuentro:

# hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19929/255/63, sectors = 320170943, start = 0

# hdparm -i /dev/hda

/dev/hda:

Model=Maxtor 6Y160L0, FwRev=YAR41BW0, SerialNo=Y46VZA5E
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):

* signifies the current active mode

# hdparm /dev/hdb

/dev/hdb:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 234439535, start = 0

# hdparm -i /dev/hdb

/dev/hdb:

Model=ST3120022A, FwRev=3.06, SerialNo=3JT3PHGK
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234439535
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

* signifies the current active mode

Parece que se activa por defecto el IO_support, es decir, el acceso 32 bits. Creo, de todas maneras, que un valor más alto podría mejorar el rendimiento, luego lo tengo que mirar. Además. también está activado unmaskirq, que permite el enmascaramiento de interrupciones mientras se está accediendo al disco (debido a otra interrupción).

Por último, en ambos discos duros se encuentra activado el DMA y seleccionado el modo más rápido (udma6 en /dev/hda y udma5 en /dev/hdb).

Bien, hagamos unas pruebas de rendimiento:

# hdparm -t -T /dev/hda

/dev/hda:
Timing cached reads: 1248 MB in 2.00 seconds = 622.85 MB/sec
Timing buffered disk reads: 172 MB in 3.03 seconds = 56.83 MB/sec

# hdparm -t -T /dev/hdb

/dev/hdb:
Timing cached reads: 1240 MB in 2.00 seconds = 618.55 MB/sec
Timing buffered disk reads: 158 MB in 3.02 seconds = 52.33 MB/sec

Lástima no tener las pruebas de cuando no tenía mi flamante controlador instalado correctamente. Probemos, de todas maneras, desactivando el DMA:

# hdparm -t -T /dev/hda

/dev/hda:
Timing cached reads: 1248 MB in 2.00 seconds = 623.78 MB/sec
Timing buffered disk reads: 16 MB in 3.09 seconds = 5.18 MB/sec

# hdparm -t -T /dev/hdb

/dev/hdb:
Timing cached reads: 1208 MB in 2.01 seconds = 602.28 MB/sec
Timing buffered disk reads: 16 MB in 3.13 seconds = 5.12 MB/sec

¡Anda, la hostia! Pues si que hay diferencia. Sospecho que anteriormente tenía valores desde luego más altos, pero no tanto como cincuenta y pico megas de transferencia por segundo. En cualquier caso, veremos en los días siguientes si hay diferencia.

Quedan otras opciones que podría tocar. Por un lado el modo IO. Consultando el artículo "Hdparm" de RTFM-Wiki se comenta que los modos son los siguientes:

0 : default 16-bit
1 : 32-bit
2 : 16-bit
3 : 32-bit w/sync

El modo 3 podría ser, por tanto, algo más rápido.

Por otro lado, queda multisect, que indica cuantos sectores son leidos del disco en una sola interrupción. Así, cuanto mayor sea más mejora podría obtenerse.

Sin embargo, activando ambas opciones en ambos discos, obtengo:

# hdparm -t -T /dev/hda

/dev/hda:
Timing cached reads: 1236 MB in 2.00 seconds = 617.79 MB/sec
Timing buffered disk reads: 170 MB in 3.00 seconds = 56.60 MB/sec

# hdparm -t -T /dev/hdb

/dev/hdb:
Timing cached reads: 1248 MB in 2.00 seconds = 622.85 MB/sec
Timing buffered disk reads: 154 MB in 3.03 seconds = 50.77 MB/sec

Curioso, obtengo velocidades más lentas. Quizá por eso el sistema arrancó con esas opciones desactivadas, por que sabía que no eran buenas.

En fin, es bueno saberlo, quizá más adelante descubra por qué no me benefician esas opciones, por el momento se quedan desactivadas.

MiKernel.v4 a MiKernel.v5 (Soporte DMA)

2005-04-26T14:54:00.000+02:00

Vaya vaya, pequeño problema para activar el soporte de DMA para mis discos duros.

Veamos como he llegado hasta aquí.

Primero se usa lspci para comprobar el chipset de sistema IDE.

# lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
0000:00:0c.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

Como puede verse, es un VIA 82CXXX.

Compruebo en el kernel que el soporte para el chipset VIA 82CXXX está marcado como módulo. Mediante lsmod compruebo que está cargado. En principio bastaría para poder activar el soporte DMA.

Para activarlo, se usa la herramienta hdparm:

# hdparm -d1 /dev/hda

/dev/hda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

Ops! No funciona. ¿Operación no permitida? Parece que como si el disco o el controlador no admitiese DMA, pero no es posible, ya que ambos lo deben de soportar.

Tras un rato surfenado por la red, encuentro el siguiente artículo en Gentoo Linux Wiki: "HOWTO Use hdparm to improve IDE device performance", en el que se comenta, en la sección de problemas, lo siguiente:

I get "Operation not permitted" errors on setting DMA (-d1)

Your kernel is not supporting these IDE instructions. After compiling the kernel with all settings right, the same error returns, and this is a bug / sloppy hardware problem (my experience). You might want to try to compile your IDE chipset extension into the kernel, NOT AS A MODULE. That way this code loads before IDE_GENERIC and the problem is gone.

Uhm... así que si compilo el soporte IDE para mi chipset como módulo, al cargar el kernel se carga antes el módulo IDE genérico, que carece de soporte DMA, quedando el módulo específico para mi chipset sin utilidad.

Bien, no me queda más que generar una nueva versión de mi kernel de v4 a v5 compilando para esta nueva versión el soporte para chipset VIA 82CXXcon el núcleo en vez de como módulo aparte.

Lo compilo e instalo sin problemas, y parece que mediante hdaparm puedo activar el soporte para DMA.

Respiro satisfecho admirando de nuevo a la Comunidad. Más adelante echaré un ojo a las opciones de hdparm ahora que tengo el controlador adecuado.

Tamaño de fuente pequeña en GTK

2005-04-25T01:15:00.000+02:00

Tiempo llevaba yo doliéndome por el tamaño tan pequeño que presentaban las aplicaciones de GTK, o al menos algunas de ellas. La estrella era el XMMS, claro, por lo mucho que lo usaba.

Mirando varias veces, se me nombró gtk-theme-switch y gtk-theme-switch2, sin éxtio.

La solución parece ser instalar los paquetes que incluyen fuentes 'transcoded'. Si, no sé a que se refiere. Parece ser que han sido generadas al transcodificar fuentes de del ISO 10646 (¿conjunto de carácteres?). Los paquetes en cuestión son:

xfonts-100dpi
xfonts-100dpi-transcoded
xfonts-75dpi
xfonts-75dpi-transcoded
xfonts-base
xfonts-base-transcoded

Tras instalarlos mediante el pertinente apt-get y reiniciar las X, los programas GTK parecen ir bien. Lo que es un misterio es por que los programas gtk-theme-switch y gtk-theme-switch2 permiten seleccionar fuentes, pero siguen sin afectar al XMMS. Parece que el repodructor usa una especie de fuente por defecto, de tamaño legible eso si, ya que no hallo la manera de cambiar la tipografía.

Bueno, al menos tengo el interfaz gráfico con un tamaño de fuente decente, puedo sobrevivir sin cambiar el tipo de letra.

Notas rápidas sobre PHP

2005-04-19T11:53:00.000+02:00

Hay un básico y sencillo manual de PHP en WebEstilo, que si bien no es en absoluto exhasutivo si tiene las cosas básicas para ir manejandose (variables, instrucciones condicionales, funciones y librerias, cadenas, algo de sesiones, BD, métodos POST y GET, etc).

En caso de error en una llamada a MySQL, se puede ver la causa del error mediante:

echo mysql_errno() . ": " . mysql_error(). "\n";

Como puede verse, el punto (.) sirve para concatenar cadenas.

Conviene organizar las funciones más usadas en un fichero de funciones que pueden ser incluidas al inicio del script php, mediante la instrucción include:

include("funcionesAuxiliares.php");

Para acceder a los valores recibidos mediante GET se usa la varaible especial $_GET[]. Así, si la cadena recibida es:

http://localhost/Prueba/unaPrueba.php?parametroA=valor1¶metroB=valor2

Usaremos para obtener el valor del parámetro A:

$_GET[parametroA]

Y para el parámetro B:

$_GET[parametroB]

Por último, un breve código para realizar una consulta y recorrer los resultados:

$con=mysql_connect();
// $con será la conexión a la BD

mysql_select_db("prueba", $con);
// Se selecciona la base de datos 'prueba'

$consulta = mysql_query("SELECT * FROM tabla1 WHERE campo1 > 1 ORDER BY campo1")
  or die("Se produjo un error ejecutando la consulta"); 
  // Se lanza la consulta, se muestra error si no se pudo ejecutar

if (mysql_num_rows($consulta) == '0') {
   echo("No se hallaron resultados");
} else {
while($fila = mysql_fetch_object($consulta)) {
  echo("Valor campo1: $fila->campo1"); 
  // Se muestra el valor del campo1
}
}

mysql_close($con);                                 
// Cierre de la conexión

Un par de enlaces:

Manual básico de WebEstilo: Muy sencillo pero viene bien para ir enterandose de como va PHP.
Referencia de PHP en castellano: Descripción del lenguaje, seguridad, referencia de funciones, etc.. Herramienta imprescindible una vez se conoce la manera básica de funcionar de lenguaje.

Creando una Web mediante LAMP

2005-04-18T14:03:00.000+02:00

Mi deseo ahora es crear una web mediante LAMP.

Para ello he de instalar Apache, MySQL y PHP. Usaré Apache 1.3.x, PHP 4.3.x y MySQL 4.0.x.

Lamentablemente, no hice seguimiento del proceso de instalación y configuración, por lo que no estoy muy seguro de los pasos que seguí, ni como resolví los problemas que tuve.

Lo primero es instalar Apache, MySQL y PHP4. Para ello uso apt-get, herramienta genial dónde las haya. Se debe seleccionar con cuidado los paquetes a instalar, pues en mi caso no conseguía que Apache procesase las páginas de PHP debido a que me faltaba un paquete (no recuerdo cuál) y después daba error al conectar a MySQL ante la falta de otro paquete, php4-mysql, que permite a PHP conectar con MySQL (sí, éste era de cajón, no estuve nada fino).

La configuración es Apache 1.3.x es sencilla como puede verse en muchas páginas. Basta con añadir al archivo httpd.conf (configuración del servidor Apache) las líneas:

LoadModule php4_module /usr/lib/apache/1.3/libphp4.so
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

La primera activa el módulo de PHP, la segunda y tercera informan a Apache que los archivos php y phps son de tipo aplicacción/php, de manera que antes de servirlas deberá procesarlas mediante el módulo php.

Una vez realizado esto y en ausencia de errores, el sistema está listo para ofrecer páginas dinámicas mediante Apache, PHP y MySQL.

Más adelante iré escribiendo mis pasos con PHP, el cuál conozco apenas un poquito. Como lo uso solamente de vez en cuando, es bueno tener un recordartorio de lo que hago, en vez de tener que ir reaprendiendolo cada vez que lo quiero usar.

Usando los caminos del software libre

2005-04-12T03:33:00.000+02:00

Como me recomendó nx5 en la conversación de IRC respecto a mi cámara BenQ DC 3410, decidí ponerme en contacto con el autor, Michel Xhaard.

El jueves 7 de abril, por anoche, le envíe un correo comentandole lo que me pasaba junto a con mi configuración del equipo. El viernes por la mañana recibía un correo suyo pidendome que usase el módulo con debug=5 y le envíase el cotenido relevante de /var/log/messages referente a la conexión, captura de imágenes y desconexión de la cámara. Menos de 2 horas después de haberselo enviado me remitia un mensaje informando que en principio todo iba bien, pero que por algún motivo su módulo no hallaba el frame inicial dentro de streaming de vídeo que enviaba la cámara. 40 minutos después recibia la siguiente versión de su módulo, diciendome que lo probase. Compilo, instalo el módulo, ejecuto spcaview -f jpg y... la ventana muestra perfectamente lo que la cámara está viendo.

Un par de correos más de agradecimiento y envío del registro de /var/log/messages con el nuevo módulo, y el comentario de que pronto actualizará el módulo indicando el soporte probado con la BenQ DC3410.

Los caminos del software libre son ciertamente interesantes. No creo que hubiese podido recibir mejor servicio de ninguna multinacional por un problema parecido. En menos de 24 horas tenía mi asunto arreglado, y él ajustado su módulo para dar soprte probado a una nueva cámara.

Nuevos tiempos, nuevas posibilidades, nuevos módelos.

Lidiando con mi Benq 3410

2005-04-06T10:21:00.000+02:00

Bueno, he llegado a la página más reciente del proyecto del controlado spca5xx y parece que mi cámara no está completamente soportada :-(

Así que me he armado de valor, y voy a intentar depurar un poco el asunto.

Hablando con el IRC de debian, en el canal spca5xx, he encontrado lo siguiente:

NaSz: hi
NaSz: i got a benq 341phot camera and webcam supported by spca5xx controller
NaSz: i've recompiled my kernel for videodev module, an then compiled and installed spca5xx
NaSz: when i plug mi webcam dmesg shows it, but when i try to see the video stream, program freezes
NaSz: does anybody have a clue?
NaSz: I searched for a spca5xx forum but didn't find it
nx5: what's your camera's usb id?
NaSz: the one that is showed at spca5xx supported webcams page...
NaSz: ai don't remember now.. wait
NaSz: vendor: 0x04a5
NaSz: product: 0x300a
nx5: Benq 22 0x04a5 0x300a DC 3410 spca504b Test Jpeg spca5xx ***
nx5: it says "test" in the list of supported cam :/
NaSz: but at sourceforge webpage of that project it says that camera is fully supported
NaSz: wait
nx5: mxhaard.free.fr
nx5: forget sf
NaSz: ok :(
nx5: try the latest version of the driver
nx5: you get black frames?
nx5: or no frames?
NaSz: program freezes
nx5: try with different option in spcaview
nx5: -f jpg
NaSz: gqcam and gnomemeeting
nx5: -f yuv
nx5: try spcaview with different formats first
nx5: see if one of them works
NaSz: what is spcaview?
nx5: mxhaard.free.fr
nx5: download spcaview
NaSz: it is an external program or tool I suppose?
NaSz: ok
nx5: yep
nx5: another app
NaSz: ok, i got it, thank you very much
nx5: if you still have problems, email michel xhaard
nx5: insert the kernel module with debug=4
nx5: make snoops in windows..
nx5: etc
NaSz: ok, i take those notes
nx5: well, debug=3 or debug=4 won't do anything except output a lot of messages you can read to find out things
NaSz: ok

Es decir, la página oficial es http://mxhaard.free.fr/.

El controlador admite tres modos de transmisión con las cámaras. La mía utiliza el modo jpeg. En principio es bueno ya que se usa una compresión conocida.

Descargo la herramienta spcaview. Para compilarla necesito el paquete sdllib-dev, la cuál exige que instale gcc 2.95 (yo tengo el gcc 3.3). Comentado en el IRC de Debian, me dicen que es normal, no pasa nada, puede incluso que ni siquiera necesite usar la versión 2.95 y que bastaría compilar con la 3.3, pero que hay que dejar hacer a apt.

Compilo y ejecuto. Cuadro negro. El programa no da error, pero no muestra nada.

Instalo el módulo con nivel 5 de depuración (modprobe debug=5>). Obtengo un largo registro, pero no parece haber ningún error claro.

Gnome-meeting tampoco funciona. xawtv tampoco, ni gqcam.

Me he quedado sin salidas.

Por hoy me han ganado la batalla, habŕa que probar otros caminos.

MiKernel.v3 a MiKernel v4 (webcam)

2005-04-05T02:36:00.000+02:00

Bien, necesito instalar mi webcam, para lo cuál toca activar video4linux en el Kernel.

Los archivos de configuración del kernel se encuentran en el directorio /usr/src/linux, ocultos, nombrados como config.vx.[indicación de cambios realizados].

Uso make-kpkg para compilar el kernel y crear los paquetes correspondientes a la imagen del kernel, sus corresponientes fuentes y sus fuentes. Después se instalan la imagen y las cabeceras. En principio las fuentes no hacen falta para nada, pués son iguales sólo que configuradas para otras opciones del kernel. Imagino que esto puede ser útil cuando se parchea el núcleo, puesto que éstos si que modifican las fuentes (si no me equivoco).

Hay que recordar que hay que hacer make-kpkg clean antes de crear los paquetes o se puede obtener el error por las versiones ('...I'm confused about this discrepancy, and I'm halting', me encanta la manera de decir que hay error).

Para crear los paquetes se usa:

make-kpkg --revision=[nombreRevisión] kernel_image kernel_headers kernel_source

Los diferentes make_xxx corresponden a los diferentes objetivos al comando make-kpkg (imagén del kernel, cabeceras y fuentes).

Al intentar instalar el paquete imagen, dará un error (me ha pasado anteriormente), debido a que existe el directorio /lib/modules/2.6.8, dónde se hallan las depencias del kernel actual. Dado que se va a instalar otro kernel, se deben quitar de ahí. Lo suyo es renombrar el directorio por si acaso falla el nuevo kernel y queremos poner el antiguo (es decir, des-renombramos y arrancamos con el kernel antiguo)

Al instalar el kernel, y habiendo eliminado dicho directorio, se muestra un mensaje que explica esto:

You are attempting to install a kernel version that is the same as
the version you are currently running (version 2.6.8). The modules
list is quite likely to have been changed, and the modules dependency
file /lib/modules/2.6.8/modules.dep needs to be re-built. It can
not be built correctly right now, since the module list for the
running kernel are likely to be different from the kernel installed.
I am creating a new modules.dep file, but that may not be
correct. It shall be regenerated correctly at next reboot.

I repeat: you have to reboot in order for the modules file to be
created correctly. Until you reboot, it may be impossible to load
some modules. Reboot as soon as this install is finished (Do not
reboot right now, since you may not be able to boot back up until
installation is over, but boot immediately after). I can not stress
that too much. You need to reboot soon.

Tras instalar el paquete kernel_image, se reinicia. Efectivamente las X dejan de funcionar, por lo que se debe reinstalar el controlador de nVidia. Fácil, basta con ejectuar el script de instalación. Al tener un kernel propio, se compila un interfaz con el kernel específico, ya que los precompilados no tienen por que ajustarse a mi kernel, lógicamente.

Para hacer funcionar la webcam se necesitan los módulos videodev y spca5xx cargados en memoria. Si no lo están se cargan con modprobe .

Desgraciadamente mi webcam no rula. El kernel parece reconecerla a tenor de lo que dice dmesg:

usb 4-2: USB disconnect, address 2
/usr/src/modules/spca5xx-20050328/drivers/usb/spca5xx.c: usb_submit_urb() ret -19
/usr/src/modules/spca5xx-20050328/drivers/usb/spca5xx.c: usb_submit_urb() ret -19
usb 4-2: new full speed USB device using address 3
/usr/src/modules/spca5xx-20050328/drivers/usb/spca5xx.c: USB SPCA5XX camera found. Benq DC 3410 Spca504b
/usr/src/modules/spca5xx-20050328/drivers/usb/spca5xx.c: [spca5xx_probe:7806] Camera type JPEG

Sin embargo tanto gqcam, xawtv como gnomemeeting se cuelgan al intentar visualziar lo que la cámara ve. He intentado probar con el kernel precompilado no consigo cargar el módulo spca5xx.o, asi que el sistema ni siquiera detecta la cámara.

No tengo pistas de por dónde seguir, tendré que buscar ayuda. :-(

Punto de partida

2005-04-05T02:17:00.000+02:00

Comenzamos, tras muchas otras instalaciones (he tenido una Caldera, una Suse, jugué con una Red Hat en Telefónica Rios Rosas, Knoppix) ahora dispongo de una bonita Debían, principalmente Sarge (testing) con algunos en Sid (unstable), con kernel 2.6.8.

El kernel lo he compilado yo, he ido añadiendo cosas según las necesitaba. Hoy tocaba añadir soporte para la webcam, asi que he tenido que activar la opción de Video4Linux del Kernel. Antes tocó añadir soporte para USB y alguna cosilla que ahora no recuerdo.

Tengo instalado el módulo de nVida, descargado de la web oficial de nVidia. No dió ningún problema, simplemente ejecutar el script de instalación. Me temo, eso si, que deb ser instalado con cada versión del kernel que se instale, así que sospecho que hoy me tocará hacerlo.

Instalé hace poco el Quake III Arena e iba como la seda, bien que lo demostré en la fiesta en red en el palacio de los marqueses.

Por cierto, esta bitácora no está para nada pensada para el público en general, es más un recordatorio para mi mismo.