Hace unos meses tuve la ocasión de registrarme para el examen de Openstack EX210, y como oferta, Red Hat otorgaba acceso al entorno de formación online ROLE.

Como entorno de formación me pareció bastante correcto. Con el usuario habitual de la RedHat Network (RHN), se obtiene acceso tanto a la documentación como a un set de máquina o máquinas virtuales que permiten hacer prácticas y resetear el estado al original en caso de que rompamos algo. Además, el acceso permanece durante 90 días para poder utilizarlo cuando mejor nos convenga.

La única parte mala que le veo es que la única forma de acceder a las VMs es a través de una consola Javacript, y no tienen conectividad desde o hacia afuera. Esto significa que el teclado es tipo US y que para escribir algunos caracteres especiales es algo complicado sin utilizar el teclado en pantalla.

En lo relativo al proceso de examen, también novedades al haber utilizado el Kiosk disponible para hacer los exámenes en solitario. Todo bien, salvo el hecho de tener que utilizar un teclado (físico) US. Hay que venir acostumbrado para no tener problemas ;-)

Como siempre, en la web de Red Hat tenemos disponibles los objetivos del examen. Hay que tener en cuenta que, siendo un curso introductorio de Openstack, los contenidos van más sobre tener un entendimiento general de la arquitectura del sistema que tener un conocimiento muy detallado de cada parte.

De cada a preparar el examen por cuenta propia, se puede montar un laboratorio con la distribución RDO de Openstack. Grosso modo , es una distribución equivalente a lo que sería Fedora/CentOS en relación a RHEL, el 90% del producto es igual en la versión de pago de RHOSP (RedHat OpenStack Platform).

Así que para instalar un entorno pequeño de Openstack en CentOS 7, es tan sencillo como hacer lo siguiente:

yum install -y epel-release
yum install -y https://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-4.noarch.rpm
yum install -y openstack-packstack
packstack --allinone

Como siempre, de cara al examen hay que tener muy en cuenta el tiempo asignado a cada ejercicio y no pararse en exceso en una parte concreta si no sale a la primera.

Happy hacking :-)

Si queremos configurar el navegador predeterminado del escritorio, hay una herramienta muy útil llamada xdg-settings.

Las opciones para cambiarlo son:

$ xdg-settings --list
Known properties:
default-url-scheme-handler Default handler for URL scheme
default-web-browser Default web browser

$ xdg-settings get default-web-browser
midori-private.desktop

$ xdg-settings set default-web-browser firefox.desktop

$ xdg-settings get default-web-browser
firefox.desktop

Esto es válido en Fedora, Debian, tanto para XFCE como Gnome. El paquete que provee este ejecutable es xdg-utils, que da esta información :

Name : xdg-utils
Summary : Basic desktop integration functions
URL : http://portland.freedesktop.org/
License : MIT
Description : The xdg-utils package is a set of simple scripts that provide basic
: desktop integration functions for any Free Desktop, such as Linux.
: They are intended to provide a set of defacto standards.
: This means that:
: * Third party software developers can rely on these xdg-utils
: for all of their simple integration needs.
: * Developers of desktop environments can make sure that their
: environments are well supported
: * Distribution vendors can provide custom versions of these utilities
:
: The following scripts are provided at this time:
: * xdg-desktop-icon Install icons to the desktop
: * xdg-desktop-menu Install desktop menu items
: * xdg-email Send mail using the user's preferred e-mail composer
: * xdg-icon-resource Install icon resources
: * xdg-mime Query information about file type handling and
: install descriptions for new file types
: * xdg-open Open a file or URL in the user's preferred application
: * xdg-screensaver Control the screensaver
: * xdg-settings Get various settings from the desktop environment

Ya no perderé el tiempo buscando entre confusos menús gráficos :-)

Hace poco escribía sobre la dificultad de encontrar de encontrar un escenario donde aplicar técnicas de análisis y mejora de rendimiento. Basta hablar para que venga un proyecto que te haga cerrar la boca :-) . Lo que me ha tocado es un proyecto de High Frequency Trading (HFT) donde se compra-venden divisas y la latencia es fundamental.

