lunes, mayo 30, 2016

Algunos enlaces sobre Elasticsearch

Estos últimos meses estoy trabajado con el motor de búsqueda Elasticsearch. Durante este tiempo, he ido buscando información sobre ciertos aspectos de su uso, configuración y monitorización. Esto son algunos enlaces que he encontrado sobre aspectos de Elasticsearch sobre los cuales me ha interesado profundizar.

El primer enlace que os dejo es Monitor Your Elasticsearch Cluster Performance donde se describe el uso de varias herramientas en la nube que hacen peticiones a las API de Cluster Health de Elasticsearch para poder monitorizar el estado del mismo. Quizás de esta me quedo como usar nginx como un frontal que pase peticiones al API RESET de Elasticsearch.

Este booklet, Performance Monitoring Essential, Elasticsearch Edition de la empresa Sematext, donde se da una visión general del producto, como indexa y sobre todo cuales son los indicadores básicos a vigilar para estudiar el rendimiento.

Si queremos usar Docker para desplegar Elasticsearch, se peude seguir las indicaciones de como crear un Dockerfile.

Microsoft ha publicado una guía de como configurar Elasticsearch en Azure. Hace una buena introducción a la configuración de Elasticsearch y su despliegue en Azure.

Si tenéis una instalación que use una versión 1.7.x y pasáis a la nueva versión 2.x , es conveniente leer con detalle los puntos a tener en cuenta para que la actualización se pueda hacer sin problemas.

Probablemente esto sea una entrada dinámica, que actualizaré conforme vaya leyendo artículos y encontrando información que me interese sobre Elasticsearch.

sábado, mayo 14, 2016

Xvfb: Virtual framebuffer X server

En el mundo de los sistemas operativos tipo Unix, el sistema gráfico con el cual se implementan las interfaces de usuario en modo gráfico es X Window. Éste tiene una arquitectura cliente servidor, donde los programas se conectan a un servidor, X Server, el cual recibe las órdenes necesarias para dibujar en pantalla lo que deseen los programas clientes. Se encarga de mandar a los clientes información de los eventos de los distintos dispositivos (ratones, teclados, ...) del sistema. Toda esta comunicación se realiza usando el protocolo X. Este servidor se encarga de manejar todos los dispositivos necesarios para la entrada y salida.

Hay diversas implementaciones del servidor X, y hoy quiero hablar de una de ellas, Xvfb. Este servidor corre en máquinas donde no hay pantallas ni dispositivos de entrada y se comporta como un framebuffer tonto, donde el servidor va dibujando lo que se le pide.

Pero, ¿qué sentido tiene un sistema de este tipo, si no siquiera podemos interaccionar con el mismo?. Pues hay varios escenarios donde encaja:

  • Programas que sean clientes X, pero que no necesiten mostrar ventanas para interaccionar con el usuario.
  • Pruebas: Se quiere hacer pruebas automáticas con algún tipo de framework y no queremos tener ventanas abriéndose y cerrando en nuestro escritorio mientras se ejecutan. Este fue el escenario

Mi caso de uso ha sido poder probar una web a través del navegador Firefox que era controlado por una serie de scripts, ejecutándose en una máquina virtual sin necesidad de que interactúe con la pantalla.

Xvfb admite las opciones del servidor X, mas las propias que ayudan a configurarlo. Lo básico es decir cual va a ser la pantalla que va a usar y la resolución junto con la profundidad de color. Puede arrancarse:

$ Xvfb :0 -screen 0 1280x1024x24

Le estamos indicando que el servidor "0" tenga una pantalla "0" con una resolución de 1024x768 y 24 bits de color. Podemos conectarnos a ella, con lo cual la variable DISPLAY debe tener el valor 0:0. Cambiando el número de servidor X (:0) se puede ejecutar junto a un servidor X normal que interactúe con la pantalla, teclado y ratón.

Se puede comprobar que funciona con estas simples órdenes (supuestos que tenemos xterm e imagemagick instalados), de tal manera que nos generará la captura de pantalla en screen.jpg

$ env DISPLAY="0:0" xterm &
$ import -window root screen.jpg

Por defecto, el servidor Xvfb va a permitir conexiones TCP/IP, así que puede ser interesante desactivar la misma con -nolisten tcp

$ Xvfb :0 -screen 0 1280x1024x24 -nolisten tcp

jueves, abril 28, 2016

AMD SME/SEV: Cifrado de memoria en el microprocesador y máquinas virtuales

