LXC Debian Wheezy at DigitalOcean

DigitalOcean provides scalable virtual private servers (called droplets), provisioned with SSD storage, in multiple locations, and provides DNS hosting.

The LXC or Linux Containers may be defined as a way to isolate the tree process, the full user system, and the network configuration in a separate disk space (filesystem) into the same host thanks to the Linux kenel function to provide separate namespaces and control groups (cgroups) to access resources.

In the container operating environment the system is showed as a complete installation of a linux distribution with its root user, system users, and normal users; its processes, crontab and services, its own installed software, its IP address and network configuration. Perhaps, for these reasons it has been misunderstood many times as a guest system running into a virtualized environment, but it is not.

The droplet (host) is a virtualized environment (KVM based) which only runs one kernel that manages all the processes, memory, network, blocks, etc. For this reason it is possible to create containers in it, because containers are only isolation.

Moreover, droplets also come with just one public IP address, because of this a basic virtual network configuration is requried to access from outside to a service listen at the virtual IP of a container.

To know more about LXC I suggest two documents:


apt-get install -y lxc libvirt-bin

Mount the cgroup

The control groups are a Linux kernel feature to limit, account and isolate the resources (i.e. CPU, memory, disk I/O, etc.)

It is required to add the following line at the end of the /etc/fstab file:

cgroup  /sys/fs/cgroup  cgroup  defaults  0   0

and then mount it with the command mount /sys/fs/cgroup.

live-debconfig into containers

(perhaps this step will be obsolete) The package live-debconfig will be required to containers but it is not available into Debian Wheezy, therefore it is require to download from unstable version. You must make available live-debconfig package following these commands:

echo "deb http://ftp.de.debian.org/debian unstable main contrib non-free" > /etc/apt/sources.list.d/live-debconfig.list
apt-get update
cd /usr/share/lxc/packages
apt-get download live-debconfig
rm /etc/apt/sources.list.d/live-debconfig.list 
apt-get update


It is important full understanding of the network where the containers system will be connected, because you will need to forward ports and masquerade IPs and if you implement a full firewall configuration you will deal with inter-container communication rules.

The following schema is the configuration that implements this document:


Mark default Network to autostart:

virsh net-autostart default

and start it:

virsh net-start default

Check installation

Run these commands to check the output:

The cgroup filesystem with mount

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=126890,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102708k,mode=755)
/dev/disk/by-label/DOROOT on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup on /sys/fs/cgroup type cgroup (rw,relatime,perf_event,blkio,net_cls,freezer,devices,cpuacct,cpu,cpuset,clone_children)

The network configuration with virsh net-info default

Name            default
UUID            f1fed759-c42b-a727-6513-1bcea1a03436
Active:         yes
Persistent:     yes
Autostart:      yes
Bridge:         virbr0

and with ip addr show virbr0

4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether fe:cf:e2:f5:51:2a brd ff:ff:ff:ff:ff:ff
    inet brd scope global virbr0

The LXC configuration with lxc-checkconfig

Kernel config /proc/config.gz not found, looking in other places...
Found kernel config file /boot/config-3.2.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

First container

It is time to deal with containers:


It is possible to create the container with any name -n: for this document firstc is the name. Also the template -t for this document is debian but you also have available fedora ubuntu-cloud and archlinux templates with default lxc installation.

lxc-create -n firstc -t debian

For the first container you will need to wait because all packages are being downloaded. From there on all packages will be copied from the local disk.

Network the container

The installed container does not have any network configuration, you must add it add the end of the file /var/lib/lxc/nombrecontainer/config

## Network
lxc.network.type = veth
lxc.network.flags = up

# Network host side
lxc.network.link = virbr0

lxc.network.veth.pair = veth0
lxc.network.hwaddr = 00:FF:AA:00:00:01

# Network container side
lxc.network.name = eth0
lxc.network.ipv4 =

Start container

lxc-start -n firstc -d

and check if it is running with lxc-list with output:




Attach to console

Now you may login the container system with a standard console and user root with the password root

lxc-console -n firstc

Remember Type Ctrl+a q to exit the console