Sin entrar en muchos detalles, este es un negocio muy competitivo donde solo los mejores ganan, y donde cada microsegundo pueden suponer millones de euros.

Ahora el proyecto está en fase de implmentación y pruebas, y es de esperar que en las próximas semanas llevemos unas pruebas para determinar qué latencia conseguimos en cada transacción y qué se puede hacer para mejorarla.

Las guías de referencia y buenas prácticas que he consultado hasta ahora recomiendan lo siguiente:

Del lado del hardware (BIOS, procesadores, RAM, etc) :

• Desactivar hyperthreading.
• Desactivar cores de cada CPU si no son necesarios.
• Elegir módulos de memoria grandes (ej mejor uno de 16Gb que dos de 8Gb).
• Desactivar todos los estados de ahorro de energía de los procesadores.
• Desactivar el máximo posible de SMIs (System Management Interrupts).
• Desactivar la revisión de fallos en módulos de RAM, y bajar la frecuencia de refresco CAS si es posible.

También incluyo unos cuantos recursos interesantes que encontré preparando el examen de certificación:

• Taste of Training - Exploring Red Hat Enterprise Clustering and Storage Management.
• Presentación en el Red Hat Summit 2012 de Thomas Cameron sobre clustering. Incluye también scripts para crear y desconfigurar el entorno.
• Por supuesto, la guía de contenidos del curso oficial, y el detalle de los objetivos del examen.

La preparación del examen se puede hacer en entornos virtuales; en mi caso lo hice bajo Fedora 17 con KVM. La parte de storage se puede hacer con RHEL6 "pelado", la parte de GlusterFS se puede hacer con los paquetes de gluster de EPEL y la parte de cluster se puede excepto la configuración de dispositivos de fencing.

Happy hacking ;-)

Acabo de presentarme al examen de RedHat Performance Tuning tras atender al curso y tengo una sensación agridulce. Independientemente de la nota, no tengo la sensación de "Saber Kung-fu" [tm]. En otros cursos exámenes o sales con la sensación de saber casi todo lo que que hay saber sobre el producto o servicio en cuestión, mientras que tras este todo es un mar de dudas y un "ahora sé lo que no sé" :-)

Algunos comentarios aleatorios sobre el curso en sí:

• Es un curso bastante denso en cuanto a pequeñas cosas que recordar. Desde luego, no es fácil de impartir y requiere mucha preparación previa para darlo de forma fluida. Especialmente difícil si solo impartes el curso de pascuas a ramos.

• Deja más puertas abiertas al mundo del performance tuning. No espero en una semana convertirme en un super experto del kernel a bajo nivel, ni en un Alan Cox o Ingo Molnar. Pero también es cierto que las espectativas de los asistentes pueden ir por otros derroteros.

• Al ser un curso enfocado a ver únicamente tecnologías de RedHat, se puede quedar un poco "corto" en el mundo real con productos de muy diversos fabricantes; ej: tuning avanzado de HBAs, LVM, filesystems, ... Por otra parte, las referencias a Valgrind, y en menor medida a SystemTap se quedan un poco cogidas de los pelos para sysadmins puros y duros - normalmente no vas a debuggear software en entornos de producción (normalmente se trabaja con software privativo o del que no se tiene el código fuente igualmente).

También incluyo unos cuantos recursos interesantes que encontré preparando el examen de certificación:

• Taste of Training - Exploring Red Hat Enterprise Clustering and Storage Management.
• Presentación en el Red Hat Summit 2012 de Thomas Cameron sobre clustering. Incluye también scripts para crear y desconfigurar el entorno.
• Por supuesto, la guía de contenidos del curso oficial, y el detalle de los objetivos del examen.

