En esta entrada voy a tratar de plasmar mi experiencia en los dos años que llevo trabajando profesionalmente, de forma seria, con GNU/Linux sobre las distribuciones.

Las distribuciones que he manejado son:

• Red Hat AS 2.x i386 sobre hardware de IBM.
• SLES 8 i386 y ia64 sobre hardware de IBM, HP/Compaq y entornos virtualizados en VMware ESX Server.
• Red Hat AS 4.x x86_64 sobre hardware de IBM.
• Debian Woody i386 sobre hardware de IBM.
• Debian Sarge i386 sobre hardware de IBM y entornos virtualizados en VMware ESX Server.

En el caso de SLES 8, en los Linux físicos, son entornos grandes con acceso a SAN (también de IBM), multipathing y máquinas arrancando desde SAN. Mientras que con Red Hat AS (RHEL de aquí en adelante) es un entorno mediano con acceso a SAN y NAS (esta vez EMC2).

Aunque las conclusiones se acostumbran a poner al final del artículo pondré, de forma resumida, la mía ahora:

Red Hat es un producto inmaduro, calcado de su distribución para escritorio y que a mi modo de ver es bastante mejorable.

SLES 8 es una maravilla y lo poco que pude catar de SLES 9 me dio la misma impresión.

Debian es una solución a tener muy en cuenta siempre y cuando no se vayan a montar productos comerciales.

Análisis de RHEL

Red Hat no incluye ReiserFS y no da soporte. Cuando empecé a trabajar me toco instalar y configurar varios servidores con RHEL 2.x para un banco. Me llamó la atención que se utilizara ReiserFS ya que no venía en la distro y había que descargarlo y compilarlo para utilizarlo, obviamente también había que compilar el módulo para el kernel. Además estaba el hecho de que la gente se quejaba de la falta de estabilidad, corrupciones de datos, ...

Pregunté a mis compañeros el motivo y que había de cierto en eso de las corrupciones de datos y me dijeron que ReiserFS permitía el incrementar los filesystems en caliente (siempre y cuando estuvieran bajo LVM) y que de corrupciones de datos y demás marujeos que había en la red nada de nada. Y puedo atestiguar que hasta el momento el comportamiento de ReiserFS en sistemas en producción del que he podido ser testigo ha sido más que bueno.

No entiendo el motivo de la gente de Red Hat a incluir este sistema de ficheros en las distribuciones de Servidor. ¿Alguien considera normal el tener que parar una BBDD en producción para ampliar un filesystem? En la versión 4.0 han introducido el parche para ext3 en el update 2 o el update 3 y ya es posible hacer el resize online con ext3. Ya iba siendo hora.

He estado utilizando LVM+ReiserFS con RHEL 2.x y SLES8 tanto en máquina física como en virtual y no comprendo la reticencia de Red Hat al respecto.

Otro tema que me llama la atención es el del multipathing. Para los que no lo conozcan en los entornos grandes/medios los datos suelen ir en discos externos en una SAN (discos SCSI accesibles por fibra óptica de forma "muy resumida"). Para que todo este redundado se suelen poner dos tarjetas de fibra o HBAs por máquina y dos caminos por tarjeta. Es decir la máquina llega a los discos por cuatro caminos. Es posible configurar la máquina para que se haga balanceo y todas las operaciones de I/O se lleven a cabo por todos los caminos disponibles o únicamente failover y que se acceda a los discos por un único camino y switcheando de forma transparente al perder la conexión por un camino a otro.

Bien, con LVM1 es posible configurar el multipath aunque sólo funciona en unas versiones muy especificas de LVM. En Red Hat no es posible hacer multipathing mediante LVM y una cosa, cuando menos curiosa, es que cuando un compañero se puso en contacto con el mantenedor de la documentación de LVM, trabajador de Red Hat, esta persona no era consciente de la posibilidad de multipathing a través de LVM.

Otro defecto, y grave, que le veo a Red Hat es que no incluye EVMS (Enterprise Volume Management System), el cual me parece la mejor herramienta que he visto en GNU/Linux para el manejo de filesystems. Cierto es que no he tenido acceso al Volume Manager de Veritas, pero EVMS tiene algo que la fabulosa herramienta de Veritas no tiene. EVMS es libre.

Siguiendo con más carencias. En el proyecto en el que estoy ahora hay que consolidar la infraestructura dispersa por 11 países en un único sitio. Todo esto se va a hacer con RHEL 4.0. Bueno pues cual es mi sorpresa cuando me encuentro que el postfix que viene con la distribución no trae soporte para cuotas, esto puede ser comprensible (quiza), y que ademas no trae soporte para MySQL. Claro, pense yo, es que nosotros somos muy sibaritas y lo normal es que en un entorno con cienes y cienes de usuarios de correo le crees una cuenta shell a cada uno. Pero aunque luego deshabilites el acceso remoto sigue habiendo una serie de implicaciones de seguridad al tener tantas cuentas creadas.