Una de las nuevas funciones que va a incluir AMD en su próxima microarquitectura (Zen) es la posibilidad de cifrar usando el algoritmo AES los datos antes de escribirlos en memoria con una clave que se generada dentro del chip. AMD ha publicado un artículo, AMD MEMORY ENCRYPTION donde se describe esta nueva funcionalidad así como una serie de parches para Linux que habilitan el cifrado

Cuando se activa el cifrado de memoria, existe un nuevo bit en las tablas que describen las páginas de memoria. Si ese bit está activo, cuando se escriban datos desde la CPU hacía la memoria física que describe ese marco de página, será cifrada internamente por la CPU y descifrada al leerla. El controlador de memoria integrado en la CPU es el encargado de gestionar el cifrado y descifrado de la misma. La clave de cifrado para AES es aleatoria y se genera en cada arranque de la CPU. Nunca es visible para los programas que ejecuta la CPU y se maneja desde el AMD Secure Processor, un procesador Cortex-A5 integrado en el SOC.Esta tecnología no sólo funciona con los accesos a RAM, sino que también puede usarse con los dispositivos que realizan transferencias DMA a la RAM del sistema.

Como puede verse, se necesita soporte desde el sistema operativo para que configure las tablas de páginas adecuadamente para usar el cifrado de memoria. Para los sistemas antiguos o que no tienen soporte para SME, AMD tiene un modo transparente que hace que todos los accesos a memorias sean cifrados y que puede activarse a través de la BIOS del sistema.

Este tipo de funcionalidad es útil en sistemas de virtualización, donde se quiere que las máquinas virtuales estén lo más aisladas posibles, y llegado el caso, se pueda parar ciertos ataques. Sin embargo, en un host donde se ejecutan varias máquinas virtuales bajo el control de un hipervisor, nada puede hacer que el administrador del hipervisor use sus privilegios para leer la RAM física de la máquina y por tanto obtener la información de las máquinas virtuales

Para esto AMD ha diseñado el sistema SEV: La idea es que las máquinas virtuales que corren bajo el hipervisor puedan verificar criptográficamente que están ejecutándose en un chip de AMD con estas funcionalidad y configurar el cifrado de memoria por ellas mismas,sin intervención del hipervisor, el cual no tiene acceso a ninguna de las claves de cifrado que usan las máquinas invitadas. Con este mecanismo se evita que un administrador poco honesto pueda aprovechar los privilegios del hipervisor para leer la memoria de las máquinas invitadas. Esto está implementado como una extensión a la arquitectura AMD-V

miércoles, marzo 30, 2016

MacOS X "El Capitán" y problemas de Bluetooth

Hace un par de meses empecé a tener problemas con el Macbook del trabajo: En ciertas circunstancias, los auriculares bluetooth que utilizo y el Magic Trackpad no funcionaban bien. El ratón se movía a trompicones y los auriculares reproducían el sonido de manera entrecortada. Comencé a buscar información para ver si había casos similares y encontré varias referencias a problemas de bluetooth a partir de Yosemite, específicamente problemas en la reproducción de audio a través de dispositivos bluetooth.

La solución al problema que tenía la encontré en Troubleshooting OS X Bluetooth Issues: A partir de Yosemite, OS X incluye una nueva funcionalidad llamada Handoff que permite - a través de iCloud - comenzar una tarea en un dispositivo y pasarnos a otro continuando con la misma tarea: por ejemplo, empezar a escribir un correo en el iPhone y continuar en el Mac. Esto funciona si los dispositivos están en rango de bluetooth y ambos están usando la misma cuenta iCloud. Desactivando el Handoff en el Mac, se solucionaron los problemas de audio y de saltos del track pad. Para desactivar Handoff, abrimos Ajustes del Sistema, General y desmarcamos la casilla Permitir Handoff entre este Mac y sus dispositivos iCloud.

martes, marzo 15, 2016

Que sean muchos años más, maestro Ibáñez

Hoy cumple 80 años el genial autor de cómics Francisco Ibañez. Creador de Mortadelo y Filemón, el Botones Sacarino, Rompetechos o 13 Rue del Percebe, personajes con cuyas historietas disfruté de horas de risas y diversión durante mi infancia y adolescencia. Sus personajes forman ya parte de la historia del cómic español y de la memoria de muchas personas. Aquí os dejo la portada de uno de los álbumes con los que más he disfrutado: El sulfato atómico.

Ojalá podamos disfrutar muchos años más de las creaciones de este gran maestro del cómic.