La preparación del examen se puede hacer en entornos virtuales; en mi caso lo hice bajo Fedora 17 con KVM. La parte de storage se puede hacer con RHEL6 "pelado", la parte de GlusterFS se puede hacer con los paquetes de gluster de EPEL y la parte de cluster se puede excepto la configuración de dispositivos de fencing.

Happy hacking ;-)

Estos días estoy cacharreando con Red Hat Cluster Server en RHEL6. En su momento configuré una buena cantidad de clusters con RHEL5, pero hasta el momento no había podido meterme con esta nueva versión y disfrutar de las mejoras que trae.

Las cosas más reseñables que he visto hasta ahora:

• Soporte de comunicación intra-cluster en HA. Hasta el momento, sólo se podía definir un único interfaz de red por el que los nodos del cluster se comunicaba entre sí (típicamente el interfaz de producción con un bonding ó un cable cruzado si solo son 2 nodos). Si ese mecanismo falla (fallo de tarjeta de red, diseño de red inadecuado, escenario de fallo de red no suficientemente probado, etc), los nodos del cluster pierden conexión entre sí y se produce un escenario de split-brain o de particionamiento del cluster. Para remediar esto, se puede configurar un segundo interfaz por el que los nodos del cluster se comunican entre sí.
• Soporte de nuevos mecanismos de fencing. En el escenario anterior de split-brain, los miembros del cluster intentan "apagar" (Shoot the other node in the head - STONITH) a los miembros que no cooperan (están particionados o colgados) para evitar que multiples nodos accedan simultáneamente a los datos y se produzcan corrupciones de datos. Pues bien, RHEL6 soporta power fences como UCS, iLo, Drac y también han añadido soporte para Vmware vSphere, RHEV, etc.
• Soporte (limitado) de snapshots LVM dentro de un cluster. Hasta ahora, no se podían hacer snapshots de un volumen LVM en cluster; con la versión 6 ya se pueden realizar aunque existe la limitación de que el LV ha de estar activado exclusivamente en el nodo que realiza el mismo; en el resto de nodos hay que inactivar el LV manualmente.
• tgtd no soporta (aún) reconfiguración en caliente. tgtd es el demonio que permite ofrecer dispositivos (ej: volúmenes LVM) a través de iSCSI a clientes. En el caso de querer añadir LUNs o tener que reiniciar el servicio por cualquier motivo, no se dejará al tener clientes conectados. Al no tener posibilidad de iniciar múltiples instancias, no tendremos un HA iSCSI real. Así que de momento a seguir usando nuestras cabinas iSCSI de toda la vida ;-)
• ccs está mucho más maduro que antes. Incluso podríamos configurar un cluster desde 0 sin usar el GUI web ni editar el cluster.conf a mano. Un ejemplo aquí: Creating a cluster with CCS .
• En GFS2 por fín se pueden añadir copias de los metadatos en caliente. En versiones anteriores, era necesario planificar cuántas máquinas iban a acceder al filesystem de forma simultánea y disponer una copia de los metadatos para uno. Dado que esto se tenía que hacer en el momento de la creación del filesystem, era un engorro encontrarte más tarde que te habías quedado corto.
• GlusterFS: En general todo ha sido una novedad para mi, pues no había usado nunca antes este sistema de ficheros distribuido. La sensación es que, aun teniendo un producto comercial basado sobre él (Red Hat Storage Server), está un poco verde a nivel de documentación. En todo caso, es una alternativa interesante para replicación de ficheros low-cost, especialmente teniendo en cuenta que soporta geo-replicación.

También incluyo unos cuantos recursos interesantes que encontré preparando el examen de certificación:

• Taste of Training - Exploring Red Hat Enterprise Clustering and Storage Management.
• Presentación en el Red Hat Summit 2012 de Thomas Cameron sobre clustering. Incluye también scripts para crear y desconfigurar el entorno.
• Por supuesto, la guía de contenidos del curso oficial, y el detalle de los objetivos del examen.

