PyPy without the GIL – Armin Rigo:
PyPy has a version without the Global Interpreter Lock (GIL). It can run multiple threads concurrently. But the real benefit is that you have other, new ways of using all your cores. In this talk I will describe how it is possible (STM) and then focus on some of these new opportunities, e.g. show how we used multiple cores in a single really big program without adding thread locks everywhere.

Python Profiling – Amjith Ramanujam:
This talk will give a tour of different profiling techniques available for Python applications. We’ll cover specific modules in Python for doing function profiling and line level profiling. We’ll show the short comings of such mechanisms in production and discuss how to do sampled profiling of specific functions. We’ll finish with statistical profilers that use thread stack interrogation.

Making Apache suck less for hosting Python web applications – Graham Dumpleton:
It is not hard to find developers who will tell you that Apache sucks for running Python web applications. Is there a valid basis to such claims or have they simply been misguided by the views of others? This talk will endeavor to shine a light on the realities of and limitations in working with Apache, as well as the challenges in implementing the mod_wsgi module for Apache.

Using futures for async GUI programming in Python 3.3 – Dino Viehland:
In Python 3.2 a new feature was added for concurrent programming – futures. In Python 3.3 generators have been extended to allow returning from a generator with a value. In this talk we’ll show how these features can be combined to create a rich and easy to use asynchronous programming model which can be used for creating highly responsive GUI applications or easy async programming.

