Mailman is a mailing list software written in Python. It includes mailing list operation, management and a web interface.

Usually Mailman is running in a machine having a web server and a mail server. In this article I will describe how to operate a Mailman environment where the mail server resides in a different machine. Why? Because I already have a mail server running. Taking care of configuration, operation and spam filtering of an additional service is a burden.

Leer más…

En informática existe la regla básica de que todo debe caber en RAM. El espacio SWAP no debería utilizarse. La realidad es más complicada y depende del sistema operativo. En Solaris, por ejemplo, no hay una distinción clara entre RAM y SWAP y, de hecho, al medir el espacio disponible se muestra la suma de ambos recursos y cuando un proceso reserva memoria, se reserva de ese total. En Linux, en cambio, existe el concepto de overcommit de memoria: un proceso puede pedir la memoria que le de la gana, pero no se reservarán bloques de memoria hasta que el proceso los vaya utilizando. Esto permite que un proceso tenga un espacio de direcciones inmenso si no lo utiliza de forma intensiva, pero la contrapartida es que si un proceso realmente emplea toda la memoria que ha solicitado, puede fallar a mitad de ejecución porque no hay recursos suficientes. En Solaris fallaría directamente en la solicitud de memoria inicial.

Sobre el SWAP hay muchos mitos. Por ejemplo, es frecuente reservar tanto espacio de SWAP como RAM tengas en la máquina o el doble de dicha cantidad. ¿Por qué? La respuesta habitual es "porque sí, todo el mundo sabe que es lo que hay que hacer". Hay algunas razones históricas, pero hoy en día no tienen sentido.

La verdadera regla de oro respecto al SWAP es que todo el working set de los procesos en ejecución en el sistema debe caber en RAM. Si tu working set no cabe en RAM, tu rendimiento será ridículo. Una vez que tienes RAM suficiente, el tamaño del SWAP depende de tus necesidades. En Solaris, por ejemplo, es conveniente proporcionar un SWAP amplio porque el sistema lo usará para enviar allí lo que menos se use y así hacer hueco en RAM para cosas más importantes. En Linux el SWAP es más secundario, en buena parte debido al overcommit. Hay que señalar que los entornos Linux que no pueden permitirse que mueran procesos arbitrarios por escasez de recursos, se configuran para desactivar el overcommit y las necesidades de SWAP cambian completamente.

Leer más…

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 using this configuration you can do this:

Leer más…

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…

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…

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.

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 :-(.

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.

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…

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…

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…