El otro día, ante una necesidad específica, cree mi cuenta en IFTTT y puse a funcionar mi primer receta y también estuve viendo las posibilidades de este servicio que, en conclusión, es maravilloso y aquí estoy escribiendo este artículo.

Todos conocemos los sitios que ofrecen compartir en Twitter o Facebook lo que se está leyendo, o de alguna extensión del navegador que permite guardar en Dropbox o Evernote un sitio web, video de Youtube o archivo.  Bueno, IFTTT lleva la vinculación entre distintas aplicaciones o sitios en la nube a donde tu imaginación o necesidades puedan llegar.

La idea que plantea IFTTT es simple: dada una cierta condición en algún servicio (Instagram, Facebook, Twitter, Dropbox, etc.) se produce una acción en otro servicio de la nube (Tumblr, Delicius, WordPress, Last.fm, o cualquiera de los ya nombrados).

esquema del artículo de JJ Velasco

Las reglas las hace cada usuario, otorgando los accesos correspondientes a IFTTT para que pueda manejar sus cuentas en la nube. De ahí que tus necesidades y tu imaginación sean el límite  (claro que el poder de IFTTT tiene límites, pero…).

Imaginemos algunos escenarios de recetas de IFTTT:

• Cada vez que en twitter se publica una determinada #etiqueta me envía un correo
• Cuando una determinada acción de bolsa (a través de Yahoo Finance) pasa un determinado umbral, publica un twitter
• Cuando hay mal tiempo (a trvés de Yahoo Weather)  se activa la corriente eléctrica en un toma de mi casa (a través de de un Belkin WeMo)
• A determinada hora o cuando se publica una foto en Instagram o se envía un determinado SMS,  se encienden las luces de mi casa en determinados colores con un sistema Philips Hue.
• Cada vez que se promociona un nuevo par de anteojos en Svppy, envía un mensaje en mi Google Talk.
• Cada vez que se publica un video en Youtube en un determinado canal, lo publica en mi blog de Tumblr.
• Cuando recibo un determinado correo en GMail, me llama por teléfono.
• Cuando el paquete que me han enviado por DHL, Fedex o UPS cambia de estado, prende la luz del Blink(1) conectado al USB de mi equipo.
• Cada vez que cambio la foto de mi perfil en Facebook, la cambia también en el de Twitter.

Los servicios que permite vincular IFTTT son muchos y se van agregando nuevos.

Las recetas se pueden compartir, de hecho ya hay miles recetas compartidas para utilizar y adaptar a nuestras necesidades.

Para mi ha sido todo un descubrimiento, no solo de IFTTT, sino también un montón de servicios y gadgets que están disponibles.

JJ Velasco ha escrito un muy buen artículo en Bitelia con Recetas IFTTT para sacarle partido a Evernote, que fue precisamente Evernote el motivo de mi ingreso a IFTTT.

Gracias Quino por mostrarnos el mundo de esta forma….

En este artículo describo brevemente cómo lo hice.

Instalación

Luego de tener arrancado y configurado en la red el Raspberry Pi con Raspbian procedí a instalar transmission-daemon que fue lo que encontré más adecuado luego de analizar un poco otras opciones como uTorrent

apt-get install transmission-daemon

Crear los directorios necesarios para transmission-daemon donde esté montado el disco externo, en este caso /data (que lo coloco en el /etc/fstab para que lo monte siempre):

cd /data
mkdir torrent
cd torrent
mkdir info finish temp
chown debian-transmission info finish temp

Editar archivo de configuración /etc/transmission-daemon/settings.json y cambiar

“download-dir”: “/data/torrent/finish”,

“incomplete-dir”: “/data/torrent/temp”,
“incomplete-dir-enabled”: true,

editar archivo de daemon /etc/default/transmission-daemon y cambiar

CONFIG_DIR=”/data/torrent/info”

reiniciar transmission para que cree la estructura por defecto en /data/torrent/info

/etc/init.d/transmission-daemon restart

detener transmisión:

/etc/init.d/transmission-daemon stop

Crear un symlink de la estructura creada al archivo en el /etc/transmission-daemon/

cd /data/torrent/info
rm settings.json
ln -s /etc/transmission-daemon/settings.json

Iniciar transmisión nuevamente

/etc/init.d/transmission-daemon start

Conectar la interfaz web (tunel ssh)

Transmission-daemon quedará esperando conexiones en el puerto definido en rpc-port del archivo /etc/transmission-daemon/settings.json, por defecto el 9091; así que http://IP-RaspberryPi:9091 me conectará con la interfaz de administración de transmission.