Kivy: Building GUI and Mobile apps with Python – Mathieu Virbel / Thomas Hansen:
This talk will introduce the Kivy project (http://kivy.org). Kivy’s mission is to make building graphical user interfaces on any device fun, efficient, and pythonic.
The talk will focus on giving attendees an overview of how they can use kivy to build exiting UIs and mobile apps.

Make More Responsive Web Applications with SocketIO and gevent – Luke Sneeringer:
An explanation of how to implement a socket.io server in Python to serve websocket requests from browsers.

El resto de los videos del evento, acá: http://pyvideo.org/category/33/pycon-us-2013

Dejo en este post el mío, no sin un dejo de “vergüencita”, je… (encima todavía no lo vi):

Cualquier duda me pueden consultar o comentar este mismo post. Espero próximamente escribir más en profundidad de ciertos aspectos que me quedaron afuera de la charla.

¡Saludos!

Terminó la PyCon Argentina 2012, y con ella vienen semanas menos movidas (espero). Este post es para agradecer a la organización, Mariano, Juan BC, y a todos aquellos que concurrieron y compartieron conmigo este evento que tanto nos gusta a los fanáticos de este lenguaje de programación.

Además, tuve el placer de dar una charla introductoria del protocolo SPDY, que pretende reemplazar a HTTP 1.1, y que muy probablemente ya estés usando sin darte cuenta.

En definitiva, los slides de mi charla, “Introducción a SPDY, ¿futuro HTTP 2.0?” se pueden ver más abajo en esta página, y también se pueden descargar en formato ODP y PDF.

En cuanto tenga el video, lo pondré a disposición también.

¡Muchas Gracias PyConAr!

De ahí en adelante (dado que el desarrollo es abierto a la discusión en general) me dediqué a profundizar en él, entender sus ventajas (lo cual implica entender algunas cosas feas de HTTP 1.1 y la Web de hoy en día), limitaciones, y cosas que faltan implementar. Me apasionó el tema, tanto es así que lo propuse como tema de Tesis para mis estudios y hasta ahora vengo bien (bien con las promesas a mi Director, claro está ).

Mi idea era con este post abrir una serie de artículos para documentar lo que voy aprendiendo sobre este protocolo, que cada vez tiene más hype en la industria, tanto que Twitter y Google ya lo implementan en sus servidores (Facebook está en camino), mientras que Chrome/Chromium y Firefox (Opera se está sumando) también lo usan si está disponible.

Personalmente me puse a probarlo y a tratar de implementarlo usando Python, forkeando un proyecto que ya existía y arreglando los problemas más obvios que encontré. Todavía tengo todo el código “atado con alambre”, no bien testeado, y no estoy seguro si funciona del todo (jua!), pero de ahora en más voy a tratar de mejorarlo y mantenerlo mientras pueda, además de dejar algún rastro por aquí y por mi trabajo de investigación formal.

En resumen, el IETF draft de SPDY está disponible acá; tanto parece estar movilizando este protocolo, que el HTTPbis Working Group, encargado de definir un futuro HTTP 2.0, se está moviendo desde hace un tiempo para discutir las propuestas de SPDY. Y esto recién empieza…

Les dejo un video del último Google IO 2012 que es un excelente acercamiento técnico al tema:

Saludos

Pero lo más común es que suceda todo lo contrario. Mi router TP-Link TL-WR941ND, apenas lo compré, le actualicé el firmware oficial, y de ahí en más, a los dos o tres días de estar prendido, mágicamente “se cae”, dejando de responder, acudiendo obligatoriamente a apagar y encenderlo nuevamente. Ni hablar de actualizaciones posteriores, ni funcionalidades “copadas”. Casi que me sentí estafado; siendo previo poseedor de un mítico Linksys WRT54G, lo cambié por el TP-Link que es de norma 802.11N, por ende prometía más velocidad y alcance en mi red.

Pasaron unos meses, hasta que en el FLISOL Luján de este año, Efraim me instaló en el Linksys un firmware libre, basado en Linux, llamado DD-WRT que funciona en muchísimos modelos de Access Points/Routers (más de 200 según la página, aunque seguro son más). De antemano sabía de la existencia de estos proyectos/distros de Linux, aunque ignoraba lo bien logrado que estaba y las muchísimas capacidades que le agregaba automáticamente al tenerlo instalado.

Es por todo eso que tenía pendiente instalar DD-WRT en mi TP-Link para liberarlo… hasta hoy: migración exitosa.

Puedo comentar que:

• El proceso de instalación tiene bastantes particularidades, dependiendo mucho del dispositivo y de la versión del hardware que se tiene; sí, dentro de un mismo dispositivo, hay como diferentes “releases” o versiones del hardware (1.0, 2.0, 3.0…), donde el fabricante agrega/saca características, y puede influir tranquilamente en la versión del firmware a instalar.
• Por lo anterior, sugiero encarecidamente leer toda la documentación, foros y wiki disponible, además de tomar todas las precauciones del caso, ya que un error se puede pagar tirando el router al tacho de basura.
• Yendo más a mi situación particular, el router TL-WR941ND figura en el Router Database del proyecto, y dice que funciona con la versión 15778 del firmware dd-wrt (que entre otras cosas, ¡parece ser del 2010!). Además está dentro de la página de dispositivos con hardware Atheros soportado.
• Yo tengo la versión 3.6 del hardware, lo compré hace algunos meses nomás en Galería Jardín, así que es bastante probable que todavía y por un tiempo haya versiones iguales dando vueltas.
• Lo único que hice fue buscar, en foros, como documentación, y encontré que el “router database” estaba desactualizado, y había una versión mucho más actualizada y probada que no estaba linkeada en la página (está en este FTP).
• La parte más fácil fue el upgrade en sí: sólo tuve que ir a “Upload firmware” en el administrador web del TP-Link, subí el archivo “factory-to-ddwrt.bin” que bajé del FTP, apagar/prender y listo.

Ahora tengo muchísimas más opciones y potencia que antes en mi equipo y la casi certeza de que va a funcionar correctamente. En este mismo FTP también se van subiendo periódicamente las versiones nuevas del dd-wrt (del 2012), separada por equipo/versión de hardware: ftp://dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2012/

A disfrutar del Software Libre se ha dicho.

¡Saludos!

Durante el Python Day se darán pequeños cursos y charlas relacionadas a este lenguaje, creando un espacio en donde cualquier persona interesada pueda acercarse para preguntar, aprender y experimentar con esta herramienta.

Python es un lenguaje moderno, sencillo de aprender pero muy poderoso en cuanto a la cantidad de aplicaciones en las que es usado profesional y académicamente: en sitios web, en juegos, aplicaciones de escritorio y en scripting en general, etc…

El publico al que nos dirigimos es de todos los niveles, pero estamos muy interesados en acercar Python a quienes solo lo conocen de oído o directamente no saben de que tipo de lenguaje se trata. Tendremos charlas especiales para ellos.

Con esta misma invitación damos por iniciado el Call For Charlas; aquellos interesados ya pueden proponer nuevas charlas y son bienvenidos los colaboradores y empresas/entidades interesadas en participar y auspiciar la jornada.

Cualquier duda o consulta, puede visitar la página del evento, o contactarse vía mail a pydaylujan@gmail.com.

El encuentro se llevará a cabo en el pabellón 400 de la sede central de la UNLu (ver página Cómo Llegar)

La entrada libre y gratuita (previa inscripción web), ¡los esperamos!

Bitsense, empresa dedicada a la implementación de soluciones telefónicas, dará comienzo a su curso de capacitación de Telefonía IP denominado BiaC (Bitsense Initial Asterisk Course) edición 2011, el mismo es el primer curso en la Argentina dictado por dos instructores certificados dCAP (Digium-certified Asterisk Professional) junto con el apoyo de certificados Cisco y Juniper. Este curso está orientado a brindarle las herramientas y conocimientos necesarios para implementar una infreastructura de Telefonía IP basado en Asterisk desde su inicio.

Para solicitar mas informacion envienos un mail a capacitacion@bitsense.com.ar y un representante se comunicará con usted o llamenos al telefono 5353.9858 (opción 2).

Le informamos también que referenciando esta publicación (si, ¡este blog!) usted accederá a un descuento especial.

http://www.bitsense.com.ar/cursos/biac/

Saludos

HTTPS es la manera de establecer conexiones HTTP pero seguras, en el sentido de que previo al diálogo HTTP estándar pero luego de establecerse la conexión TCP contra el servidor, se negocia entre los participantes una conexión/sesión “especial” entre ambos.  Allí se intercambian certificados con el fin de autenticar contra quién se “está hablando”, para luego, si hubo éxito en la dicha comprobación, encriptar (o no) todo lo que va para el otro lado, tanto del Servidor al Cliente (generalmente un navegador), como del Cliente al Servidor.

Todo eso forma parte de SSL 3.0 (hoy TLS 1.0), y si bien se puede utilizar para cualquier conexión TCP (SMTP, IMAP, etc., lo pueden usar también), su uso más común se da cuando uno entra a su casilla de Webmail o su cuenta del Banco desde el navegador;  lo que sucede allí es que nuestro navegador autentica al Servidor, y si todo va bien nos muestra el famoso “candadito” e informa que la sesión “es segura”. Ahora bien, en esos casos, el Banco o Webmail no nos autentica a nosotros como Cliente y deja que cualquiera se conecte a su página, ya que eso requiere varios pasos más (sería realmente engorroso que sea obligatorio).

Sin embargo, en nuestra vida de programadores nos solemos encontrar con necesidades del entorno que nos obliguen a esta situación un tanto extrema y bastante más segura: que tanto el Cliente que desarrollamos autentique al Servidor como que el Servidor autentique al Cliente, amén de que la conexión muy probablemente deberá estar encriptada. Esto nos permitirá asegurarnos que los Clientes (software) que se conecten a nuestro Servidor sean únicamente quienes queremos que sean (o casi).

Python, dentro del módulo httplib nos provee de la clase HTTPSConnection, que maneja y nos abstrae en varias de estas cuestiones de SSL/TLS y nos deja trabajar a nivel HTTP (una capa más arriba). Lo que hay que observar bien (y que recién en la versión 2.7 de la documentación apareció en rojo), es que esta clase aún cuando uno le puede pasar como parámetro los paths a certificados, en realidad no hace ninguna comprobación de validez del certificado que el Servidor exporta. Con lo cual, hay un potencial problema: que nuestro cliente mande los datos a cualquier lado menos a nuestro Servidor de confianza.

¿Y cómo se fuerza a que nuestro programa Cliente chequee el certificado del Servidor? Armé esta clase que extiende sólo lo necesario a HTTPSConnection, que funciona en Python 2.6.x y que me permite hacer eso.

Le agregué un ejemplo en la llamada a __main__ para mostrar cómo se usa:

#!/usr/bin/env python
#-*- coding: utf-8 -*-
 
import socket
import ssl
import httplib
 
class HTTPSClientAuthConnection(httplib.HTTPSConnection):
    """ Class to make a HTTPS connection, with support for full client-based
        SSL Authentication.
    """
 
    def __init__(self, host, port, key_file, cert_file, ca_file, timeout=None):
        httplib.HTTPSConnection.__init__(self, host, key_file=key_file,
                                                   cert_file=cert_file)
        self.key_file = key_file
        self.cert_file = cert_file
        self.ca_file = ca_file
        self.timeout = timeout
 
    def connect(self):
        """ Connect to a host on a given (SSL) port.
            If ca_file is pointing somewhere, use it to check Server Certificate.
 
            Redefined/copied and extended from httplib.py:1105 (Python 2.6.x).
            This is needed to pass cert_reqs=ssl.CERT_REQUIRED as parameter
            to ssl.wrap_socket(), which forces SSL to check server certificate
            against our client certificate.
        """
        sock = socket.create_connection((self.host, self.port), self.timeout)
        if self._tunnel_host:
            self.sock = sock
            self._tunnel()
        # If there's no CA File, don't force Server Certificate Check
        if self.ca_file:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
                        ca_certs=self.ca_file, cert_reqs=ssl.CERT_REQUIRED)
        else:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
                                              cert_reqs=ssl.CERT_NONE)
 
if __name__ == '__main__':
    # Little test-case of our class
    import sys
    if len(sys.argv) != 6:
        print 'usage: ./https_auth_handler.py host port key_file cert_file ca_file'
        sys.exit(1)
    else:
        host, port, key_file, cert_file, ca_file = sys.argv[1:]
    conn = HTTPSClientAuthConnection(host, port, key_file=key_file,
                                           cert_file=cert_file, ca_file=ca_file)
    conn.request('GET', '/')
    response = conn.getresponse()
    print response.status, response.reason
    data = response.read()
    print data
    conn.close()

En cuanto a la generación de las claves de Cliente, Servidor y CA hay unos cuantos artículos y es relativamente sencillo una vez que se entiende qué se está haciendo. Por otra parte que en estos casos es muy común que el Servidor exija que el Cliente si o sí envíe su certificado o sino la conexión se deberá caer; esto en el caso del Servidor Apache está bien documentado.

Entiendo que en Python 3.2 esto está resuelto en la misma API standard de Python (en su momento abrí un ticket similar para usar esto con urllib2, que incluye cosas importantes como el manejo de cookies, por ejemplo), y comentaron eso.

Según me dijeron en PyAr, es casi seguro que este ejemplo no funcione en Python 2.7, así que en un futuro no muy lejano espero poder adaptar este código a dicha versión y seguramente lo estaré subiendo en esta página.

Saludos

Quería consolidar un disco real de 80 GB que tiene XP instalado en su C:, pero en total el disco tiene 4 particiones (primarias). Sólo me interesaba el disco C:, con lo que ahorraba espacio en el proceso ya que la partición del C: sólo ocupa 25 GB.

Entonces hice la copia con “dd if=/dev/sdb1 of=imagen.raw”. Como uso VirtualBox, con un comando lo convertí de .raw a .vdi. Pero no logré bootear.

Hice varias pruebas, siempre con VirtualBox y no lo logré. Supongo que es porque no se copió el MBR. En cambio, cuando copié el disco completo, booteó sin problemas.

La pregunta es: ¿Cómo debería haber hecho para trabajar solo con esa partición y de esa forma evitar trabajar con los 80GB?

Bueno, el problema era que, efectivamente, al hacer el dd sobre /dev/sdb1 sólo se copian los bytes dentro de la partición y no el MBR+Bootloader (la vieja “pista 0” del disco). Para resolver el problema habría que copiar los bytes de la pista 0 más los bytes de la partición en cuestión, siguiendo estos pasos:

Ejecutar el comando parted sobre /dev/sdb (en mi caso, voy a usar /dev/sda como ejemplo):

marcelo@jupiter:~$ sudo parted /dev/sda u s print
Modelo: ATA WDC WD3200BEVT-0 (scsi)
Disco /dev/sda: 625142448s
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio     Fin         Tamaño      Tipo      Sistema de ficheros  Banderas
 1      63s        32001479s   32001417s   primary   ext4                 arranque
 2      32001541s  94494329s   62492789s   extended
 5      32001543s  94494329s   62492787s   logical   ext4
 3      94494330s  98494514s   4000185s    primary   linux-swap(v1)
 4      98494515s  625137344s  526642830s  primary   ext4

El parámetro “print” le dice a parted que me imprima la tabla de particiones, y “u s” que imprima los tamaños en sectores (que en los discos <=1.0TB son siempre de 512 bytes, sino mismo parted lo dice en la salida, ver este post para más detalles).

De esta manera se tienen todos los sectores a copiar de /dev/sda directamente; en mi caso, 63 sectores de la pista 0, que contiene al MBR, más los de la primera partición, 32001417, total: 32001480 sectores.

Luego el dd que sólo copia los bytes que nos interesan (Pista 0 + Partición “C:”) es fácil:

sudo dd if=/dev/sda of=imagen.raw bs=512 count=32001480

Y listo. Eso sí, luego hay que particionar la imagen con Parted, Fdisk, GParted o el software que se quiera utilizar a tal efecto. Es necesario hacerlo porque el MBR copiado va a reportar las 4 particiones que se tenían previamente en el disco y ahora sólo se va a disponer de una sola.

Asumo que este procedimiento también se puede aplicar para copiar una partición que no sea la primera, usando las opciones “skip” y “append” del comando dd; por ejemplo, si quisiera hacer un disco de sólo mi partición 5, tendría que:

1. Copiar la pista 0 en un archivo con algo así como “dd if=/dev/sda of=imagen.raw bs=512 count=63″.
2. Ejecutar otro dd con la partición a copiar, salteando (“skipeando”) N sectores con la opción “skip” y especificando la opción “append” para agregar al archivo anterior de salida: “dd if=/dev/sda of=imagen.raw bs=512 count=62492787 skip=32001543 append”.

Lógicamente esto último no lo probé, acepto comentarios de si funcionó o no

Espero que a alguien le sirva…

¡Saludos!

Linux KVM vs. VirtualBox 4.0 Virtualization Benchmarks
Este es un test de performance entre KVM y Virtualbox. En resumen, y con los parámetros por defecto en cuanto a I/O, VBox gana, pero parece que es debido a que no hace los fsync del guest en el host y termina utilizando su caché; muy probablemente este comportamiento es configurable (¿ver acá?), pero así y todo ¡es bueno saberlo!. De todas maneras, de alguna manera es peligroso para un entorno de servidores ya que hay riesgo de pérdida de datos, pero por ejemplo, para mi notebook (target primario adonde Virtualbox siempre estuvo orientado) está bien.

Por el otro lado, cuando hay que usar la CPU, KVM “le pasa el trapo” a VBox. Hay un test de I/O de red (TCP) que a KVM le dio mal, tan mal, que seguro es debido a que los salames testers no habilitaron VirtIO en los guests KVM.

Multi-Core Scaling In A KVM Virtualized Environment
Este test trata de dilucidar si es mito o no que el Hyperthreading (las VCPUs) de los microprocesadores Intel Xeon basados en Nehalem hacen más lentas o más rápidas las VMs que corren sobre KVM. Esto es algo que pregunté personalmente en el IRC de KVM (#kvm en Freenode, dicho sea de paso), y me sugirieron lo mismo que dió en los tests: hay veces en donde las VMs aprovechan todas las CPUs virtuales (VCPUs) y otras en que no, con lo cual hay que probar en cada caso en particular y dejar la configuración que nos dé mejores resultados.

Interesante de leer y experimentar.

Saludos