Notificaciones de mails Prioritarios de Gmail en nuestro escritorio

GMail

GMail

En estos días GMail empezó a implementar la Priority Inbox, o Prioritarios en su versión en castellano. No es nada demasiado novedoso, en realidad es una etiqueta que define a un mensaje como prioritario. Lo más interesante es que Gmail no solamente te puede mostrar por separado los mails con prioridad de los otros, sino que nos promete ir “aprendiendo” a determinar cuáles son prioritarios y cuáles no.

En estos días estuve probando el feature y me viene bien. Yo recibo muchos mails por día, la mayoría de distintas listas de correo. Y como soy muy obsesivo, cada vez que tengo un mensaje nuevo voy a ver de qué se trata y “marcarlo como leído”. Este feature me permite perocuparme solamente por los prioritarios y dejar los menos importantes (como los de las listas) para más tarde.

Hoy pensé: “qué bueno estaría tener una aplicación que me notifique solamente de los mails importantes”. Ya existen varios notifiers para Gmail, tanto de Google o de terceros, para Firefox o para el Desktop. Pero supongo que todavía no habrán implementado esta posibilidad de solamente avisarte de los mensajes prioritarios. Así que lo que hice fue hacerlo en Python que es muuuy fácil.

En su versión simplificada, ver si hay mails “Importantes” y notificarlo es tan sencillo como esto:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import imaplib
import pynotify
from email.header import decode_header
from email.parser import Parser

host = ‘imap.gmail.com’
port = 993
username = ‘usuario@gmail.com’
password = ‘passwordsupersecreto’

def get_header (msg, header):
        """Gets a header from a message"""
        header = decode_header(msg.get(header))
        if (header[0][1]):
            return unicode(header[0][0], header[0][1]).encode(‘utf8′)
        else:
            return header[0][0]

if not pynotify.init("GMail Important Messages"):
    print "Failed to initialize pynotify"
    sys.exit(1)

client =  imaplib.IMAP4_SSL(host, port)
if not client.login(username, password):
    print "Failed to login"
    sys.exit(1)

status, data = client.select(‘[Gmail]/Important’)
if status != ‘OK’:
    print "Failed to select Important label"
    sys.exit(1)

status, data = client.search(None, ‘(UNSEEN)’)
if status == ‘OK’ and data[0] != :
    for msg_id in sorted(data[0].split()):
        if msg_id != :
            status, data = client.fetch(msg_id, ‘(RFC822)’)
            if status == ‘OK’:
                msg = Parser().parsestr(data[0][1])
                pynotify.Notification(get_header(msg, ‘From’), \
                                       get_header(msg, ‘Subject’)).show()
            else:
                print "Failed to fetch message #%s" % str(msg_id)

Ese código lo que hace es inicializar pynotify, conectarse al servidor IMAP de GMail usando imaplib, autenticarse con el user y password provisto, seleccionar la etiqueta “[Gmail]/Important” y ver si hay mensajes sin leer. En caso de que haya itera sobre ellos, obtiene su contenido (para sacar el remitente y el asunto) y lanza un mensaje de notificación.

Para convertir eso en una aplicación básicamente hace falta meterlo en un while y corregir un detalle que es que el fetch del mensaje lo marca como leído (y eso no es algo que queramos en un simple notificador), así que hay que volver a marcarlo como no leído. Eso y algunos toques cosméticos es lo que hice en el script completo.

Por supuesto se trata solo de una prueba de concepto y a una aplicación completamente funcional deberían hacersele algunas correcciones más. Pero creo que es una idea divertida como para que otros puedan hacer algo mejor.

Backups con tar + rsync + rotación

En estos días tuve que configurar unos backups para un cliente. Algo bastante sencillo. Tenía dos servidores y necesitaba hacer backups de distintas cosas en cada equipo y copiarlos al otro. Por supuesto, la herramienta clave para esto es rsync. Googleando un poco vi que existe esta página donde se puede ver cómo generar snapshots incrementales automáticos usando hard links y rsync. Realmente es una solución muy interesante, pero a mí no me terminaba de convencer porque yo quería tener archivos comprimidos que fueran rotando.