and also install and configure what you wish into the container as any recent installed system, because the container may access Internet by masquerade with the droplet IP.

Stop and manage your container

Now you may manage your container:

  • lxc-stop -n firstc to stop the container
  • lxc-destroy -n firstc to complete delete container installation

or configure it to autostart when you restart the droplet with:

ln -s /var/lib/lxc/firstc/config /etc/lxc/auto/firstc.conf

Access services into Container

You must configure a static IP to the container, for it to fullfil iptables access rules. There are two ways to do it:

  • With static IP address saved into the config file /var/lib/lxc/firstc/config adding
    lxc.network.ipv4 =

    line. This is equivalent to a static address configuration.

  • A static IP address assigned by the DHCP matching the MAC address of the container. Virsh provides a basic dhcpd through dnsmasq.

Configure static IP with DHCP

In /var/lib/libvirt/network/default.xml configure a static IP address to match with the container’s MAC address:

    <range start="" end="" />
    <host mac="00:FF:AA:00:00:01" name="firstc.example.com" ip="" />
    <host mac="00:FF:AA:00:00:02" name="secondc.example.com" ip="" />

after these, it is required for you to re-start the complete network, the commands are:

virsh net-destroy default

virsh net-start default

but if you are running containers they will lost their network and will be required to be restarted.

Port forwarding

All services are being accessed by just one IP address, thus the same service from a different container requires a different public port

ssh into each container (firstc)

iptables -t nat -A PREROUTING -p tcp --dport 1022 -j DNAT --to

in this case it is required to move the standard sshd port because the droplet has its sshd on 22 by default.

http into just one container (secondc)

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to

In this case if no other container or doplet has a webserver, you may use the standard httpd port.


Containers are fun and are supported by the droplets, so play with them.

Linux – Windows – Mac, la comparación adecuada

Recientemente llegó a mis manos (entre esas tantas cosas que me envían) un gráfico de alquilen que comparaba Linux, Windows y Mac con, digamos, fotos de cabinas para dirigir vehículos, que no me pareció muy justa para ninguno de los tres:


Linux no es un caza, tal vez en alguna época se requería mucho entrenamiento para manejarlo, pero actualmente no. Windows puede o no ser un vehículo deportivo, depende. Pero Mac seguramente no es un juguete.

Así que puse manos a la obra para hacer mi propia versión:


Digamos que, en primer lugar, los tres son automóviles.

Linux es un Forumula Uno, si sabes manejar lo diriges, pero si eres piloto experimentado seguramente lo harás volar.

Windows es un coche deportivo pero, como en la foto, tiene 4 pedales (un feature o un bug, según quién lo analice)

Y Mac representa aquello que quieres hacer, en este caso: si quieres manejar, entonces un volante.

El reverso de tu IP no está configurado … ¿el qué?

El spam ha llevado a quienes administramos servidores de correo a tomar precauciones para que no abusen de nuestros servidores y molesten lo menos posible a los usuarios que tienen cuenta allí. Esas precauciones van bastante más allá de instalar un sistema anti-spam, estos suelen ser la última barrera (y la más costosa).

Una de las precauciones a tener en cuenta es la configuración del servidor que desea entregarnos correo, llamado el «cliente». Las computadoras que envían SPAM suelen estar en la cuerda floja pues si son demasiado prolijos en su configuración pierden capacidad de adaptación cuando son descubiertos y bloqueados, mientras que los servidores que no envían spam tienen todo el tiempo para ajustar su configuración.

En fin, uno de los chequeos básicos es consultar un servidor de nombres (DNS) para saber si la dirección IP del cliente tiene configurado reverso, es decir resuelve un nombre y si ese nombre corresponde a su IP. En postfix esto se realiza mediante las directivas:

Rechaza el correo cuando:

  • la dirección IP no resuelve un nombre (no tiene reverso)
  • el nombre no resuelve contra la IP (no tiene configurado el directo A)
  • el nombre (A) resuelve contra una IP que no es la IP del cliente que se conecta

Rechaza el correo cuando:

  • la dirección del cliente no resuelve reverso con un nombre.