La preparación del examen se puede hacer en entornos virtuales; en mi caso lo hice bajo Fedora 17 con KVM. La parte de storage se puede hacer con RHEL6 "pelado", la parte de GlusterFS se puede hacer con los paquetes de gluster de EPEL y la parte de cluster se puede excepto la configuración de dispositivos de fencing.

Happy hacking ;-)

Una de las cosas que me fastidia de mi trabajo son las notificaciones de incidencia que recibimos, indicando que tal o cual sistema no funciona: Exchange, Blackberries, Intranet, web publica, VPNs, etc. No por la incidencia en sí misma, si no porque todos los correos acaban con una frase del tipo: "Estamos investigando la causa raíz de la incidencia y ya daremos más detalles".

Tal notificación nunca se produce, y como usuario de esos servicios, se queda uno con la sensación de oscurantismo, de incertidumbre y un cierto grado de desconfianza hacia la gente que opera dichos servicios. Además, como ingeniero de sistemas, quiero saber qué ha fallado, cómo ha fallado y cómo se va a evitar que eso pase en el futuro.

Empresas tan importantes como Google o Amazon AWS hacen públicos análisis post mórtem con unos elevados niveles de detalle que permiten aprender alguna cosa que otra:

• Google Apps afectado por la caida del 25% de servidores en un datacentre (2010)
• Amazon pierde decenas de volúmenes EBS (2011)

Estos informes son especialmente interesantes de cara a evaluar distintos proveedores de servicio: cuando contratas algo, deseas saber el grado de transparencia de la empresa que hay detrás, si son capaces de entender los servicios que ofrecen, su grado de madurez y experiencia operando los mismos y qué has de esperar de ellos cuando las cosas vayan mal. Por ejemplo:

• Que no haya documentación clara de cómo tratar una incidencia o desastre.
• Que esa documentación exista, pero no esté actualizada, sea incompleta o parcialmente incorrecta.
• Que el personal que ha de tratar la incidencia no conozca al dedillo dicha documentación y se tenga que poner a buscarla y leerla en el momento.
• Que, durante un cambio programado, no exista un guión detallado con los pasos a seguir.
• Que dicho guión no se haya seguido correctamente porque la persona encargada llevaba trabajando 12h seguidas en un turno sin fin (O porque la noche anterior estuvo de guardia y le llamaron 4 veces).
• Que un sistema que aporta "mejor disponibilidad" (HA, cluster, redundancia hardware, ...) no se pruebe suficientemente y no se active cuando lo deseamos.
• Que si se activa, no lo haga en el tiempo que esperamos.
• O que se active, pero haya otros elementos que fallen y haya una indisponibilidad de servicio.

Las posibilidades de fallo son tantas que hay toda una ciencia encargada de estudiar la resiliencia ó resistencia en infraestructuras IT: Resilience Engineering (parte 1) y parte 2 (ojo, el segundo enlace es bastante denso).

En otro post hablaré algo mas sobre resilience engineering... cuando tenga las ideas más claras :-)

Llevaba ya unos cuantos meses planteándome conseguir la certificación RHCA (Certified Architect) de Red Hat. Hoy he dado el primer paso presentándome al examen EX401 que cubre lo siguiente:

• El propio RH Satellite, basado en el proyecto libre Spacewalk.
• Cobbler, como herramienta de provisioning, usando servidores DHCP y TFTP.
• Subversion para gestión de repositorios de datos.
• Generación y firma de paquetes RPM, usando GPG.

Dado que me presentaba al examen sin atender al curso oficial, he tenido que tirar de diversos recursos encontrados en Internet, fundamentalmente:

• De perogrullo, la documentación oficial del Satellite.
• La presentación de Thomas Cameron sobre Satellite (Systems deployment) en el Summit 2012.
• Idem sobre construcción de RPMs (Packaging Software), también en el Summit 2012.
• Cómo crear paquetes RPM, de Linuxparatodos.

Aunque lógicamente Red Hat no permite que se divulguen detalles del examen, aquí van algunas cosas a tener en cuenta.

