Leyendo el post de Ramón Ramón  sobre “La falsa creencia de la propiedad y las licencias privativas” se me ha ocurrido escribir sobre otro aspecto diferencial entre el software libre y el software propietario: El soporte.

Primero un gran disclaimer: Trabajo para Red Hat  y además he trabajado para el departamento de Soporte  , y aunque intento siempre ser objetivo a veces mi pasión por el software libre me puede :) También tengo amigos que trabajan o han trabajado en departamentos de soporte de otras grandes empresas como Canonical, Oracle, RSA o Rackspace. Además quiero dejar claro que este post es una opinión puramente personal y no tiene vinculación ningún con mi empresa.

Ahora al lío: El tipo de licencia de un software no tiene nada que ver con el soporte que vas a recibir por él, como dice el post de Ramón Ramón , la licencia de un software privativo sólo te da derecho a usarlo, de hecho normalmente no es que te dé derecho a usarlo, sino que te restringe en que puedes usarlo y en que no, además durante un tiempo determinado. Además la empresa propietaria del software se guarda el derecho a no renovarte la suscripción, aumentar el precio en el futuro o simplemente descontinuar el producto.

Sobre el soporte del software libre hay 2 tipos bien diferenciados, el soporte de “la comunidad” y el soporte empresarial que ofrecen muchas empresas como Suse, Canonical o Red Hat.

