This post transcribes some emails I sent to the SmartOS mailing list some time ago. You can check the original thread:

Message-ID: <15dec164-940e-17d7-a7db-dcdf19f9ec2d@jcea.es>
Date: Tue, 12 Mar 2024 14:07:13 +0100
To: smartos-discuss <smartos-discuss@lists.smartos.org>
From: Jesus Cea <jcea@jcea.es>
List-Id: "smartos-discuss" <smartos-discuss.lists.smartos.org>
Subject: [smartos-discuss] Stock "mkvtoolnix" crashes on 2023.4.0 with locale
  error

Hi, there.

I install "pkgin install mkvtoolnix" with no issues (but a huge number
of dependencies, 1.6 Gigabytes total!).

Then, I run "mkvmerge" and it crashes:

"""
[jcea@test ~]$ mkvmerge
terminate called after throwing an instance of 'std::runtime_error'
what():  locale::facet::_S_create_c_locale name not valid
Abort (core dumped)
"""

This worked fine in 2022.4.0.

My environment variables are:

"""
MANPATH=/opt/local/man:/usr/share/man:/opt/local/lib/perl5/man:/opt/local/lib/perl5/vendor_perl/man
LC_MONETARY=es_ES.UTF-8
TERM=xterm
SHELL=/usr/bin/bash
SSH_CLIENT=***
LC_NUMERIC=es_ES.UTF-8
SSH_TTY=/dev/pts/26
USER=root
COLUMNS=80
PAGER=less
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/opt/local/sbin:/opt/local/bin:/usr/sbin:/usr/bin:/sbin
LC_COLLATE=es_ES.UTF-8
PWD=/home/jcea
LANG=en_US.UTF-8
TZ=Europe/Madrid
LINES=25
SHLVL=1
HOME=/home/jcea
TERMINFO=/opt/local/share/lib/terminfo
LOGNAME=jcea
SSH_CONNECTION=****
LC_TIME=es_ES.UTF-8
FTPMODE=auto
_=/opt/local/bin/env
"""

Jonathan Perkin replied:

Leer más…

Artículos previos sobre este proyecto para enviar por email las novedades diarias de un feed RSS:

• Generar un email diario a partir de un feed RSS (Slashdot).
• Mejoras a la hora de generar un email diario a partir de un feed RSS (Slashdot).
• Los peligros de volcar a "pickle" cualquier cosa.
• "Nullmailer", "Return-Path" y GMail.

Aunque el código va necesitando una refactorización y limpieza, sigo haciendo pequeñas modificaciones y mejoras:

• Modo verboso: Normalmente cuando se invoca el programa hace su trabajo sin más. Pero a veces nos interesa saber qué ha hecho, si ha enviado un correo electrónico o no, por ejemplo, cuántas entradas nuevas hay en el feed RSS, etc.

• Peticiones HTTP incondicionales: De vez en cuando el feed RSS de Slashdot da un error HTTP 50x, indicando un error interno. Cuando esto ocurre, el Sistema Operativo de mi servidor me envía un email indicando que el proceso ha fallado. Ejecutándolo manualmente compruebo que cuando ocurren esos errores el feed RSS de Slashdot no ha cambiado desde la petición anterior y que, de hecho, el problema se resuelve solo cuando aparece una entrada nueva.

  Esto tiene toda la pinta de ser un bug en el código de Slashdot y en realidad solo me afecta de forma cosmética (los correos electrónicos de errores que me llegan por ser administrador de la máquina que ejecuta este servicio), pero durante las pruebas comprobé que hacer una petición HTTP incondicional [1] no produce un error, así que añadí esa funcionalidad al programa.

  [1]

  Cuando mi programa detecta una actualización del feed RSS se queda con sus entradas y las siguientes peticiones no vuelven a pedir el feed RSS sin más, sino que envía al servidor HTTP de Slashdot lo que se llama una petición condicional que básicamente dice: "envíame el feed RSS solo si ha habido algún cambio desde la versión anterior. Si no no me mandes nada". Esto es ventajoso para todo el mundo, pero parece que Slashdot falla de vez en cuando cuando en realidad no ha habido un cambio en el feed RSS y simplemente tendría que haberme respondido con un código HTTP 304. Es así cómo debería ser y, de hecho, es lo que hace el 99.99% del tiempo. Pero falla ese 0.01%...

El parche es largo, pero fácil de entender:

Leer más…

En Generar un email diario a partir de un feed RSS (Slashdot), Mejoras a la hora de generar un email diario a partir de un feed RSS (Slashdot) y Los peligros de volcar a "pickle" cualquier cosa describo un programa para enviar por email las novedades diarias de un feed RSS.

Hace un tiempo modifiqué el programa para enviar los emails a varias direcciones de correo electrónico, no solo a mi cuenta. Todo ha ido bien hasta recientemente que añadí una dirección de GMail a la lista de destinatarios. GMail me rechazaba los mensajes por spam, sin un motivo claro a solucionar.

Tras dedicar unos ratos de diagnóstico y experimentos, he llegado a las siguientes conclusiones:

• El remitente de mis emails era root@P2Ppriv.jcea.es. Ese dominio no existe. No es sorprendente que GMail no aceptase mis mensajes de las novedades diarias del feed RSS.

  No había tenido problemas hasta ese momento porque todos los destinatarios de las novedades diarias del feed RSS de Slashdot eran usuarios locales de mi propio servidor de correo electrónico.

• Incluso poniendo un dominio remitente que exista en la cabecera From, nullmailer estaba usando un envelope SMTP con el mismo dominio inválido. Leyendo la documentación de nullmailer, en concreto el componente nullmailer-inject, podemos leer lo siguiente:

  -f sender

  Set the envelope sender address to sender.

  Esto es esperanzador, pero no estamos usando nullmailer directamente para inyectar los mensajes en el sistema de correo, sino el comando estándar mail, que no tiene un parámetro para controlar el envelope SMTP.

  Revisando otra vez el manual de nullmailer-inject, vemos algo interesante:

  If the Return-Path header field is present and contains a single address, its contents will be used to set the envelope sender address.

  Vaya, podemos utilizar la cabecera Return-Path para controlar el envelope SMTP utilizado por nullmailer.

Por tanto el parche es sencillo:

             msg = MIMEText(html, 'html')
             msg['Subject'] = f'Feed Slashdot {time.strftime("%Y-%m-%d", ts_max)}'
+            msg['From'] = 'slashdot-sender@jcea.es'
             msg['To'] = addr
             msg['Date'] = email.utils.formatdate()
             msg['List-Id'] = 'Notificaciones Slashdot'
             msg['Message-Id'] = email.utils.make_msgid(domain='P2Ppriv')
+            # Esto es para controlar el "sender" del envelope que pone "nullmailer".
+            # Ver "man nullmailer-inject".
+            msg['Return-Path'] = 'slashdot-sender@jcea.es'
+
             msg = msg.as_bytes()

Esta modificacion utiliza una cabecera From para indicar una dirección de correo electrónico que sí exista (en concreto, su dominio) y una cabecera Return-Path para controlar el envelope SMTP y que salga también con un dominio correcto.

Con esto GMail está satisfecho aceptando mis mensajes y tengo amigos felices con su dosis diaria de noticias curadas.

This post transcribes some emails I sent to SmartOS mailing list:

My initial email:

Message-ID: <d50150d8-b863-3886-89d7-f2ae156610a2@jcea.es>
Date: Mon, 4 Mar 2024 03:02:31 +0100
To: smartos-discuss <smartos-discuss@lists.smartos.org>
From: Jesus Cea <jcea@jcea.es>
Subject: [smartos-discuss] How to pin a "pkgin" package, what
   is the right way to deploy my own packages?

I compiled an Apache server package myself because I need some
special compilations. I used the pkgsrc-tls zone image. In
order to avoid automatic updates, I modified the package
version from "2.4.58" to "2.4.589" (I added a 9 at the end). I
naively considered that since my version is higher, it would
override system package.

I did that change in the Makefile.

I manually installed the package with "pkg_add". So good so
far.

Then, I installed stock pkgsrc package
"py312-ap24-mod_wsgi-4.9.4". The dependencies of that package
are:

"""
[root@TEST ~]# pkgin show-deps py312-ap24-mod_wsgi-4.9.4
direct dependencies for py312-ap24-mod_wsgi-4.9.4
         py312-setuptools-[0-9]*
         apache>=2.4.58nb1<2.5
         gcc13-libs>=13.2.0
         python312>=3.12.0
"""

