Usar HTC Desire como módem en Linux

Recientemente compré un HTC Desire. Aún estoy maravillado con las cosas que puedo hacer con este "smartphone". Es un teléfono super completo y eso de que tenga Android... ufffff lo máximo.

Para explotar todo el potencial de este tipo de teléfonos, hay que contratar un plan de datos de tarifa plana porque si no, la factura es descomunal.

Ok, pasando al tema en cuestión, mi proveedor de telefonía (Orange España al momento de escribir esto) permite utilizar el teléfono como modem para conectarse a internet y el HTC Desire viene con ese "modo" incluido de fábrica. Solo faltaba tratar de hacerlo funcionar en Linux ya que el manual solo se limita a hacerlo con el HTCSync.

Como era de esperarse, el HTCSync no viene para Linux, así que me puse a probar por mi cuenta.

Cuando conectas el HTC Desire a una computadora (yo lo hice en mi laptop) sale un mensaje proponiendo una serie de opciones:

• Solo cargar el teléfono
• Utilizarlo como un dispositivo de almacenamiento (acceso a la SD que trae)
• Compartir conexión

La opción que nos interesa es la última, compartir conexión. Hay que tener en cuenta que el teléfono solo comaprte conexión cuando está habilitado el sistema 3G, es decir, cuando estamos conectados a la red de datos del proveedor de telefonía móvil. Si no está activado el modo 3G, sale un aviso recordándonos que debemos activar el 3G. Si le damos en "Aceptar", pasamos a la pantalla de configuración de conexiones inalámbricas. Desde aquí podemos activar el 3G.

Una vez activado el 3G, en el syslog de Linux saldrá un mensaje diciendo que hay una nueva interfaz usb (usb0 si no se tiene otra).

Con el comando ip addr show deberían salir todas las interfaces y entre ellas la usb0 con el flag de "DOWN". Simplemente debemos correr ifconfig usb0 up y verificar que ahora muestra el flag "UP".

Falta colocarle un IP, un default gateway y los servidores DNS. Afortunadamente, el teléfono tiene un servidor dhcp con lo que basta ejecutar:

dhclient usb0

y esperar a que tengamos IP, DNS's y default gateway.

Verificar con route -n que tenemos default gateway y ejecutar dig para ver si obtenemos respuesta.

En mi caso si la tuve. Eso es todo, ya estamos conectados a internet utilizando el HTC Desire.

Todo este procedimiento se puede automatizar escribiendo unas simples reglas de udev, pero eso queda a gusto del consumidor.

Espero que esto le sirva a alguien, agradecería sus comentarios.

Extraer cookies de Firefox 3 (en Linux)

El cuento es el siguiente, tengo una cuenta premium en rapidshare y hasta ahora me había funcionado perfectamente mi script para guardar cookies:

wget --save-cookies .cookies/rapidshare --post-data "login=el_login&password=el_password" --no-check-certificate -O - https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi > /dev/null

Pero como no todo puede ser fácil, los "amigos" de rapidshare decidieron cambiar la forma de hacer login en el sitio, de manera que ya no puedo guardar las cookies como antes.

Buscando por la red encontré un plugin de firefox para exportar cookies pero no quiero estarle instalando cosas a firefox, embasurándolo pués. También encontré scripts en python que hacen el trabajo pero me dió flojera usar python y tener que "entender" el script, así que decidí intentar sacar las cookies "a mano" yo mismo.

El archivo de cookies de firefox 3 es una base de datos sqlite que se encuentra (en Linux) en $HOME/.mozilla/firefox/cookies.sqlite.

En este archivo hay una tabla con el nombre moz_cookies con los siguientes campos:

id INTEGER PRIMARY KEY,
name TEXT,
value TEXT,
host TEXT,
path TEXT,
expiry INTEGER,
lastAccessed INTEGER,
isSecure INTEGER,
isHttpOnly INTEGER

Para bajarme la mayoría de las cosas de rapidshare uso wget con la opción --load-cookies. Wget espera un archivo de cookies con el siguiente formato:

.rapidshare.com TRUE / FALSE 1731510000 enc cadena


El formato es explicado aquí: http://kb.mozillazine.org/Cookies.txt

Cada uno de estos campos debe estar separado por un "TAB".

Para extraer esta información debemos hacer lo siguiente:

• Entrar en la página deseada y autenticarse.


• Verificar en el navegador que se tiene la cookie (depende del navegador... investiga!!!).


• Copiar el archivo de cookies a un lugar "seguro" (/tmp por ejemplo).


• Ejecutar lo siguiente (en Linux):
  
  $ sqlite3 cookies.sqlite
  sqlite> .separator \t
  sqlite> .output /tmp/cookies.txt
  sqlite> select host, "TRUE", path, "FALSE", expiry, name, value from moz_cookies where host = '.rapidshare.com' and name = 'enc';
  sqlite> .quit
  
  En /tmp deberíamos tener el archivo cookies.txt con los resultados separados por "tab".
  
  Con el comando:
  
  $ cat -vte /tmp/cookies.txt
  
  deberíamos observar el archivo de cookies con los valores seleccionados y con el caracter "^I" de separador.


