SSH avanzado - Multiples Hosts a la vez y conexión automática a través de un pivot host

Llegó el momento de administrar varios servidores, y a veces las tareas se vuelven un poco repetitivas, especialmente cuando los servers que estás administrando son replicas para obtener alta disponibilidad: las configuraciones, ubicación de archivos, paquetes instalados, etc, son iguales en todos los servers. Entonces para que ejecutar actualizaciones y cambios de configuraciones secuencialmente si se puede hacer todo junto?

Para esto recurrí a una herramienta indispensable para los sysadmins que manejan varios servers: ClusterSSH, o "el pulpo", como lo llama el gran sysadmin Germán, a quién vi manejando unos 30 servers a la vez.

ClusterSSH se conecta a varios servers a la vez, abriendo una ventana de xterm por cada server, y una ventana extra donde ingresas comandos y estos se replican a todos los servers conectados (o podés elegir a cuales desde uno de los menúes). Si querés ejecutar algo solo en un server, seleccionas la ventana adecuada y listo. Super simple.

En mi caso, el problema para usarlo era que me conecto a todos mis servers desde un server que uso como pivot, de esta forma tengo mi 'estación de trabajo' principal en la nube y puedo acceder desde cualquier lado. Como el ClusterSSH necesita X (usa xterm), levantarlo en mi server pivot no es una opción muy satisfactoria ya que acá en el fin del mundo la velocidad de conexión no es tan buena como para levantar aplicaciones X remotas.

Acá entra en juego la versatilidad de ssh, si puedo hacer que desde mi notebook se conecte a un server pasando automáticamente por el pivot, seguramente puedo usar ClusterSSH local en mi notebook sin tener que abrir el acceso a todos mis servers.

La configuración es muy simple, todo va en el ~/.ssh/config:

Host pivot
    Hostname pivot.example.com

Host server1
    ProxyCommand ssh -q pivot -nc -q0 server1

Host server2
    ProxyCommand ssh -q pivot -nc -q0 server2


Para que esto funcione, tenemos que tener acceso a pivot.example.com, y desde este server poder acceder por ssh a los servers server1 y server2 (tiene que poder resolver los host names como los ponemos aca). Si usamos usuarios diferentes en los servers, se indican con la opción User.

Para probar, desde tu máquina local haces: 'ssh server1' o 'ssh server2', ambos deberían conectarse directamente a los servers pasando por la máquina pivot.

Ahora que todo funciona, instalás 'el pulpo' y entrás a los dos (o n) servers a la vez:

$ sudo apt-get install clusterssh
...
$ cssh server1 server2

Y empieza la diversión... y si, la gente de sistemas somos vagos por definición.

Imagen sacada de la web, créditos a quién corresponda.

Poniéndole aún más vi a tu vida

Acabo de aprender dos cosas buenísimas para los que gustamos de vi y vim, gracias a Leo Vidarte:

vimium
Empezamos con el más liviano de los dos. Vimium es una extensión para Chrome que te permite usarlo con algunas de las combinaciones de teclas de vim. 

Para mí, lo más interesante es la letra 'f', que te muestra una etiqueta al lado de cada link y si presionas esas teclas te lleva a esa página (usando 'F' te los abre en una nueva pestaña).

Cómo se ven los links al presionar 'f' o 'F'

Bash en modo vi
Esto se lleva todos los premios... bash en modo vi!

No solo en la terminal, sino en el cliente de mysql, el interprete de python... en todos lados tenes los comandos de vi a un Esc de distancia.

La felicidad de buscar en el history con / y después navegar con 'n' o 'N', moverte entre palabras con 'b', 'w', 'e', borrar, insertar al principio, al final... hace rato que no me emocionaba tanto con una computadora! Hasta podés deshacer la edición de un comando con 'u'...

Como se habilita: set -o vi

Si te gusta tanto como a mí, vas a querer dejarlo permanente. Crea el archivo .inputrc en tu home y ponele:


set editing-mode vi
set keymap vi

Podés bajar un cheat sheet desde este link para ver las opciones disponibles.

Se viene la UbuConLA 2012

Nacida de una idea en conjunto de las comunidades locales de Ubuntu en Argentina y Uruguay, los días 1 y 2 de Junio de este año se hace la primera UbuConLA: una conferencia anual, internacional e itinerante sobre Ubuntu, temas relacionados a su ecosistema y software libre.