Since dependencies list "apache>=2.4.58nb1<2.5", I would
guess that my "apache-2.4.589" would fit the bill. But pkgin
"refreshes" package system "apache-2.4.58nb1" (not actually
installed!), replacing my package "apache-2.4.589".

So my questions are:

* What would be the right way to compile/install my own
packages shadowing "pkgin" packages, in order to avoid SmartOS
to mess with them when "pkgin install" some other package or,
worse "pkgin upgrade". Yes, I know that this have security
implications, I deal with them myself for my packages.

* Sometimes installing a package does a "refresh" of an
already installed package. Apparently, this uninstall and
reinstall the package. In this particular case, that "refresh"
uninstall my package and install the system package. What is
the point of this "refresh"? What are the conditions that
trigger that action?.

Any advice? Best practices?

Thanks!

PS: My packages are not signed (yet), I disabled (temporary)
signature verification, if that is something important.

After a few hours, Jonathan Perkin <jperkin@mnx.io> provided this useful reply:

Date: Mon, 4 Mar 2024 09:18:21 +0000
From: Jonathan Perkin <jperkin@mnx.io>
To: smartos-discuss <smartos-discuss@lists.smartos.org>
Subject: Re: [smartos-discuss] How to pin a "pkgin" package,
   what is the right way to deploy my own packages?
Message-ID: <ZeWR3Y9NO-ggG_Yu@mnx.io>
References: <d50150d8-b863-3886-89d7-f2ae156610a2@jcea.es>

* On 2024-03-04 at 02:04 GMT, Jesus Cea wrote:

>* What would be the right way to compile/install my own
>packages shadowing "pkgin" packages, in order to avoid
>SmartOS to mess with them when "pkgin install" some other
>package or, worse "pkgin upgrade". Yes, I know that this have
>security implications, I deal with them myself for my
>packages.

pkgin keys packages based on their PKGPATH, i.e. in the case
of apache it'll be www/apache24.  If your custom package is
built in that same directory, then regardless of the version,
pkgin will treat it as being the same.

In order to stop that happening, create a separate directory
in pkgsrc for your custom packages and copy the apache24
directory there, for example local/apache24.  You can also
then revert any version numbering changes and just use the
same as the www/apache24 package.

Ideally have your own git repository for custom packages, for
example the packages under pkgsrc/extra in our tree come from
https://github.com/TritonDataCenter/pkgsrc-extra which is
added as a git submodule.

>* Sometimes installing a package does a "refresh" of an
>already installed package. Apparently, this uninstall and
>reinstall the package. In this particular case, that
>"refresh" uninstall my package and install the system
>package. What is the point of this "refresh"? What are the
>conditions that trigger that action?.

Refresh happens if the remote package BUILD_DATE is newer than
what is installed.  This happens quite frequently, as pkgsrc
will rebuild a package if any of its dependencies have
changed, but this avoids many classes of severely unpleasant
bugs.

One thing to note is that this will happen regardless of
version, as there are some occasions where the version will go
backwards (e.g. we found a critical bug in the newer software
and had to revert back to a previous release), which is why
your modification of the version didn't really do anything.

Cheers,

Tengo un servicio OpenVPN privado desde hace diez años. Todos los certificados X.509 de acceso y el certificado X.509 del servidor OpenVPN están firmados por una autoridad de certificación privada.

El problema es que esa autoridad de certificación tiene una validez de diez años, caducando en unos meses. En ese momento OpenVPN dejará de funcionar si no hago nada.

La solución evidente es crear un nuevo certificado para la autoridad de certificación privada, con una validez de otros diez años (por ejemplo). El problema es que eso requiere emitir nuevos certificados X.509 para el servidor OpenVPN y para todos los clientes. Todo el cambio tiene que estar coordinado, porque los certificados X.509 previos dejarían de ser válidos en cuanto se active la nueva clave de la autoridad de certificación.

¿Cómo refrescar una autoridad de certificación para extender su fecha de caducidad manteniendo la validez de los certificados X.509 firmados previamente?

Los certificados X.509 tienen un número de serie y una fecha de mínima y otra máxima de validez. ¿Es posible modificar dichas fechas del certificado X.509 de la autoridad de certificación y que sigan funcionando las firmas antiguas?

Leer más…

En Generar un email diario a partir de un feed RSS (Slashdot) y Mejoras a la hora de generar un email diario a partir de un feed RSS (Slashdot) describo un programa para enviar por email las novedades diarias de un feed RSS.