Conectar desde internet requiere abrir los puertos y redirigirlos a al Raspberry Pi. Se podría hacer con el puerto 9091, pero la seguridad estaría basada en la validación de transmission, así que preferí reenviar el puerto 22 y armar cada vez un tunel con el servicio SSH.

ssh -p22 -L 9091:localhost:9091 pi@micasa.dyndns.org

y conecto con el navegador desde cualquier lugar de internet a http://localhost:9091 para acceder a la consola de administración que me pedirá primero usuario/clave de transmission.

Descargar archivos del disco externo a mi notebook

Algunos documentos en la web sugieren utilizar ownCloud para bajar los archivos desde el Raspberry Pi. Es una solución interesante, pero requiere un servidor web con soporte PHP que van a recargar el Raspberry Pi, y una configuración adicional.

¿Para qué?, si tenemos SSH que es una puerta a la felicidad, entonces con SSHFS dejo disponibles los archivos descargados en mi notebook y los puedo abrir y copiar normalmente como cualquier otro archivo; con la ventaja que no es necesario ningún nuevo servicio o configuración.

Este es el comando que utilizo, para montar en una carpeta bajo mi home que he creado con el nombre RaspberryPi

sshfs -p22 pi@micasa.dyndns.org:/data/torrent/finish RaspberryPi/

Otros documentos en la red

De gran ayuda fue el artículo de Electro titulado “Cliente Torrent con Raspberry Pi”, que fue mi guía para toda mi configuración.

También encontré un documento de Jose L. Romero titulado “Raspberry Pi como cliente torrent”, que me permitió obtener algunos otros tips para mi configuración original.

Podría haber abierto mi correo electrónico y escribirme un correo (fue mi primera intención), también un documento en GoogleDocs, una nota en Evernote o, lo que hubiera sido natural, usar mi propio wiki… pero no recordaba ninguna clave.

Hace ya tiempo que tengo claves únicas para cada sitio y difíciles de recordar, de hecho no las recuerdo y tengo un software de repositorio de claves (nota mental: un día de estos escribir sobre esto) al que no tenía acceso en ese momento.

Así que vine al blog y busqué un artículo más o menos relacionado al tema y escribí un comentario con toda la información que quería recordar. Y ahí quedó la información guardada.

Hace tiempo que este blog se ha vuelto un lugar donde guardo las cosas que deseo recordar y compartir; pero encontré este uso novedoso (al menos para mi) que seguro estaré usufructuando más frecuentemente.

Una Amazon Machine Image (ami) es una imagen virtual pre-configurada con software que es usada para crear máquinas virtuales en la nube de Amazon (EC2).

Una vez que sabemos la ami que necesitamos, podemos iniciar nuestra propia instancia, basada en ella, con el comando:

ec2-run-instances ami-0cdf4965 -t m2.2xlarge –region us-east-1 –key keypar

El uso de UbuntuFinder es realmente trivial y de alta utilidad, este video lo demuestra:

DomainKeys Identified Mail (DKIM) es un método por el cual los correos son verificados con la firma digital del servidor de origen; esto permite validar el dominio del remitente, evitar la suplantación de identidad, asegurar el remitente y la integridad, evitando la modificación de los correos.

La instalación que se presenta permite disponer de Postfix en Debian/GNU validando correo recibido con DKIM y firmando los mensajes salientes para todos los dominios, en un servidor multi-dominio.

Instalación

Si tenemos Postfix correctamente funcionando, solo debemos instalar dkim-filter que se encargará de firmar y verificar los correos.

# aptitude install dkim-filter

Llave digital

# dkim-genkey -b 1024 -d dominio.com -s cartero

Donde:

• -d dominio.com – es el dominio del servidor de correo (MX)
• -s cartero – es la forma de identificar la llave y es el nombre del host (MX)

El resultado de la ejecución son dos archivos: cartero.private y cartero.txt

# cp cartero.private /etc/mail/dkim.key
# chown dkim-filter /etc/mail/dkim.key

y cartero.txt se usa para el DNS, como se ve más adelante.

Filtro

Habilitarlo para que escuche en un puerto de localhost, editando el archivo /etc/default/dkim-filter y dejando esta línea:

SOCKET=”inet:1025@localhost”

Luego configurar el archivo /etc/dkim-filter.conf:

Syslog yes
UMask 002

Domain *
KeyFile /etc/mail/dkim.key
Selector cartero

AutoRestart no
Background yes
Canonicalization simple
DNSTimeout 5
Mode sv
SignatureAlgorithm rsa-sha256
SubDomains no
X-Header yes

Aquí son importante estas líneas (y por supuesto que las demás también):

• Syslog yes – Dejará un registro del funcionamiento de dkim-filter en el /var/log/mail.log
• Domain * – Hace que la firma de los correos salientes sea para todos los dominios
• Selector cartero – es el identificador que le pusimos a la llave cuando la creamos y que coincide con el nombre del host

y podemos iniciar el daemon dkim-filter y verificar que efectivamente ha quedado escuchando en el puerto que configuramos (en este caso 1025)

Postfix

Resta decirle a Postfix que se vincule con dkim-filter para los correos entrantes y salientes, agregando estas líneas al /etc/postfix/main.cf:

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:127.0.0.1:1025
non_smtpd_milters = inet:127.0.0.1:1025

DNS

La configuración indicada previamente hace que todos los dominios de origen sean firmados por el servidor de correo, lo que puede no ser una escenario común.

Así, en cada dominio se debe agregar el registro TXT que contiene la llave pública con que será verificada la firma.

Para esto editar el archivo de zona DNS del dominio y colocar la información que ha queado en el archivo cartero.txt, así:

cartero._domainkey.dominio.com. IN TXT “v=DKIM1; g=*; k=rsa; p=MIGfM…wIDAQAB”

Verificación

Para verificar que todo anda como uno espera (hola Murhpy!), se pueden observar las líneas en el /var/log/mail.log de dkim-filter, semejantes a esta:

Jan 18 01:23:12 cartero dkim-filter[6484]: Sendmail DKIM Filter v2.8.2 starting (args: -x /etc/dkim-filter.conf -u dkim-filter -P /var/run/dkim-filter/dkim-filter.pid -p inet:1025@localhost)

y se puede enviar correo a una cuenta de yahoo.com (creadores de DKIM) y verificar que el correo no sea colocado en spam y que su cabezal tenga una línea semejante a esta:

Authentication-Results: mta1052.mail.ac4.yahoo.com from=dominio.com; domainkeys=neutral (no sig); from=dominio.com; dkim=pass (ok)

Basado en los artículos de:

• Julien Valroff
• Daniel Coletti
• Google’s Internet Identity Research
• Ubuntu Community Help Wiki

La Linux Foundation ha publicado un video que resume en dos minutos el año 2012 para Linux, con palabras del propio Linus Torvalds:

… y cómo concluye el video…

Se parte del proyecto de desarrollo colaborativo más grande del Mundo

…

En este artículo describo cómo tengo mi instalación en Mac OS X, aunque perfectamente es aplicable para Linux u otros Unix. Esta descripción también incluye la configuración para poder trabajar con varias cuentas de Amazon independientes.

Sin duda, esta instalación puede ser perfeccionada, así que espero sugerencias en los comentarios.

Java JDK

Las herramientas de Amazon requieren Java, sirve tanto sea JDK como JRE. El documento de instalación oficial de Amazon describe cómo realizar esta instalación.

Es mandatorio tener configurada la variable de ambiente JAVA_HOME. Esto se se hace agregando la siguiente línea al archivo ~/.bashrc:

export JAVA_HOME=”/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home”

Amazon EC2 API Tools

Descargar las herramientas de Amazon EC2 API Tools y descompactar en /usr/local; renombrar directorio de extracción a amazon

cd /usr/local
unzip ec2-api-tools.zip
mv ec2-api-tools-1.6.5.1 /usr/local/amazon

Configurar el entorno creado para dejarlo disponible, agregando las siguientes líneas en el archivo ~/.bashrc

export EC2_HOME=/usr/local/amazon
export EC2_AMITOOL_HOME=/usr/local/amazon
export PATH=$PATH:$EC2_HOME/bin

Certificados de Seguridad

Crear y descargar los certificados X.509 de Credenciales de Acceso en la cuenta de Amazon. Estos certificados digitales permiten validar SOAP para las herramientas de línea de comandos.

Se obtienen dos archivos:

• pk-33XYJMEMKWAFXK0UZ7OU6FWCRYBR99Y.pem
  Llave privada RSA: respaldar (si se extravía se debe generar una nueva)
• cert-33XYJMEMKWAFXK0UZ7OU6FWCRYBR99LY.pem
  Certificado público X.509: se puede acceder y volver a bajar siempre.

En caso de dudas de cómo funciona el sistema de validación en Amazon, consultar la documentación oficial.

Dejar esos dos archivos en un directorio “oculto” en el home el usuario

cd
mkdir .ec2
chmod 700 .ec2