Lamentablemente, las buenas prácticas de configuración, que deberían ser estándar, para un servidor de correo no lo son. Generalmente porque los técnicos a cargo del servidor de correo desconocen o no invierten tiempo en estos detalles; así es que muy seguido me veo en la necesidad de explicar esto.

Detectando un servidor mal configurado

Si el cliente no resuelve un nombre aparece en el DNS:

Nov  6 06:27:55 postfix/smtpd[4944]: connect from unknown[]

Nov  6 06:36:47 postfix/smtpd[9419]: NOQUEUE: reject: RCPT from unknown[]: 450 4.7.1 Client host rejected: cannot find your hostname,

y es facil de verificar el reverso de una IP con los comandos host o dig:

# host does not exist, try again

En el anterior ejemplo no hay ningún nombre configurado para el reverso de esa IP.

# dig -x
;; ANSWER SECTION: 2605 IN	PTR	static-201-151-212-105.alestra.net.mx.

# dig static-201-151-212-105.alestra.net.mx
;static-201-151-212-105.alestra.net.mx. IN A

En el anterior ejemplo, hay un nombre configurado para la IP, pero luego ese nombre no está configurado para ninguna IP.

Revisando nuestro servidor

Si queremos ver si nuestro servidor está bien configurado, debemos tener en cuenta lo siguiente:

  1. Verificar la IP del servidor que realmente entrega los correos salientes. Me he topado con Admins que revisan una y otra vez la IP de su MX, y ese es el servidor que recibe los correos.
  2. Verificar la IP pública con la que el servidor sale a entregar correo. Algunas veces los Admins no saben claramente cuál es la IP pública que toman sus servidores, pues de esto se encargan «los de redes».

Y si bien los comandos host y dig son útiles, muchas veces no tenemos la posibilidad inmediata de revisar nuestra IP desde el universo público («desde afuera»), así que este servicio de Terra para Postmasters nos permite hacerlo.

Terra Postmaster Reverso

Así que si Ud. es administrador de servidores de correo (postmaster) y puede colaborar mejorando su configuración, espero este artículo sea de utilidad.

Automatizar proceso en screen

Uno de mis programas favoritos para administrar servidores es screen pues permite multiplexar una terminal como si fuera varias terminales (ventanas de comandos); es decir que luego de establecer una conección al servidor (mediante SSH) se pueden poner a correr varios programas como si se tuviera varias conexiones establecidas a la vez.

Además se puede salir y desconectarse del servidor, dejando corriendo cada uno de esos programas.  Al volver a conectarse se pueden re-tomar esas terminales que se dejaron abiertas. Sería como poner a correr un programa en un PC y apagar el monitor que se enciende al día siguiente; esto hace screen, cuando se desconecta y se vuelve a conectar a los servidores remotos (en la nube).

Generalmente conecto por SSH e invoco screen, dentro del cual pongo a correr lo que necesito; pero me surgió la necesidad auotmatizar (sin mi intervención) todo para actuar en varios servidores y aquí describo como lo he hecho.

Se puede invocar screen con el programa a correr y quedar desvinculado (deattached) de la terminal screen, invocándolo de esta forma:

screen -dmS prueba watch ls -al
  • -d hace que screen se invoque en forma desvinculada, es como escribir «C-a d» dentro de screen
  • -m hace que screen ignore si hay otro screen corriendo
  • -S prueba es el nombre de la sesión de screen, que luego puede ser usado para gestionar la misma en forma automatizada

ahora solo hay que llamarlo en una sesión ssh:

ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto screen -dmS prueba watch ls -al

(los parámetros de la sesión ssh son ejemplo y deben adaptarse al caso particular)

Luego de ejecutar esto se obtiene nuevamente el prompt local ($), pero ha quedado corriendo una sesión screen en el servidor remoto que está ejecutado el watch ls -al, veámoslo:

$ ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto screen -ls
There is a screen on:
	24411.prueba	(00/22/2113 33:44:55 PM)	(Detached)
1 Socket in /var/run/screen/S-root.
$ ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto ps ax | grep -i screen
24411 ?        Ss     0:00 /usr/bin/SCREEN -dmS prueba watch ls -al

para apagarlo, también remotamente, se puede enviar la señal TERM al PID remoto:

ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto 'kill $(screen -ls | grep prueba | cut -d. -f1)'