Este año se hace en la sede de la Universidad Austral en Buenos Aires (mapa), y es totalmente gratis.
Sin embargo, hay cosas que no son gratis y alguien tiene que pagarlas, así que estan juntando fondos para algunas gráficas, etc. Si sos usuario de Ubuntu o tenes ganas de asistir a la conferencia, fijate si podes colaborar con algo, para esto se abrió un proyecto en Groofi. Con 10 dolares podés ayudar un montón, y por el precio de una entrada de cine vas a estar ayudando a organizar este evento de dos días!

Más información en el sitio de UbuConLA. De yapa, un folleto para compartir. Si quieren los PDF para imprimir y publicitar en universidades y oficinas, avisenme.

Se viene la release party para Intrepid

Como de costumbre, el gupo local de Ubunteros porteños/bonaerenses están organizando la release party de la nueva versión de Ubuntu, Intrepid Ibex.

El ágape se celebrará el jueves 20 de Octubre, en el bar Dr Mason (Aráoz 1199, Palermo).

Es un buen momento para conocer en persona a algunos de los que constantemente leemos via mails o en los foros. Por supuesto, nunca faltan un par de cervecitas, y algúna partida de pool.

Más información en la página de Ubuntu-ar, no es necesario registrarse, pero sí es útil para saber cuantos vamos a ser.

Nos vemos!

Cómo ejecutar un programa no ejecutable

En un post anterior puse un problema que me pareció muy interesante para ejercitar la creatividad de los sysadmins/linuxeros ahí afuera.

El tema era como volver a darle permisos de ejecución si le sacamos estos permisos al chmod. En los comentaros se publicaron respuestas relacionadas con usar lenguajes de scripting (en el enunciado decia que no se podía compilar) pero la idea era ser un poco más creativos.

La primer solución que encontre fue:

cp otro_ejecutable xxx
cat /bin/chmod > xxx
mv xxx /bin/chmod

Lo interesante de esto es que los permisos de ejecucion de la copia original se mantienen al 'llenar' el archivo con otro contenido.

Isart, quien me propuso el acertijo, encontró otra un poco mas simple que es:

cp otro_ejecutable xxx
cp --no-preserve=mode /bin/chmod xxx
mv xxx /bin/chmod

Yo sabía que tenía que haber otra forma de ejecutar un archivo a la fuerza, y me encontré con esto:

/lib/ld-linux.so.2 /bin/chmod

Si lo dejamos estrictamente en el enunciado del acertijo, cualquiera de las tres sirve para cambiar los permisos de un archivo sin que el chmod sea ejecutable, pero la última me llamo mucho la atención porque incluso la puedo usar como un usuario normal sin ningún privilegio.

¿Puede ser esto una falla de seguridad?

No creo que sea demasiado grave porque no encontre la forma de cambiar el propietario de un archivo a root con un usuario común, pero hay que tener en cuenta que un usuario comun puede ejecutar cosas sin importar los permisos que tengan los archivos (bueno, por lo menos tiene que tener lectura)

Acertijo para sysadmins

Hoy a la tarde, Isart me propuso un acertijo interesante, que suena más a pregunta de examen que otra cosa, pero me dio un buen rato de entretenimiento super geek.

Seguramente más de uno lo conoce, pero esta bueno para investigar un poco sobre el sistema, aca va el enunciado:

Alguien ejecutó el comando:

chmod -x /bin/chmod

¿Cómo lo arreglás sin reinstalar ni recompilar ningún programa?

Cada uno encontró una solución diferente, y después encontré una tercera solución más académica. Conclusión, somos un poco chapuceros, pero creativos :P

Que se diviertan, y dejen que el resto se divierta un rato antes de postear alguna solución ;)

Firefox Download Day 2008

La gente de Firefox esta preparando un evento para entrar al libro Guinness: batir el record de downloads de un software en 24 horas.

Actualización: Ya está definido el día del evento: el 17 de Junio (el próximo martes) es el día elegido para poner a Firefox en el libro Guinness.

Ayuden a incluir el software libre en el libro Guinness, y de paso aprovechen para descargar y usar la nueva versión de este excelente navegador.

Firebug para Firefox 3

Para los que extrañabamos el firebug en Firefox 3, acaba de sarlir una beta de la release 1.2, que funciona con la nueva versión del navegador.

