Problemas comunes al usar Software Libre como herramienta de desarrollo tecnológico

Hace ya algún tiempo hable sobre el uso del Software Libre como herramienta para el desarrollo de la Sociedad de la Información en México (ver [Domínguez, 2010]), hoy día algunas cosas han cambiado y he compartido experiencias de uso del Software Libre en México con diferentes personas ya sea en cuestión académica o laboral.

Estas experiencias no son del todo positivas y para explicar esto voy nuevamente a citar nuevamente una definición indispensable, la Sociedad de la Información:

Es una forma de desarrollo económico y social en el que la adquisición, almacenamiento, procesamiento, evaluación, transmisión, distribución y la diseminación de la información con vistas a la creación de conocimiento y a la satisfacción de las necesidades de las personas y de las organizaciones, juega un papel central en la actividad económica, en la creación de riqueza y en la definición de la calidad de vida y las prácticas culturales de los ciudadanos.[Delors, 1993]

Bajo esta definición entendemos que si bien es impensable la existencia de este desarrollo sin los beneficios que hoy obtenemos con las Tecnologías de la Información, la base real para que éste modelo sea posible lo encontramos en la información porque de ella se obtiene el conocimiento, es decir, las TIC son en realidad una herramienta y no un fin; no servirá de nada que una persona sepa como manejar una computadora si no genera contenidos útiles para mejorar su calidad de vida.

Ahora bien, en las instituciones educativas hay personas que ven a la Sociedad de la Información como una oportunidad para que los estudiantes puedan aprender de manera más rápida y con mejor calidad los contenidos y las materias, incluso algunos ponen su meta en la generación y diseminación de conocimiento generado dentro de las aulas y los laboratorios.

Para aprovechar esta oportunidad es necesario tener el control necesario sobre las herramientas que utilizarán para conseguir sus metas particulares. Una de las herramientas más utilizadas consciente o inconscientemente es el Software Libre, porque ofrece ventajas de control y manejo de la información que ningún otro modelo de tecnología ofrece. A pesar de esto siempre surgen errores al momento de aprovechar la tecnología a nuestro favor entre los que destacan por su frecuencia:

  1. Creación de proyectos de software innecesarios.
  2. Los proyectos de software implementados no son utilizados.
  3. Seguir pensando que el software de código cerrado es la mejor opción.

Es momento de hablar de cada uno de ellos más a fondo.

Creación de proyectos de software innecesarios

Las instituciones con frecuencia requieren optimizar sus procesos, no importa el área de la institución de la que estemos hablando. Con esa misma frecuencia se inicia un proyecto de software que solucione la necesidad que acaba de aparecer.

En la UNAM donde hasta hace poco fue mi lugar de trabajo, una de mis primeras tareas asignadas fue la creación de un directorio para la división, directorio que no existía por la falta de políticas internas. De este modo se inició un proyecto de creación de un pequeño sistema de base de datos para resolver este problema. Sin embargo, el proyecto no se terminó; a las pocas semanas habían nuevos proyectos de mayor prioridad.

Independientemente de los problemas de política interna y prioridad de proyectos, es importante señalar el error de crear un proyecto de software cuando se tiene conocimiento de la existencia de software elaborado para resolver tareas que dentro de una organización son comunes. En este caso particular es posible nombrar proyectos como OpenLDAP para hacer la tarea y ahorrar tiempo de implementación, desarrollo y teniendo las ventajas que ofrece un protocolo estandarizado.

El caso se repite comúnmente, en la Escuela Nacional de Antropología e Historia (ENAH), fue mencionada la idea de iniciar el proyecto de una distribución de GNU/Linux orientada a las funcionalidades requeridas por el laboratorio de lingüistica de la institución.

En esta ocasión estamos tratando otro matiz del mismo problema. Todos los programas libres usados por estudiantes y maestros del laboratorio son fácilmente instalables por muchas distribuciones GNU/Linux ya existentes y cuyas comunidades son grandes y mantienen los programas actualizados. Entonces, no existe razón para crear un proyecto independiente cuando la mejor opción es integrarte a uno que ya funciona e incluye los objetivos que están trazados por la institución y además pone a disposición una comunidad sólida y más grande.

El Software Libre es viable en las organizaciones porque permite aprovechar proyectos existentes permitiendo ahorrar tiempo y dinero, al mismo tiempo permite integrarse a una comunidad de usuarios y desarrolladores que ofrecen orientación y soporte.

Los proyectos de software implementados no son utilizados

Este es quizá la causa principal de fracaso de proyectos de Software Libre alrededor del mundo. No existe proyecto de Software Libre sin comunidad. Que existan usuarios dispuestos a usar las implementaciones de proyectos es imprescindible y al parecer es lo último en lo que se piensa cuando se inicia un proyecto en algunas instituciones.

Retomaré el caso de la ENAH donde el portal Campus Virtual (una implementación del software Moodle), es desconocido por una porción nada reducida de la comunidad estudiantil y pocos profesores fomentan su uso.

