En Generación en Python de certificados X.509 con "Subject Alternative Name" y una entidad de certificación privada (o autofirmados) muestro un programa en Python para generar certificados X.509 con Subject Alternative Name sin depender de OpenSSL y su sintaxis y configuración oscuras. Prefiero hacerlo con un programa propio.

Eso fue en 2018. En los años transcurrido he ido haciendo cambios:

1. Permitir que el campo SAN incluya direcciones IP, no solo nombres DNS. Esto es útil con infraestructura interna.
2. La autoridad de certificación X.509 se especifica de forma explícita. Si utilizas constantemente una autoridad de certificación privada, puedes usar un wrapper Shell.

Leer más…

Estoy teniendo problemas a la hora de procesar ficheros Matroska con subtítulos en formato WebVTT.

Veamos un ejemplo:

La utilidad Matroska mkvmerge -i reconoce las pistas correctamente:

Track ID 0: video (AVC/H.264/MPEG-4p10)
Track ID 1: audio (E-AC-3)
Track ID 2: audio (AC-3)
Track ID 3: subtitles (SubRip/SRT)
Track ID 4: subtitles (WebVTT)

En cambio la utilidad FFmpeg ffprobe tiene problemas para identificar el códec a utilizar con los subtítulos WebVTT:

  Stream #0:4: Subtitle: none
    Metadata:
      title           : Completos
      BPS             : 53
      DURATION        : 01:43:10.562000000
      NUMBER_OF_FRAMES: 1471
      NUMBER_OF_BYTES : 41590
Unsupported codec with id 0 for input stream 4

El none indica que no sabe qué hacer con esa pista.

Curiosamente mi instalación FFmpeg sí soporta el formato WebVTT:

jcea@jcea:~$ ffmpeg -codecs | grep -i webvtt
ffmpeg version 6.1.2 Copyright (c) 2000-2024 the FFmpeg developers
[...]
 DES... webvtt               WebVTT subtitle

Vemos que mi FFmpeg sí tiene soporte de subtítulos WebVTT, tanto para codificar como para decodificar.

Investigando por qué FFmpeg 6.1 no reconoce las pistas WebVTT de mis ficheros Matroska, veo que se trata de un problema conocido:

• [FFmpeg-devel] [PATCH] Add matroska codec id S_TEXT/WEBVTT for WebVTT streams (I).
• [FFmpeg-devel] [PATCH] Add matroska codec id S_TEXT/WEBVTT for WebVTT streams (II).

La explicación sencilla es que hay dos formas de codificar subtítulos WebVTT y mi versión de FFmpeg solo soporta el formato antiguo, no el nuevo utilizado en los ficheros Matroska modernos.

Parece que lo más sencillo sería actualizar a FFmpeg 7, pero por diversos motivos no es algo que pueda hacer a corto plazo.

¿Qué opciones tengo?

Leer más…

Como es evidente para cualquiera que siga este blog, Slashdot es una de mis fuentes de información diaria. Lo sigo desde hace décadas y forma parte de mis rutinas de vida.

Hace unos días estaba hablando con un amigo sobre esto y me comentaba que Slashdot es muy interesante, pero le resultaba molesta su publicidad. "¿De qué publicidad me hablas?", le dije. Así que me mandó una captura de pantalla.

Madre mía. No entiendo cómo la gente "normal" puede tolerar cosas así.

Yo tengo instaladas un puñado de herramientas que me filtran prácticamente toda la publicidad, vídeos y sonidos de internet. Navego tranquilo. Curiosamente este amigo también, pero le sale publicidad en Slashdot. ¿Qué está pasando?

Entonces me di cuenta de un detalle: Una de las extensiones que utilizo en mi navegador para ahorrarme ver toda esa basurilla es uBlock Origin, que permite añadir reglas personales. Comprobando mi configuración, ahí estaba:

! 2023-05-09
slashdot.org###announcement

¡Ahá!, ahí está. En 2023 añadí esa regla a mi configuración y por eso no veo publicidad en Slashdot.

Mi amigo añadió esa regla en su uBlock Origin, en la sección My Filters, y ahora es un hombre más feliz.

This blogpost documents how to install SmartOS in a datacenter machine, with no remote KVM neither physical access.

