X.Org

Resumen

Un monitor ViewSonic VG2021wm y una placa de video nVidia GeForce 6500 dejan de entenderse espontáneamente en Linux Mint y el Xorg pasa a funcionar sólo en modo 640×480. ¿La solución? Deshabilitar el uso de EDID y configurar manualmente los datos del monitor en el xorg.conf.

Desarrollo

Ayer me sucedió algo muy raro. Hace varios meses vengo usando Linux Mint sin mayores inconvenientes en mi máqunia. Cuando ayer fui a encender la máquina (sin que mediara ningún cambio extraño, ningún update de los drivers de la placa de video ni ninguna instalación de software), el X iniciaba sesión solamente en resolución 640×480. Teniendo un monitor de 20″, cuya resolución óptima es de 1680×1050, se darán cuenta que la imagen era espantosa: no entraba nada en la pantalla.

Después de varias horas sin entender bien cuál era el problema, postear en el foro de Linux Mint sin respuesta, y buscar en Internet, me puse a revisar los logs del X y encontré que mencionaba errores para leer el EDID. Por ejemplo:

Unable to get display device CRT-0's EDID; cannot compute DPI

¿Qué es el EDID? Extended display identification data, es una estructura de datos que ofrecen los dispositivos de visualización (ej.: los monitores) y que permiten, por ejemplo, a una placa de video conocer sus cualidades. De esta manera, la operatoria normal habría sido que mi placa de video obtuviera los datos del monitor de su EDID y conforme a ello me diera las opciones adecuadas para configurar mi pantalla. Más concretamente, el Xorg lo que hace es obtener a través de la placa de video, entre otros datos, la frecuencia horizontal (HorizSync) y la tasa de refresco vertical (VertRefresh) (para más información sobre qué es cada una de estas variables, pueden consultar esta página).

La cuestión es que de buenas a primeras, el Xorg dejó de poder leer el EDID de mi monitor y por eso levantaba con los datos default para un monitor CRT (por cierto, entre las cosas que aprendí ayer, el driver de nVidia le pone de nombre “CRT” a cualquier dispositivo que se conecte al puerto VGA, no tiene nada que ver con lo que efectivamente esté conectado). Eso quiere decir que tomaba un HorizSync y un VertRefresh que solamente eran compatibles con una resolución de 640×480@50 Hz.

¿Por qué pasa esto? La verdad, no lo sé a ciencia cierta. Encontré a este usuario que le pasó lo mismo, y levantando de un Live CD se dio cuenta que no era un problema de configuración, entonces lo resolvió cambiando su cable DVI por un cable VGA con un adaptador. Yo comprobé lo mismo, el problema no estaba en la configuración de mi Xorg, pero como yo sólo tenía cable VGA, probé cambiandolo por otro cable VGA, pero no hizo diferencia. Entonces seguí buscando y llegué a este otro post donde alguien lo resolvió sencillamente cambiando los HorizSync y VertRefresh en el xorg.conf.

Me bajé el manual de mi monitor (ViewSonic VG2021wm) y busqué los datos correspondientes (HorizSync y VertRefresh), y los puse en el xorg.conf. Este tipo de configuración manual del Xorg es lo que viene a evitar el EDID. El tema es que al reinicar el X, el Xorg seguía intentando leer el EDID y como no podía, seguía dando el mismo problema.

Finalmente, y casi por casualidad, me di cuenta que el nvidia-xconfig tenía unos parámetros para que configurara el xorg.conf indicándole al Xorg ignorar el EDID. Entonces ejecuté el siguiente comando:

sudo nvidia-xconfig --no-use-edid --no-use-edid-dpi --no-use-edid-freqs --mode=1680x1050

Y con eso me quedó generado el siguiente xorg.conf

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 280.13  (pbuilder@cake)  Mon Aug  8 15:37:15 UTC 2011

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"

    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "LCD-1"
    HorizSync 24.0 - 82.0
    VertRefresh 50.0 - 85.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
EndSection
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option "UseEdidFreqs" "False"
    Option "UseEdid" "False"
    Option "UseEdidDpi" "False"
    SubSection     "Display"
        Depth       24
        Modes      "1680x1050" "1680x1050_60.00"
    EndSubSection
EndSection

Si ven los parámetros resaltados, en la sección Monitor defino el HorizSync y el VertRefresh. Y luego en la sección Screen, los parámetros que evitan que se use el EDID (anteriormente existía una opción IgnoreEDID que fue deprecada, ver los comentarios de este artículo).

Una vez modificado el xorg.conf solamente tuve que reiniciar el X y volvió a la normalidad. Después tuve que pelearme un rato con GDM para volver a configurar la resolución adecuada (1680×1050@60 Hz) utilizando nvidia-settings. Pero esto puede tener que ver con todas las vueltas que dí antes de encontrar la solución.

