Un buen servicio de DNS

Esta semana contraté un servicio de banda ancha (Flash), y la verdad que los DNS que me asignaron dejan mucho que desear. Sólo resuelven direcciones cuando se les canta y para los dominios que se les canta.

Le comenté esto a Marcelo quien me recomendó OpenDNS. Santos remedios Batman!

No sólo es un buen servicio de DNS (por lo menos, hasta ahora) sino que si uno le pifia a un nombre de dominio, te devuelve una busqueda de dominios similares, por supuesto agregando algo de publicidad, pero dentro de todo el servicio es bueno.

En el sitio hay instrucciones para configurarlo en varios sistemas operativos, en Ubuntu recomiendo que los agreguen al archivo de configuración del cliente de DHCP, así usan siempre los mismos DNS sin importar la ubicación (útil para los que andan con la notebook de un lado al otro). Pueden acceder a las instrucciones para configurar Ubuntu directamente desde acá.

Linux en una Dynapos PST-5000

Estuve haciendo algunas pruebas sobre una máquina de Dynapos, la PST-5000. Si bien la máquina es algo bastante estándar (un Celeron de 650 con 256Mb de RAM), uno nunca sabe que se va a encontrar al intentar instalar/usar Linux en uno de estos aparatos. La distribución seleccionada fue Ubuntu Feisty (7.04)

El primer tema fue la instalación del sistema operativo. La máquina que probé venía con un disco rígido de 40Gb, pero como la máquina no tiene disketera ni cdrom, había que buscar otra forma de instalar.
El primer intentó fue de la forma que me recomendó el proveedor: usando un adaptador ide-usb e instalando desde otra máquina. Lamentablemente la única máquina que tenía disponible para hacer esto tenía USB 1.0 y no era suficiente para instalar el sistema operativo usando debootstrap.
Descartada la opción recomendada, decidí probar con el booteo por red. La máquina tiene placa de red, y sólo fue cuestión de bajar el instalador de red de Ubuntu y hacer unos retoques a nuestro servidor DHCP (ver este howto).
Por ansiedad, durante la instalación no seleccioné ningun grupo de paquetes, por lo tanto la instalación fue rápida y pude probar si el kernel podía iniciar sin problemas.

Luego de la primera instalación, probé que el hardware haya sido detectado, la placa de red funcionaba, todo ok, asi que después de un 'apt-get install ubuntu-desktop' (y casi dos horas de espera) tenía el gdm esperando el usuario y contraseña.

La gran duda era si iba a funcionar el touchscreen, según las especificaciones es un Elo, y debería funcionar bien en Linux. Lamentablemente el Ubuntu no lo configura por default, así que tuve que 'ensuciarme las manos': a editar el xorg.conf a mano...

Este debe ser uno de los archivos más temidos, y la verdad que no hay nada por que temerle. En este archivo se definen los dispositivos que se van a usar desde el entorno gráfico, de qué tipo son (teclado, pantalla, placa de video, etc), y como se relacionan en una configuración determinada. El miedo popular viene de que al romper uno de estos archivos no vuelve a levantar el entorno gráfico, y en estos casos hay gente que llega a reinstalar el sistema completo. La solución es muy simple: 'sudo dpkg-reconfigure xserver-xorg' desde una consola. Tampoco es una mala idea hacer una copia antes de modificarlo, por supuesto.

Para levantar los módulos del touchscreen tuve que crear una sección para el dispositivo:

Section "InputDevice"
      Driver      "elographics"
      Identifier  "touchscreen"
      Option      "Device"    "/dev/ttyS2"
      Option      "Type"      "cursor"
      Option      "MinX"      "4000"
      Option      "MaxX"      "50"
      Option      "MinY"      "4000"
      Option      "MaxY"      "100"
EndSection

Como pueden ver, los valores de MinX y MaxX, y MinY, MaxY están invertidos, eso es porque este modelo viene con el touch invertido (?) Los valores que muestro son para una pantalla de 15" y 1024x768. Para calibrar bien el touch, hay que usar el viejo método de prueba/error, otra opción no encontré (si alguien sabe como configurarlo de forma mas facil, que avise :))

Luego, en la sección de Layout, donde se combinan todos los dispositivos para el entorno gráfico, agregué lo siguiente:

Section "ServerLayout"
      ...
      InputDevice "touchscreen"   "SendCoreEvents"
EndSection

Por supuesto, hay que reiniciar el X, en el caso de Ubuntu, es suficiente con reiniciar el gdm: 'sudo /etc/init.d/gdm restart' y ya está: un Ubuntu con touchscreen en una máquina de POS. Para ejecutar un Gnome completo es un poco lenta, pero para aplicaciones customizadas, sin cargar un entorno completo, lo veo más que factible.

Espero que le sirva a cualquier que esté pensando en usar una máquina de estas o al menos para configurar un touchscreen en Linux. No eran tan difícil...

Traducción curiosa

Estaba escuchando música con el Rhythmbox cuando me percaté de un botón un tanto gracioso:


La traducción está perfecta, ya que la función del botón es limpiar la cola de reproducción. Pero no deja de ser gracioso ver el texto con ese icono de escobita.

Algunos se divierten con tan poco... :)

Vuelve Soda Stereo, y tengo entradas!!!

A esta altura no es ninguna noticia, pero en Octubre toca Soda Stereo en la cancha de River.

Dicen que se vendieron 90.000 entradas en los primeros dos días (menos mal que era una preventa :) y para variar, el sistema de Ticketek se 'cayó' a los cuarenta minutos de estar funcionando.

Mi hermana se portó, fue a hacer la cola y consiguió entradas para el 20 de Octubre!!!

Ahora a tener paciencia, y guardar las entradas bajo llave... no sea cosa que uno se tiene de ponerlas en MercadoLibre ;)


PD: los jóvenes vamos al campo, no como otros... jeje...

PD2: Que Ticketek se ponga las pilas, no puede ser que se les caiga el sistema cada vez que venden algo más grande que Chiquititas.

Using Ubuntu and Python in elections systems

Since 1999, Magic Software Argentina (the compay I worked for until mid 2007) was responsible for providing information systems related to electoral processes in several provinces in Argentina. Some of these proyects included some form of electronic voting. Usually the main function is to provide the results of the election before midnight.

I've been involved in the design and development of every system used since the first one, that was implemented using only propietary software and tools. On May 20th, 2007, we carried out the first implementation of the system running absolutely on free software and tools: the elections in the province of Río Negro were made using Ubuntu, Python and PostgreSQL.

A quick introduction to the case

The process takes place at the end of the election day, that is 6:00 p.m., and it's based on the data provided by the marshalls at the voting places in official paper forms wich are sent to the datacenter by some means (fax, courier mail, etc). Data in these forms are fed to the system by a group of dataentries, while another component of the system adds up this data generating reports and charts served in the results site.

The software used in this process must be both reliable, secure and overcome any contingency in less than half an hour and fast enough to process at least 90% of the forms before midnight. The information provided by the system is what public media (newspapers, tv channels, radios) take as a basis for next morning headlines.

Getting to know the penguin

The first time we made an electoral process, it was based absolutely in preopietary software and tools. All machines were running Microsoft Windows, the programming language used was Magic and the html reports were made in a batch process and then uploaded to the official results web site.

At that time, I was taking my firsts steps in the world of GNU/Linux and open source. I had some experience in AIX and SCO, but wasn't so confident in OSS tools to put it forward for that critical application.

It was in mid 2000 when we first used Linux in a process realated to elections. We where using Compaq Tru64 for the main servers, the pie-charts generating program we used only run on Windows, and the performance wasn't acceptable. Since we needed the sources to be compiled in Tru64, the options where open source software or spend a lot of money. Whe choose open source, and found ploticus, a superb charting program that helped us since that election took our testing Linux server to the datacenter, and that was the first work we gave to Linux: it spent all the night drawing pie charts without problem. The conclusion was that Linux was stable enough to be used in critical applications. We -the technical staff- already knew that, but management not always trust tools that are not backed up by a company. In the following elections in which we were involved, we included more free/open tools: Linux became the main operating system for servers, apache was used as web server and PHP was used to generate reports.

Some times the options were limited by some propietary software we still used, like Oracle. Since Oracle only supported Red Hat (and maybe SuSE), we didn't have a choice for the distro to be installed on the database server. For the data entry application, we still used Magic on Windows.

The final evolution: Ubuntu, Python and PostgreSQL