Para el que no lo conocía, Firebug es un plugin indispensable para cualquiera que tenga que hacer algún trabajo relacionado con páginas web: desde el diseño (o maquetado) hasta debugging, SEO, etc.

Para instalarlo, simplemente hagan click en el link Firebug 1.2 en la página de betas de Firebug. Y si... es un beta, y no lo probé demasiado, pero parece que funciona.

Eso sí, para hacerlo funcionar tuve que deshabilitar el plugin Yslow. Se ve que esta diseñado para la versión anterior del firebug y con este no funciona aún, así que si tienen este plugin y al abrir el Firebug no ven los queridos paneles de inspeccion de código, prueben deshabilitando el Yslow.

(gracias a Genki)

Actualización:

Gracias al comentario de Ubuntips, encontré una forma más fácil de instalar el Firebug en Ubuntu. Simplemente hay que buscarlo en los repositorios. De paso busqué otros plugins y también encontré el WebDeveloper. Ubuntu no deja de soprenderme...

¿Es Ruby tan bueno como dicen?

Hace unos años pasé por la disyuntiva de elegir un nuevo lenguaje de programación y, como les pasará a unos cuantos, llegué a la definición entre python y ruby. En ese momento me decidí por python, ahora no recuerdo bien los motivos en detalle, pero hasta ahora no me arrepentí.

Hoy encontré este post (larguísimo) de por que ruby no es un buen lenguaje. Sinceramente, es la primera vez que leo algo escrito por este tipo, pero a menos que le haya puesto muy pocas ganas a la comparación (o al aprendizaje de ruby), ruby esta en problemas.

¿Es realmente ruby tan malo e inconsistente? Ya sabía que ruby no era muy bueno en cuanto a performance, pero e sorprende que maneje tan mal el soporte de unicode, y los metodos/funciones que hacen cosas similares con nombres diferentes, y peor aun los que hacen cosas diferentes con nombres similares...

Antes que lo lean, aclaro que al tipo le gusta python, y cada tanto manda algunos comentarios que no hacen más que meter ruido, pero mas allá de eso el post me parece muy bueno, y con muchos links a otros articulos relacionados, también interesantes.

Por supuesto, este post generó un montón de comentarios, críticas y también tenía algunos errores. La semana pasada publicó otro post con algunas correccciones y comentacios interesantes.

Vulnerabilidad en openssh - como arreglarla

Aviso importante para los que usan Debian y sus derivados (entre ellos Ubuntu)!

Para el que todavía no se enteró, esta mañana se reportó una falla grave de seguridad en el OpenSSH para Debian y Ubuntu. Resumiendo, las claves generadas después del 2006 son potencialmente vulnerables dado que las función que genera números aleatorios en openssl era predecible.

Gracias a la velocidad de respuesta del software libre, ya están disponibles los paquetes de actualización para Debian y Ubuntu. Supongo que otras distribuciones pueden tener el mismo problema, pero no lo comprobé.

Para solucionar el problema de seguridad hay que seguir los siguientes pasos.

En primer lugar, actualicen sus sitemas:

$ sudo apt-get update
$ sudo apt-get upgrade

Con esto se arreglan los problemas de las futuras claves que se generen.

Para validar las claves actuales, los desarrolladores de Debian subieron un script para validar las claves personales y de host

$ wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
$ gunzip dowkd.pl.gz
$ chmod u+x dowkd.pl
$ ./dowkd.pl user
$ ./dowkd.pl host hostname

Si al script le pasamos el argumento user, chequea las claves del usuario. Con el argumento host, se puede indicar un nombre de host al cual se le quiere hacer el testeo.

Si las claves fueron generadas con esta versión defectuosa del openssl, seguro el script va a dar algun mensaje diciendo que la clave es débil. En este caso hay que regenerar las claves del usuario y del host.

Para regenerar las claves de usuario:

$ ssh-keygen -t dsa -b

Para regenerar las claves del host:

$ sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
$ sudo dpkg-reconfigure -plow openssh-server

Recuerden que deben limpiar el archivo ~/.ssh/known_hosts y volver a transmitir su clave pública a sus servidores, o es posible que no puedan volver a entrar ;)

Actualizando Ubuntu de Gutsy a Hardy

Finalmente, ayer me pasé a la nueva versión de Ubuntu: 8.04 LTS, Hardy Heron.

