La correspondencia evoluciona.

Buena vida a todos. Este es un post tal vez triste, tal vez combativo, pero definitivamente es una catarsis de la decepción que estoy pasando.

Hace 4 años que soy (feliz) usuario de Linux. Depende la óptica desde donde se lo mire, puede ser mucho o poco. Considero que es bastante, dado el desarrollo que tiene linux con el correr del tiempo. Sin embargo, hay algunas veces que me decepciona, al no haber soluciones a problemas comunes de todos los días. Entiendo porqué pasa esto, lo se; se cómo funciona la creación de software libre por adentro. Pero en lugar de seguir sacando características nuevas a programas viejos, ¿porqué no arreglar las fallas comunes que más nos molestan?

Nunca soporté demasiado Outlook Express. De hecho, en mis tiempos de usuario de Windows, cuando apenas conocía las aplicaciones que me brindaba Micro$oft vivía rotando entre Outlook Express y Microsoft Outlook. Cada nueva versión probaba la aplicación, a ver si esta vez no me decepcionaba. El patrón era sencillo y lineal: MSO era una tortuga, y OE se colgaba a cada rato.
Ahí conocí TheBat!. Era tan ortodoxo y sencillo de usar como un auto con las ruedas para arriba. Entonces un amigo me habló de Mozilla Thunderbird. Me enamoré. Rápido, liviano, potente, versátil, y prometedor, con la ENORME cantidad de extensiones que prometían llegar. Todo iba sobre aceite, hasta que... a Mozilla Foundation se le piantó la tortuga.

Thunderbird tiene una falla común, en cualquiera de sus versiones: Cuando se usan más de una cuenta de correo pop, cruza los remitentes. Esto es: si yo tengo mi cuenta asuenos @gmail.com y atrapas @gmail.com, y quiero mandar un mail desde asuenos@gmail.com, a mi me muestra, me dice y me convence que lo hizo desde asuenos@gmail.com, pero en la realidad, el mail llega desde atrapas@gmail.com. Imagínense las molestias que pueden causar cuando alguien tiene una cuenta de uso corporativo junto con su cuenta de correo de todos los días!

Este tipo de molestias no son una falla común, pero desgraciadamente ocurren. Cuando el programa tiene algunos largos meses de estar instalado, y en ese período sufrió uso intensivo, se rompe.

Cansado de darle oportunidades (vaya si le habré dado) a Mozilla, decidí optar por la estandarización. Así fue como me animé a evolucionar.

Evolution parece ser la respuesta de la gente de Ximian a aquellas personas que requieren funcionalidad símil MSO. De hecho, yo diría que es el nene malcriado de Gnome, porque si bien parece ser bastante más robusto (y veloz) que Mozilla Thunderbird, a veces es un poco rebelde y no hace lo que uno quiere. Pero así estaba bien, todo funcionaba.

Hasta que empecé a configurar los filtros de correo.

Evolution tiene la maldita costumbre de utilizar la Trash a modo de swap para mover los mails de una carpeta de correo a otra. Eso ya es un trastorno cuando uno quiere acomodar mails masivamente, digamos, unos 2000. Fuera de esto, cuando se aplican filtros de correo electrónico, ocurre lo siguiente:

1. Elabora una lista con el mail a filtrar (en la statusbar aparece el mensaje "Filtering Selected Messages (...)", lo que tarda una ETERNIDAD
   
2. Mueve los mensajes a la trash ("Moving Messages xx% complete"), lo que tarda... otra eternidad :P
3. Guarda la carpeta?!!??! (Storing Folder...)

Todo esto, claro, con un pequeño agravante: SI NO SE SELECCIONAN TODOS LOS MAILS DE UNA CARPETA NO FILTRA NI EL AIRE!

Los filtros de correo saliente, o bien no funcionan, o bien, no los se usar. Me inclino por la primera alternativa, dado que están bien configurados. Pero Evolution sencillamente los ignora. ¿Porqué quiero filtros de correo saliente? Me olvidaba de la peor parte. Contradiciendo el modelo "estándar" de MUI que utilizan felizmente tanto Thunderbird como Microsoft Outlook, en el que el mail se separa  de fábrica por cuenta, Evolution utiliza el mismo modelo de OE, en el que el mail llega todo junto al mismo Inbox.

Siglo XXI señores, esto es una vergüenza. Y lo peor es que este es el programa estándar de mi querido Gnome.
Voy a seguir filtrando correo. Hasta el mes que viene.


:(

VMWare - Reconfigurar networking/bridge

VMWare es una de las varias tecnologías de virtualización que utilizo ademas de Xen y OpenVZ (tengo bastante abandonada esta última).
Unos de los inconvenientes que tuve hoy fue reconfigurar el bridge de un VMWare Server en un cliente, hubo un cambio de servidor (físico) y como se utilizan 2 subredes distintas ademas de la red Wan, pues no tuve mas remedio que toquetear y reconfigurar todo nuevamente, previa migración de las VM's.
Por suerte, vmware provee de todo un arsenal de herramientas para ser utilizadas desde linea de comandos y una de ellas (despues de buscar en google) me permitió modificar la asociación de determinada vmnetX (subred interna de vmware) a la interface física que yo desee.

La herramienta es la siguiente:

# vmnet-bridge
Usage: vmnet-bridge [-dDP] /dev/vmnet? interface
-d : daemon mode
-P : PVN mode
-D: debug mode

Y el ejemplo de cómo lo utilizé

# vmnet-bridge -d /var/run/vmnet-bridge-0.pid /dev/vmnet0 eth0

Con eso solucionado ya pude continuar trabajando, lo bueno de todo esto es que ni siquiera me tuve que acercarme ya que tanto la instalación del nuevo server como su reconfiguración lo hice de forma remota :)

UDEV: Cambiar nombre a las interfaces

Para los casos en que se disponga de varias interfaces de red, muchos notarán que el instalador de Debian no las nombra (eth0,eth1, etc) de la forma más lógica según nos parece.

Como ejemplo puedo decir que las motherboards modernas traen ya 2 interfaces onboard, son lo suficiente para el común de los usuarios, como administrador de red y al tener varios equipos disponibles a veces necesitamos mas de 1 interface, mi caso particular es que tengo un server Debian con salida mediante 2 ISP (en un cliente), para lo cual claramente necesito tener 3 interfaces como mínimo y poder dar acceso a la red local hacia internet.


Como asiduo usuario y consumidor de otros blogs me encontré estos dias con un método, pero considero que no es necesario.
Ya que si revisan bien el directorio /etc/udev/rules.d se encontrarán con el archivo /etc/udev/rules.d/z25_persistent-net.rules el cual hay que editar y con solamente modificar el nombre (en negrita) de las interfaces es suficiente

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:18:f3:3e:02:c2", NAME="eth0"

# PCI device 0x10de:0x0373 (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:18:f3:3e:05:f3", NAME="eth1"

# USB device 0bda:8187 (rtl8187)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:15:af:05:d3:4f", ATTR{type}=="1", NAME="wlan0"

El orden no afecta el comportamiento de UDEV por lo cual es extremadamente simple controlar la nomenclatura de las interfaces, pero les advierto que por alguna extraña razón no funciona en Ubuntu 7.10 Server, hace unos meses me encontré conque debia instalar un nuevo server con hardware que el instalador de Etch no reconocía (la controladora Sata) asi que bueno, contrario a mi predilección instalé Ubuntu Server 7.10 (a la semana de haber sido lanzado) y me encontré justamente con un orden de las interfaces que no queria, modifiqué el/etc/udev/rules.d/z25_persistent-net.rules pero al reiniciar laPC me encontré conque me faltaban 2 de las interfaces, el tiempo que perdí hasta que revisé nuevamente el archivo me mostró que la versión de UDEV que viene en Ubuntu me lo habia modificado, y manteniendo la modificación que yo hice agregó la que Ubuntu queria, entonces tenia 2 interfaces distintas con las misma MAC, eso explica el porqué me desaparecieron ambas.
Al final como solamente cumple funciones de ruteo y firewall (no proxy, no dansguardian) le puse un Lenny y se acabaron los problemas :)