Cuánto hace que no actualizo este blog!! Hoy estuve jugando un poco con Python y me puse a hacer un pequeño script que supongo que a otros les podrá servir como base para hacer algo más interesante. Precisamente, tengo planes para hacer algo más interesante, pero como recién están en veremos, les voy pasando esta pequeña base a ver si alguien me gana de mano

Como muchos sabrán, Apache (y otros web servers) tiene un módulo llamado mod_status que nos permite ver en tiempo real el estado del servidor (los requests que se están procesando, el uso del CPU, el estado de las conexiones, etc.). Esta información puede ser muy útil para hacer diagnósticos cuando está habiendo algún tipo de problema, para hacer monitoreo, etc. El módulo nos muestra una página web con la información y tiene dos interfaces: una está pensada para ser vista por seres humanos y otra para ser consultada por scripts (para ver esta segunda sólo hace falta pasarle el parámetro “?auto” en la URL). El problema es que esta segunda interfaz no nos muestra a qué dominios (virtual hosts) están dirigidos los requests que se están procesando (o si hay forma de que lo muestre yo no la encontré). Entonces me puse a hacer un sencillo script en Python para parsear la página “para seres humanos”.

Por suerte Python nos ofrece muchas herramientas muy útiles para este tipo de cosas, así que no me tuve que esforzar demasiado. En este caso utilicé urllib2 para acceder a la página de mod_status y BeautifulSoup para parsear el HTML. Por si no lo conocen, BeautifulSoup es un muy poderoso parser para XML/HTML hecho en Python. No viene con el código fuente sino que hay que instalarlo, pero hacerlo es muy fácil:

En Debian/Ubuntu:

apt-get install python-beautifulsoup

En CentOS/RedHat:

yum install python-BeautifulSoup

Con easy_install:

easy_install BeautifulSoup

El código tiene una clase Status que es la que hace la magia y una función main() que utiliza la clase para parsear una URL e imprimir algunos datos a modo de ejemplo.

La forma de uso es:

python status.py "http://localhost/server-status"

Y en este caso la salida del script es algo así:

SERVER INFORMATION
==================
Server Version: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8e-fips-rhel5 DAV/2
Server Built: May 26 2011 15:14:47
Current Time: Sunday, 31-Jul-2011 00:53:59 ART
Restart Time: Saturday, 30-Jul-2011 12:07:12 ART
Parent Server Generation: 0
Server uptime:  12 hours 46 minutes 47 seconds
Total accesses: 407813 - Total Traffic: 3.7 GB
CPU Usage: u2.05 s3.23 cu52 cs0 - .125% CPU load
8.86 requests/sec - 85.0 kB/second - 9.6 kB/request
10 requests currently being processed, 8 idle workers
REQUESTS BY VHOST
=================
9: www.tail-f.com.ar
5: www.otro-dominio.com.ar
4: www.not-a-domain.com.ar
3: www.algunlado.com.ar
2: subdominio.dominio.com.ar
1: www.pepe.com.ar
1: www.no-votes-a-macri.com.ar
1: www.asd.com.ar
1: localhost

Obviamente esto no es una aplicación funcional, sino un ejemplo que espero que les sirva para hacer algo más copado. Yo seguiré jugando y si hago algo un poco más interesante, ya se los mostraré.

Festival Latinoamericano de Software Libre

Como indica su sitio web, su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo. A tal fin, las diversas comunidades locales de software libre (en cada país/ciudad/localidad), organizan simultáneamente eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

Particularmente, nuestro amigo Exos estará participando en el evento a realizarse en Lanús, organizado por LANUX (Grupo de Usuarios de Linux de Lanús). Allí el evento será este sábado 9 de abril de 2011 de 10 a 16:30 horas en la Universidad Argentina “John. F. Kennedy” Av. Hipólito Yrigoyen 4651 -Partido de Lanús.

Este tipo de encuentros son una excelente oportunidad tanto para usuarios avanzados de Linux que quieran encontrarse con otros entusiastas, como para usuarios básicos de computadoras que no conozcan nada sobre Software Libre y quieran conocer de qué se trata de la mano de usuarios experimentados, con buena onda y dispuestos a ayudar.

Mapa, registración y más información en el sitio de FLiSoL en LANUX.

Links

• Sitio web de FLiSoL 2011
• Sitio web de FLiSoL 2011 en LANUX
• Sitio oficial de LANUX
• Nota sobre FLiSoL en Periódico Tribuna por Exos

Apache

En esta oportunidad voy a explicar cómo instalar Nginx como proxy reverso en un servidor de hosting con Directadmin.

¿Qué es un proxy reverso?

Un proxy reverso en este caso es, básicamente, un servidor web que se interpone como una capa entre el cliente y un backend, de manera de optimizar la conexión. Típicamente el proxy es un servidor muy liviano que funciona de frontend, atiende las peticiones de los clientes HTTP y deriva el procesamiento en un backend que podría ser un servidor Apache. Según la configuración que apliquemos, un proxy nos permite introducir mayor seguridad en nuestra red, hacer balanceo de carga, hacer cache, etc.

También optimiza el manejo de memoria. Pensemos que Apache lanza un thread o proceso por cada nuevo cliente, el cual se cierra recién cuando termina la transferencia de datos. Si el cliente tiene una conexión lenta, por más que Apache funcione rápido, el proceso queda corriendo hasta que se terminen de enviar los datos. Un frontend liviano como Nginx nos permite que el proceso que espere al cliente sea mucho más liviano que uno de Apache.

Por último, como indican en sysadmin.es, un proxy Nginx nos sirve para prevenir ataques de denegación de servicio utilizando slowloris.

Un proxy reverso en un servidor de hosting

Nginx

Los proxies se suelen utilizar en arquitecturas para servir sitios de alta demanda. En esos casos es común, por ejemplo, hacer que Apache sirva el contenido dinámico y un servidor más liviano (lighttpd o nginx) sirva contenido estático. Pero en un servidor de hosting esto no es tan sencillo, pues al alojarse varios sitios en un mismo equipo nuestra configuración debe ser lo más genérica posible para que sirva a la mayor parte de nuestros clientes. Como veremos, podemos definir algún tipo de cache, pero también tiene que ser bastante genérico para no causar problemas. Además tenemos que pensar en la integración con el panel de control que estemos usando. Yo uso Directadmin y este panel no tiene (aún) una integración nativa con otro web server que no sea Apache.

Nginx + Apache + Directadmin

La opción que les presento es para utilizar Nginx como proxy reverso, manejando las conexiones de los clientes y haciendo un muy básico cache del contenido estático. La guía está pensada para CentOS, pero en otros sistemas operativos no debería ser muy distinto.

Primero instalamos Nginx. El proceso es muy sencillo.

# cd /usr/src
# wget http://nginx.org/download/nginx-0.7.67.tar.gz
# tar zxvf nginx-0.7.67.tar.gz
# cd nginx-0.7.67
# ./configure --prefix=/usr \
              --conf-path=/etc/nginx/nginx.conf \
              --error-log-path=/var/log/nginx/error.log \
              --http-log-path=/var/log/nginx/access.log \
              --pid-path=/var/run/nginx/nginx.pid \
              --lock-path=/var/run/nginx/nginx.lock \
              --with-http_stub_status_module \
              --with-openssl=/usr/lib/openssl
# make && make install

Creamos el directorio para guardar el cache de contenido estático:

# mkdir -p /var/tmp/nginx
# chown apache:apache /var/tmp/nginx

Lo más importante es configurar Nginx. Para ello modificaremos /etc/nginx/nginx.conf para que quede algo similar a esto:

Importante: reemplazar __SERVER_IP__ por la IP del servidor y __SERVER_HOSTNAME__ por el nombre del servidor.

user  apache;
worker_processes  1;

events {
    worker_connections  8192;
}

http {
    server_tokens off;

    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    tcp_nopush     on;

    keepalive_timeout  75 20;

    gzip  on;

    server_names_hash_bucket_size 64;
    reset_timedout_connection on;

    client_max_body_size 100m;

    # Main cache data
    proxy_cache_path  /var/tmp/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=500m;
    proxy_temp_path /var/tmp/nginx/proxy;
    proxy_connect_timeout 30;
    proxy_read_timeout 120;
    proxy_send_timeout 120;
    proxy_cache_key "$scheme$host$request_uri";

    server {
        listen       __SERVER_IP__:81;
        server_name  __SERVER_HOSTNAME__ _;

        #charset koi8-r;
        charset off;

        access_log off;
        #access_log  /var/log/nginx/access.log  main;

        # Main reverse proxy for most requests
        location / {
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                    proxy_pass              http://__SERVER_IP__;    # apache here

                    client_max_body_size       16m;
                    client_body_buffer_size    128k;

                    #proxy_buffering     off;
                    proxy_buffering     on;  

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         120;
                    proxy_buffer_size          8k;
                    proxy_buffers              32 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;

                    error_page              502 503 /50x.html;
        }

        # Proxy cache for static files
        location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                    proxy_pass              http://__SERVER_IP__;    # apache here

                    client_max_body_size       16m;
                    client_body_buffer_size    128k;

                    #proxy_buffering     off;
                    proxy_buffering     on;  

                    proxy_connect_timeout      90;
                    proxy_send_timeout         90;
                    proxy_read_timeout         120;
                    proxy_buffer_size          8k;
                    proxy_buffers              32 32k;
                    proxy_busy_buffers_size    64k;
                    proxy_temp_file_write_size 64k;

                    # Proxy cache data
                    proxy_cache_valid 200 120m;
                    expires 864000;
                    proxy_cache staticfilecache;

                    error_page              502 503 /50x.html;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /var/www/html;
        }

    }

}

Por supuesto esta es una configuración básica que debería adaptarse al caso específico. Es importante notar lo siguiente:

• Nginx escucha en el puerto 81 y Apache en el 80. Esto es importante para no tener que hacer cambios en la configuración de Directadmin.
• Se definen 3 Locations. Las primeras dos son proxies que le pasan requests al Apache esuchando en el puerto 80. La segunda aplica solamente a los requests de archivos estáticos y hace un cache en /var/tmp/nginx. Este cache es manejado siguiendo los headers HTTP correspondientes.

Ahora necesitamos instalar un módulo de Apache, mod_rpaf, para poder usar el header X-Real-IP.

# cd /usr/src
# wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
# tar zxvf mod_rpaf-0.6.tar.gz
# cd mod_rpaf-0.6
# apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

Y luego agregamos esto al httpd.conf

LoadModule rpaf_module /usr/lib/apache/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 __SERVER_IP__
RPAFheader X-Forwarded-For

Reemplazando __SERVER_IP__ por la IP del servidor.

También vamos a necesitar un script para el init del Nginx. Como no encontré uno hecho, hice este:

#!/bin/bash
#
# Name: NginX, tsj5j
#
# Function:     Start up NginX
#
# chkconfig: - 85 15
# description: NginX starter

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

prog="nginx"
nginx=/usr/sbin/nginx

start () {
        echo -n $"Starting $prog: "
        $nginx
        RETVAL=$?
        return $RETVAL
}

stop () {
        echo -n $"Stopping $prog: "
        killproc $nginx
        RETVAL=$?
        return $RETVAL
}

reload () {
        echo -n $"Reloading $prog: "
        killproc $nginx -HUP
        RETVAL=$?
        return $RETVAL
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        stop
        sleep 1
        start
        ;;
  reload)
        reload
        ;;
  graceful)
        reload
        ;;
esac

exit $RETVAL;

Una vez ubicado ese contenido en un archivo /etc/init.d/nginx lo habilitamos

# chkconfig --add nginx
# chkconfig nginx on
# service nginx start

Y nos falta una única cosa. Tenemos Apache corriendo en el puerto 80 y Nginx en el 81. ¿Cómo hacemos que Nginx atienda las peticiones de nuestros clientes? Creamos una ruta en iptables para que redirija el tráfico del puerto 81 al 80:

# iptables -t nat -A PREROUTING -p tcp -s ! __SERVER_IP__ --dport 80 -j REDIRECT --to-ports 81
# service iptables save

Reemplazando __SERVER_IP__ por la IP del servidor.

Y listo, ahora nuestro Nginx va a recibir todo el tráfico HTTP y negociar con el Apache para devolverlo a los clientes.

Verificar que atienda Nginx

Comprobar que Nginx esté atendiendo las peticiones en el puerto 80 es muy sencillo de hacer con curl. Por ejemplo, probándolo contra la URL de este blog.

# curl -I http://www.tail-f.com.ar
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 18 Sep 2010 04:09:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Cookie,Accept-Encoding,User-Agent
X-Pingback: http://www.tail-f.com.ar/xmlrpc.php
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: no-cache

Como vemos el servidor que atiende es Nginx.

Referencias:

• Sitio de Nginx
• Sitio de mod_rpaf
• HOWTO: Using Nginx – best practices!

PET: English Translation

Los artículos de este número son:

• PET First Shot
• How you can help PET
• PyAr, The History
• from gc import commonsense – Finish Him!
• Painless Concurrency: The multiprocessing Module
• Introduction to Unit Testing with Python
• Taint Mode in Python
• Applied Dynamism
• Decorating code (Part 1)
• Web2Py for Everybody
• How is this magazine made?
• PET Challenge
• A Bit of xkcd

Como también ya les había adelantado, en este número tuve oportunidad de participar traduciendo dos artículos. PyAr, The History de Facundo Batista y How is this magazine made? de Roberto Alsina.

Además, aprovechando la ampliación del público de la revista, se ha agregado la posibilidad de hacer donaciones para la comunidad PyAr, de manera de solventar futuras actividades como impresiones del tutorial de Python, compra de materiales, charlas, etc.

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:

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.

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:

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:

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:

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:

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.

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

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.

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.

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.