Para los que no están en el tema, Ubuntu es una de las distribuciones de Linux más populares, principalmente por su facilidad de instalación y soporte de hardware. Cada seis meses sacan una nueva versión, de ahí que los números de versión crezcan tan rápido: el primer número es el año, y el segundo el mes.
En el caso de Hardy, es una release especial ya que es una LTS: Long Term Support (Soporte a Largo Plazo). Las versiones comunes de Ubuntu tienen soporte por dieciocho meses, después de los cuales se dejan de liberar parches de seguridad y actualizaciones. En el caso de las LTS, el período de soporte es de tres años para el escritorio, y cinco para servidores.

La impaciencia y los embotellamientos

El año pasado, cuando salió Gutsy Gibbon (7.10), los servidores se habían saturado... bajar un imagen del cd o actualizar directamente había sido bastante tedioso. Este año, por lo menos para mí, fue directamente una tortura. Bajar 1Gb de paquetes para actualizar me llevo unas doce horas. Me da la sensación de que cada vez hay más gente ansiosa por probar las nuevas versiones de Ubuntu, lo cual es buenísimo, lástima que se arman unos embotellamientos como los de semana santa yendo para la costa ;)

Supongo que para la nueva release (8.10) deberíamos ser un poco más pacientes y no tratar de actualizar todos juntos en los primeros tres días, o lo que sería mejor, conseguir algo de fondos para configurar un mirror local ya que en Argentina no tenemos ninguno todavía. ¿Alguna empresa o universidad solidaria?

Para no esperar tanto, si consiguen un cd de instalación o un alternative de Hardy, pueden acelerar la descarga de paquetes copiando los archivos que están en el directorio pool del cd. Una vez dentro de ese directorio, ejecuten lo siguiente:

sudo -i
for file in `find ./ -iname '*.deb'`; do cp $file /var/cache/apt/cache/; done
exit


Luego lancen la actualización y solo tendrán que bajar los archivos que no estén en el CD.

Actualizando la notebook

En mi caso, no todo funcionó automáticamente ya que estoy usando la versión de 64 bits y no todos los drivers funcionan bien. Para los que no tengan ganas de andar resolviendo problemas menores, les recomiendo la versión de 32 bits.

La actualización la hice mediante el Update Manager, la utilidad de actualización de programas y versiones de Ubuntu. Luego de esperar esas 12 horas descargando paquetes de actualizaciones, comenzó el proceso de actualización propiamente dicho.

Este proceso tardó unos 35 minutos. Solo me preguntó si quería actualizar ciertos archivos de configuración o remplazarlos por los nuevos para algunos servicios determinados que dudo que utilice un usuario no técnico (webservers, bases de datos, etc)

Luego de reiniciar el sistema el nuevo Hardy estaba listo, aunque como me pasó en la instalación de Gutsy, la placa de wifi no funcionó automáticamente. Supongo que está relacionado con la instalación de 64bits, porque cuando había instalado Gutsy de 32bits funcionó de entrada. Cuando tenga tiempo pruebo la instalación de Hardy de 32bits.
De todas formas, hacer funcionar la placa fué simple. Solo tuve que instalar los drivers siguiendo los mismos pasos que para Gutsy.

La webcam tampoco funcionó, y encontré que hay un bug reportado en el que están trabajando activamente. Esperemos las primeras actualizaciones para ver si se arregla.

Actualizando un server

Hace rato tengo un server en SliceHost para hacer pruebas y mantenerme un poco al día en el trabajo de sysadmin, ya que ahora estoy trabajando sólo como programador.

En este server estaba corriendo MySQL, Lighttpd, TurboGears, y un par de cositas más, todo sobre Gutsy.

La actualización fue de lo más simple. Hay que bajar el actualizador con el siguiente comando:

sudo apt-get install update-manager-core

y luego, ejecutar la herramienta de actualización de consola:

sudo do-release-upgrade

Otra vez a esperar la descarga de paquetes, pero en este caso la velocidad fue increíble. Se nota la diferencia de acceso a internet que tenemos en sudamerica y la que tienen en EE.UU. En mi casa los paquetes se bajaron a unos miserables 30k/s, en el server, a unos 1000k/s de promedio con unos picos bastante mas altos. En menos de cinco minutos había bajado todos los paquetes para el server.

