Si seguisteis la entrega anterior de esta saga, deberíais estar con una lista de requerimientos y una decisión más o menos en firme de qué distribución de Linux usaremos para cumplir nuestros requerimientos (seguramente Debian o CentOS).

El paso siguiente es lanzarse a la piscina. Como dijimos anteriormente, una herramienta muy interesante a utilizar es la virtualización. La virtualización nos permite poder hacer instalaciones de sistemas operativos dentro de nuestro ordenador habitual, completamente aisladas del resto de nuestro entorno y con posibilidad de crear tantas instancias como queramos, de los sistemas operativos que queramos y crearlas, eliminarlas, arrancarlas y pararlas con total libertad. El único requisito duro que necesitamos es memoria; una máquina virtual consume en general tanta memoria como la que tenga la máquina que estemos virtualizando. A pesar de ello, hasta los ordenadores modernos más asequibles cuentan con respetables cantidades de memoria, y para muchas cosas, nos bastará para los habitualmente modestos requerimientos de lo que queramos montar (los ordenadores de hoy en día vienen con 4gb de RAM o más, y para una típica máquina con Linux, Apache, MySQL, etc. nos pueden bastar 256 o 512mb). Otro punto a tener en cuenta es la CPU- si bien en general no necesitaremos una CPU muy potente (una vez más, los requerimientos de CPU de los montajes habituales son bastante modestos), es interesante que nuestra CPU cuente con las extensiones de virtualización, que nos pueden facilitar la vida. Por último, en disco con unos 20-30gb libres por máquina virtual que deseemos suelen ser más que suficientes.

Respecto a los sistemas de virtualización, ciertamente existen muchos, pero cuando quiero virtualizar sistemas “de prueba” a los que quiero acceder desde mi ordenador de escritorio, me decanto por VirtualBox, un excelente sistema de virtualización de Sun Oracle,  totalmente gratuito y perfectamente funcional, que cubre perfectamente todo lo que le podamos pedir a un sistema de virtualización “de escritorio”.

Con VirtualBox instalado y la ISO del sistema operativo que queramos instalar, nos podemos poner en marcha; creamos la máquina virtual, le conectamos la ISO y nos ponemos con el proceso de instalación. La instalación de sistemas operativos Linux se ha simplificado mucho en los últimos tiempos y, especialmente en una máquina virtual donde prácticamente no hay problemas de hardware, la instalación tiende a ser extremadamente sencilla. Unos puntos a tener en cuenta:

• Particionado. A pesar de que muchas distribuciones nos pueden sugerir un particionado complejo, si no tenemos muy claro lo que hacer, o aceptamos la opción por defecto de la distribución o usamos una simple partición para todo. Usar particiones puede tener algunas ventajas, pero muchas veces nos hacen “predecir” erróneamente el uso de disco que haremos y causarnos dolores de cabeza. Con una partición única nos ahorramos estos problemas
• Usuarios. Es siempre preferible acostumbrarse a usar un usuario no privilegiado personal y usar sudo para escalar privilegios. También es interesante tener un usuario de root, con una contraseña guardada en lugar seguro para posibles emergencias. Por supuesto, toda contraseña debe ser aceptablemente segura (que no sea fácil de acertar; yo recomiendo memorizar una frase de unas cuantas palabras, usar las iniciales de las palabras y añadir algún que otro dígito; e.g. cogiendo el título de este artículo, lgdagalads2)
• Reloj. La hora de un sistema es más importante de lo que parece para su funcionamiento correcto y pese a que un reloj mal configurado puede no causar problemas, nos simplifica mucho la vida que el reloj sea fiable (por ejemplo,  a la hora de revisar logs es importante que estos “digan la verdad” respecto a la hora). Si la distribución no nos ofrece sincronizar el reloj con un servicio como ntpd, es conveniente que lo configuremos nosotros.

En todo caso, ya durante la instalación debemos aplicar una mecánica imprescindible para que todo sea correcto. Se trata de documentar. Debemos ser capaces de reproducir exactamente todo lo que realicemos para poner nuestros servicios en funcionamiento. Tras el proceso de instalación y configuración, debemos obtener un documento que contenga todo lo que hacemos y que nos permita instalar otra máquina exactamente igual. Esta documentación es extremadamente útil:

• Nos permite reconstruir la máquina en caso de necesidad, o crear un clon para hacer pruebas
• Es una guía estupenda para saber cómo está configurada la máquina
• También nos sirve de punto de partida para hacer copias de respaldo de la máquina