Por lo tanto lo que hice fue, seguramente, reinventar la rueda una vez más. Hice una pequeña librería en BASH que luego reutilicé en los distintos scripts de backup que hice. La clave aquí es la función “create_archive” que toma un path, un nombre de archivo base y una lista de archivos, y se ocupa de ir al path, ver todos los archivos que haya con ese patrón de nombre básico, rotarlos y generar un nuevo tar.gz. Después agregué un par de funciones más que me venían bien, “log” para registrar todo lo que pasaba en un archivo, “mail_notification” para mandarme mails y “sync_backup_servers” para ejecutar rsync.

El código:

#!/bin/bash
CONF_FILE="/home/sysbackup/scripts/backup.conf"
if [ -f $CONF_FILE ]; then
    . $CONF_FILE
else
    echo "Configuration file $CONF_FILE not found"
    exit 1
fi

RM_BIN="/bin/rm"
TAR_BIN="/bin/tar"
MAIL_BIN="/bin/mail"
RSYNC_BIN="/usr/bin/rsync"

function log
{
    echo "`date`: $*" >> $LOG_FILE
}

function mail_notification
{
    subject="$1"
    message="$2"

    if [ -z "$subject" ]; then
        subject="Backup Notification"
    fi

    if [ -z "$NOTIFICATIONS_MAILS" ]; then
        log "mail_notification: empty recipients list"
        return 1
    fi

    if [ -z "$message" ]; then
        log "mail_notification: empty message"
        return 1
    fi

    sysdata="Date: `date`\nHost: `hostname`"

    echo -e "$message\n\n$sysdata" | $MAIL_BIN -s "$subject" "$NOTIFICATIONS_MAILS"
}

function sync_backup_servers
{
    log "Running rsync from $LOCAL_DIR to $REMOTE_DIR as $RSYNC_USER"
    su -c "$RSYNC_BIN -aq –delete -e ssh $LOCAL_DIR/ $REMOTE_DIR/ 2>> $LOG_FILE" $RSYNC_USER
    if [ $? -eq 0 ]; then
        log "Syncronization complete successfuly"
    else
        log "Syncronization finished with errors"
    fi
}

function create_archive
{
    file_path="$1"
    file_name="$2"
    files="${*:3}"

    if [ -z $file_path ]; then
        echo "Missing file path"
        return 1
    fi

    if [ -z $file_name ]; then
        echo "Missing file name"
        return 1
    fi

    if [ -z $files ]; then
        echo "Missing file list"
        return 1
    fi

    if [ -z $MAX_BKP_FILES ]; then
        MAX_BKP_FILES=4
    fi

    archive_name="${file_name}_`date +%Y%m%d`.tar.gz"
    log "Preparing to create $archive_name archive"

    # Begin to Rotate files
    # Sort files by date and keep the latest ones
    # MAX_BKP_FILES will determine how many to store
    dir=`ls -t $file_path/${file_name}_*.tar.gz 2> /dev/null`
    if [ $? -eq 0 ]; then
        N=0
        for file in $dir; do
            if [ $N -lt $MAX_BKP_FILES ]; then
                let N++
            else
                log "Removing old file $file"
                $RM_BIN -f $file
            fi
        done
    else
        log "No other archive found on $file_path"
    fi

    log "Creating tar archive $file_path/$archive_name"
    $TAR_BIN zcf "$file_path/$archive_name" $files 2>> $LOG_FILE
}
 

Algunas consideraciones importantes.

Configuración

Al principio del script lo que hago es incluir un archivo de configuración con algunas variables básicas que voy a utilizar. Este archivo debería ser algo similar a esto:

#!/bin/bash
LOCAL_DIR="/home/sysbackup/backup/server1.domain.com"
REMOTE_DIR="sysbackup@server1.domain.com:/home/sysbackup/backup/server1.domain.com"
LOG_FILE="/var/log/sysbackup.log"
MAX_BKP_FILES=4
NOTIFICATIONS_MAILS="admin@email.com"
RSYNC_USER="sysbackup"
 

LOCAL_DIR es el directorio local base donde van a estar mis backups. REMOTE_DIR es el directorio equivalente en el otro servidor. Lo que hice fue crear un usuario “sysbackup” (un poco menos obvio que “backup”, pero también self-explanatory) en los dos servidores y generar llaves para que se puedan conectar por SSH entre los dos servidores. Luego en la /home de cada usuario creé una carpeta “backup” y adentro de ella una carpeta para cada host que iba a ser backupeado “server1.domain.com” y “server2.domain.com”.