In 2006 we made an electronic vote experience for the city of Rosario. It was a turning point since for the first time we didn't use Magic as the main programming language. The solution was based on Ubuntu LiveCDs, and the voting system was absolutely coded in Python + Gtk.

From that experience we learnt that Ubuntu was a stable Linux distro, and python is an awesome programming language that let us focus more on the functionality that in the problems related to the language. Programming in python is easy and fast, sometimes you have the feeling that you're just typing what you're thinking, it's amazing.

In these projects time is always short, but thanks to python (and Marcelo Fernandez's work) we managed to finish a module that helped people with sight disabilities to cast their vote in secret, using festival to read them the available options, and confirm the vote to be casted (using headphones).

For the elections in the province of Río Negro on May 20th, 2007, we chose to use the same tools that had been so satisfactory in Rosario, Ubuntu and python. The only problem here was that Oracle is not officialy supported in Ubuntu yet, and for the servers we should have to use Red Hat.

Since we are more experienced in managing Debian like systems, and didn't have much time to fully test our applications running on Red Hat, we took the last step left to make an election process only on open/free software: if we wanted to have our servers running Ubuntu, Oracle was not an option, so we moved to PostgreSQL.

After some quick tests, we were confident in PostgresSQL's performance. Instalation was just an 'apt-get install' away, and the online documentation was enough to set ready the database for the process.

For the data-entry application, made in python+gtk, we'd had to install Ubuntu and the application in a dozen rented machines the day before the elections day. To avoid such amount of work, time being was such a limited resource, we chose to set a Ubuntu + LTSP server, and used the machines as thin clients. This way all the configuration was made on only one server, and the deploy was reduced to net-boot the client machines.

Many technologies and products where used in the solution provided. The results where faxed from the voting centers to a datacenter in the city of Viedma. These faxes were sent to a posftix mail server by the Cisco appliances that received them. The fax images where extracted from the mails (using python and imagemagick) and sent to Buenos Aires (970 km away) through a VPN to be processed by the data entries. The results web site was running Apache + mod_python, as well as a workflow management system (only accesible in Viedma, through the VPN). Every machine involved in the process was running Ubuntu Edgy or Feisty.

Some pics of the datacenter in Buenos Aires: http://picasaweb.google.com/gepatino/EleccionesRioNegro2007

Conclusion

Many people, including IT pros, use to think that community supported free software tools or distros are not 100% reliable in mission critical applications, and they end up usign comercial distros and/or propietary software. After this project are able to state not only that this vision is erroneous, but also that in some cases productivity was greatly improved.

Using Ubuntu as the main (and only) distribution allowed us to install and configure the bunch of servers that took part in the process. The Debian package system is unvaluable, and we found any piece of software we need in the Ubuntu repositories. It wasn't necessary to download or compile a single program.

In terms of programming, Python has anything we could need for this project. Python support on Ubuntu is great, anytime we needed a specific library, we found it on the repositories. Thanks to the power of python and the programming speed you can develop, only two skilled programmers were necessary to program the whole system, when using other tools we always needed more than four. Productivity in python is awesome.

Free software tools mantained by the community are absolutely reliable for mission critical applications like the one presented in this article. If they are so valuable in this kind of sensible proceses, why not use them in your next project? ;)


Gabriel Ernesto Patiño
https://gepatino.blogspot.com


This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
Special thanks to Maria Laura Schibber for her review on this translation.

Soy famoso! :)

Hace un rato viene mi jefe y me dice 'buscá "voto electronico" en Google Images, y fijate quien aparece en la primer página'.

Por supuesto, pensé que iba a aparecer él... pero no... Google vuelve a sorprenderme. Esta vez el famoso soy yo :D

Pueden ver los resultados de la búsqueda desde este enlace, y por si Google decide eliminarme, desde acá pueden ver la foto.

Esta nota es totalmente irrelevante, pero es curioso verse a uno mismo en la primer página de resultados para un tema tan interesante. Y bueno... el que sabe, sabe ;)



La busqueda termina apuntando a una nota de un sitio de Rosario, y yo no soy el que está votando, sino el que controla en actitud solemne :)

El Blog de Marcelo!: Ubuntu GNU/Linux + Python en Rio Negro

Marcelo Fernández, un compañero del laburo, escribió algo más sobre cómo trabajamos y que herramientas usamos para el sistema de recuento de votos de Río Negro.

Si... soy un 'duro'... programo sólo con el vim... ;)

El Blog de Marcelo!: Ubuntu GNU/Linux + Python en Rio Negro

Ubuntu, Python y Software Libre en procesos electorales

Desde el año 1999, MSA - Magic Software Argentina, la empresa donde trabajé hasta mediados del 2007, fue seleccionada para llevar a cabo varios procesos electorales en diferentes provincias y localidades de la República Argentina. Recientemente algunos de estos proyectos incluyeron alguna forma de voto electrónico, pero generalmente se trata de hacer el recuento de votos del escrutinio provisorio.

Desde la primer elección en que la empresa fue seleccionada, fui parte del equipo de diseño y desarrollo del sistema. Inicialmente el sistema estaba basado 100% en tecnologías privativas. El 20 de Mayo de 2007 hicimos el primer sistema de recuento de votos basado totalmente en software libre para las elecciones provinciales de la provincia de Río Negro, usando Ubuntu como distribución de Linux, y Python como lenguaje de programación.

Introducción al problema

El escrutinio provisorio es el que se hace rápidamente tomando en cuenta los datos que registran los presidentes de mesas en un formulario determinado. Éstos son los datos oficiales que generalmente están disponibles a la medianoche del día de las elecciones, y los que vamos a consultar en todos los medios de prensa al día siguiente.

Para el escrutinio definitivo, el juzgado electoral resuelve algunos votos que no fueron tomados en cuenta en el escrutinio provisorio como los votos recurridos e impugnados, y determinan si son o no votos válidos. Como este proceso puede tardar varias semanas, es de suma importancia obtener el resultado del recuento provisorio lo antes posible para dar transparencia al acto electoral. A menos que la elección haya sido muy pareja entre dos o más candidatos, no hay diferencias entre el escrutinio provisorio y el definitivo ya que los porcentajes de votos recurridos e impugnados son muy bajos, y generalmente no deciden ninguna elección.

En base a los requerimientos implícitos del recuento provisorio (velocidad y confiabilidad) el sistema que se encargue de tomar la información generada por los presidentes de mesa y genere los reportes «minuto a minuto» que van a ser consultados públicamente debe ser extremadamente confiable, estar diseñado como para permitir resolver cualquier contingencia (desde cortes de luz, hasta daños en el hardware) en menos de media hora, y como si todo esto fuera poco, tiene que ser lo suficientemente rápido como para procesar más del 80% de las mesas antes de la medianoche.

Conociendo al pingüino

El primer proceso electoral que hicimos fue basado completamente en herramientas y software privativo. Todas las máquinas corrían el sistema operativo de Microsoft (no recuerdo las versiones), el lenguaje de programación era Magic (una herramienta de desarrollo post 4GL) y los reportes (html) eran generados en lotes que luego eran subidos al sitio web de publicación de resultados.

En esa época estaba dando mis primeros pasos en el mundo de GNU/Linux, y aunque ya había utilizado sistemas AIX y SCO, no tenía el conocimiento ni la confianza como para proponer el uso de herramientas de software libre.

Rápidamente fui aprendiendo a relacionarme con el pingüino, en gran parte gracias a la comunidad de LUGAr y su maravillosa lista de correos. Gracias a toda la gente que participa de la lista aprendí mucho, primero haciendo preguntas, luego respondiendo las preguntas que estaban al nivel de mis conocimientos.

Desde el año 2000, Linux empezó a acompañarnos en los procesos electorales. Su primer colaboración fue trabajar como generador de gráficos para los reportes de resultados. Inicialmente habíamos seleccionado una herramienta que corría sobre Windows, pero la performance no era aceptable. Las bases de datos (Oracle) corrían sobre Compaq/Tru64, así que buscamos alguna herramienta de código abierto que cumpla con los requerimientos y encontramos a ploticus que desde ese momento siempre nos acompaño. La idea era compilar ploticus para que corra sobre Tru64, ya que Linux no estaba visto como algo confiable por los «no-técnicos». Por problemas de librerías y compiladores, no pudimos hacer compilar el programa para que corra en esa plataforma, así que directamente nos llevamos nuestra máquina de pruebas en Linux, y esa fue la entrada en escena del pingüino. Se realizó el proceso sin problemas, y quedó comprobado que podíamos confiar en Linux para procesos importantes.

En procesos posteriores, fuimos incorporando gradualmente más Linux y software libre dentro del sistema. Configuramos nuestros propios servidores web (Apache), hicimos la generación de reportes con PHP, las bases de datos Oracle fueron instaladas sobre RedHat, de a poco íbamos ganando conocimiento (y confianza) en la utilización de herramientas libres.

Muchas veces la selección de las herramientas libres estaba limitada a las herramientas no libres que también formaban parte del sistema. Generalmente usábamos Red Hat como distribución ya que Oracle sólo brindaba soporte para esa distribución, para el módulo de ingreso de datos seguíamos utilizando Magic sobre Windows.

Al final, Ubuntu y Python

En el año 2006 hicimos una experiencia con voto electrónico para la Municipalidad de Rosario. Ese fue un punto de inflexión ya que utilizamos por primera vez un ambiente de desarrollo abierto para desarrollar las interfases de usuario. La solución utilizada se basaba en LiveCDs de Ubuntu modificados para contener el software de voto que usaban los electores. Dado que Magic no tiene un cliente GUI para Linux, decidimos utilizar Python + Gtk.

La combinación funcionó a la perfección, y nos sirvió para sentar precedentes que no solo las distribuciones comerciales son estables y confiables. Ubuntu corriendo desde un LiveCD fue sumamente confiable, y sólo tuvimos problemas con los módulos de un touch screen cuyo fabricante sólo nos facilitó una versión beta de los mismos.

Por otro lado comprobamos que Python es un lenguaje de programación extremadamente poderoso. Sin la velocidad de programación que brinda Python, no hubiéramos tenido tiempo de hacer un módulo especialmente diseñado para que puedan votar las personas con capacidades de visión disminuidas, utilizando 'festival' para que asista al elector durante el proceso de emisión del voto (gracias a Marcelo Fernández)

En base a la experiencia recogida en la ciudad de Rosario, para el proceso de recuento provisorio de las elecciones de Río Negro, el 20 de Mayo de 2007, queríamos utilizar la misma plataforma (Ubuntu + Python) pero se imponía el problema de que Oracle sólo brinda soporte si se ejecuta sobre Red Hat Enterprise Linux.

Para el sistema de reportes y el sistema de carga de datos, ya habíamos seleccionado Ubuntu como plataforma, dado que es la distribución que usamos para trabajar diariamente. Si todo el software era desarrollado y probado en una plataforma, no era muy convincente cambiar de distribución par el día del proceso. La base de datos podría haber corrido sobre un RHEL, pero necesitábamos que los dos servidores principales puedan cumplir con las funciones del otro en caso de una caída inesperada. Tener un RHEL por un lado y un Ubuntu por el otro no nos permitía estar totalmente seguros que la aplicación se comporte igual, y si había que levantar el Oracle en Ubuntu, no íbamos a tener soporte.

Dado que los tiempos estaban muy ajustados, no podíamos hacer pruebas de compatibilidad de la aplicación en diferentes distribuciones, con diferentes librerías y versiones de programas. Entonces se tomó la decisión que tanto tiempo tardamos en tomar. Dado que Oracle no soporta Ubuntu, y necesitamos Ubuntu en los dos servidores principales, seleccionamos a PostgreSQL como base de datos.

Luego de un par de pruebas rápidas, quedamos totalmente convencidos que era lo que necesitábamos. La instalación fue más simple de lo que pensábamos: un simple apt-get install. Para la configuración no tuvimos que tocar demasiados parámetros ya que el volumen de datos no era demasiado grande. Lo importante era que los inserts y las consultas sean rápidos, y consistentes.

Para la parte de carga de datos, teníamos que instalar la aplicación en doce máquinas alquiladas para la ocasión. Si bien nos permitían hacer una instalación e instalar Ubuntu en todas las máquinas, hacer esto nos hubiera llevado un par de horas largas. Para resolver el problema, configuramos un LTSP sobre Ubuntu, y utilizamos las máquinas como clientes delgados. En consecuencia la instalación de la aplicación sólo se hizo en una máquina, y el resto fue arrancar las máquinas desde la red.

Descripción de la solución utilizada

El funcionamiento del sistema es, en forma sintética, el siguiente:

• Luego de hacer el recuento manual de votos, el presidente de mesa llena un formulario con los resultados del recuento para esa mesa.
• Los formularios son enviados físicamente al juez de paz más cercano.
• Los jueces de paz son los responsables de transmitir los formularios por fax al centro de cómputos de la ciudad de Viedma.
• Tres equipos Cisco reciben los faxes y los envían a un servidor de correos dentro de la red local.
• Un proceso en python se encarga de desempaquetar las imágenes y procesarlas para que puedan ser utilizadas en el resto del circuito.
• Mediante una aplicación GUI, varios operadores confirman que los faxes recibidos sean verídicos, legibles, etc.
• Las imágenes aprobadas son transmitidas a través de una VPN al centro de computo de Buenos Aires.
• Los dataentries ven las imágenes en un programa que muestra la imagen y los campos para ingresar los votos.
• Las imágenes son cargadas por dos personas distintas, si los datos de las dos cargas no coinciden, se resuelve la incidencia en la ciudad de Viedma mediante un sistema de carga web (apache + mod_python) que sólo es accesible mediante la VPN.
• Las planillas que fueron cargadas correctamente son publicadas en el sitio web de reportes públicos (apache + python).

En la ciudad de Viedma, se utilizaron las siguientes herramientas:

• Ubuntu 7.04 (mailserver, aprobación de faxes)
• postfix
• Python + Imagemagick (proceso de imagenes)
• Python + pygtk + glade

En la ciudad de Buenos Aires:

• Ubuntu 6.10 (servidor de base de datos, servidor web, servidor LTSP)
• PostgreSQL 8.1
• Python + pygtk + glade (programa de carga de datos)
• Apache 2.2 + mod_python (consulta de estado de proceso y resolución de incidencias)
• Apache 2.2 + python (cgi de generación de reportes públicos)
• ploticus (generación de gráficos para los reportes)

Pueden ver algunas imágenes desde este enlace.

Conclusión

Generalmente se piensa que las herramientas de software libre mantenidas por la comunidad no son 100% confiables en aplicaciones de misión crítica, y se termina recurriendo a distribuciones comerciales, bases de datos propietarias, etc. Durante el desarrollo de este proceso, no sólo pudimos comprobar que esta visión es errónea, sino que en algunos casos se incrementa la productividad.

Usar Ubuntu como única distribución nos facilitó muchísimo la instalación y configuración de los múltiples servidores que participaron del proceso. El sistema de paquetes apt-get (y sus derivados) son una ayuda invaluable, y en los repositorios pudimos encontrar todas las herramientas que necesitamos. No necesitamos bajar programas o librerías de sitios no oficiales, y no fue necesario (re)compilar ni un sólo programa.

En cuanto a la programación, Python nos brindó todo lo que necesitamos, y al momento de necesitar instalar algunas librerías en particular, siempre las encontramos en los repositorios de Ubuntu. Python, al ser tan potente y rápido para el desarrollo, nos permitió desarrollar el sistema completo solamente entre dos personas (Marcelo y yo). Cuando usábamos otras herramientas de desarrollo nunca fuimos menos de cuatro desarrolladores.

En definitiva, las herramientas libres mantenidas por la comunidad, por lo menos las utilizadas en este proyecto, son totalmente confiables en aplicaciones de misión crítica como el caso presentado. Si son confiables para este tipo de procesos tan delicados, ¿por qué no usarlas en su empresa? ;)

Gabriel E. Patiño

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

Presentación

Tarde, pero seguro, decidí dar de alta un blog para ir publicando una que otra cosa.

Soy analista de sistemas, y aunque hago diseño e ingeniería de software, lo que más me gusta es la programación y administración de sistemas Linux (o unixes, en su defecto)

Trabajo en esto desde 1994, y aproximadamente desde el 1998-1999 empecé con Linux y software libre.

Cuando tengo tiempo participo de varias listas de mail sobre Linux y Python, y he colaborado en Ubuntu con traducciones y algo de bug traking. Pueden ver mi perfil en Launchpad desde este enlace.

Espero poder subir notas interesantes, nos vemos.

Gabriel