• Como en todos los exámenes prácticos, el tiempo es MUY limitado. Hay que ser consciente del tiempo empleado en cada ejercicio para que algo pequeño no nos agote todo el tiempo.
• En relación con lo anterior: leerse detenidamente el examen, hacerse un esquema de todo lo que hay que hacer y sus pre-requisitos y ser consciente de completar el máximo de tareas dentro de cada ejercicio que se pueda. Siempre es mejor tener alguna tarea completa que todo el ejercicio a medio hacer.
• La documentación online del Satellite está disponible. Pero claro, si la tienes que estar leyendo en el momento, tienes un problema... ;-)
• Es muy muy recomendable hacerse varias instalaciones desde 0 para familiarizarse con el proceso, así como montar toda la infraestructura Cobbler, Kickstarts, canales, canales de configuración, etc. Spacewalk tiene una terminología un poco enrevesada que conviene conocer al dedillo para no liarse durante la prueba.

En fin, un examen exigente en el que he disfrutado un montón (soy el único que al que le pasa eso en los exámenes?), y, también he de decir, aprendido un par de cosas nuevas que no se me habían ocurrido en los laboratorios que me había diseñado o en el uso diario que le daba al Satellite.

El muy sonado caso del ataque a Mat Honan me ha hecho pensar sobre la clase de seguridad que tenemos en nuestros dispositivos conectados al cloud. (Resumen ejecutivo: Atacantes consiguen password de iCloud, borran remotamente TODO el contenido del iPhone/iPad/MacBook y toman el control de cuentas tipo Twitter, etc).

He de decir que siempre he sido un gran defensor de tener mis propias copias de "todo" en local; tengo almacenados correos de hace mas de 15 años, scripts/software, proyectos, textos, fotos, y prácticamente cualquier ristra de bits que haya generado en estos años.

Hasta el momento, estoy usando Gmail para tener una copia online y siempre disponible de estos correos. No es la "fuente primaria" de datos, si no meramente un backup de los mismos. Más por comodidad que por otra cosa; está bien poder localizar un cierto documento que te mandaron hace tiempo, o un enlace, o un correo con datos importantes.

Sin embargo, el hackeo antes mencionado me hace plantearme si realmente es tan buena idea tenerlo todo en la nube: una vez que un dato ha salido de tu ordenador has de considerarlo dominio público. De ahí el adagio de "No subas a Internet nada que no quieras que tu madre vea" :-) . Y no solamente eso, si no que te pueden privar de acceder a esos datos. Pierdes tu agenda, tus contactos, las direcciones de correo, fotos irreemplazables, ... A todos los efectos, borrar tu presencia digital es casi como borrar tu vida real de un plumazo

Me hace especial gracia esta cita del artículo:

In short, the very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification.

Las conclusiones que saco de esto son :

• Haz un backup local de tus datos. Nadie sabe mejor que tú lo que los valoras y qué repercusiones puede tener el perderlos.
• No subas a Internet nada que no puedas asumir que se haga público. Ya sean fotos, documentos, tarjetas de crédito y DNIs/Pasaportes escaneados, ...
• Plantéate a cuantas cosas pueden acceder si pierdes una sola cuenta. En el caso de Mat, al perder su cuenta iCloud el atacante tuvo acceso a todas sus demás cuentas en otros servicios. La seguridad del email se ha vuelto crítica en los últimos tiempos.
• Revisa las políticas de verificación de identidad de tus proveedores. La doble autenticación de Gmail ("algo que sabes , algo que tienes") añade un punto más de dificultad para poder asaltar una cuenta, pero no es definitivo. En el caso de Apple, bastó con "marear" un poco a los empleados de su call centre hasta que uno de ellos cometió una indiscreción y reveló un dato crítico.
• Cambia tus contraseñas periódicamente. Quizás no mensualmente, pero sí una vez al año como mínimo. No es necesario que te sepas todas ellas; basta con que estén apuntadas en un sitio seguro (como Keepassx) y que tu navegador las recuerde. Por supuesto, no compartas contraseñas entre servicios. Es buena idea usar también generadores de passwords como pwgen y apg .
• No asumas que no te han hackeado ya. Quién sabe si ya hay algun exploit para Gmail, Outlook et al, y alguna panda de criminales chinos, rusos, etc no tiene ya todos tus datos ( sí, me gusta la paranoia ;-) )

