Upgrading SmartOS when installed in your harddisk

Advertencia

Installing SmartOS in your harddisk is a not supported configuration. Be careful and try to understand what are you doing.

SmartOS is designed to boot from USB, DVD or PXE. Nothing is installed in the harddisk, only your configuration and data. Upgrading the SmartOS hypervisor is, therefore, trivial and risk free and rollback safe.

In Installing/booting SmartOS in/from a harddisk without physical access I describe a procedure to install SmartOS in your harddisk when you have no physical access to your server. This is very important to me because I want to run SmartOS on hosted servers that I have never actually seen in real life.

To upgrade SmartOS in this configuration you can do this:

Leer más…

Installing/booting SmartOS in/from a harddisk without physical access

Advertencia

Installing SmartOS in your harddisk is a not supported configuration. Be careful and try to understand what are you doing.

SmartOS is a hypervisor derived from Illumos, the open source evolution of OpenSolaris. I have been using Solaris since early 90's and I still consider this Operating System far more "serious" and enterprise ready than Linux.

Most distributions based on Illumos are complete Operating Systems. SmartOS is a different beast. A typical SmartOS deployment consists in a thin hypervisor running multiple Solaris containers. Something similar to Docker but more capable and far more secure.

As a hypervisor, SmartOS boots from a read only media like a USB flash drive, a DVD or PXE. The image is quite small, less than 300 Megabytes. There is no personalization stored in the boot media, the server boots from that media and tries to read the configuration from the local harddisk. That is a quite nice approach: upgrading the hypervisor is trivial and failsafe because you can always boot from the previous version, you can not bork your server with a problematic upgrade. Being 300 Megabytes in size, you can keep quite a few versions of SmartOS around, just in case.

I like the idea a lot, but it usually requires direct access to the physical infraestructure. You need to replace the DVD or you need control over the network in order to run PXE securely. Some hosting providers have the option to plug an USB flash drive as a one-time option, for a price. The problem here is that you have to pay and you will need to pay again if you migrate to a new server in the future. It could require a KVM too (more money) in order to configure the BIOS to boot from a USB flash drive. Also, many cloud providers doesn't have this option. You are restricting the choice of providers if you go thru this path.

Installing SmartOS in a harddisk is something undocumented and unsupported, but there are some nice and useful docs around. The suggested approach have several problems:

Leer más…

Resincronizar audio cuando el vídeo se congela un momento

Como ya he descrito en otros artículos, cada caso de desincronización de audio y vídeo es un mundo y hay que estudiar cada situación en particular.

En este artículo describo cómo corregir la desincronización debido a la corrupción de vídeo que congela la imagen durante un momento.

El primer paso es el diagnóstico: en este caso lo que observa es que el audio está bien sincronizado al principio del vídeo, pero tiene un desfase de un segundo al final del mismo. La causa habitual para un desfase progresivo es la conversión entre 24 y 25 fotogramas por segundo, pero en ese caso el desajuste será mayor (66 segundos).

Observo también que el sonido parece correcto a lo largo de la primera mitad del vídeo, pero existe un desfase constante de un segundo en la zona final del mismo.

Procedo, pues, a buscar el punto exacto donde se produce el desajuste y lo localizo mediante búsqueda binaria en 1:00:32. Hasta ese momento el audio y el vídeo están perfectamente sincronizados. En ese punto la imagen se congela durante un segundo, pero el sonido prosigue de forma que se introduce un desfase continuo de un segundo entre imagen y sonido hasta el final del vídeo.

Leer más…

Utilizar programas OSS en PulseAudio

Open Sound System fue, tal vez, el primer sistema de audio popular en entornos Linux (1992), suplantado después por Advanced Linux Sound Architecture (1998) y, recientemente, por PulseAudio (2004).

Durante muchos años era habitual que las distribuciones Linux soportasen varios de estos sistemas de sonido en paralelo. Por ejemplo, mi antigua Ubuntu 10.04 proporcionaba un dispositivo /dev/dsp correspondiente a OSS, aunque su sistema de sonido nativo era PulseAudio.