El soporte “comunitario” no es más que aquel que puedes encontrar por parte de usuarios o desarrolladores de ese software, ya sea en blogs, foros, wikis, es decir contenido “estático” o mediante interacciones: Listas de correo, herramientas para reportar problemas (tipo http://bugzilla.redhat.com) o canales de irc

Este tipo de soporte tiene sus ventajas: es muy abundante, es gratis y en muchas ocasiones te puedes encontrar interactuando con el creador(es) del propio software. Pero también tiene sus problemas: falta de organización, no tiene tiempos de respuesta definidos y evidentemente no tienes forma de “quejarte” si crees que no estas recibiendo el soporte adecuado.

Pero es mentira que el software libre no disponga de soporte empresarial, como ya he nombrado hay muchas empresas que si dan soporte:
Red Hat
Canonical
Suse
Puppetlabs 

Desconozco en detalle como trabajan otras empresas de software libre, pero estoy seguro de que ofrecen un soporte excelente, pero puedo aprovechar para hacer una breve introducción al soporte de Red Hat, que espero que ayude a desmitificar la idea de con el software libre todo tienes que hacerlo tu mismo.

  • Red Hat Enterprise Linux ofrece un ciclo de vida de soporte de 10 años, extensibles otros 3 años, con diferentes etapas. Aunque personalmente me parece una mala idea tener en produción un software con tanto tiempo.
  • Como ya he dicho, Red Hat ofrece tiempos de respuesta definidos, además para ciertos tipos de incidencias , aquellas en las que se está impactando la produción, el soporte es 24×7
  • La forma de acceder al soporte de Red Hat puede ser via web (mediante casos de soporte o via chat una vez abierto el caso), por email (una vez abierto el ticket via web) o por telefono. Además en algunas ocasiones se pueden tener sesiones remotas 
  • La base de datos de conocimiento de Red Hat  es el mejor sitio para buscar información, los artículos que aparecen son artículos aprobados por Red Hat, basados en casos reales, se van actualizando y puedes comentarlo en un caso abierto con soporte. Personalmente hay 2 cosas que no me gustan: Que requiera login para ver los artículos (aunque cualquiera puede crearse una cuenta) y el motor de búsqueda no funciona del todo fino.
  • Que está incluido en el soporte de Red Hat? Pues la regla básica es “Lo que distribuimos es lo que soportamos”  Pero ante la duda siempre abrid un caso y preguntar.
  • El soporte de Red Hat no está solo para incidencias, sino que está también para otras muchas cosas: petición de nuevas funcionalidades  , reportar problemas, mejoras de la documentación, revisiones de arquitectura de ciertos productos (Cluster o RHEV por ejemplo), grupos de discusion , laboratorios de soporte  , certificación de hardware, etcétera
  • Si la atención que se recibe no te parece satisfactoria siempre puedes requerir una escalación  o incluso llamar directamente al móvil a uno de los directores de soporte de tu respectiva zona horaria .
  • A la hora de abrir casos de soporte, Red Hat tiene varias herramientas que se utilizan para recopilar información sobre los sistemas, de forma que sea más fácil resolver los problemas: sosreport  , kdump-crash , spacewalk-debug , etcétera
  • Además dependiendo del nivel de soporte necesario, Red Hat ofrece otros servicios asociados como Technical Account Manager  o Support Relationship Manager 

Bueno como todos probablemente hayáis leído, ha aparecido un bug de OpenSSL que podría permitir el robo de información, que en otras condiciones estaría protegida por el cifrado SSL/TLS.

Voy a dividir el post en 2 partes, la primera la técnica:

Se puede encontrar más información en http://heartbleed.com/ y puedes ver si un sitio está afectado usando https://code.google.com/p/go/downloads/list También hay una herramienta online, pero no es muy buena idea usarla: https://gist.github.com/janl/10107626

El bug se resolvió de forma muy rápida, por ejemplo en Red Hat no pasaron ni 24 horas:
https://rhn.redhat.com/errata/RHSA-2014-0376.html

Y por ejemplo en Red Hat, no afectaba a ninguna de las versiones de RHEL 5, y en RHEL 6 solo afectaba a la ultima versión la 6.5.
https://access.redhat.com/site/solutions/781793

El problema se soluciona actualizando simplemente el paquete openssl, y después de hacerlo hay que tener en cuenta que hay que reiniciar todos aquellos servicios que estén usando la versión antigua, se puede comprobar usando el comando:
“lsof -n | grep ssl | grep DEL”

Ahora la parte menos técnica:

En Linux (Red Hat, Debian, Ubuntu…) había un fix en apenas 24 horas, que hubiera pasado si fuera un sofware privativo, como Microsoft o Apple? Pues nunca sabremos la respuesta, pero tenemos ejemplos pasados de retrasos en problemas parecidos:
http://www.forbes.com/sites/andygreenberg/2014/02/25/apple-patches-its-gotofail-security-bug-for-osx-after-four-days-of-heckling/
http://microsoft-news.com/microsoft-finally-fixes-the-svchost-bug-in-windows-xp-after-years/

Ojo, estoy totalmente desconectado del mundo privativo, así que no sé si los ejemplos que pongo son algo aislado, pero por los titulares que suelo leer, creo que no.

Otro tema a tener en cuenta que comentaba https://twitter.com/pantulis/ aquí https://twitter.com/pantulis/status/453508912327974912 era la problemática de que los clientes valoren el mantenimiento y de la plataforma/sistema operativo, que está alrededor de una solución.

Desde mi experiencia como administrador de sistemas y como consultor: Nadie lo valora hasta que tienen un problema, por eso hace años que cuando algún familiar o conocido me pregunta por temas de hosting o similar, siempre les oriento hacia soluciones de hosting compartido, en las que pagas a una empresa para que (al menos supuestamente) se encargue de todo este mantenimiento.

Además, por desgracia, esto también pasa no solo de cara a clientes que solo ven en la tecnología un medio para su negocio, hay empresas de tecnología que ni siquiera tienen definido ciclos de vida de sus soluciones, ni definidas políticas de parcheado.

Por último como comentario “corporativo”, para entender como Red Hat entiende los ciclos de vida del Sistema Operativo:

Red Hat no diferencia entre versiones “menores”, es decir, para Red Hat, solo existe RHEL 6, lo de RHEL 6.1, 6.2, etcétera son sólo imágenes iso que se sacan cada cierto tiempo, cuando se saca alguna actualización, que pueden ser de seguridad, arreglo de fallo o nueva funcionalidad, pues se incorpora directamente en el canal (repositorio) de RHEL 6, pero no a las isos que siguen siendo las mismas.

Para la gestión del software del sistema operativo Red Hat ofrece, Red Hat Network Satellite, con este producto, entre otras muchísimas cosas, lo que dispones es de un “Canal” (algo parecido a un repositorio) que se sincroniza con Red Hat Network para tener las ultimas versiones de todos los paquetes RPM. Hasta aquí nada nuevo, la ventaja es que además permite “clonar” estos canales para adaptarlos al ciclo de vida de la empresa, que puede ser por versiones menores, o cualquier otro criterio. Además desde la interfaz web o mediante la API, podríamos actualizar sistemas o grupos de sistemas en base a muchos criterios:
– Cambios de versión (la que haya definido el cliente)
– Aplicar sólo actualizaciones de seguridad
– Aplicar sólo actualizaciones relativas a una(s) errata(s)

Permite también obtener informes para ver las erratas pendientes de aplicar a estos sistemas y un largo etcétera de utilidades para la gestión del ciclo de vida de los sistemas.

Pero incluso si solo dispusieramos de repositorios RPM, y aunque tuvieramos que hacerlo uno a uno en cada sistema, mediante yum también podríamos:
– Comprobar si un sistema está afectado o no por una determinada errata o alerta de seguridad
– Aplicar sólo actualizaciones de seguridad
– Aplicar sólo actualizaciones relativas a una(s) errata(s)

Y por supuesto en el resto de distribuciones Linux seguro que hay alternativas parecidas para hacer lo mismo, en definitiva, que es un problema más de estrategia corporativa y de mentalidad que técnico, y por desgracia no se valora el trabajo “en la sombra” de los administradores de sistemas.