Esta guía no tiene que ser algo más complicado que un fichero de texto plano elaborado a base de copiar y pegar con el bloc de notas. Recomiendo incluir enlaces web a la documentación que hayamos usado (manuales, HOWTOs, etc.), pero aún así incluir lo que hemos hecho (el referente puede desaparecer o cambiar). Personalmente utilizo Redmine, un sistema de gestión de proyectos que incluye un correcto wiki, que hace bastante cómodo mantener esta documentación.

Con la guía podemos tranquilamente instalar en nuestra máquina virtual, hacer pruebas, etc. y luego ser capaces de reproducir el proceso (sin pasos en falso) en nuestra máquina en producción. Una herramienta útil que nos proporciona la virtualización son los snapshots. Fácil y cómodamente podemos guardar estados de la máquina y volver a ellos posteriormente. Esto nos permite experimentar y luego volver atrás rápidamente; así pues podemos experimentar sin miedo a “ensuciar” la máquina, tomando un snapshot antes de comenzar.

Tras instalar, y en cuanto tengamos la guía para configurar nuestros servicios en producción, podemos realizar estas operaciones en nuestro entorno de producción y obtener un sistema limpio que cumple los requisitos.

Una vez aquí, tenemos que ser capaces de:

• Crear copias de respaldo. Fácilmente podemos programar copias del sistema con herramientas como cron, rdiff-backup, tar, etc. Partiendo de la documentación del sistema, debemos ser poder capaces de crear copias de toda la información del sistema que nos permitan restaurar el sistema en caso de desastre. Es conveniente que existan copias almacenadas de la manera más independiente del sistema original; física y geográficamente, pero también bajo otro “responsable”- si bien nuestro proveedor de hosting puede ofrecernos un sistema de copias de seguridad, puede ser conveniente almacenar copias también bajo nuestra propia propiedad o la de otro proveedor. También es importante verificar ocasionalmente las copias- un buen sistema es intentar reconstruir el sistema a partir de la documentación y las copias de seguridad en una máquina virtual
• Actualizar. Debemos introducir en el sistema las actualizaciones (especialmente de seguridad) que vayan apareciendo, de la manera más simple posible. Existen sistemas que nos notifican o incluso pueden instalar las actualizaciones tal como aparecen automatizadamente. En un sistema muy estable tipo RHEL, puede ser válido instalarlas automáticamente dado el poco riesgo que suelen entrañar las actualizaciones. En otras situaciones es mejor recibir las notificaciones e instalar las actualizaciones manual y controladamente
• Monitorización. Más allá de saber si los servicios están funcionando correctamente (algo a veces más problemático de comprobar de lo que parece), es interesante que recibamos notificaciones de los problemas y de ciertas métricas. Recomiendo siempre una herramienta como logwatch que nos envía un resumen diario de la actividad de la máquina. Una métrica muy interesante de monitorizar es el espacio en disco- si este se llena es un gran problema y es conveniente no dejar que suceda. Por supuesto, los errores en las copias de respaldo son otro punto muy importante. Estos temas se simplifican enormemente si podemos configurar el sistema para que pueda enviar correo con las herramientas estándar

Con estos puntos cubierto, podemos dar un servicio que, pese a no ser completamente profesional, sin un uptime perfecto y sin redundancias, puede ser más que adecuado para la mayoría de los propósitos.

Tradicionalmente se divide el campo de la informática en dos grandes áreas: programación y administración. El programador idea software nuevo o modifica el existente para cumplir con requisitos que no cubre ningún sistema disponible, mientras que el administrador utiliza software existente para cubrir estos requisitos. El entusiasta informático (o pringado de turno) a veces adquire alguna de estas (o ambas) funciones, aunque con mayor frecuencia suele desempeñar la segunda.

Mantener nuestro equipo funcionando e instalar el software que queremos es, por supuesto, administración de sistemas, así como otros temas de hardware doméstico, como mantener una red local. Esta serie de artículos, sin embargo, se centrará en la administración de sistemas no doméstica.

Mucha gente desea tener un blog, una web, un sistema de correos propio, etc. por los más diversos motivos. Por supuesto, para la mayoría de cosas se pueden encontrar proveedores que por un módico precio (o en ocasiones, incluso gratis) podrá proporcionarnos estos servicios fácilmente, pero en ocasiones no encontraremos a alguien que cumpla nuestros requisitos, no querremos depender de un tercero o simplemente querremos experimentar.

Cabe decir, que salvo la última situación o variantes, probablemente estemos cometiendo un error. Pero si estás leyendo esto, probablemente sea tarde para disuadirte. Así que, sigamos adelante (nota: iré recordándote esto periódicamente).