chmod 400 .ec2/pk-33XYJMEMKWAFXK0UZ7OU6FWCRYBR99Y.pem

ls .ec2/
cert-33XYJMEMKWAFXK0UZ7OU6FWCRYBR99LY.pem pk-33XYJMEMKWAFXK0UZ7OU6FWCRYBR99Y.pem

Entorno para uso de certificados

Crear un alias que cargue las variables de ambiente con los certificados, con la siguiente línea en el archivo ~/.bash_aliases (o en el ~/.bashrc):

alias ec2cuentaA=’KEY=”33XYJMEMKWAFXK0UZ7OU6FWCRYBR99LY”;
export EC2_PRIVATE_KEY=$HOME/.ec2/pk-$KEY.pem;
export EC2_CERT=$HOME/.ec2/cert-$KEY.pem’

(es una única línea, pero se muestra aquí en tres líneas para facilitar la lectura)

Para cada cuenta que se tenga de Amazon EC2 se crea un alias que cargue los certificados correspondientes, por ejemplo ec2cuentaB, ec2empresa1, etc.

Probar Instalación

Al abrir una nueva terminal se estará cargando el entorno definido en el ~/.bashrc (si así está previamente definido en el archivo ~/.profile o ~/.bash_profile o ~/.bash_login).

Cuando se desea conectar con una cuenta determinada, ejecutar el alias:

ec2cuentaA

Y ya se pueden usar dos comandos para consultar Amazon EC2:

$ ec2-describe-regions
REGION eu-west-1 ec2.eu-west-1.amazonaws.com
REGION sa-east-1 ec2.sa-east-1.amazonaws.com
REGION us-east-1 ec2.us-east-1.amazonaws.com
REGION ap-northeast-1 ec2.ap-northeast-1.amazonaws.com
REGION us-west-2 ec2.us-west-2.amazonaws.com
REGION us-west-1 ec2.us-west-1.amazonaws.com
REGION ap-southeast-1 ec2.ap-southeast-1.amazonaws.com

$ ec2-describe-availability-zones
AVAILABILITYZONE us-east-1a available us-east-1
AVAILABILITYZONE us-east-1b available us-east-1
AVAILABILITYZONE us-east-1c available us-east-1
AVAILABILITYZONE us-east-1d available us-east-1
AVAILABILITYZONE us-east-1e available us-east-1

Los comandos de las Amazon API Tools quedan disponibles en el PATH y expandibles con el tabulador (en Bash). En caso de que algo no esté bien configurado muestra un error.

Referencias

El origen de este artículo es una página de mi Wiki Pi.Lastr.Us donde mantengo la información actualizada de este tema.

Los artículos de Hugh Gilmour “Installar las herramientas de EC2 API en Mac OS X Leopard” y de Robert Sosinski “Starting Amazon EC2 with Mac OS X” fueron de gran ayuda para escribir este artículo.

ssh shelluser@server.remoto.com “mysqldump -uusuario -pclave123 basedatos | gzip -c1″ | gunzip -c | mysql -uroot -ppassword basedatos

Los comandos ente comillas mysqldump -uusuario -pclave123 basedatos | gzip -c1 se ejecutan en el servidor remoto mediante la conexión ssh que debe poder realizar el usuario ‘shelluser’, para sacar por estándar output el dump compactado de la base de datos.

Localmente se recibe por estandar input con los comandos gunzip -c | mysql -uroot -ppassword basedatos, que descomprimen y ejecutan los comandos del dump en el mysql local contra la base de datos que se indica.

El gzip y el gunzip es opcional y lo que busca hacer es comprimir el tráfico que se transfiere mediante SSH, y solo sería necesario si la base que se está bajando es de cierto volumen.

La siguiente porción de código se puede incorporar al final del script lua para conocer cómo será recibida la petición para ser servida:

print(“>>>>> parts of the URI”)
print(“request.uri: ” .. lighty.env["request.uri"])
print(“uri.path: ” .. lighty.env["uri.path"])
print(“uri.path-raw: ” .. lighty.env["uri.path-raw"])
print(“uri.scheme: ” .. lighty.env["uri.scheme"])
print(“uri.authority: ” .. lighty.env["uri.authority"])
print(“uri.query: ” .. lighty.env["uri.query"])
print(“>> filenames, pathnames”)
print(“physical.path: ” .. lighty.env["physical.path"])
print(“physical.rel-path: ” .. lighty.env["physical.rel-path"])
print(“physical.doc-root: ” .. lighty.env["physical.doc-root"])

y la salida quedará guardada en el archivo /var/log/lighttpd/error.log