Los aspirantes para el ingreso a la institución obtienen acceso al Campus Virtual con un número de aspirante y contraseña al contenido correspondiente de un curso propedéutico. Después, los alumnos aceptados no tienen información sobre el portal, si ya no son aspirantes ¿Dónde obtienen su cuenta de alumno para acceder a nuevo contenido? De hecho en toda la escuela no hay a disposición un folleto informativo sobre Campus Virtual, ni se escuchan las ventajas que se tiene al usarlo o los servicios que ofrece el mismo.

Aquí es importante tener en cuenta que la sensibilización al usuario es uno de los primeros aspectos a tener en cuenta cuando se inicia un proyecto. El software es solo una herramienta como se dijo al inicio de este artículo y el manejo y generación de la información es lo realmente importante, mostrar al usuario como las soluciones implementadas pueden ayudarlo y hacer una diferencia positiva real en sus actividades es importante para el éxito de todo proyecto.

Además es obligación de la institución ofrecer servicios de calidad que proporcionen la confidencialidad, integridad y disponibilidad de la información suficiente para que el usuario se sienta seguro al usar estos servicios. Lo mencionado anteriormente solo es posible apegándose a estándares y protocolos fuertes, configurando y modificando el software implementado de forma ordenada y siguiendo metodologías confiables al mismo tiempo que se sensibiliza al usuario.

Seguir pensando que el software de código cerrado es la mejor opción

Un escenario común es cuando el software seleccionado no realiza todas las funciones necesarias o pueden ser difíciles de realizar para una puesta a punto. Al encontrarse con este problema las instituciones ven dos soluciones inmediatas:

  1. Compra de software comercial que comúnmente no es de código abierto.
  2. Compra de hardware optimizado para realizar específicamente una tarea.

La solución número uno rompe con el esquema planteado por el Software Libre. Si bien ya se han discutido formas para la permanencia de este tipo de software en proyectos de migración al Software Libre[Domínguez, 2010] no es conveniente la introducción de este software nuevamente pues rompe el esquema y los objetivos que se tienen al optar por el uso de Software Libre.

La segunda solución es bastante discutible y de razones mucho más técnicas. En realidad la diferencia entre un servidor de uso general y uno optimizado para realizar una tarea específica (appliance) no se encuentra en el hardware porque pieza a pieza el servidor puede ofrecer las mismas prestaciones en este sentido. La diferencia está en el software. Un appliance es una computadora cuyo software esta limitado para ofrecer soluciones a ciertas tareas previamente definidas. Podemos elaborar listas enormes por las cuales es conveniente usar un appliance y decir incluso que son una gran idea pero también hay razones para tener cuidado al seleccionar estas soluciones. Entre las razones que hoy nos atañen destaca que estas computadoras no son actualizables, el hardware esta cuidadosamente seleccionado para que no pueda cambiarse por cuenta propia. El software es obligatorio generalmente no se proporciona el código fuente del mismo por lo que puede ser una ayuda o bien, llegando al extremo quizá, se este comprando una computadora limitada con un malware instalado como sistema operativo[Doctorow, 2011].

Esto puede parecer paranoico para muchos y seguramente será el menor de los males cuando hablamos de ofrecer servicios a un grupo de usuarios, sin embargo, podemos calificar como appliance otros sistemas usados en áreas mucho más sensibles, por ejemplo en la medicina y me refiero a algo como un equipo de cirugía hasta un marcapaso electrónico donde una falla tiene consecuencias mucho peores y podemos ver una vez más que la tecnología no es el fin sino el instrumento.

Entonces, antes de favorecer la compra de un appliance, la solución recomendable esta en el modelo de Software Libre, nuevamente sabemos que falta programar herramientas bajo este esquema y es por eso que las organizaciones tienen área de desarrollo de software.

Pero ¿Qué debemos programar realmente si ya sabemos que no debemos crear proyectos innecesarios? Pensemos en un sistema GNU/Linux instalado en una computadora de uso general, ¿Qué necesitamos? un navegador web, un programa de mensajería, un cliente de correo, un reproductor multimedia, un editor y un procesador de textos e imágenes, todo eso ya esta disponible, entonces podemos intuir que cuando decimos que al Software Libre le faltan aplicaciones nos referimos a esas aplicaciones que una organización desarrolló para su uso interno y/o para ofrecer un servicio específico (como sus aplicaciones web) y no tienen un sustituto libre. Algunas de estas aplicaciones podrán ser instaladas con uso de herramientas como Mono pero las restantes junto con las nuevas aplicaciones que tampoco tengan una opción libre serán programadas al igual que las modificaciones necesarias para que los programas cumplan a cabalidad las necesidades del usuario.

Curso de Becarios CUAED

Resulta que después de un tiempo sin hacer de maestro, me encuentro enseñando sobre GNU/Linux a un grupo de becarios (3 mandriles) en CUAED. Con ese propósito he utilizado un pequeño documento que contiene las bases de este sistema operativo, uso de comandos y algunas cosas que creo son interesantes para el usuario que pretende ser administrador.

El documento esta disponible en formato de texto plano aunque los usuarios de Emacs pueden verlo con org-mode de una forma más fácil.

Descargar

Balanceador de cargas con Haproxy

En el trabajo se tiene un problema, servidores web implementados con websphere que suelen saturarse, ya sea en el número de usuarios o en requerimientos de hardware.

Actualmente se implementa una forma de enrutar a diferentes servidores basado en un round-robin simple sin embargo es complicado implementar un contador de tiempo en este caso por la alta cantidad de usuarios, además resulta innecesario al contar con balanceadores de carga que implementan una serie de algoritmos de forma completa.

Una solución sencilla entonces es tener un balanceador (LB1) que reciba las peticiones de los clientes, el cual opere de la siguiente manera (imagen obtenida de Internet, pero no recuerdo el sitio :( ):

  • Si una petición no contiene una cookie de asignación de servidor, será enviado a un servidor válido.
  • Se regresa una cookie llamada SERVERID con el cual es posible organizar la respuesta del servidor y continuar la conexión si este ofrece keepalive (HTTP 1.1).
  • Cuando el cliente haga una nueva petición la cookie SERVERID hará que la sesión del usuario pueda pasar a cualquier servidor de la granja o que permanezca directamente en el primer servidor asignado. La cookie nunca es enviada fuera de LB1 por lo que no existe riesgo de seguridad.
  • Si un servidor es retirado, saturado o simplemente cae de la red, las peticiones serán reasignadas a otro servidor inmediatamente y sin tener que volver a iniciar la sesión.

El software Haproxy da la oportunidad de elegir entre varios métodos de balanceo:

  • Round Robin
  • Número de conexiones
  • Fuente de la petición
  • URI
  • Parámetros en la URL

Además puede ajustar el número máximo y mínimo de conexiones concurrentes a manejar, tiempo de vida de las conexiones con el cliente y el servidor, gestión de colas, emular servidores virtuales, configurar servidores de respaldo y crear granjas de balanceadores, así se afianza la disponibilidad del servicio. Además brinda un monitor de los servidores virtuales y los servidores físicos.

Haproxy funciona en la en la capa 4 del modelo OSI y puede escalar parcialmente a la capa 7, por lo que puede optimizar el protocolo TCP y reconocer opciones de HTTP.

Haproxy actualmente está configurado así:

# El frontend es el servidor virtual

frontend FONDOS 172.16.6.105:7070

# Escucha a otros puertos que corresponden a los servidores reales

bind :9093

bind :9097,:9098

# Lee la URI y decide una acción

acl fondos2_rule url_dir FONDOS2

use_backend FONDOS2 if fondos2_rule

default_backend FONDOS

# El backend es una granja de servidores

backend FONDOS

# Se crea una cookie que mantendrá la asignación del servidor

cookie SERVERID insert nocache indirect

server epmwserv epmwserv.main.unlugar.mx:9093 cookie K check

server hrmsepws hrmsepws.main.unlugar.mx:9093 cookie L check

backend FONDOS2

cookie SERVERID insert nocache indirect

server epmwserv epmwserv.main.unlugar.mx:9098 cookie M check

server hrmsepws hrmsepws.main.unlugar.mx:9097 cookie N check

Ventajas:

  • La IP de Haproxy es 172.16.6.105 y existe un servidor virtual llamado FONDOS que escucha el puerto 7070, esta es la entrada general.
  • El servidor virtual tiene 2 granjas de servidores (FONDOS y FONDOS2).
  • Dependiendo de la URI el servidor virtual eligirá una granja de servidores para responder la petición, la condición es si el servicio está contenido en FONDOS, ejemplo: /psp/FONDOS/?cmd=login&languageCd=ESP o FONDOS2, ejemplo: /psp/FONDOS2/?cmd=login&languageCd=ESP
  • Las conexiones atendidas son cerradas, por lo que se reduce el riesgo de la denegación de servicio.
  • Es posible crear colas y balanceo por pesos si es que se supera el número de conexiones posibles.
  • Permite tener periodos de mantenimiento donde el servidor sea deshabilitado totalmente o solo para nuevas conexiones.

Notas:

  • Si un cliente usa HTTP/1.1 solo la primera respuesta será analizada e ignorará la cookie. Además ocupará permanentemente los recursos de red. La solución es deshabilitar las conexiones permanentes con la opción httpclose.
  • LB1 es un servidor sensible. Todas las conexiones pasan permanentemente por el proxy, si este cae las conexiones establecidas se perderán también. Es recomendable usar un respaldo permanente.
  • El cambio de configuración del proxy llevará a la caida del servicio, esto es evitable si se actualiza la configuración sin que el servidor se detenga:

haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid –sf $(/var/run/haproxy.pid)

Por hacer:

Hacer que FONDOS y FONDOS2 trabajen como una sola aplicación porque de hecho contienen lo mismo, solo de que subcarpeta donde están instalados es diferente.

Recursos:

Archivo de configuración completo de Haproxy

Comando de reinicio de Haproxy

Fuentes:

http://haproxy.1wt.eu/download/1.4/doc/configuration.txt

http://www.exceliance.fr/en/ART-2006-making%20applications%20scalable%20with%20LB.pdf