Aunque al programa le vendría bien una reescritura, todo fue bien hasta hace unos días, cuando el programa falló con un error indicando que no se podía recuperar el estado volcado con pickle debido a una dependencia (inesperada e inadvertida) con beautifulsoup4.

El error en sí era críptico y poco claro, pero ocurrió tras haber actualizado la biblioteca beautifulsoup4. Esto fue una pista crucial. Obviamente todo volvió a la normalidad tras instalar una versión previa y así siguió cumpliendo con su trabajo unos días hasta que encontré tiempo para echarle un vistazo. La actualización de beautifulsoup4 no era urgente y pude aplazar la investigación hasta que me vino bien.

Una vez metido en faena quedó claro que el problema era que la estructura interna de beautifulsoup4 había cambiado y los objetos serializados de la versión anterior de beautifulsoup4 no podían cargarse en la versión actual de la biblioteca. Esto no es ninguna sorpresa, es lo normal. La sorpresa es que estuviera serializando objetos beautifulsoup4 de forma inadvertida.

Leer más…

En Mi IoT ha muerto: Cómo actualizar una instalación LUA sobre ESP8266 para que sea compatible con TLS 1.2 explico que he tenido que compilar una versión nueva de NodeMCU (Lua) para un ESP8266.

Tengo el tema olvidado porque ahora utilizo MicroPython y microcontroladores más capaces, como ESP32 o RP2040 (Raspberry Pi Pico). En su momento usaba una zona SmartOS con personalidad Debian para estas cosas, pero en 2024 hay opciones más sencillas.

El procedimiento que yo he usado está documentado en el manual de NodeMCU y usa Docker: https://github.com/marcelstoer/docker-nodemcu-build.

Los cambios que he hecho:

Leer más…

En Medir y registrar temperatura, humedad relativa y presión atmosférica con un ESP8266: el componente LUA realizo un montaje doméstico para monitorizar la temperatura y humedad de mi casa. Ese montaje ha estado funcionando, sin apenas variaciones y sin incidencias, desde 2016. Casi ocho años. No está mal.

El problema es que acabo de actualizar las zonas SmartOS de mis servidores a la versión 2023.4.0 y casi todos mis dispositivos IoT han dejado de enviar datos.

La investigación ha sido interesante. La cosa ha ido así:

Leer más…

La solución propuesta en Por qué es conveniente usar NSEC3 en vez de NSEC en un dominio DNSSEC define NSEC3PARAM ya sea en el fichero de zona o utilizando rndc signing -nsec3param.

Este enfoque tiene un problema serio: ocasionalmente el signed o el journal de BIND se corrompen y hay que borrarlos. No parece grave porque BIND vuelve a regenerar esos ficheros pero... la configuración NSEC3PARAM se pierde. Y si BIND pierde la configuración NSEC3PARAM deja de servir NSEC3 y la zona pasa a ser NSEC... y no te enteras.

Tras ocurrirme un par de veces decidí ver qué estaba haciendo mal.

Leer más…

No me gusta Meetup por muchos motivos, pero es un hecho que es la plataforma mayoritaria para organizar reuniones, al menos en las comunidades tecnológicas en las que estoy involucrado. Es curioso, precisamente las comunidades que tendrían capacidad técnica para no tener que depender de Meetup...

En fin, la humanidad es así.

Así que no me queda otra que tener automatismos que consumen datos extraídos de Meetup, como los calendarios de los encuentros. Hay grupos que requieren ser miembro para acceder a sus detalles, pero la mayoría están más que encantados de que sus reuniones sean públicas y se les dé difusión.

Todo fue bien hasta la primavera de 2023, cuando Meetup pasó a requerir acceso autenticado para poder acceder a todos los calendarios.

Les escribí varios correos electrónicos que no tuvieron ningún tipo de respuesta (¿se trataba de un error?), consulté el asunto en varios foros técnicos y todo el mundo estaba igual de perdido. La única alternativa que se proponía era hacer scraping a lo bruto de la web, lo cual es bastante fácil, ciertamente, pero me parecía una solución poco elegante y bastante frágil. La última opción.

En mi caso, preferir no utilizar un acceso autenticado no es una cuestión de privacidad sino de sencillez de programación. Puestos a programar y mantener un scraper, podía echarle un ojo a la autenticación en Meetup, que es bastante más complicada que simplemente enviar una cabecera HTTP.

Leer más…