para los screen de nuestra sesión prueba. Si se quieren apagar todos los screen, se puede invocar más fácilmente asi:

ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto 'kill $(pidof SCREEN)'

Mi requerimiento en varios servidores, me llevó a armar un pequeño script que recibe por parámetros start/stop y devuelve la lista de screen corriendo:

# ejecuta screen remotos en los SERVERS

SERVERS="server1 server2 server3 server4 server5"

case $1 in
start) for i in $SERVERS; do
       ssh -p222 -i ~/.ssh/cert1 rodolfo@$i screen -dmS prueba watch ls -al
       done ;;
stop)  for i in $SERVERS; do
       ssh $i 'kill $(pidof SCREEN)'
       done ;;
*)     typeset -i a=1
       for i in $SERVERS; do
          echo "$a ==== $i"
          ssh $i '/usr/bin/screen -list | grep Detached'
       done ;;

exit 0

Linux Containers ¿cuántos Linux quieres tener?

Linux Containers (LXC) es un sistema de virtualización con Software Libre nativo en GNU/Linux, que habilita aislar procesos y recursos sin la necesidad de correr software de interpretación y emulación, ni las complejidades de otros sistemas de virtualización. LXC permite además la virtualización en entornos ya virtualizados como Cloud Computing y está siendo una herramienta muy apreciada por los DevOps para crear entornos efímeros donde correr aplicaciones en entornos controlados y deshechables. Se presentarán los principales  aspectos técnicos de los  LXC desde un punto de vista práctico; pues si necesitas otro Linux alcanza con pedírselo al tu kernel. También se presenta Docker como herramienta de automatización de PaaS.

Público Objetivo: Usuarios de GNU/Linux, administradores de redes, SysAdmins y DevOps.  Público en general.

Requisitos: Nociones de virtualización; de preferencia conocer comandos de shell.

Conferencia dictada en:

Puppet para hacer el trabajo por ti en el Datacenter

Para manejar un número importante de servidores en un datacenter, originalmente contábamos con un conjunto de scripts que ajustaban la instalación a nuestras políticas; con la virtualización comenzamos a usar templates; pero hoy día con el advenimiento de la nube y las aplicaciones que crean servidores, necesitamos mayor flexibilidad para atender requisitos variables y muy particulares, pero además se necesita un método que permita asegurar que cualquier cambio de políticas pueda ser impactado rápidamente en toda la granja. Puppet hace ese trabajo por ti en el Datacenter. En esta presentación se aborda también algunos ejemplos prácticos en los que Puppet está siendo utlizando con éxito.

Público Objetivo: Técnicos encargados de administración de servidores, SysOps y DevOps, administradores de centros de datos.

Requisitos: Conocimientos de sistemas operativos (Unix), administración de servidores.

Conferencia dictada en:

¿Qué es un DevOps?

220px-Devops.svg DevOps MVD es un grupo de MeetUP que se ha formado en Montevideo con la idea es compartir entre desarrolladores y sysadmins distintas experiencias que mejoren nuestras capacidades DevOps; pero ¿qué es ser un DevOps?

En estos días llegó a mis manos un artículo que responde exactamente esa pregunta, así que esta es la traducción del artículo What Is a DevOps Engineer? publicado el 23.mayo.2013 en el Blog de Puppet Labs.

¿Qué es ser un DevOps?

(Por: Aliza Earnshaw – Traducción: Rodolfo Pilas)

La demanda de las personas con habilidades de DevOps está creciendo rápidamente porque las empresas están obteniendo grandes resultados de ellos.

Las organizaciones que utilizan prácticas de DevOps son abrumadoramente eficientes: actualizan código hasta 30 veces más frecuentemente que sus competidores, con un 50 por ciento menos de posibilidades que sus instalaciones fracasen, según muestra nuestra encuesta El Estado de DevOps del 2013.

Con todas estas ventajas, se podría pensar que había un montón de ingenieros DevOps por ahí. Sin embargo, sólo el 18 por ciento de los encuestados dijo que alguien en su organización realmente tenía este título.

¿Por qué sucede esto?