SmartOS used to need a CD, DVD or USB pendrive to boot the Hypervisor (saving hacks like Installing/booting SmartOS in/from a harddisk without physical access), but since late 2020 you can install it in the ZFS ZPOOL and directly boot from there, using the new utility piadm.

Leer más…

Todo empezó de manera inocente con este mensaje que escribí en el foro OSMC:

Title: Audio related messages flooding the logs when no HDMI display present

For “reasons”, during the christmas holidays, I am using my regular OSMC Raspberry PI device abroad with no HDMI cable connected to a screen. No display at all. This is useful to me because this device does other functions beside OSMC.

I noticed these messages flooding /home/osmc/.kodi/temp/kodi.log:

2024-12-27 02:00:52.928 T:688      info <general>: CActiveAESink::OpenSink - initialize sink
2024-12-27 02:00:52.929 T:688      info <general>: CAESinkALSA::Initialize - Attempting to open device "default"
2024-12-27 02:00:52.931 T:688      info <general>: CAESinkALSA - Unable to open device "default" for playback
2024-12-27 02:00:52.931 T:688     error <general>: CAESinkALSA::Initialize - failed to initialize device "default"
2024-12-27 02:00:52.931 T:688     error <general>: CActiveAESink::OpenSink - no sink was returned
2024-12-27 02:00:52.931 T:687     error <general>: ActiveAE::InitSink - returned error
2024-12-27 02:00:52.935 T:674     error <general>: failed to duplicate EGL fence fd (EGL_SUCCESS)

The logfile grows fast, possibly filling soon the microSD and decreasing its lifetime.

Beside that, maybe unrelated, KODI is using all the file descriptors (1024 in my case) trying to do “something”. Maybe related to those logs or not:

root@osmcpi:/home/osmc/.kodi/temp# ls -la /proc/674/fd|tail
lr-x------ 1 root root 64 Dec 27 02:03 990 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 991 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 992 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 993 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 994 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 995 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 996 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 997 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 998 -> anon_inode:sync_file
lr-x------ 1 root root 64 Dec 27 02:03 999 -> anon_inode:sync_file

Checking /proc/674/fdinfo/ I see this (the same data for any file descriptor):

root@osmcpi:/home/osmc/.kodi/temp# cat /proc/674/fdinfo/999
pos:    0
flags:  02000000
mnt_id: 14
ino:    7559

I can not determine what mount id 14 filesystem is, even using findmnt.

Leer más…

Tras actualizar a Python 3.13 y mod_wsgi, tal y como se describe en Problema actualizando mis servicios WSGI a Python 3.13, empecé a ver estos errores en el log:

Exception ignored in: <gzip on 0x7fd58e3c6fb0>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 373, in close
    fileobj.write(self.compress.flush())
zlib.error: Error -2 while flushing: inconsistent stream state

La excepción no parece tener ningún efecto práctico en el programa, pero muestra que hay un problema a resolver.

Lo primero que llama la atención es que el traceback no parece completo, no indica qué código está llamando a la función close(). Ese detalle junto al mensaje Exception ignored in: indica que se trata de una excepción asíncrona que ocurre en un destructor.

Para saber qué parte del código está generando esa excepción (de forma asíncrona), podemos modificar el código añadiendo esto al principio:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

 import sys, inspect
 class GzipFile(gzip.GzipFile):
     def __init__(self, *args, **kwargs):
         creador = inspect.stack()[1]
         self._creador = (creador.filename, creador.function, creador.lineno)
         del creador
         return super().__init__(*args, **kwargs)

     def close(self):
         try:
             print("CLOSE", file=sys.stderr)
             return super().close()
         except Exception as exc:
             print(self._creador, file=sys.stderr)
             raise

 gzip.GzipFile = GzipFile

Leer más…

Este artículo fusiona los anteriores:

• Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap".
• Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap" (II).
• Compilar una versión más moderna de "Bind" que la disponible en PkgSrc para SmartOS.

Adicionalmente queremos tener en cuenta:

• How to pin a "pkgin" package, what is the right way to deploy my own packages?
• Queremos incorporar parches propios.

Con todo lo anterior, queda algo así:

Leer más…

El otro día estaba mirando las cabeceras SMTP de mis correos electrónicos y me he llevado una sorpresa:

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
            Thunderbird/102.15.1

Mi cliente de correo, Thunderbird, filtra la versión que estoy utilizando y que estoy usando Linux sobre x86-64.

Y esto no lo hace solo en los correos electrónicos salientes sino también en las conexiones HTTP que se generen al visualizar mensajes en formato HTML.

Esto me parece algo innecesario y un peligro de privacidad y de seguridad.

Afortunadamente podemos irnos al editor de configuración de Thunderbird y editar (o crear, si no existe) la preferencia general.useragent.override. Ahí ponemos el texto que nos de la gana.

En versiones modernas de Thunderbird podemos indicarle directamente al programa que sólo envie Thunderbird como identificación, sin referencias de plataforma o versiones. Para ello hay que entrar en el editor de configuración y poner (o crear) la preferencia mailnews.headers.useMinimalUserAgent a True. Si no queremos enviar una identificación de usuario en absoluto, podemos poner a False la preferencia mailnews.headers.sendUserAgent.

Podeis ver los detalles por vosotros mismos en el código fuente de Thunderbird, en su servidor Mercurial.

En una máquina con sistema operativo basado en Illumos, como un SmartOS, podemos ver los detalles de su CPU con el siguiente comando:

[root@X ~]# kstat -p cpu_info:0:cpu_info0:brand
cpu_info:0:cpu_info0:brand      Intel(r) Core(tm) i7-6700 CPU @ 3.40GHz

Una vez que conocemos el modelo, podemos investigar sus características en infinidad de páginas online. Si lo que queremos es saber cuántos núcleos tiene esa CPU, sin andar buscando online, podemos ir probando valores de núcleo:

[root@X ~]# kstat -p cpu_info:0:cpu_info0:brand
cpu_info:0:cpu_info0:brand      Intel(r) Core(tm) i7-6700 CPU @ 3.40GHz
[...]
[root@X ~]# kstat -p cpu_info:7:cpu_info7:brand
cpu_info:7:cpu_info7:brand      Intel(r) Core(tm) i7-6700 CPU @ 3.40GHz
[root@X ~]# kstat -p cpu_info:8:cpu_info8:brand
[root@X ~]#

La CPU de esta máquina tiene ocho núcleos. Recuerda que se empieza a contar desde cero.

Este comando es útil, por ejemplo, en máquinas en hospedaje en centros de datos ajenos, a las que no tenemos acceso físico.

Acaba de salir Python 3.13 y, como siempre, actualizo mi código y servicios a esta nueva versión. Actualizo rápido para aprovechar las mejoras de la nueva versión de Python y porque acumular actualizaciones pendientes supone que el coste de migrar va creciendo cada año.

Normalmente los cambios necesarios son mínimos, pero en esta ocasión tengo problemas con mis servicios WSGI a través del módulo mod_wsgi.

Los servicios en sí parecen funcionar correctamente, pero los logs se saturan de cientos de líneas por segundo con el siguiente error:

Exception ignored in: <_io.TextIOWrapper name='<wsgi.errors>' encoding='utf-8'>
RuntimeError: log object has expired

Viendo el código fuente de mod_wsgi y del propio intérprete de Python, esto ocurre cuando se escribe en el log (o se hace flush) una vez que ya se ha llamado a close. La parte de Exception ignored está dentro del intérprete de Python, cuando se intenta escribir en un fichero que no puede dar una excepción. Por ejemplo, cuando un destructor levanta una excepción o durante la recogida de basuras.

Aunque todo parece ir bien, de momento seguiré con Python 3.12, mientras investigo el problema en detalle. Ahora mismo estoy bastante ocupado...

20241015: Alguien se me ha adelantado informando del problema: RuntimeError: log object has expired in mod_wsgi 5.0.1 with Django 5.0.9 python 3.13.0 #912.

20241122: Se publica la versión 5.0.2 de mod_wsgi que, aparentemente, soluciona este problema.

20250125: Encuentro un rato para actualizar mis servicios WSGI a la nueva versión de mod_wsgi y confirmo que el problema se ha solucionado.