Configurar sendmail para que use a Gmail como smarthost con Debian Wheezy

Recientemente monté un "servidor multimedia" en la casa, básicamente una laptop vieja con debian Wheezy para utilizarla como servidor NAS y DLNA. Fue entonces cuando me surgió la idea de utilizar el SMTP de gmail como smarthost y de esa manera, todos los correos que se generen en el "servidor multimedia" saldrían por gmail ya que la mayoría de los ISP's colocan deliberadamente las IP's de los clientes en las listas negras de spam.

El procedimiento que explico lo realicé utilizando todo "out of the box", así que debería ser de muy fácil mantenimiento (debian way).

Elementos de software que utilicé
Distribución: Debian Wheezy
Sendmail: 8.14.4-2
sasl2-bin: 2.1.25.dfsg1-4
libsasl2-2: 2.1.25.dfsg1-4
libsasl2-modules: 2.1.25.dfsg1-4

Nota: Si falta algún otro paquete, por favor decirlo. No recuerdo si sendmail ya instala las librerías sasl.


Configuración

1. Hacer un respaldo del /etc/mail/sendmail.mc


2. Editar el /etc/mail/sendmail.conf y colocar MSP_MODE="None"


3. Editar el /etc/sendmail.mc y colocar toda la sección de "Default Mailer setup" al final del archivo.


4. Añadir la siguiente sección antes de "Masquerading options"
   
   
   dnl ###################################
   dnl # Comienzo pruebas de gmail
   dnl #
   dnl #
   dnl # Soporte para TLS (para pruebas de gmail)
   dnl #
   include(`/etc/mail/tls/starttls.m4')dnl
   dnl #
   dnl #
   dnl #
   define(`SMART_HOST',`smtp.gmail.com')dnl
   define(`RELAY_MAILER_ARGS',`TCP $h 587')dnl
   define(`ESMTP_MAILER_ARGS',`TCP $h 587')dnl
   FEATURE(`authinfo', `hash /etc/mail/client-info-gmail.db')dnl
   define(`confAUTH_MECHANISMS',`EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
   TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
   dnl #
   dnl #
   dnl # Fin de pruebas de gmail
   dnl ##################################
   
   
   Nota: Cuidado al copiar esto ya que aveces las comillas se malinterpretan. Yo recomiendo copiar secciones del .mc y luego editarlas para evitar problemas. Dicho queda.




5. Editar el archivo (nuevo) /etc/mail/client-info-gmail y colocar la siguiente información:
   
   AuthInfo:smtp.gmail.com "U:root" "I:usuario@gmail.com" "P:password" "M:LOGIN PLAIN"
   AuthInfo:smtp.gmail.com:587 "U:root" "I:usuario@gmail.com" "P:password" “M:LOGIN PLAIN"
   
   Nota: Cuidado al copiar las comillas dobles, mejor hacerlo a mano, sendmail puede no entenderlas bien y el servidor de gmail nos mostrará un error diciendo "530-5.5.1 Authentication Required".
   
   Nota 2: Cada "AuthInfo" es una sola línea


6. Hacer el mapa con el siguiente comando:
   makemap -r hash client-info-gmail.db < client-info-gmail


7. Asegurarse de que saslauthd está arrancado (si no, arrancarlo) y verificar que arranque en el inicio (update-rc.d saslauthd defaults).


8. Ejecutar sendmailconfig y verificar que no salga ningún error.


9. Ejecutar update-rc.d sendmail defaults para que arranque en el inicio.

Eso debería ser todo, solo queda probar.

Linux como servidor DLNA

Hace algunos meses compré un televisor Samsung LED UE37C6000. El televisor es una joya, la imágen excelente, la nitidez impresionante, es super delgado y liviano (muy apropiado para paredes de pladur) y el sonido, mejorable aunque bueno para propósitos generales.

Como todo televisor "moderno" tiene la opción de DLNA, conectores USB, HDMI, etc, etc, etc.

La primera prueba "importante" fue reproducir series y películas desde un penn drive. Bueno, eso es otra cosa, se ve impresionante y eso que están comprimidas en XviD.

Me faltaba probar la conexión a la red y la reproducción de contenido utilizando DLNA. Este televisor solo viene con un conector rj45, así que con un cable bastante largo lo conecté a un router linksys en la habitación contigua.

El televisor viene configurado de fábrica como cliente DHCP, así que se conectó sin problemas a la red. Comenzaba entonces mi aventura para conseguir un servidor DLNA para Linux.

El primero que utilicé fué mediatomb. Lo instalé en mandriva 2009.1 sin problemas (urpmi). Después de leer en varios foros, configuré el mediatomb. Es necesario agregar algunos encabezados especiales para que los videos puedan reproducirse en algunos dispositivos (como el mío). Aquí tengo un enlace si a alguien le interesa.

Que el media player el televisor viese los archivos compratidos por DLNA ya me parecía un milagro tecnológico pero cuando pude reproducir las películas fue el "non plus ultra".

Como todo en la vida, siempre hay un "plus ultra" y cuando no pude ver los subtítulos de las películas (archivos srt) me di cuenta de eso.

Volví a leer y a leer los foros, proponían una solución con mediatomb que no me gustó, consistía en hacer un "transcoding" del video adjuntándole los subtítulos al stream que se le manda al televisor, de esta manera, el cliente DLNA (el televisor) obtendría un stream con todo mezclado.

Esa solución no me gustó nada porque al hacer transcoding, el cpu estará trabajando casi al 100% todo el tiempo de reproducción lo que no es eficiente y podría afectarme en la fluidez del stream de video.

Seguí investigando y encontré MiniDLNA. Este es un pequeño servidor DLNA, muy simple, que las personas de los foros reportaban que funcionaba muy bien casi casi "out of the box". Desafortunadamente, mandriva 2009.1 no empaqueta MiniDLNA por lo que tuve que bajarlo de aquí. El programa viene en formato binario compilado estáticamente, con lo que solo necesité descomprimirlo, editar el archivo de configuración y ejecutarlo.

Eureka!!!, el MiniDLNA funciona correctamente, el televisor es capaz de reproducir una película con los subtítulos en un archivo aparte (archivo srt).

Coloco un resúmen de las cosas que se pueden hacer con MiniDLNA:

• Reproducción de subtítulos contenidos en un archivo separado.
• Funciones de pausa, stop, avance y retroceso rápido con las teclas de "cursor" del control remoto (las negras) no con las teclas de la sección de reproducción (las blancas).

A continuación coloco mi archivo minidlna.conf como ejemplo


port=8200

network_interface=eth0

media_dir=V,/peliculas

friendly_name=Linux DLNA Server

album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg

inotify=yes

enable_tivo=no

notify_interval=900

serial=12345678

model_number=1

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