Lo primero es determinar tus requisitos. ¿Queremos tener un blog? ¿Quizás unos foros? ¿Queremos almacenamiento online? ¿Un servidor de correo?

Especifiquemos. ¿Cuánto espacio necesitamos? ¿Qué software cumple con nuestros deseos? Todo esto debería ser fácil de articular- estamos emprendiendo este viaje porque ninguna de las soluciones que hemos investigado cumple nuestros requisitos: ¿cuáles son?

Los requisitos no están aislados, forman una cadena de dependencias. Si quiero usar WordPress, necesitaré un servidor web capaz de ejecutar PHP de una determinada versión, una base de datos MySQL de otra versión, etc. Tomemos un momento para intentar enumerar en la medida de lo posible todos nuestros requisitos.

Típicamente, necesitaremos un sistema con el que podamos satisfacer los requisitos. Hay básicamente dos alternativas, escoger un sistema gestionado o no gestionado.

Un sistema gestionado es lo que comunmente se conoce por estos lares como “hosting compartido”. El proveedor nos da un sistema con PHP, MySQL en unas determinadas versiones al cual no tenemos acceso completo. En cambio, un sistema no gestionado en general nos da un sistema operativo al que tenemos acceso prácticamente completo- esto es lo que en general se denomina VPS o servidor dedicado (dependiendo de si el sistema es una máquina virtual o física).

En general, cuanto más gestionado el sistema, menos trabajo para nosotros pero también menos control. Si el hosting compartido cumple nuestros requisitos, seguramente será más barato y nos requerirá menos tiempo hacer funcionar lo que queremos. Muchas veces estos hostings compartidos ofrecen software conocido (i.e. WordPress, etc.) con sencillos instaladores que lo ponen en marcha sin esfuerzo. Es poco probable, sin embargo, que quien lea estas líneas se vea satisfecho por estas opciones, pero cabe valorarlas y (una vez más), poder señalar qué requisito no cumplen.

Los sistemas no gestionados son un poco más complicados. Nuestro primer paso probablemente sea escoger uno. El precio y fama son factores importantes, pero también debemos considerar otros.

El sistema operativo es probablemente la decisión clave. Muchas veces nuestros propios requisitos nos forzarán a escoger uno- un software puede funcionar sólo sobre Windows o sobre alguna versión específica de Linux. Si no, la cosa es un poco más complicada.

Por temas de coste, los sistemas Linux suelen ser una elección natural- Windows en general es más caro y representa una parte sustancial del coste de un alojamiento, y además muchas aplicaciones populares no están tan probadas y rodadas sobre Windows. Existen otros sistemas operativos fuera de estos dos, por supuesto, pero para las situaciones en las que nos encontramos no suelen ser muy populares ni adecuados.

Dentro de las distribuciones Linux hay un vasto elenco de opciones, y resulta poco viable evaluarlas todas. Mi sugerencia se reduce a escoger sólo entre dos: CentOS/RHEL y Debian.

RHEL (Redhat Enterprise Linux) es la distribución comercial de Linux más popular. Su interés se centra en dos puntos principales:

• Algunos programas comerciales están pensados para RHEL
• Su largo ciclo de vida

Si deseamos ejecutar algo que requiere RHEL, raramente hay otra opción viable, así que nuestra elección está realizada. Sin embargo, esto cada día es menos habitual, así que el motivo principal para usar RHEL es su prolongado ciclo de vida. Redhat se compromete a dar actualizaciones exclusivamente de corrección de bugs y de seguridad durante mucho tiempo- concretamente de hasta 10 años.

¿Por qué es importante esto? Pues porque los servicios que expongamos a Internet deben ser seguros. Nuestro servicio no funcionará si un ente hostil lo ataca con éxito y lo deja inoperativo. Existe una poderosa motivación económica que hace que sea rentable atacar sistemas, lo que se traduce en un riesgo más que significativo. Así pues, deberemos ser proactivos en la corrección de defectos de seguridad, y eso prácticamente siempre implica la instalación de nuevas versiones del software que usamos.

La ventaja de RHEL es que nos proporcionan estas actualizaciones sin ningún otro tipo de cambio. Es decir, sin mejoras de funcionalidad. Esto que parece contraproducente es en cambio a menudo una gran ventaja. Una nueva funcionalidad puede introducir bugs o cambios en el funcionamiento del software que nos fuercen a trabajar; actualizar configuraciones, instalar otro software, etc. Si nuestro sistema cumple nuestros requisitos, es probable que esto no nos dé ningún beneficio y sí nos haga perder el tiempo.