Hoy en día, para bien y para mal, el mundo Linux se ha estandarizado en torno a PulseAudio. Existen programas antiguos, no obstante, que dependen de OSS (o, incluso, programas modernos que emplean OSS por ciertas capacidades convenientes) y que son incompatibles con las distribuciones Linux modernas porque han dejado de incluir esas capas de compatibilidad. Hoy en día o hablas PulseAudio o no funcionas.

Afortunadamente PulseAudio incluye algunas utilidades para facilitar la transición.

Por ejemplo, podemos lanzar una aplicación OSS de forma que su uso del dispositivo /dev/dsp se convierta automáticamente a PulseAudio:

$ padsp PROGRAMA PARÁMETROS

El manual de padsp dice:

padsp starts the specified program and redirects its access to OSS com‐ patible audio devices (/dev/dsp and auxiliary devices) to a PulseAudio sound server.

padsp uses the $LD_PRELOAD environment variable that is interpreted by ld.so(8) and thus does not work for SUID binaries and statically built executables.

Equivalent to using padsp is starting an application with $LD_PRELOAD set to libpulsedsp.so

Esta descripción nos indica qué hace padsp y también cómo lo hace.

El programa padsp podemos encontrarlo, por ejemplo, en Ubuntu en los paquetes pulseaudio-utils y osspd.

Bibliografía

Conversión de Opus a MP3

El formato de audio interno de una aplicación que he desarrollado es Opus, pero cuando algún cliente me pide un audio porque ha perdido su copia no me queda otro remedio que entregárselo en MP3, que es lo único que sabe manejar [1]. Las viejas costumbres tardan en morir, aunque Opus sea técnicamente superior en todos los sentidos. La sombra del legacy es alargada :-(.

[1] Técnicamente el cliente también podría manejar ficheros WAV, pero mover ficheros de varios gigabytes de un lado para otro a través de internet es poco práctico.

Toda conversión supone una pérdida de calidad, con suerte, inapreciable. En este caso no nos importa mucho porque esta conversión es puntual y el flujo de trabajo normal de mi aplicación usa Opus. Esta conversión a MP3 es anecdótica, la excepción.

El proceso, en realidad, es sencillo y rápido:

$ opusdec --force-wav ENTRADA.opus - | lame -v - SALIDA.mp3

Estos comandos encadenados tienen dos ventajas: aprovechan dos núcleos de tus CPUs y no generan un fichero WAV intermedio potencialmente muy largo. El fichero MP3 generado es un VBR sin limitaciones de bitrate, por calidad y tamaño. Las etiquetas OPUS se pierden en vez de convertirse a ID3 en el MP3, pero eso no es un problema en esta aplicación.

Para el perfil de audio de mi aplicación, los audios en MP3 ocupan un 54% más que la versión Opus, con una calidad objetiva (marginalmente) inferior. Es decir, para una calidad de sonido comparable, el formato MP3 necesita un 54% más de bitrate que Opus.

¿Cómo desactivar la WIFI y/o el Bluetooth internos de una Raspberry PI 3?

Cambiar mi red WIFI al canal 13, como se describe en Usar los canales WIFI 12 y 13 en una Raspberry PI, ayudó un poco, pero la calidad seguía siendo insuficiente. En la práctica no se podía confiar en el funcionamiento WIFI de la Raspberry PI 3, lo que resulta la mar de frustrante.

Antes de la Raspberry PI 3 usaba modelos anteriores con un USB WIFI externo. Funcionaba a la perfección. ¿Y si pruebo ese dispositivo en la Raspberry PI 3?.

Esa Raspberry PI 3 usa OSMC como media center. Esta distribución solo permite una tarjeta WIFI así que tenemos que desactivar la capacidad WIFI interna para que utilice el WIFI USB.

Leer más…

Usar los canales WIFI 12 y 13 en una Raspberry PI

Compré una Raspberry PI 3 cuando salió y llevo usando su WIFI integrada desde entonces. La velocidad y estabilidad de esa conexión, no obstante, se ha reducido a medida que más y más vecinos han ido instalando conexiones de alta velocidad en casa. A ciertas horas del día la WIFI de la pobre Raspberry PI 3, sencillamente, dejaba de funcionar.

Estudiando la distribución de uso del ancho de banda WIFI me resultaba claro que todos los canales estaban ocupados. Existía, sin embargo, un pequeño hueco al final de la banda, correspondiente a los canales 12 y 13. Esa zona recibe solapamientos de los canales adyacentes, pero no había nadie emitiendo centrado en esa zona. ¿Una oportunidad?.

Leer más…

Borrado seguro de datos en discos duros y SSDs (con FreeBSD)

Hace unas semanas tuve que devolver un servidor hospedado en un centro de datos remoto y me surgió la necesidad de borrar cuidadosamente sus dispositivos de almacenamiento. Normalmente usaría unas cuantas pasadas con el comando dd if=/dev/zero of=.... No obstante, este caso tiene algunos factores interesantes: la máquina tiene tanto discos duros como dispositivos SSD lo que me permite poder comparar ambos tipos de dispositivos, es lo bastante moderna como para soportar versiones recientes del estándar ATA y la máquina tiene instalado OpenSolaris. El último punto es importante, porque el entorno de recuperación que me ofrece el centro de datos no incluye Linux; tan solo una versión prehistórica (2009) de OpenSolaris y una versión aún calentita de FreeBSD.

Mi borrado habitual con varias pasadas de dd if=/dev/zero of=... es muy seguro, pero a) no borra absolutamente todo el disco duro. Por ejemplo, no se borran los sectores remapeados o sectores considerados como dañados o sectores de reserva. Y b) el tiempo de borrado es proporcional al tamaño del disco duro y, en cualquier caso, es bastante lento y monopoliza el ordenador durante el proceso.