ACTUALIZACION: Tengo una PC con varias placas en calidad de prestamo asi que hice una instalacion de prueba con Ubuntu server y aqui no me ha dado problemas.

Conky en Debian Lenny

http://conky.sourceforge.net/ es un monitor para nuestros sistemas Linux, según dice el sitio oficial es un fork de torsmo otro similar pero con menos funcionalidades que ahora esta discontinuado, recuerdo que en su momento lo probé (a torsmo) y estaba muy bueno.

Conky es la evolución de ese mismo software con mayores funcionalidades y estética mejorada. Este post es para dar a conocer cómo lo hice andar en Debian Lenny (a la fecha del post).

Por mas que la documentación aclare los pasos, el "know how" para implementarlo a veces no se cumple al pie de la letra en cada distro. Lo primero por supuesto es hacer un:

# aptitude install conky

Una vez instalado y siguiendo las instrucciones del propio sitio, nos hacemos con una copia del .conkyrc desde el archivo ejemplo que esta en la siguiente ruta.

$ zcat /usr/share/doc/conky/examples/conkyrc.sample.gz > ~/.conkyrc

Este archivo aunque bastante amplio casi con seguridad hay que editarlo para su adecuada aplicación a nuestro sistema.

Pero los detalles por los cuales esta este post es que la instalación y personalización de conky en Debian Lenny queda a medias y no es del todo funcional.
Para empezar si modificamos correctamente el .conkyrc que esta en nuestro home, veremos que al ejecutar el programa tenemos cada 5 segundos (configuración por defecto) un molesto destello/flickering en la actualización de la información, en mi caso es DEMASIADO molesto.

Siguiendo las instrucciones como siempre, menciona que debemos habilitar un módulo "dbe" en xorg.conf

Section "Module"
Load "dbe"
EndSection

Pero he aqui que en la nueva configuración del mismo en Lenny ya no existe esa linea (según dice en /usr/share/doc/xserver-xorg/NEWS.Debian.gz)
no entiendo la razón asi que tenemos que editar el /etc/X11/xorg.conf y agregar las siguientes lineas tambien (antes de la sección Module, y preferentemente al principio de todo el xorg.conf):

Section "Files"
ModulePath "/usr/lib/xorg/modules"
EndSection

Con esto modificado y el servicio de X reiniciado queda pendiente el arranque automático en nuestra sesión de usuario (Gnome en mi caso) lo más cómun seria que desde System-->Preferences-->Sessions en "Startup Programs" coloquemos el comando "conky" directamente, pero no sé porque no funciona. La solución pasó por crear en mi home un archivo .conky_start.sh

#!/bin/bash
sleep 10 && conky;

Darle los correspondientes permisos de ejecución

$chmod a+x .conky_start.sh

Recién alli si poner ese script en el System-->Preferences-->Sessions en "Startup Programs" como muesta la imagen a continuacion:


ACTUALIZACION: habia hecho un post con mi archivo de configuración pero como era muy largo decidí ponerlo como archivo en otro host, asi que aqui está:
~/.conkyrc (modo texto)

~/.conkyrc.zip (zipeado)

Blog recuperado

Y sí...

Resultó ser que sí tenía un blog, pero no lo recordaba (no es de sosprender, tengo pésima memoria) asi que sumado a las intenciones siempre pospuestas de tener mi propio blog, me puse a ordernar los CNAME de mi dominio y ordenar/apuntar todo a blogspot.com

Y este es el resultado.
Posteriormente tengo intenciones de colgar todo en mi propio hosting ya que no deseo no tener el absoluto control de la información que publique, amén de que mis opiniones probablemente no vayan de la mano con el contenido aceptado por google.

Y sí, el porqué de la demora en tener mi propio blog, no sé contestarla, consumo desde hace muchos años la información publicada a diario por muchas personas, y el estar vinculado a la profesión de "Sistemas/IT" hubiera facilitado mucho el tenerlo antes, se puede decir que llego tarde a la mesa.
Pero bueno, lo hecho, hecho está.

Bienvenidos...!