Java, Linux y IPv4 vs IPv6

Hoy he tenido una ración de problema extraño en un servidor. Por suerte no era un servidor de producción sino que era un servidor de red que tenia un servicio Tomcat secundario y casi de pruebas. El tema ha empezado al instalar una tercera tarjeta de red para gestionar una nueva conexión (a guifi.net aunque eso no es relevante). Al rato me doy cuenta que el servicio Tomcat no funciona. Reviso los logs y tras mucho pelearme veo esto:

Jan 3, 2010 7:57:55 PM org.apache.catalina.core.StandardServer await
SEVERE: StandardServer.await: create[8005]:
java.net.SocketException: Invalid argument
        at java.net.PlainSocketImpl.socketBind(Native Method)
        at java.net.PlainSocketImpl.bind(Unknown Source)
        at java.net.ServerSocket.bind(Unknown Source)
        at java.net.ServerSocket.(Unknown Source)
        at org.apache.catalina.core.StandardServer.await(StandardServer.java:363)
        at org.apache.catalina.startup.Catalina.await(Catalina.java:616)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:576)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)

Tras mucha pelea, aumentar el verbose del servidor, busquedas por la red... nada. Al final me creo una pequeña aplicación Java para intentar encontrar el error...

import java.net.*;

public class Test {
  public static void main (String[] args) throws Exception {
    InetAddress ip = InetAddress.getByName("127.0.0.1");
    System.out.println(ip);
    ServerSocket ss = new ServerSocket(2033, 1, ip);
    System.in.read();
  }
}

La sorpresa es que... falla!

sargue@bsg:~$ java Test
/127.0.0.1
Exception in thread "main" java.net.SocketException: Invalid argument
        at java.net.PlainSocketImpl.socketBind(Native Method)
        at java.net.PlainSocketImpl.bind(Unknown Source)
        at java.net.ServerSocket.bind(Unknown Source)
        at java.net.ServerSocket.(Unknown Source)
        at Test.main(Test.java:7)

Muy, muy extraño. Si en el código elimino la parte de la IP entonces sí funciona. Así que el problema debe estar en la IP. Cuando elimino la IP se me ocurre mirar donde la asigna y lo hace a una IPv6.

tcp6       0      0 :::2033                 :::*                    LISTEN      27945/java

Así que eso me da la pista definitiva. Buscando más encuentro este post donde me entero de la opción de Java para forzar IPv4 lo cual resuelve la cuestión:

sargue@bsg:~$ java -Djava.net.preferIPv4Stack=true Test
/127.0.0.1

Próximamente: ¿overclock cerebral?

Impresionante: http://librodenotas.com/guiaparaperplejos/17412/apuntes-sobre-la-velocidad-del-pensamiento

Un experimento similar permitió recientemente a investigadores del MIT hacer lo contrario, pero esta vez con monos: aceleraron la velocidad de percepción de los simios a través de la manipulación de sus ondas cerebrales.

Así que en breve podremos aplicar un overclock a nuestro cerebro. Si hacemos un 2x quizás con trabajar 4 horas nos paguen 8. ¿Resolveremos lo mismo más rápido? ¿Consumirá el cerebro más electricidad? ¿Habrá que subir el voltaje? ¿Iremos con un casco de aluminio en plan disipador?

Ojo que el caso contrario también es de lo más interesante. Imagina que tienes que esperar cualquier cosa y no tienes nada que hacer mientras: ralentizas y para ti habrán pasado 5 minutos y en el MundoReal 2 o 3 horas. Los viajes largos ya no seran lo que son. El nuevo viaje low cost será un barco lleno de zombies a cámara lenta.

Copia de seguridad de Gmail

Una idea me ronda la cabeza hace tiempo. Pero hasta ahora no habia decidido tomar medidas. Así que llegó la hora de hacer una copia de seguridad de todo mi correo en Gmail.

Buscando por google salen muchísimas opciones, incluyendo varias aplicaciones (tanto de pago como gratuitas). Incluso alguna FOSS. Realmente creo que las posibilidades de que me desaparezca todo o parte del correo de mi cuenta de Gmail son bastante remotas así que me conformo con un backup cutre pero que sea simple de realizar.

Al final tras ver algunos artículos me he decidido a utilizar getmail. En su versión para Debian claro. De esa manera puedo ejecutarlo en uno de los servidores dedicados que tengo de la empresa para con mucho ancho de banda para luego comprimir el resultado y guardarlo.

Para los interesados por los artículos referenciados y buscando algo más hay soluciones mucho más elaboradas pero mi objetivo es simplemente sacar todo el correo y guardarlo en disco. La estructura, etiquetas y demás es secundario porque como he dicho dudo que pierda los datos de la cuenta. Si pasara quiero al menos tener los correos. Luego estoy seguro que seria bastante tedioso volver a montarlo, pero al menos allí estarian.

De manera que simplemente he creado un directorio gmail-backup y un fichero de configuración getmail.rc con el siguiente contenido:

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = xxxxx@gmail.com
mailboxes = ("[Gmail]/All Mail",)

[destination]
type = Mboxrd
path = gmail-backup

Como veis lo que hago es coger todo el correo y meterlo en un único fichero. Podria usar el Maildir pero seria más lento y dados mis objetivos el formato mailbox me va mejor. Luego cojo el fichero generado, lo comprimo con 7z y lo archivo. Repitiendo de vez en cuando se tiene una copia de seguridad decente.

Por si alguien echa en falta el password en el fichero de configuración no lo he puesto porque no me fio que esté en texto abierto incluso en un servidor que controlo yo. Llamadme paranoico.

Sincronizando la Palm con mi entorno KDE (II)

Finalmente no he podido hacer funcionar el kpilot para poder sincronizar mi Palm. Funciona parcialmente pero al intentar configurar conductos útiles como el calendario, los contactos o la lista de tareas simplemente se cuelga. Así tal cual.

Alternativa? El jPilot, una aplicación Java que en este casi sí me funciona. Sin embargo no es tan cómoda como el Palm Desktop de Windows o el KPilot. Para hacer la sincronización tienes que pulsar en la interficie un botón y luego ir a la Palm y pulsar otro. Un poco raro. Además la interficie es bastante pésima. No del todo mala pero necesita una reescritura bajo estandares de usabilidad.

Otro punto menos. Esto va pintando mal, pensaba que estaba en un estado mucho más maduro el Linux Desktop pero veo que está más o menos como estaba hace unos años. Ha avanzado, pero no al ritmo suficiente a como han avanzado el resto de partes.

Veremos...

Sin salida SPDIF de sonido

Otro tanto negativo para el Linux Desktop. La placa que equipa el sistema lleva el chipset VIA vt1828s para salida de sonido. El subsistema ALSA lo detecta pero apenas manteniendo un nivel mínimo de compatibilidad que no incluye el soporte de salida digital.

Una búsqueda por google de ese chipset sobre linux arroja CERO resultados relevantes. Al parecer no me está detectando exactamente mi dispositivo sino a través de uno genérico que sólo me ofrece salida PCM básica (es lo que muestra el KMix).

Esta es la salida de aplay -l:

sargue@sileo:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: HDA Generic [HDA Generic]
Subdevices: 1/1
Subdevice #0: subdevice #0