El proceso de actualización tardo unos 15-20 minutos, las mismas preguntas sobre archivos de configuración de servicios, reiniciar... y todo funcionando exactamente igual que antes: bases de datos, servicios, todo 10 puntos. Ahora tengo un server con 5 años de soporte! Aunque supongo que no me voy a aguantar y en octubre lo paso a la nueva release :)

Conclusión

Sacando los temas conocidos para las MacBook con la placa wifi en 64bits, la actualización fue excelente. Sólo tenemos que conseguir uno o dos mirrors locales en Argentina, porque con cada release, el embotellamiento es más grande.

Cuando pruebe la instalación de 32bits (recomendada para los menos experimentados), les cuento como me fué.

Actualizaciones cuando las necesitas

Una de las ventajas que frecuentemente se mencionan sobre el software libre, es la rapidez con la que se generan actualizaciones.

La semana pasada, se aprobó la ley (en Argentina) que indica que tenemos que adelantar una hora durante el verano para ahorrar energía.

Todo fué muy rápido, y los archivos de configuración de zonas horarios no contemplaban este cambio. Actualizar las definiciones de estos archivos no fué nada problemática para los impacientes como yo, que queremos que todo esté como corresponde (gracias al post de Fer de soluciones3f)

Lo que sí me sorprende es que hoy, primer día hábil del año, veo que en mi Ubuntu tengo actualizaciones disponibles, y cuando abro el Update Manager veo que la actualización es justamente del paquete tzdata, que contiene las definiciones de las zonas horarias.

Quedé sorprendido con la velocidad de respuesta de la comunidad de software libre en general y de Ubuntu/Debian en particular. Teniendo en cuenta que se trataba del último fin de semana del año, y supongo que se debe haber festejado en todo el mundo, la comunidad lanzó el parche el 1ero de Enero a las 13hs GMT, según el changelog:

tzdata (2007k-0ubuntu0.7.10) gutsy-proposed; urgency=low

* Replace tzdata2007j.tar.gz with new version tzdata2007k:
- Updates DST rules for Argentina. (LP: #178924)

-- Martin Pitt Tue, 01 Jan 2008 14:00:20 +0100



No es por buscar pelea, pero...
¿Ya salió el parche para Windows? ;)

¿Es conveniente el voto electrónico?

En base a las irregularidades denunciadas durante las últimas elecciones nacionales, se comenzó a hablar de impulsar el voto electrónico ya que teóricamente estos problemas no pasarían si se usara esta forma de votar.

Como contrapartida, también hay mucha gente que se opone argumentando que el voto electrónico no haría otra cosa que facilitar el fraude escondido detrás del misterio de la tecnología, ya que la mayoría de la gente no podría auditar que ocurre realmente dentro de una máquina de voto electrónico.

En este artículo voy a tratar de contar mi experiencia haciendo una máquina de voto electrónico que se utilizó en las elecciones de presupuesto participativo de la ciudad de Rosario en el año 2006, y cuales son mis opiniones personales sobre el (posible) fraude en las elecciones.

Desde 1995 hasta mediados del 2007, trabajé en una empresa (MSA) que a partir del año 1999 participó en varios procesos de recuentos de votos, en un par de ocasiones implementando algún método de voto electrónico. Aclaro que mis opiniones no son las de la empresa, y no tengo una postura definida sobre si el voto electrónico es mejor o peor que el sistema tradicional (boleta y sobre).

Recuento de votos

Como primer punto, me gustaría comentar que en ninguno de los procesos electorales que hicimos recibimos ningún tipo de presión de partidos politicos, entidades gubernamentales, etc, para influir de alguna forma en el resultado del proceso.

Durante los procesos de recuento, constantemente hay fiscales informáticos de los diferentes partidos políticos pidiendo todo tipo de información, y luego del proceso, generalmente se les da una copia de la base de datos para que crucen los datos con sus propios recuentos. Por ende, no sería una buena idea hacer fraude en este punto ya que sería descubierto tarde o temprano.

Emisión del voto

En el caso de las máquinas de voto electrónico, no es tan fácil auditar todas las máquinas ya que seguramente van a estar distribuidas geográficamente, y se necesita personal capacitado para controlar que no haya fraude. En esto estoy de acuerdo, pero...

Algo que generalmente se deja de lado cuando se ennumeran las características negativas del voto electrónico, es que en realidad el voto electrónico puede ser tan seguro y secreto como se quiera hacer, y por otro lado, el sistema de voto tradicional tampoco asegura que los votos sean registrados correctamente.

Haciendo una analogía un poco apresurada, es como decir que viajar en avión es más peligroso que viajar en auto, porque si se cae no hay muchas chances de salvarse. Es verdad. Pero hay más accidentes de autos que de aviones. De echo, en Argentina cualquiera de las dos cosas son peligrosas... y ese me parece que es la base de ambos problemas: que estamos en Argentina. :(

La máquina de voto electrónico

Cuando hicimos la máquina de voto electrónico, tratamos de hacerla lo más segura, secreta y accesible que pudimos:

• La máquina era un LiveCD que podía funcionar en cualquier PC. De esta forma nadie tenía acceso al software antes de iniciar las máquinas, a excepcion de los auditores del juzgado electoral. Es más fácil mantener seguros unos cuantos CDs no regrabables, firmados fisicamente, que la misma cantidad de máquinas.
• Al votar se emitía una boleta de papel con la selección impresa. La boleta era ingresada en una urna tradicional, y en el peor de los casos se podía hacer el recuento manualmente.
• Los votos no se registraban en la PC. Tampoco en medios remobibles. En la misma boleta de papel se almacenaban los datos del voto en un medio elecrónico no reescribible. No se si la empresa terminó patentando esto, pero a fines prácticos supongamos que imprimimos un código de barras con la información de los votos.
• El elector podía verificar el voto emitido. Aparte de leer el texto impreso en la boleta, ingresando la misma en un lector el sistema le muestra las opciones almacenadas, que deberían ser las mismas que están impresas.
  
• Se podían leer los fuentes del software en ejecución. Dado que el sistema estaba totalmente escrito en Python (que no necesita ser compilado) se daba la posibilidad de auditar el sistema de la máquina leyendo el CD desde cualquier PC.
• Accesibilidad. Gracias a la facilidad de integración de las herramientas que disponemos en el software libre, los usuarios con problemas de visión podían utilizar un modulo especial que leía las opciones sin mostrar nada en la pantalla. Por primera vez, una persona ciega tuvo la posibilidad de votar sin alguien que lo asista, simplemente usando auriculares y un teclado numérico con etiquetas braille.
  

Una vez terminada la elección, el recuento se hizo con el mismo software. Todos los CDs tenían un modulo de recuento, con el cual se juntaban los resultados y se enviaban al centro de computos.

Como se puede ver en una foto que anda dando vueltas por la red, me comí todo el día en uno de los centros de votos asistiendo a la gente en la operación de las máquinas. Algunas de las cosas que pude observar:

• Curiosamente, la gente mayor era la más contenta estaba con el sistema. Los abuelos estaban fascinados, y nos pedían por favor que utilicemos este mecanismo para las elecciones presidenciales (como si fuera nuestra desición :) )
• Al igual que en el sistema tradicional, llegaban micros con gente para votar a quienes les habían dado un papelito con los números que tenían que votar.

En mi opinión, en esto último esta el principal problema, y no tiene mucho que ver con que método se use. Me resultaba increíble ver con que desinterés votaba esa gente. Si bien no se trataba de elegir cargos, votaban sin chistar los números que les habían dado. Parece que les daba absolutamente lo mismo votar, no votar, o que voten por ellos.

En el sistema tradicional, se acostumbra a utilizar otros métodos como el voto cadena o las boletas dobladas de una forma determinada, o sea que este tipo de corrupción no se puede evitar.

Conclusión

Lamentablemente, cualquiera de los dos métodos permite más o menos los mismos métodos de fraude, ya que no hace falta que se hagan en el momento del voto, sino que el fraude ya viene hecho de antes, o se hace después, modificando las planillas de recuento antes que sean procesadas. Esos son los momentos donde es más dificil hacer una auditoria.

Por otro lado, si bien una persona sin conocimientos técnicos no puede auditar una máquina de voto electrónico, tengo entendido que tampoco puede estar presente cuando se abre la urna, se cuentan los votos, y se escribe la planilla de resultados en el sistema tradicional.

En este momento, me parece que la única gran diferencia entre un método y otro es el costo y la velocidad de proceso. Ambos son superiores en un sistema electrónico que en el tradicional: más caro pero más rápido. Supongo que para saber cual es mejor, habría que ver de cuanto dinero se dispone, o cual es el apuro para obtener los resultados.

Más allá de estar o no en contra, pienso que en el futuro el voto electrónico va a ser la norma, ya que toda la sociedad apunta al camino de la tecnología. En este punto me parece que la solución más acertada sería que las organizaciones promotoras de software libre se encarguen de proponer sistemas/máquinas de voto electrónico de código libre. Es sabido que el software libre tiene entre sus ventajas los miles de ojos que lo auditan, imaginense cuantos ojos van a querer auditar el código de una máquina de voto electrónico!!!

Por supuesto esto no asegura que el último código que se ejecute sea el mismo que se escribió, a menos que se usen lenguaje como Python, que permiten leer el mismo código que se está ejecutando.

La comunidad del software libre debería interesarse seriamente en este tema, antes que se haga moneda común que las máquinas de voto electrónico sean algo cerrado y propietario como las que existen actualmente. Ahí si que estaríamos en problemas. Si el único que puede ver que pasa dentro de la máquina es el que la hizo, estoy totalmente de acuerdo... el voto electrónico no sirve.

Gabriel E. Patiño


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

Ubuntu Gutsy 64 bits en la Macbook

El fin de semana instalé la última versión de Ubuntu en la Macbook, y esta vez me decidí por la versión de 64 bits.

Como es de esperar de un sistema operativo como la gente, la instalación fue sin problemas: en menos de cuarenta minutos tenía la máquina lista para usar. Y con esto me refiero a tener un navegador de última generación, una suite de oficina comlpeta, programa de mensajería multiprotocolo, bla, bla, bla.

En el caso de la Macbook, lo único que tuve que hacer a mano fue instalar los drivers para la placa WiFi. Si... tuve que usar la consola:

sudo aptitude install build-essential
wget http://snapshots.madwifi.org/madwifi-trunk-current.tar.gz
tar -zxvf madwifi
cd madwifi
make
sudo make install

Curiosamente la webcam me la detectó de una, aunque en el wiki de Ubuntu dice que no la detecta. Más curioso fué que después de un par de días dejó de funcionar y tuve que seguir las instrucciones del wiki para hacerla andar.

Más allá de estos dos detalles, la máquina funciona diez puntos. Resultado: una máquina con un hardware excelente y un rendimiento espectacular. Todavía no noto la gran diferencia por los 64bits, pero todo parece un poco más rápido, aunque puede ser por las mejoras generales de Gutsy.

Totalmente recomendable Gutsy en 64bits, el gran problema en otras versiones eran los programas cerrados que no tienen una versión de 64bits, como el Flash, pero instalarlo fue cuestión de seleccionar el paquete nspluginwrapper. Y según me comentaron después, de haber elegido la opción de instalar plugins faltantes desde el mismo Firefox, todo hubiera sido automático.

Que esperan??? a aprovechar los 64 bits del micro!!!

CaFeConf 2007

Hace rato que no escribo nada, así que aprovecho para escribir algo sobre las charlas que fui a ver al CaFeConf 2007. Si, seguramente ya leyeron algo sobre esto, y no soy el primero, pero algo es algo.

Mi visita a la conferencia comenzó el día sábado, ya que el viernes tuve que laburar. Como hace rato que no programo nada importante en Python (como lo extraño... ) por la mañana asistí a dos presentaciones de la gente de PyAr:

• PyWeek: Un juego en siete días - Una charla muy entretenida sobre la experiencia de los grupos pythoneros de Capital y Córdoba en la competencia PyWeek, donde el objetivo es desarrollar un juego en sólo siete días. Cada vez que escucho algo sobre el tema me dan ganas de participar, pero cuando llega el momento siempre surge algo que me lo impide.... (cobardía quizás?). Felicitaciones a los integrantes de todos los equipos que participaron, y que nos hacen quedar tan bien en el exterior. Para los que todavía no conozcan Python... bueno... que les puedo decir... es hora de salir de la cubetera :) Deberían ver la calidad de los juegos que hicieron, y sólo en siete días. Pueden ver los resultados de las competencias y descargar los juegos desde el sitio de PyWeek.
  
• Python más rápido que C - Esta charla me encantó. Felicitaciones a Lucio y Facundo, hicieron un trabajo muy interesante tratando de comparar que tan lento es Python al lado de C, arriesgándose a ser lapidados por herejía. Algunas conclusiones fueron muy interesantes y la charla fue por demás entretenida. Fanáticos de C, abstenerse ;)

Al mediodía me fui a comer con Marcelo y un amigo de él. La pasamos bien charlando sobre... si... informática, trabajo... lo de siempre. A ver si nos ponemos las pilas y hacemos algo sobre las experiencias con Python en procesos de misión crítica. Después de comer estuve charlando un rato con Alecu, y me quedó pendiente presentar a Marcelo al resto del grupo de PyAr, pero se me escapó y cuando lo volví a encontrar era tarde.
Después de navegar un rato por internet, leer un par de mails y todas esas cosas que uno hace compulsivamente cuando hay wi-fi disponible (como si no tuviera suficiente internet durante la semana), volvía a las charlas:

• Modelos de negocio con Software Libre - Una charla bastante interesante de Román Gelbort (el profe) sobre las posibilidades de montar un negocio en base al software libre, y de yapa unos cuantos consejos muy útiles, más que nada para los técnicos como yo que nunca pensamos en las betas comerciales.
  
• Aulas libres - La Universidad y el bien común - Esta charla para mi fue casi obligatoria, ya que tiene mucho que ver con el tema de la tesis que estoy preparando (si, todavía no me recibí, y que?). Por momentos Franco Iacomella estaba un tanto nervioso... y no era para menos: se salía de la vaina para decir un montón de cosas que tuvo que recortar sino le iban a cortar la luz... jeje.
  
• ¡Liberemos las Universidades! - Segunda charla obligatoria para mí, más que charla fue una reunión de presentación de alumnos y profesores de diferentes casas de estudio que están involucrándose con el software libre. Lamentablemente, sacando un par de excepciones, todo se hace a pulmón por parte de alumnos y profesores, nada a nivel institucional. Es increíble que las Universidades prioricen pactos comerciales a la educación abierta... pero bueno, estamos en Argentina. Si en tu Universidad hay un grupo de entusiastas del Software Libre, pegate una vuelta por la página de Gleducar, ahí van a encontrar una lista de correo de Universidad Libre.
  

Esa fue la última charla, que fue seguida de un poco de cotorreo generalizado en el hall del 2do subsuelo. Conocer a algunos que no conocía personalmente, posar para una foto de Ubuntu-ar (no se olviden de gimpearme ;).

Por último, el cierre... espectacular el Sr. Pingüino jaja... aunque me parece que tiene que hacer un poco más de ejercicio porque daba la sensación de que le faltaba un poquito el aire... ;) En el cierre se sortearon unos cuantos libros muy interesantes, pero con la suerte que tengo no me gané nada. Es más, cuando revolearon gorras y remeras, una gorra me cayó en la cabeza, y el de al lado me la manoteó... por favor... abstenganse de comentar al respecto.

Cerrando, aunque no pude ir el viernes a un par de charlas que me interesaban, la pasé bien. Me dió la sensación que este año hubo mucho más gente que el año pasado, pero puede ser porque era sábado. De todas formas, mis más sinceras felicitaciones a todos los que colaboraron en la organización del evento... son unos grosos.

PD: Me olvidaba... Los muchachos de PyAr tenían un pare de OLPC par probar... muy interesantes los bichitos. Ya se que están orientadas a los niños pero me sorprendió que sean tan chiquitas... y yo que quería una para mi.. :)

Firebug: Un excelente plugin para el Firefox

Seguramente muchos de ustedes ya lo conozcan, pero para los que no, y sean desarrolladores de sistemas web, les va a ser de suma utilidad.

Estaba acostumbrado a usar el plugin de Firefox WebDeveloper para todo lo que sea debug de páginas web. La semana pasada, Damián (pasame tu blog) me comentó sobre el Firebug (otro plugin para el Firefox)... y quedé alucinado.

Las funciones en general son similares a las del WebDeveloper, pero esta muy bueno como se puede navegar por los componentes de la página mientras se ven marcados de celeste en la pantalla principal, y ni que hablar de poder visualizar variables y expresiones javascript a medida que se va a actualizando la página.

Puede ser que no se emocionen tanto como yo, pero para quien desarrolle web puede ser una herramienta de suma utilidad. Pruebenlo y comenten que les pareció.

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

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.