LOG_FILE indica el archivo donde se van a guardar los logs del backup y MAX_BKP_FILES determina la cantidad máxima de archivos de backup que va a haber por cada elemento.

Rotación

Como dije, la función más importante es create_archive. La pensé para logs que se crean una vez por día (o cada más tiempo), por lo que si la quieren usar para rotar logs generados en intervalos de tiempo más cortos van a tener que modificarla. Lo que hace es generar un nombre de archivo con una raiz elegida por nosotros (digamos “db”) y la fecha actual (la función pone la fecha, pero si necesitan intervalos más cortos van a tener que poner fecha y hora). Luego hace un `ls -t` del directorio donde hay que generar el backup para ver si hay otros archivos que coincidan con el patrón del nombre correspondiente (por ejemplo, ‘db_*.tar.gz’). Si hay archivos, va a conservar los últimos 4 (en realidad la cantidad la determina MAX_BKP_FILES) y va a borrar los más viejos. Por último, va a generar el tar.gz con la lista de archivos que le hayamos pasado.

Ejemplo:

create_archive "$LOCAL_DIR/web" "web" "/var/www/html"
 

Va a generar con un archivo de nombre como “web_20100902.tar.gz” en la carpeta $LOCAL_DIR/web con todos los contenidos de /var/www/html.

Rsync

La función sync_backup_servers hace la sincronización entre los dos servidores usando rsync por SSH. Una cosa a tener en cuenta es que en mi caso, yo necesitaba que el script de backup corriera como root (para poder acceder a todos los archivos que había que backupear) pero quería que el rsync se ejecutara con el usuario sysbackup (para mayor seguridad). Por lo tanto la función usa “su -c sysbackup”. Si a uds. este enfoque no les sirve pueden poner en la función directamente:

$RSYNC_BIN -aq –delete -e ssh $LOCAL_DIR/ $REMOTE_DIR/ 2>> $LOG_FILE
 

Notificaciones por mail

Es muy útil poder tener notificaciones por mail, sobre todo cuando las cosas andan mal. El comando “mail” de Linux/Unix es muy útil para esto. La funcion mail_notification usa ese comando para mandar un mail con el mensaje que queramos y le agrega dos datos útiles: la fecha y el hostname desde el que se manda. En realidad son datos que siempre viajan en los headers del mail, pero a mí me parecía útil que estuvieran en el body.

Espero que les sirvan estos recursos. No son una solución completa y cerrada, sino herramientas que quizás les sirvan para implementar o al menos pensar cómo hacer sus propios sistemas de backup. Les recomiendo enfáticamente que lean este artículo sobre cómo generar backups con rsync porque explica muchas cosas fundamentales.

PET: Python Entre Todos, primera revista de Python

A esta altura ya es una noticia vieja, pero quizás alguno no se haya enterado de que la semana pasada salió publicada la revista PET: Python Entre Todos.

La revista es una producción colaborativa de la Comunidad PyAr, con artículos de muy alto nivel de distintos participantes de la lista y el esfuerzo especial de sus dos editores, Roberto Alsina y Emiliano Dalla Verde Marcozzi.

PET: Python Entre Todos Num. 1

PET: Python Entre Todos Num. 1

Los artículos incluidos en la revista son:

  • PET First Shot
  • Cómo contribuir a PET
  • PyAr, la historia
  • from gc import commonsense – Finish Him!
  • Concurrencia Indolora: el módulo processing
  • Introducción a Unit Testing con Python
  • Taint Mode en Python
  • Dinamismo Aplicado
  • Decorando Código (Parte 1)
  • Web2Py Para Todos
  • ¿Cómo Está Hecha Esta Revista?
  • Desafío PET
  • Un poco de xkcd

La publicación fue todo un éxito porque se dinfundió rápidamente por Internet con la ayuda de diversos medios: blogs, twitter, barrapunto, etc. En mi opinión esta buena recepción se debió dos factores clave: la calidad del contenido que es realmente muy alta y que gracias a las tecnologías de software libre utilizadas para la edición de la revista, la misma pudo ser publicada en múltiples formatos: HTML online, PDF en distintos layouts y para e-book readers en ePub y Mobi. A todos ellos se puede acceder en la página del primer número de la revista.

