Truco: Seleccionar el navegador predeterminado

Si queremos configurar el navegador predeterminado del escritorio, hay una herramienta muy util 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 🙂

Camino al RHCA: Performance tuning (EX442)

Después de una larga pausa vuelvo a la carga con otro examen para completar mi RHCA. Este ha sido el examen más difícil que he hecho hasta ahora, fundamentalmente por la variedad de temas que toca y por el poco margen de error que hay durante el mismo — cualquier despiste leyendo el enunciado o acordándose de en qué unidad está expresado cierto parámetro dará al traste con el ejercicio.

Los contenidos del curso y examen están disponibles en la web de Red Hat, y muy resumidamente son:

  • Tuning de red
  • Tuning de disco (planificadores, etc)
  • Tuning de memoria (buffers, swappiness, NUMA)
  • Servicios confinados (cgroups)
  • SystemTap
  • Gestión de energía
  • Tuned

De los cursos que he hecho con Red Hat, es el que menos me ha gustado. Si bien es cierto que el temario es completo, siempre se queda uno con la sensación de haber sacado menos cosas en claro que antes de empezar 🙂 .

Al final todo se reduce a medir, cambiar un parámetro, y medir otra vez a ver si ese parámetro ha causado una mejora en el sistema que estamos analizando. Y, por supuesto, quien vaya esperando encontrar recetas mágicas para arreglar un problema, que se vaya olvidando… (más allá del net.ipv4.low_latency = 1). Quizá se echan en falta algunos ejemplos más de qué es “lo normal” en el mundo real (ej, cuantas IOPS se pueden esperar de un cierto almacenamiento, …) y algún parámetro más.

En definitiva, un examen exigente donde hay que llevar las cosas muy claras y que me alegro de haberme quitado de encima 🙂 . Y para acabar, una reflexión:

– Por favor, ¿la unidad de pediatría?
– niños por segundo.

Camino al RHCA: Cluster y Storage (EX436)

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:

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 😉

Sobre análisis post mórtem

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:

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 🙂