Se me ocurrió montar una VPN IPSec/L2TP usando openswan + xl2tpd + pppd para poder acceder a la red de casa de forma segura. Cuando la tengo funcionando me doy cuenta de que tengo abierto el puerto 1701 (l2tp) para cualquier cosa que venga desde el dispositivo de internet, y como estoy usando netkey no tengo dispositivos ipsecX que me permitan diferenciar de forma trivial el tráfico que viene en tuneles IPSec del resto del tráfico entrante desde internet. Buscando por ahi y después de diversas pruebas encontré mi solución en el módulo policy de netfilter:

iptables -A INPUT -m policy --pol ipsec --dir in -p tcp --dport 1701 -j ACCEPT

iptables -A INPUT -m policy --pol ipsec --dir in -p udp --dport 1701 -j ACCEPT

Especificamos que aceptamos el tráfico TCP/UDP entrante en el puerto 1701 para tráfico IPSec entrante, evitando así el aceptar paquetes con destino al l2tpd desde orígenes dudosos.

VMware y el kernel 2.6.21 se llevan mal, muy mal. Casi todo el día perdido con cuelgues intentando montar unas 2003, que si comprobando que tuviese bien el disco duro, la RAM…

Para acabar descubriendo que hay algún tipo de problema entre VMware & 2.6.21, ha sido bajar la versión del kernel a 2.6.20 y dejar de tener problemas.

Actualmente en el despacho tenemos 2 equipos en los que interesa reproducir audio y sólo 1 par de altavoces conectados a un equipo. Había 2 opciones o bien comprar un selector de señales de audio y conmutar entre un equipo y el otro o bien compartir los altavoces/tarjeta de sonido.

Como en tiempos había conseguido hacer que un xmms mandase la salida de audio a un esound remoto decidí probar por el camino de compartir altavoces.

Resulta que esound actualmente está viejo/desfasado/deprecated/oxidado, buscando un poco encontré en Pulseaudio la solución perfecta. Pulseaudio es un servidor de audio con soporte de red, con la ventaja de estar soportado por el propio ALSA, con lo cual no sólo ciertas aplicaciones se escucharán en los altavoces remotos, si no que todo lo que soporte ALSA ó OSS (ALSA nos ayuda a emular OSS) podrá ser escuchado en nuestros altavoces compartidos.

Manos a la obra, en el equipo que posee los altavoces y tarjeta de sonido deberemos de tener el demonio de Pulseaudio funcionando y admitiendo conexiones via TCP/IP. En mis gentoo es algo así:

1. emerge pulseaudio (con USE=”alsa” como mínimo para que pueda mandar el audio a la tarjetea de sonido, que en mi caso lo tengo definido en /etc/make.conf)
2. editamos /etc/pulse/default.pa y descomentamos la siguiente línea para que la salida de Pulseaudio sea el ALSA del equipo que tiene la tarjeta de sonido funcionando:
   • load-module module-alsa-sink
3. en el mismo /etc/pulse/default.pa añadimos las siguientes líneas para admitir conexiones entrantes desde localhost y la red local (192.168.0.0/24 en mi caso):
   • load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24
   • load-module module-esound-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24
4. Arrancamos pulseaudio: /etc/init.d/pulseaudio start

En los equipos cliente deberemos de hacer lo siguiente:

1. Añadimos pulseaudio al USE del /etc/make.conf e instalamos pulseaudio, xine-lib (si ya está instalado la reinstalamos para que vaya con soporte de pulseaudio) y alsa-plugins: emerge pulseaudio xine-lib
2. Editamos /etc/pulse/client.conf y añadimos la siguiente línea para que el pulseaudio de los clientes mande el audio al pulseaudio que si tiene tarjeta de sonido como salida (multivac en mi caso):
   • default-server = multivac
3. Configuramos ALSA para que utilice pulseaudio por defecto añadiendo las siguientes líneas a /etc/asound.conf:
   • pcm.pulse { type pulse }
   • ctl.pulse { type pulse }
   • pcm.!default { type pulse }
   • ctl.!default { type pulse }

Una vez hecho esto he comprobado que el amarok ejecutado en los clientes, que usa xine-lib, usa pulseaudio tanto si elegimos como salida ALSA o Pulseaudio, así que teoricamente cualquier cosa que sea capaz de usar ALSA la escucharemos en el equipo con salida de altavoces

Al migrar mis sistemas a UTF-8 me encontré con un grave problema en el bitlbee.. todos los acentos que usaba los veían mal en el cliente de Microsoft, pues bien, he aquí la solución:

set charset utf-8

Lo sé… resulta evidente, pero en parte por pereza ni siquiera lo había mirado, y fue Sevein quien me dio la solución, thx.

Este sábado entre otras cosas, tocó migrar los equipos de ISO-8859-15 a UTF-8, nada del otro jueves, pero que puede dar algún que otro quebradero de cabeza. Aquí teneis una pequeña guía describiendo el proceso.

Aunque aparentemente Bitlbee no soporta el servicio de mensajería instantanea de Google, podemos usarlo sin mayor problema, para ello tenemos que compilar bitlbee con soporte Jabber y añadir la cuenta de la siguiente forma:

account add jabber cuenta@gmail.com contraseña talk.google.com:5223:ssl

Esto funciona tanto con las cuentas gmail.com como con el servicio que ofrece google de dar correo, chat a tu propio dominio, yo lo tengo funcionando para mi cuenta @mundodisco.net sin problemas.

Le ha tocado el turno de jubilación a mi Logitech MX 1000, tenía la batería hecha polvo después de 2 años, se agotaba enseguida.. una lástima porque la verdad es que iba de vicio. El sustituto es un Microsoft IntelliMouse Explorer 3.0, 5 botones, óptico y con muy buena fama.

La configuración de este ratón en linux ha sido de lo más sencilla, basta con modificar en el /etc/X11/xorg.conf la sección del ratón y dejarla como sigue:

Section “InputDevice”

Identifier “Microsoft Intellimouse Explorer 3.0″

Driver “evdev”

Option “Device” “/dev/input/event1″

EndSection

Hay que tener en cuenta que para poder usar evdev, tenemos que tener activada la siguiente opción en el kernel CONFIG_INPUT_EVDEV=y. Y para saber que Device nos corresponde basta con mirarlo en /proc/bus/input/devices

Sincronizar con rsync un directorio que este bajo un sistema de ficheros vfat puede llegar a ser un problema, bien porque a veces con vfat cambia mayusculas y minusculas de los nombre de ficheros/directorios; o bien porque windows no es preciso en exceso a la hora de fijar las fechas de modificación. Para hacer mas sencilla la sincronización deberemos recurrir a estos 2 comandos:

• mount -t vfat -o shortname=mixed,iocharset=utf8 /dispositivo /punto_de_montaje
• rsync –modify-window=1 -rtv –delete /origen /destino

La opción shortname=mixed evita mezclas entre mayúsculas/minusculas de forma incorrecta, cosa que es muy molesta a la hora de usar rsync, porque nos llega a duplicar directorios enteros y es incapaz de sincronizar correctamente. El –modify-window=1 de rsync hace que compare los tiempos de modificación con menos exactitud de la normal (compare mod-times with reduced accuracy, dice la man page del comando). Esto elimina algunos problemas a la hora de hacer la sincronización de ficheros modificados recientemente.

Navegando por ahi el otro día llegue a la página de Picotux. Picotux presume de ser el ordenador con linux más pequeño del mundo. Lleva un procesador ARM 7 a 55Mhz y 8MB de SDRAM. Como almacenamiento tiene una flash de 2 ó 4Mb. Tiene conexión de red a 100Mbits, y acceso por cable modem-nulo a través de puerto serie. Por si solo este juguete no puede hacer mucho.. pero a través de su conexión a red y su soporte de NFS las posibilidades se multiplican. A ver si alguien me regala uno

Ayer migré a mis cuñados (espejo.ordenycaos.org && minina.ordenycaos.org) de una OpenSuSE 10 AMD64 a una Kubuntu 6.10 edgy AMD64. El motivo principal de la migración fue que su OpenSuSE fallaba como una escopeta de feria a la hora de reproducir música y/o video. El amarok ni se iniciaba, los diversos reproductores de video no abrían ni un mísero divx. Así que hartos de todo esto me pidieron que me deshiciese de la OpenSuSE por algo que en AMD64 funcionase bastante mejor y diese menos problemas.

Personalmente habría montado gentoo, pero no estaba dispuesto a echarme allí dia y medio viendo compilar cosas.. y para usar un repositorio binario mejor me monto unas Kubuntu y listo .

Así con todo listo, y habiéndome asegurado de que la partición /home y el disco duro de datos estaban a buen recaudo empecé con la instalación. Fue bastante rápida, no dió un solo problema, sus KDE funcionando, su openoffice en castellano, y todo el hardware a la primera.

Ahora empezamos con las pegas, nada de win32codecs ni soporte de flash en condiciones, cosa bastante normal en una distribución 64 bits. Pero no hay problema, aquí entra en juego Automatix. Automatix es un front-end para apt-get que se encarga de instalar/desinstalar ciertas aplicaciones conflictivas y muy solicitadas.

Instalar automatix fue así de sencillo:

1. echo “deb http://www.getautomatix.com/apt edgy main” | sudo tee -a /etc/apt/sources.list
2. wget http://www.getautomatix.com/apt/key.gpg.asc
3. gpg –import key.gpg.asc gpg –export –armor 521A9C7C | sudo apt-key add -
4. sudo apt-get update
5. sudo apt-get install automatix2

Gracias a automatix pude instalar VLC, win32codecs, swiftfox (firefox optimizado para una arquitectura en concreto, en este caso AMD64) con sus plugins (flash, java) en un par de clicks (y lo mejor de todo es que funcionó a la primera).

Nunca había probado unas ubuntu en un entorno de escritorio (Ubuntu Server funciona muy bien). Y la verdad es que quedé muy contento, rápido de instalar, ningún problema con los típicos incovenientes de montar en 64 bits y tiene apt-get de serie

Actualización: otra cosa que había dado guerra en OpenSuSE fue la impresora, una HP LaserJet 1010, en kubuntu fue tan sencillo como instalar foomatic y utilizar el driver que me sugería CUPS a la hora de agregar la impresora