Una instalación con RHEL puede ser mantenida al día con correcciones de seguridad casi sin esfuerzo, lo cual es un gran beneficio.

Eso sí, hay tres inconvenientes.

El primero es que RHEL es un producto comercial (y bastante costoso, de hecho). Pero existe una solución sencilla- RHEL es prácticamente completamente open source, con lo que Redhat distribuye libremente el código fuente de RHEL (excepto unas partes específicas que no son open source, pero que en general no nos interesarán), con lo que existen ciertas entidades que cogen este código fuente y construyen clones de RHEL libremente distribuibles. El más popular actualmente es CentOS. La gran diferencia, más allá de las partes no open source, es que estos proyectos no suelen tener las actualizaciones listas a la misma velocidad que la propia Redhat.

El segundo es que esta garantía sólo es aplicable al software incluido dentro de RHEL- cada software que necesitemos que entre dentro de nuestos requisitos que no esté en RHEL nos irá restando de la facilidad de mantenimiento. Con un poco de suerte, el software que querremos estará en repositorios de calidad como EPEL, repositorio mantenido por gente de Fedora que funciona bien y está bien actualizado- existen algunos repositorios de este tipo. Alternativamente, hay software que dispone de repositorios propios de RHEL que funcionan bastante bien. Pero añadir estos repositorios de terceros siempre añade algo de entropía al sistema e incluso podemos encontrarnos que el software que queramos no esté empaquetado para RHEL y lo tengamos que instalar desde el código fuente… haciendo de los procesos de actualización un proceso manual.

El tercero es que el proceso de actualización de una versión de RHEL a otra no está soportado. Un sistema instalado con RHEL 6 (la versión más reciente), no podrá ser actualizado fácilmente a RHEL 7 cuando este salga a la luz (salen cada dos-tres años). Podremos usarlo sin problemas hasta que acabe su (largo) ciclo de vida de 10 años, pero cuando acabe o necesitemos actualizar a RHEL 7, lo mejor será construir un nuevo sistema con RHEL 7.

Si el motivo para escoger RHEL es la facilidad de mantenimiento y actualización, todo requisito que se salga de los paquetes de RHEL es un motivo más para no usar RHEL.

Y si el software que queremos no está en RHEL, ¿qué hacemos? Pues la otra alternativa es Debian. Debian es la distribución completamente open source más relevante del mercado. Sus objetivos incluyen el de ser “el sistema operativo open source universal”, algo que incluye la voluntad de empaquetar todo software libre existente (y de hecho, también parte del no libre), algo que se refleja en el descomunal número de paquetes; si es open source, lo más probable es que esté en Debian.

Sin embargo, esta gran cantidad de paquetes hace más complicado ofrecer un ciclo de vida largo como el de RHEL. Debian tiene una versión estable que sale cada más o menos un par de años (las últimas versiones estables son de 2011, 2009, 2007, 2005, 2002) y tiene actualizaciones de seguridad hasta la siguiente versión estable, así que si con RHEL podíamos estar hasta 10 años actualizando con mínimo esfuerzo, en Debian sólo podremos estarnos 2. Eso sí, Debian sí soporta actualizar entre versiones y al cabo de dos años podremos (con un poco de esfuerzo) pasarnos a la siguiente versión estable.

Debian también nos ofrece testing, una versión constantemente actualizada donde van entrando paquetes nuevos a medida que van saliendo. Testing puede tener más esfuerzo de actualización (pueden entrar paquetes que introducen cambios significativos que nos obliguen a trabajar), pero dispone de software relativamente actualizado y moderno.

En general, la vida con Debian es algo menos cómoda que un RHEL donde nos mantengamos dentro de los paquetes estándares, pero no mucho peor. Y si nuestros requisitos no están cubiertos por los paquetes estándar de RHEL, seguramente viviremos mucho mejor con un servidor Debian. Para ayudaros a tomar esta decisión, podéis usar los índices de paquetes de ambas distribuciones. Podéis consultar en el FTP de Redhat la lista de paquetes disponibles para RHEL 6 y Debian ofrece packages.debian.org donde podéis ver qué software hay en stable y testing.

Más allá de esto, hay otras diferencias entre ambas; documentación, herramientas administrativas, etc. son diferentes y cada cuál preferirá una u otra (a mi en general me gusta más Debian, pero la documentación de RHEL es muy interesante, por ejemplo). Antes de tomar una decisión también es conveniente que las probemos- con la facilidad hoy en día de usar virtualización es muy muy sencillo instalar ambas distribuciones en máquinas virtuales y hacer pruebas.

actualizado: correcciones del sospechoso habitual