Pero no sólo fue esto, sino que además me encontré que courier-imap no viene en la distribución. Ni clamav tampoco. Ni amavis-new tampoco.Resumiendo para instalar un sistema de correo de lo mas normal postfix+MySQL+amavis-new+clamav+spamassassim he tenido que recompilar y crear casi 60 paquetes RPM, la mayoría módulos de PERL requeridos por amavis-new y sus dependencias.

Lo que terminó por quitarme la poca fe que tenía en Red Hat, si que alguna vez tuve alguna, fue que al recompilar el .spec (fichero a partir del cual se compila y se crea el rpm para instalar el binario) del postfix en la arquitectura x86_64 me toco modificarlo ya que primero no detectaba la librería del MySQL, luego no comprimía bien las páginas man, ... Lo curioso es que si haces lo mismo en la arquitectura i386 ¡funciona a la perfección!

Análisis de SLES 8

Bueno, pues poco hay que decir. Si incluye ReiserFS, con soporte, es posible hacer multipathing con LVM. No incluye EVMS pero también hay que tener en cuenta que esta distribución ya es un poco vetusta (los núcleos son todos 2.4.x), motivo por el cual es achacable a que EVMS no estuviera maduro cuando fue lanzada.

Para ser justos no puedo evaluar el tema del sistema de correo ya que no hubo que montar ninguno en ese proyecto y la mayoría del software que se instalaba eran cosas como SAP, Oracle o aplicaciones propias desarrolladas por el cliente u otro tipo de software de terceros.

El único problema que tuve fue que me toco instalar un SLES 8 en un IBM xSeries 460 con una controladora SeverRaid 8i la cual no esta soportada y el driver que viene en la distro no funciona. Algo que también pasa en Red Hat. Me costo, pero al final encontré no se donde unos drivers compilados para diferentes núcleos y uno de ellos me sirvió para poder instalar. Y de esto se deriva el único fallo que le veo a SLES.

Cuando inicias el proceso de instalación se arranca con un núcleo. En mi caso era con el SP4 y era un 2.4.21-278 (no estoy seguro de la release). Bien, cargando el modulo del aacraid durante el proceso de instalación lograba acceder a los discos y realizar la instalación. Pero, y siempre tiene que haber algún pero, al reiniciar no arrancaba ya que no veía los discos. Claro que no instalaba el módulo correcto. Con lo cual al terminar la instalación tenia que reiniciar en modo rescue. Cargar el módulo correcto. Montar todo el disco en un punto de montaje, copiar el módulo al lugar correspondiente (/lib/modules/....), hacer un chroot y rehacer el initrd. Cual sería mi sorpresa cuando la máquina no arrancaba. El motivo es que al instalar no instalaba un 2.4.21-278, instalaba un 2.4.21-278-smp y claro el kernel no tragaba con el módulo, por lo cual había que volver a arrancar con el SP4 en modo rescue, cargar el módulo de la aacraid para el 2.4.21-278. Montar todo el disco duro en un punto de montaje, copiar el módulo para el 2.4.21-278-smp a su lugar correspondiente, hacer un chroot y regenerar el initrd. Aunque parezca que quejarse de esto es una tontería no lo es. Cuando tienes un huevo de trabajo, te encuentras con esta situación en la que esas dichosas máquinas tardan en arrancar una eternidad y te toca hacerlo varias veces quedas un puntin quemado. Cuatro reinicios de máquina a unos 5 minutos por reinicio. Añadir el tiempo que se tarda en instalar y demás y en apagar la máquina.

Habrá gente que se piense:

1) Yo habría recompilado el módulo y me hubiera dejado de tonterías con buscar un driver precompilado. De haberlo hecho así se hubiera perdido el soporte en algo tan crítico como el acceso a los discos. Además de que al principio si encontré los fuentes buenos, pero en una equivocación los borre y luego desaparecieron de la página de IBM y no hubo manera de encontrarlos, con lo cual estábamos restringidos a encontrar alguno precompilado.

2) Yo la habría instalado arrancando desde SAN y me hubiera evitado el problema de la controladora SCSI. Efectivamente, eso es lo que hacíamos normalmente. Pero aquí había un problema grande que lo desaconsejaba. Era necesario instalar un producto de SAP que sólo funcionaba en SLES 9 y no en SLES 8. Con lo cual había que instalar un SLES 8 e instalar la versión vieja de SAP, que si funcionaba en SLES 8. Importar los datos y la aplicación en producción. Migrar a SLES 9 y luego migrar el SAP. De haber instalado arrancando desde SAN tendríamos un problema muy grande y es que el multipath en SLES 8 se estaba haciendo con LVM1 mientras que en SLES 9 había que hacerlo con device-mapper (o bien con SDD, driver multipath de IBM) con lo cual la migración de SLES 8 a SLES 9 se tornaba muy peligrosa y como el proyecto además de urgente era crítico para el cliente la mejor opción era la que se tomo.

Todo esto junto con el driver inadecuado y la diferentes versiones de núcleo son el único punto negro que le he encontrado a SLES 8.

Análisis de Debian

El mayor problema que le veo a Debian es el tema del soporte. Aunque el otro día me lleve un casi alegrón. Resulta que Veritas soportaba Debian en sus productos, no se si todos. Pero en las versiones nuevas los deja de soportar según me comentó un empleado de Veritas.