En parte, es porque la definición de lo que es un DevOps está aun en evolución. Sin embargo, esto no impide la contratación de DevOps. Entre enero de 2012 y enero de 2013, los listados de empleos para DevOps en Indeed.com aumentaron 75 por ciento. En LinkedIn.com, menciones de DevOps como una habilidad aumentó 50 por ciento durante el mismo período.

Nuestra encuesta reveló la misma tendencia. La mitad de los encuestados de más de 4.000 (en más de 90 países) dijeron que sus empresas tienen en cuenta las habilidades DevOps la hora de contratar.

¿Cuáles son las habilidades DevOps?

Los encuestados identificaron las tres principales áreas de habilidades para el personal DevOps:

  • Codificación o scripting
  • Reingeniería de procesos
  • Comunicarse y colaborar con los demás

Estas habilidades, apuntan a un creciente reconocimiento de que la complejidad del software de hoy en día se encuentra  en la creación y también en garantizar que el nuevo software funciona a través de un conjunto diverso de sistemas operativos y plataformas.

Del mismo modo, actualmente las pruebas e instalación se hacen con mucha más frecuencia. Es decir, pueden ser más frecuentes: si los desarrolladores se comunican rápido y regularmente con el equipo de operaciones, y si los operadores aportan su conocimiento del entorno de producción para el diseño de las pruebas y puesta en producción.

La discusión de lo que distingue a los ingenieros DevOps sobrepasa lo que se ha escrito en blogs y foros, y ocurre cuando los técnicos se reúnen.

Hay un montón de cosas para hablar, por ejemplo, cómo impulsar la codificación -no sólo el código- por encima del muro en las operaciones. Werner Vogels, el CTO de Amazon, dijo en una entrevista que cuando los desarrolladores asumen más responsabilidad de las operaciones, mejora la tecnología y el servicio a los clientes.

«El modelo tradicional trata de pasar el software por encima de la pared que separa el desarrollo de las operaciones y una vez del otro lado, olvidarse de él. No en Amazon. Usted lo construye, Usted lo corre. Esto hace que los desarrolladores estén en contacto con la operación del día a día. También quedan en contacto día a día con el cliente».

Sobre el bucle de realimentación con el cliente, Vogels dijo, «es esencial para la mejora de la calidad del servicio.»

Desde hace mucho tiempo desarrollador y empresario rico Pelavin de Reactor8 también ve los beneficios de la cultura DevOps en términos de una mayor responsabilidad de todos:

«He visto a las organizaciones donde los ingenieros tienen beepers, por lo que ellos son advertidos por el beep si algo sale mal [en la instalación y ejecución]. Eso los empuja hacia el resto del ciclo de vida del software. Creo que es una gran idea».

Eso es un cambio real para entornos no-DevOps, en los que los desarrolladores impactan los últimos cambios del día y se van a sus casas… o a la sala de ping-pong.

Y al final ¿qué es un DevOps? ¿Y quién los contrata?

No hay una carrera formal para convertirse en un ingeniero de DevOps. Ellos suelen ser los desarrolladores que se interesen en el despliegue de sus aplicaciones y en la red de operaciones; o los administradores de sistemas que tienen una pasión por secuencias de comandos y codificación e intervienen pasar a la parte de desarrollo, donde pueden mejorar la planificación de la prueba e instalación. De cualquier manera, se trata de personas que han empujado más allá de sus áreas de competencia definidas y que tienen una visión más integral de sus entornos técnicos.

Los DevOps siguen siendo un grupo muy pequeño, por lo que es razonable que pocas compañías tengan ese cargo. Kelsey Hightower, que dirige las operaciones aquí en Puppet Labs, describe a estas personas como las «Fuerzas Especiales» en una organización.

«El ingeniero DevOps encapsula profundidad de conocimientos y años de experiencia práctica», dijo Kelsey. «Está probado batalla. Es la persona que combina las habilidades del analista de negocios con las plantillas técnicas para construir la solución – además de que conoce bien el negocio, y puede ver cómo cualquier problema afecta a toda la empresa «.