Los discos ATA modernos implementan una extensión para el borrado seguro de datos. Su uso es mucho más rápido que el borrado "a mano" y teóricamente más exhaustivo. La entrega de este servidor fue la ocasión perfecta para probar la extensión.

Leer más…

Añadir un fichero a un repositorio Mercurial respetando su fecha de modificación

Mercurial es un excelente sistema de control de versiones comparable a Git, pero, en mi opinión, mejor por una gran variedad de razones. En febrero de 2013 di una charla en Python Madrid sobre este tema. Fue muy polémica. Ese es un tema para otro día :-).

Cuando se introduce una nueva versión de un fichero en el sistema de control de versiones, la fecha que se almacena es la fecha del commit. Esto no es problema porque, en general, hacemos el commit segundos o minutos después de hacer las modificaciones en el fichero.

El problema surge cuando queremos añadir un fichero antiguo a un sistema de control de versiones respetando la fecha de última modificación del fichero, no la hora del commit. Esto puede ser importante para respetar la historia del proyecto, preservar la integridad legal del mismo, etc.

Mercurial es versátil. A la hora de hacer un commit podemos especificar la fecha y hora que queremos reflejar mediante el parámetro -d o --date. Por ejemplo:

$ hg commit -d "$(date -u -r FICHERO +'%s') 0" -m "TEXTO"

El comando anterior hará un commit reflejando la fecha y hora del fichero especificado.

Migración de una base de datos LMDB a otra plataforma

LMDB es una base de datos ACID ligera y de alto rendimiento, especialmente recomendable para entornos con pocas escrituras y poca concurrencia de escritura. Dado el cambio de licencia de la extraordinaria Berkeley DB a partir de su versión 6.0, estoy usando LMDB cuando no necesito utilizar las sobresalientes características de Berkeley DB. Cuando necesito tirar de las funcionalidades de Berkeley DB, pero el proyecto no puede utilizar la licencia AGPL3, utilizo la última versión con una licencia utilizable en la práctica, la 5.3.

Una buena parte del rendimiento de LMDB proviene de mapear la base de datos directamente en memoria. Una consecuencia de eso y del uso de punteros y estructuras nativas es que la base de datos no es portable. Cambios de arquitectura entre 32 y 64 bits o de endianness hacen que la base de datos resulte ilegible.

Leer más…