El tema del soporte es una putada y gorda por un motivo:

1) No hay nadie que te garantice que ante un problema se te va a solucionar en poco tiempo.

Parece una tontería ya que si has tratado con el soporte que te dan las compañías comerciales al uso la mayoría es pésimo. Pero bueno, si se tiene soporte y al responsable le exigen explicaciones del motivo por el cual no funciona algo siempre puede, y de hecho lo hace, cargar las culpas al soporte que no nos dan una solución, ...

Hasta el momento nunca he tenido que tratar con el soporte ni de SLES ni de Red Hat, si con el de VMware que me parece pésimo y lento.

Como anécdota. Se recomendó el uso de Debian en un cliente, sobre itanium, para instalar una aplicación desarrollada por el cliente. Era una especie de cluster HPC para cálculo científico. Digo especie porque el cluster era una única máquina, un itanium de 8 vías. Todo esto lo cuento desde la barrera ya que yo no llevaba ningún tema de este cliente. Eran mis compañeros.

No se quiso por el tema del soporte y se eligió Red Hat. Se instaló la versión 4 que acababa de salir (en contra de la opinión de nuestro responsable y nuestra). Nos encontramos con que la máquina tenia un uptime increíblemente alto, 20 minutos. ¡Viva Red Hat! al final se instaló la versión 3.0. Había que hacer unos backups a discos USB y el USB 2.0 no funcionaba. El soporte de Red Hat no daba ninguna solución que funcionara y se estuvo más de un mes con el tema. Al final no se si se soluciono.

Cuando mi compañero, Debianero a más no poder, andaba lidiando con el soporte de Red Hat. Recibí una petición de grupo de comunicaciones ya que había problemas con los balanceadores de carga que había montado con Debian en un entorno virtualizado. No funcionaban.

Después de un rato de investigación observe que al compilar el paquete del keepalived se compilaba contra la librerías del ipvs del núcleo 2.6 en lugar de las del núcleo 2.4. No fui capaz de solucionarlo, con lo cual me puse en contacto con el mantenedor del paquete Debian y me sugirió que utilizara un núcleo 2.6 que estaba más optimizado e iba a sacar más rendimiento. Le conteste que tenía toda la razón, pero que lamentablemente con el 2.6 teníamos serios problemas de estabilidad ya que estábamos en un entorno virtualizado y por ello habíamos tenido que utilizar un 2.4. 30 minutos después de mi primer correo solicitando ayuda tenia una versión del sources que compilaba bien. Según palabras textuales del mantenedor era una chapuza pero funcionaba y con el tiempo ya lo dejaría bonito.

Debian 30 minutos (y gratis), Red Hat más de 30 días (y pagando).

Cierto es que esto no garantiza que con Debian vaya a ser siempre igual de rápido y/o eficiente. Pero en mi experiencia profesional el soporte de los voluntarios de Debian es el mejor que he tenido tanto en calidad, como en precio.

Otra cosa que no me gusta demasiado y que es muy frecuente, salvo en Debian :-), es que hay dependencias "estúpidas" y es que se compilan algunos programas con dependencias de LDAP o NIS por si se utilizan estos servicios. Algo que esta muy bien. Pero es preferible tener varios binarios del mismo software:

- postfix
- postfix-ldap
- postfix-mysql

y que dependiendo de tus necesidades instales el que necesites. Siempre puedes recurrir a recompilar, pero el tema de perder el soporte no es aconsejable y muchas veces no es asumible (aunque no valga para mucho).

El motivo de esto es que muchas veces es necesario tener instalado software, por ejemplo relacionado con LDAP, que no es necesario únicamente por las dependencias del paquete. Esto tiene dos problemas asociados:

1) Cuanto más software haya instalado en la máquina más vulnerabilidades o fallos de configuración pueden afectar a la máquina.

2) Es necesario instalar las actualizaciones de seguridad de este software para evitar agujeros en la seguridad, aunque no se utilicen. Esto tiene una problemática y es que muchas veces es necesario actualizar librerías del sistema y si tenemos software instalado ajeno a la distribución es posible que alguna de esas actualizaciones de librerías no este certificado y el producto deje de funcionar o haya que esperar a que se certifique esa versión y tener el sistema desactualizado con el consiguiente riesgo.

Mis conclusiones

Si se va a utilizar software libre Debian o SuSe (Novell para los puristas :-)), si se va a utilizar software comercial SuSe o Red Hat (ver antes la matriz de certificación del fabricante). Pero sobre todo que los técnicos tengan sentido común, sean competentes y que no tengan miedo de preguntar a quien fuere menester. Parece una tontería pero hay muchos que prefieren probar algo en una máquina de producción antes de preguntar ya que les parece que están demostrando ignorancia al preguntar.

Personalmente me decanto por Debian sobre todo lo conocido y probablemente, aunque con cautela, sobre todo lo que venga. Profesionalmente con SLES que me sigue pareciendo una maravilla a pesar de los incovenientes que le encuentro.