• Utilizar este archivo de cookies con wget.

Un solo detalle más, si se quiere alargar la fecha de expiración se puede sustituir el expiry en el por algo como expiry+3600*24*365, con lo que le estaríamos añadiendo un año a la fecha de expiración de la cookie.

Espero que esto sirva de ayuda.

Configuración de multipath en RHEL 5.3

Multipath es una herramienta que permite administrar los diferentes path's que existen hacia un LUN en un ambiente de SAN.

El Device Mapper de Linux permite agrupar todos los path's que un servidor ver hacia un LUN específico bajo un solo device file (/dev/mapper/mpathn por omisión) de manera que la administración se simplifique y dando la felxibilidad de utilizar diferentes políticas de balanceo de carga además de la alta disponibilidad que provee la arquitectura.

Requisitos
Para configurar multipath se debe tener instalado el paquete device-mapper-multipath. Además de esto, el servidor tiene que estar conectado a la SAN y sus tarjetas de fibra deben estar funcionando correctamente.

Iniciando multipath por primera vez
Cuando se va a iniciar multipath por primera vez, se deben realizar los siguientes pasos:

Verificación del archivo /etc/multipath.conf

Este es el archivo de configuración del demonio multipathd. La configuración que viene de fábrica es aceptable para la mayorí de los ambientes y solo debemos comentar las siguientes lineas:

blacklist {
devnode "*"
}

Con esto le decimos al demonio multipathd que no excluya nada a la hora de verificar los path's hacia los LUN's presentados.

Inicio del demonio multipathd

Para iniciar el demonio mulipathd ejecutamos el siguiente comando:

# /etc/init.d/multipathd

y verificamos que salga el mensaje [ OK ]

En el syslog (/var/log/messages) pueden aparecer los siguientes mensajes:
multipathd: cannot open /sbin/dasd_id : No such file or directory
multipathd: cannot open /sbin/gnbd_import : No such file or directory
multipathd: [copy.c] cannot open /sbin/dasd_id
multipathd: cannot copy /sbin/dasd_id in ramfs : No such file or directory multipathd: [copy.c] cannot open /sbin/gnbd_import
multipathd: cannot copy /sbin/gnbd_import in ramfs : No such file or directory

No representan ningún problema ya que son módulos que no estamos utilizando.

Para asegurarnos de que el demonio se iniciará cada vez que el servidor arranque, utilizanos el siguiente comando:

# chkconfig multipathd on

Descubrimiento de LUN's
Después de que se le hayan presentado los LUN's correspondientes al servidor en cualquiera de las cabinas se debe forzar a este a descubrir los LUN's.

Para descubirir LUN's sin reiniciar el servidor, se corre el siguiente comando:

# echo 1 > /sys/class/fc_host/hostn/issue_lip

El valor de n depende de cuantas tarjetas de fibra se tengan. Si se tienen 2, n tendrá los valores 0 y 1, por lo tanto se debe correr el comando tantas veces como tarjetas de fibra tengamos, variando el valor de n respectivamente.

En el syslog deben aparecer los discos descubiertos y el device mapper debe crear el device file correspondiente, como es el primer LUN que se está asignando, el nombre del device file debe ser /dev/mapper/mpath0

Para verificar que el device mapper ha configurado el multipath correctamente, se ejecutar el comando

# multipath -ll

y el resultado debe ser parecido a este:

# multipath -ll
mpath0 (360060e80141a230000011a2300000090) dm-7 HP,OPEN-V
[size=100G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=4][active]
\_ 0:0:0:16384 sda 8:0 [active][ready]
\_ 0:0:1:16384 sdb 8:16 [active][ready]
\_ 1:0:0:16384 sdc 8:32 [active][ready]
\_ 1:0:1:16384 sdd 8:48 [active][ready]

De ahora en adelante el device file /dev/mapper/mpath0 puede ser utilizado como un disco más, por ejemplo, se puede hacer pvcreate sobre él para utilizarlo con LVM.

Desasignando LUN's
Si por alguna razón se deben desasignar los LUN's que a los cuales referencia /dev/mapper/mpath0, lo primero que hay que hacer es destruir toda la arquitectura de filesystems que exista sobre el device file. Una ves que esté "libre" se procede a borrar el device file de la siguiente manera:

# multipath -f /dev/mapper/mpath0

Luego se procede a "borrar" los paths hace el LUN

# echo 1 > /sys/block/sd?/device/delete

Donde “?” indica la letra correspondiente al “disco” por ejemplo sda.

Obtener el WWN de una HBA en RHEL 5

Esto lo hice con unas tarjetas QLogic. Primero hay que obtener el PCI ID

# lspci|grep Q
10:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
10:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)

Con los PCI ID's hago lo siguiente:

# cat /sys/bus/pci/drivers/qla2xxx/*<PCI_ID>/host*/fc_host*/port_name

en este caso sería:

# cat /sys/bus/pci/drivers/qla2xxx/*10:00.0/host*/fc_host*/port_name


Actualización (2009-07-20)

Utilizando el filesystem /sys podemos acortar las cosas de la siguiente manera:

Para la primera tarjeta de fibra colocamos

# cat /sys/class/fc_host/host0/port_name


Para la segunda

# cat /sys/class/fc_host/host1/port_name

y así con las demás HBA's (si existen).

Alfabeto fonético aeronáutico en IT

Si has trabajado en IT, seguramente has tenido que decir muchas veces códigos, nombres de usuarios, seriales, part numbers, etc. utilzando el teléfono.

Seguramente también lo has hecho en ambientes de mucho ruido (data centers por ejemplo) y no es una tarea fácil, más aún sabiendo que el otro extremo debe recibir, exactamente, lo que estás diciendo.

A pesar de esto he visto que no le prestamos atención a este tipo de transmisión de la información y nos nos aseguramos que las cosas lleguen correctamente a su destino. Es común escuchar los ¿qué? ¿cómo? repite, no te escucho.

También es común escuchar a personas deletreando frases o códigos y parándose a pensar en qué palabra pueden decir que comience con la letra requerida..... para la "s" puede ser.. Sevilla, Soria, Salamanca.... y así cualquier cosa que se les ocurra (o no).

Como siempre digo, la rueda no hay que inventarla, hay que usarla y si, ya alguien ha inventado un método de comunicación para ambientes con mucho ruido y donde hay que asegurarse de que el otro extremo recibe la información correcta. Se llama Alfabeto fonético aeronáutico y copio textualmente de wikipedia:

"Se utiliza para transmitir por vía oral cualquier tipo de información pero principalmente cuando se trata números o términos en los que es vital su correcta escritura y entendimiento, a pesar de ambigüedades o dificultades idiomáticas."

"Por medio de un acuerdo internacional entre los países miembros de OACI se decidió crear un alfabeto fonético para uso universal en radio transmisiones internacionales que está basado en el abecedario inglés (idioma acordado para uso aeronáutico internacional) que tomara el lugar de los alfabetos fonéticos existentes hasta esas fechas. Además de ser usado en transmisiones aeronáuticas reguladas por OACI (civiles) es usado en transmisiones de carácter militar, es el alfabeto estándar de la OTAN, y radioaficionados de todo el mundo."

Es decir que no es nada nuevo, no estamos decubriendo el agua tibia y si lo usa la OTAN y los radioaficionados, debe ser que funciona.

Entonces, vamos a usarlo, que seguro la comunicación es mucho más fluida.

Dejo el enlace (en español) para ir aprendiendo la letras, los números y cómo transmitirlos.

http://es.wikipedia.org/wiki/Alfabeto_fonético_de_la_OTAN

Configurando mailx para leer buzones en formato maildir

*** Actualización (28 de Junio de 2015) ***
Cuando digo mailx quiero decir  heirloom-mailx. bsd-mailx no soporta buzones en formato maildir.
****

En un post anterior expliqué cómo configurar procmail para trabajar con buzones en formato maildir, ahora es necesario poder leer los correos. En este post explico cómo configurar mailx para que lea buzones en formato maildir.

Es muy fácil, solo definir la variable de ambiente MAIL para que contenga la "raiz" de la estructura de directorios maildir. Un ejemplo, asumamos que tengo mi procmail configurado para dejar los correos en formato maildir en la siguiente ubicación:

/var/spool/mail/usuarios/ricardo

Debajo de esta ruta se encuentran los directorios new, cur y tmp, entonces, la variable mail debe ser definida así:

MAIL="/var/spool/mail/usuarios/ricardo/"

Muy importante, nótese el "/" al final de la ruta

La variable puede ser definida de manera parametrizada también (y de manera más conveniente) como

MAIL="/var/spool/mail/usuarios/$LOGNAME/"

Configurando procmail para que use Maildir

No voy a detallar mucho lo que es procmail ni en lo que es maildir ni si es mejor que mailbox. Este post, simplemente trata de explicar, de manera rápida, cómo configurar procmail para que trabaje con maildir. Más que todo, como una "chuleta" para mi y si le sirve a alguien, muy bien.

Simplemente, colocar en el ~/.procmailrc las siguientes líneas:

MAILDIR=/var/spool/mail/usuarios/ricardo/
DEFAULT=$MAILDIR

Esto es solo un ejemplo, lo importante aquí es que, el path que esté en la variable MAILDIR termine en "/"

Notas importantes:

1. MAILDIR debe existir, procmail se saldrá con un error si no existe.
2. La estructura de directorios (new, cur, tmp) la creará procmail si no existe.
3. No creo que sea buena idea colocar esto "system wide" para que el correo de root siga estando en /var/spool/mail/root (o donde sea que se haya configurado que deba estar el correo de root).

Si se va a automatizar esto y el archivo .procmailrc se va a colocar en el /etc/skel (para que sea copiado a cada usuario que se crea de manera automática), es mejor definir la variable MAILDIR de la siguiente manera:

MAILDIR="/var/spool/mail/usuarios/$LOGNAME/"

Espero que les sirva.