Si DevOps se entiende como una forma de pensar, puede resultar confuso. Por suerte, muchas personas han probado definiciones como para permitirnos hacer una lista de los atributos principales del DevOps:

  • Capacidad para utilizar una amplia variedad de tecnologías y herramientas de código abierto
  • Capacidad para codificar y hacer scripts
  • La experiencia sistemas y operaciones de TI
  • Comodidad con las frecuentes pruebas de código incrementales e instalaciones
  • Buen conocimiento de las herramientas de automatización
  • Capacidad de gestión de datos
  • Un fuerte enfoque en los resultados del negocio
  • Confort con la colaboración, la comunicación abierta y pasar a través de fronteras funcionales

Incluso con un amplio acuerdo acerca de los atributos fundamentales del DevOps, nace la controversia alrededor  del término «ingeniero DevOps.» Algunos dicen que el término en sí mismo contradice los valores DevOps.

Jez Humble, el co-autor de Continuous Delivery, señala que sólo con llamar a alguien un ingeniero DevOps puede crear un tercer compartimento además de dev y ops«… claramente es una forma inadecuada (e irónica) para tratar de resolver estos problemas.»

Dice que DevOps propone «estrategias para crear una mejor colaboración entre los compartimentos funcionales, o acabar con esos compartimentos funcionales en conjunto y la creación de equipos multifuncionales (o alguna combinación de estos métodos).» Al final, Humble cede terreno al decir que está bien llamar a la gente haciendo DevOps por este término, si Usted quiere.

Para convertirse en un ingeniero DevOps: ¿Qué se necesita?

¿Se ha convencido de que DevOps es su futuro? Si es así, querrá empezar a ampliar sus habilidades y experiencia para competir por estos nuevos puestos de trabajo.

Por un lado, está bien reforzar sus habilidades de codificación, familiarizarse con las herramientas de automatización, pero también buscar proyectos y nuevas funciones que permitan ejercitar las habilidades «accesibles» que se encuentran en la esencia del DevOps. Además encontrar oportunidades para colaborar dentro y fuera de su equipo. Tal vez, ayudar en  su empresa para pasar a un régimen de pruebas rápidas y alto ritmo de instalación. Y estar abierto a escuchar las ideas de los demás. Tenga en cuenta que DevOps se trata tanto de hacer las cosas de una manera particular, y más acerca de cómo mover el negocio hacia adelante y darle una ventaja tecnológica más fuerte.

Más información sobre DevOps:

How Do You Make $100K in IT? Look to the DevOps Shops
Bridging the Two Worlds: IT and Networking
Hiring for the DevOps Toolchain: The Need for Generalists
DevOps Resources


IFTTT vinculando tus aplicaciones en la nube y mas

ifttt-product-thumbBastante tiempo atrás, creo que en los inicios del servicio, El General me había hablado de IFTTT y sus posibilidades, pero recuerdo haberlo visto por arriba sin entender mucho cuál era su utilidad, a pesar de que El General me explicó.

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
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:

ifttt services

  • 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.

Raspberry Pi como cliente torrent

Hace ya tiempo pre-compré un Raspberry Pi, tuve mi plazo de espera (como de 3 meses) y lo recibí hace casi 6 meses atrás en casa; pero desde aquel momento no me hice un tiempo para atender a este hermoso aparatito. Pero esta semana comencé a armarlo en forma decidida hasta crear un cliente Bittorrent y podes descargar archivos y compartirlos.

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



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


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 del archivo creado al /data/torrent/info

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

Nota: Si se arma al revés, dejando en /etc/transmission-daemon un symlink hacia el archivo original en /data/torrent/info el sistema lo sobre-escribirá cada vez con información por defecto (parece ser algo hardcoded).

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.

Ubuntu Finder, cómo encontrar la ami que necesitas

UbuntuFinder es una herramienta web creada por Gustavo Niemeyer que permite buscar la ami (Amazon Machine Image) Ubuntu que cumple con los parámetros que deseamos. Así, podemos configurar UbuntuFinder para buscar una máquina de 4 cores con 34G RAM y Ubuntu 12.04 y UbuntuFinder nos va a sugerir la instancia tipo m2.2xlarge con la imagen ami-0cdf4965

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: