Linux

Aún falta un poco hasta que los proveedores de acceso a Internet nos asignen un rango IPv6 en cada router, sobre todo en España, donde nos venden a precio de oro una conexión del siglo pasado.

Estos últimos días he estado configurándome un túnel IPv6-en-IPv4 de Hurricane Electrics, y la verdad es que funciona muy bien. Os cuento como he hecho la configuración en Fedora 16:

Lo primero de todo es darse de alta y solicitar un túnel, se nos asignará un IP y un rango /64 para nuestra red local. En la página de información detallada de nuestro túnel vienen todos los datos que vamos a necesitar.

Para evitar pérdidas de datos si falla algún disco duro, tengo la partición /home montada sobre un RAID por software. Voy a explicar cómo activar el servicio de monitorización en Fedora 16 para que nos mande un correo en caso de que haya algún problema con nuestro array.

Existe un servicio llamado mdmonitor.service que se encarga de monitorizar el estado de los arrays, pero no arranca si no existe el fichero /etc/mdadm.conf. Por lo tanto, lo primero es crear el fichero y añadir nuestro array:

Un pequeño truco para que no nos falle el uso de find y xargs cuando tratamos con nombres de archivos que contienen espacios, es usarlos con estas opciones:

find /dir -print0 | xargs -0 _<comando>_

De esta forma los comandos separan los nombres de archivos con el caracter NUL en vez del espacio.

Visto en: https://notfaq.wordpress.com/2006/07/30/unix-filenames-with-spaces-in-find-xargs/

Después de leer las últimas noticias sobre CarrierIQ me he decidido a rootear mi teléfono Android e instalar CyanogenMod 7.1 para quitarme la ROM del operador y poder tunelizar las conexiones por VPN. No me voy a explayar en el proceso de rooteado del teléfono (un HTC Desire) ya que hay muchas guías que lo explican y con unrevoked es muy sencillo.

Voy a explicar cómo configurar un servidor VPN para poder usarlo desde el teléfono.

En casa tengo la típica línea ADSL, y ya llevaba tiempo dándole vueltas a varios problemas de latencia y velocidad que estaba sufriendo cuando conectaba aMule, Transmission o similares. Cuando estaba usando estos programas P2P, la navegación se ralentizaba hasta extremos desesperantes, muchas veces lo que más le costaba era la resolución DNS de las páginas, algo que tendría que ser lo más rápido posible.

Para mejorar la situación he creado un script basándome en el fantástico Wonder Shaper, un script que usa el algoritmo HTB para asegurar un ancho de banda a las clases que definamos. La principal diferencia es que wonder shaper está pensando para un equipo que tenga conexión directa a Internet con una IP pública asignada, y mi script está diseñado para un equipo con una IP privada dentro de la LAN, que es la configuración habitual de los routers ADSL. Por supuesto, esta aproximación solo funciona bien si nuestro equipo es el único en la red local, ya que si otros hosts están generando tráfico, llenaremos el buffer del router y no conseguiremos nada.

Acabo de adquirir un disco SSD para usar como disco principal del sistema, concretamente el modelo OCZ Vertex 3, y os puedo asegurar que da al sistema una fluidez impresionante.

Con unos pequeños ajustes se puede optimizar al máximo el rendimiento. Os cuento cómo lo he hecho yo.

Lo primero que he hecho ha sido actualizar el firmware a la última versión, ya que añadían mejoras importantes de estabilidad y de soporte de TRIM.

Voy a montar un entorno de pruebas en una sola máquina con un cluster de Liferay + un cluster de Terracotta con Web sessions. He usado CentOS 6 x86_64 y las versiones open source de estos dos productos.

Recientemente ha aparecido el proyecto OpenDNIe para poder usar el DNI electrónico con herramientas libres y mejorar la lamentable situación de los drivers oficiales. Yo he usado esta versión para varios trámites y no he tenido ningún problema, os cuento como instalarlo en Fedora 15 x86_64:

Descargo los paquetes fuente para RedHat en la página de descarga y compruebo la suma md5.

$ md5sum -c opensc-opendnie-0.12.2-1.fc14.src.rpm.md5 < opensc-opendnie-0.12.2-1.fc14.src.rpm -: La suma coincide

El agente de GPG es una herramienta muy útil para evitar estar metiendo continuamente las contraseñas para desbloquear las claves GPG o en las conexiones SSH. Por desgracia no suele estar habilitado por defecto en la consola, pero vamos a ver como solucionarlo. Esta solución está basada en este comentario.

El kit de la cuestión es que solo puede haber una instancia de gpg-agent por usuario y en cada sesión se tienen que configurar las variables de entorno necesarias. Estas variables las vamos a guardar en el archivo ~/.gpg-agent-info

Todo un clásico, pero extremadamente útil cuando tienes varias máquinas para administrar.

$ ssh-keygen -t rsa -b 4096 -C "_your_email@youremail.com_" #Genera la clave $ ssh-copy-id _username_@_remote-host_ #Copia la clave al servidor remoto

Para los paranoicos es una buena idea tener anotados de antemano los fingerprints de los servidores. De esta forma si intentamos conectar alguna vez desde algún entorno no seguro donde no tengamos cacheada la clave en ~/.ssh/known_hosts podremos estar seguros de que no nos están haciendo un man in the middle.