Además, al poco tiempo de publicada la revista, Roberto descubrió que PET es la primera revista de Python… en el mundo!. Esto animó a la comunidad a crear una versión en inglés para poder difundirla a un mayor público. Personalmente tuve la opotunidad de colaborar traduciendo dos artículos, “PyAr, la historia” de Facundo Batista y “¿Cómo Está Hecha Esta Revista?” de Roberto Alsina. De esta manera, si no puedo aportar con un artículo interesante, por lo menos puedo colaborar para que las cosas interesantes que escriben otros puedan llegar a un público más amplio.

Así que seguramente pronto estemos anunciando la versión en inglés del número 1 de PET. Y en el futuro, según entiendo, la idea es poder incorporar artículos de colaboradores internacionales en ambas versiones de la revista.

Una vueltita por las Charlas Abiertas de Python en La Tribu

Charlas Abiertas de Python en La Tribu

Hoy pude darme una vuelta, por primera vez, por las Charlas Abiertas de Python en La Tribu. Le robé un tiempo al estudio y me dirigí a Lambaré 873 junto a un amigo, a ver qué tal estaban esas charlas.

No esperaba encontrar grandes revelaciones porque la charla a la que iba era la de Introducción al Desarrollo Web I, a cargo de Alejandro Cura, y yo ya trabajo en el rubro hace algunos años. Sin embargo me interesaba verle las caras a algunos miembros de la comunidad por quienes tengo un gran respeto.

Me encontré con un ámbito muy amigable, lleno de gente deseosa de aprender. Me alegró mucho encontrar algunas personas “mayores” (por lo menos mayores al tipo de gente que uno suele conocer en este acotado segmento del mercado laboral), muy interesadas y participativas. La charla estuvo muy bien, era una introducción para quienes no tienen idea de en qué consiste hacer un sitio web (y preparatoria para la próxima charla que dará algunos conceptos básicos de Web2Py). Me pareció muy copado que se le diera un poco de bola al protocolo HTTP y cómo funciona, porque en mi experiencia laboral me he encontrado con desarrolladores que pueden manejar muy bien algunos lenguajes como PHP, Javascript o HTML pero no tienen idea de cómo llegan esas cosas “a la mesa” del browser.

Incluso me encontré aprendiendo una cosita de CSS que no sabía y era la posibilidad de incluir tipografías externas (que quisiera ver qué tan compatible es con la bosta de IE, pero que me resultó muy útil).

Me hubiera gustado quedarme a la charla siguiente del eminente Roberto Alsina, pero lamentablemente tenía que volver a la cueva a estudiar.

Felicito desde este humilde lugar el enorme trabajo que está realizando la comunidad PyAr organizando estas charlas que permiten acercar herramientas a la sociedad para conocer y apropiarse de las nuevas tecnologías asociadas a la informática e Internet.

Recalcular quota en Directadmin

Directadmin utiliza el sistema de quotas del sistema operativo para calcular el espacio que está siendo utilizado por cada usuario. A veces, por diversas circunstancias, puede ser que necesitemos recalcular estos datos. Particularmente, en estos días tuvimos un problema con el acceso a un dispositivo que generó problemas en la ejecución del comando repquota y cuando solucioné el problema, tuve que recalcular la quota de todos los usuarios del sistema. Me pareció que sería útil explicar cómo hacerlo, porque si bien es algo que está explicado en la Knowledge Base de Directadmin, allí está en inglés.

Para que el sistema recalcule las quotas, es decir, analice todo el filesystem verificando el uso del disco y cree, confirme o repare los archivos de quotas, necesitamos correr el comando quotacheck. Para ello necesitamos deshabilitar las quotas, chequear y volver a habilitarlas.

# /sbin/quotaoff -a
# /sbin/quotacheck -avugm
# /sbin/quotaon -a

Esto tomará algunos minutos (particularmente el proceso quotacheck). Luego de lo cual podemos esperar que Directadmin corra el tally y recalcule los valores para cada usuario, o podemos indicarle explícitamente que lo haga en este momento. Para ello debemos agregar la tarea del tally a la cola:

# echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

El tally se ejecutará cuando corra el proceso dataskq de Directadmin (que se ejecuta cada minuto). Podemos ver los logs de este proceso en /var/log/directadmin/system.log.

Pero si somos demasiado impacientes o queremos ver información de debug, podemos correr explícitamente el dataskq.

# /usr/local/directadmin/dataskq d10

Listo. Una vez que Directadmin re-procese todos los usuarios, los datos de consumo de disco de cada uno se habrá sincronizado con la información actual del sistema.