Está claro que aún nos queda mucho por aprender a todos, pero a base de ejemplos como este supongo que iremos espabilando :-)

Por alguna razón que no alcanzo a comprender, RHEL6 no incluye de forma predeterminada el paquete nss-mDNS necesario para que el DNS multicast funcione (Avahi/Zeroconf et al).

Aquí va una pequeña guía de instalación y configuración, incluyendo el repositorio externo EPEL:

[root@rhel6 ~]# yum install -y avahi avahi-tools  
[root@rhel6 ~]# yum install -y --nogpgcheck http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm  
[root@rhel6 ~]# yum install -y nss-mdns

Modificar en el /etc/nsswitch.conf :

# grep hosts /etc/nsswitch.conf  
hosts: files dns4_minimal [NOTFOUND=return] mdns4_minimal [NOTFOUND=return] dns

Y finalmente reiniciar DBus y Avahi-daemon:

[root@rhel6 ~]# chkconfig messagebus on  
[root@rhel6 ~]# chkconfig avahi-daemon on  
[root@rhel6 ~]# service messagebus restart  
Stopping system message bus: [FAILED]  
Starting system message bus: [ OK ]  
[root@rhel6 ~]# /etc/init.d/avahi-daemon restart  
Shutting down Avahi daemon: [FAILED]  
Starting Avahi daemon... [ OK ]

De esta forma, todos los dispositivos que estén directamente conectados en nuestra red local (VLAN) serán capaces de conocernos bajo el nombre rhel6.local , o el hostname que tengamos configurado y .local . Muy cómodo si no tenemos ningún servidor DNS en nuestra red o para dispositivos itinerantes :-)

Para poder generar de forma sencilla nuestros paquetes RPM para diferentes distribuciones, podemos usar un chroot que contenga las versiones de software necesarias.

Básicamente, chroot permite ejecutar software cuyo directorio de ejecución esté enjaulado; significando que el directorio root (/) de estas aplicaciones será otro.

Dado que generar un entorno chroot manualmente es bastante tedioso debido a que tenemos que trasladar todas los ejecutables que nos sean necesarios, más las librerías correspondientes, existen dos herramientas que nos permiten automatizar esto.

Una de ellas es rinse, que nos permite construir entornos basados en Fedora y CentOS en nuestra distribución Debian.

La forma de uso sería :

[ root@minime : /opt ] # mkdir -p /opt/centos5/dev
[ root@minime : /opt ] # mount --bind /dev /opt/centos5/dev
[ root@minime : /opt ] # rinse --distribution centos-5 --directory /opt/centos5

Una vez realizado esto, tendríamos un entorno básico en /opt/centos5 . En caso necesario, tendremos que editar los siguientes ficheros para hacerlos coincidir con los UIDs y GIDs de fuera del chroot:

/etc/passwd
/etc/shadow
/etc/group

Una vez hecho esto, podemos entrar en el chroot y empezar a instalar el software que nos sea necesario para nuestra labor :

[ root@minime : /opt ] # chroot /opt/chroot /bin/bash
(chroot) # yum install -y rpm-build sudo vim-enhanced tar gzip wget man make gcc gcc-c++

La ventaja de este método es que podemos tener varias distribuciones simultáneamente sin necesidad de necesitar pesadas máquinas virtuales, desperdiciar espacio en el disco duro creando discos virtuales; y sin ningún tipo de pérdida de rendimiento.

Si queremos construir un entorno Debian, deberemos usar la herramienta debootstrap .

Si estamos en Debian y queremos un chroot de Fedora o CentOS, podemos usar mach. (Nada que ver con GNU Mach ! ;-) )