How to pin a "pkgin" package, what is the right way to deploy my own packages?

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,

Refrescar el certificado X.509 de una entidad de certificación para OpenVPN, manteniendo sus firmas previas como válidas

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…

Los peligros de volcar a "pickle" cualquier cosa

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…

Compilar una versión moderna de NodeMCU (Lua) para ESP8266

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…

Mi IoT ha muerto: Cómo actualizar una instalación LUA sobre ESP8266 para que sea compatible con TLS 1.2

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…

Automatización y mantenimiento de NSEC3PARAM en DNSSEC

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…

Cómo autenticarse en Meetup

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…

SmartOS: Serious issue with openjdk 17 and TLS

This post transcribes some emails I sent to several mailing lists:

The initial email was sent to the Kafka User mailing list:

Reply-To: users@kafka.apache.org
Message-ID: <92aa6286-d875-04ed-6205-9e4a8fe3a1a1@jcea.es>
Date: Thu, 9 Nov 2023 03:37:39 +0100
To: users@kafka.apache.org
From: Jesus Cea <jcea@jcea.es>
Subject: How to get a X509 broker certificate with "openssl s_client"?

I am trying to remotely access to the brokers certificates (for audit
purposes, expiration alarms, etc) using this command:

"""
openssl s_client -showcerts -connect localhost:9092
"""

The connection is correctly established, but something is wrong. The TLS
session is has some errors at the beginning, but it success at the end:

"""
[jcea@Kafka ~]$ openssl s_client -showcerts -connect localhost:9092
CONNECTED(00000004)
1:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad
record mac:ssl/record/ssl3_record.c:676:
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1696 bytes and written 300 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
"""

I tried too writing a tiny TLS client in Python, same result, raising
this exception: "ssl.SSLError: [SSL:
DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac
(_ssl.c:992)".

I guess there is some kind of preamble before TLS negotiation.

Is that documented somewhere?. How can I check remotely the brokers'
certificates?

Thanks.

Leer más…

Elegir la identidad SSH que presenta un cliente al servidor

Cuando un cliente se conecta a un servidor SSH, normalmente le propondrá todas las identidades SSH presentes en el servicio SSH Agent. Esto no está necesariamente mal, pero tiene algunos problemas:

  • El servidor SSH puede tener un número de reintentos limitado y nosotros podemos tener muchas identidades SSH que ofrecer.
  • A veces queremos tener nuestras personalidades online separadas y es preferible ofrecer al servidor SSH una identidad concreta controlada en vez de informarle de todas nuestras identidades disponibles para que elija la que le sirva. Un servidor malicioso podría vincular personalidades SSH e identificarnos como la misma persona física en diferentes entornos que preferimos mantener separados.

Los pasos a seguir con OpenSSH son sencillos:

  1. Creamos una nueva identidad SSH para un servicio concreto. Para eso se usa el comando ssh-keygen.

  2. Configuramos en ~/.ssh/config un perfil para ese servicio con estos parámetros:

    # "IdentitiesOnly yes" indica que solo debemos ofrecer
    # esa personalidad, aunque el SSH-Agent tenga más.
    IdentitiesOnly yes
    IdentityFile PATH_A_LA_IDENTIDAD_SSH
    

Cuando nos conectemos al servidor usando ese perfil, el cliente SSH solo ofrecerá esa identidad.

Podemos verificar que todo está funcionando bien conectando a ese servicio con ssh -v y viendo qué identidades estamos ofreciendo al servidor.

Advertencia

La configuración propuesta ofrece una única identidad SSH a un servidor SSH concreto, pero ofrecerá esa personalidad SSH a otros servidores SSH. Si queremos aislamiento total, debemos tener configuraciones similares para todos nuestros servidores SSH (se puede utilizar el comodín para definir una configuración por defecto) o bien añadir esa identidad SSH solo a un servicio SSH Agent concreto y separado.

Recuerda que puedes indicar qué servicio SSH Agent debe utilizar tu cliente SSH utilizando la variable de entorno SSH_AUTH_SOCK.

Cómo ver los detalles de un dispositivo NVMe en Illumos (por ejemplo, SmartOS)

En una máquina con sistema operativo basado en Illumos, como un SmartOS, podemos ver los detalles de un dispositivo NVMe con el comando nvmeadm. Por ejemplo:

[root@tmz1 ~]# nvmeadm list
nvme0: model: Samsung SSD 980 PRO 1TB, serial: S5GXNF0W922518D, FW rev: 5B2QGXA7, NVMe v1.3
  nvme0/1 (c2t002538B931C60571d0): Size = 931.51 GB, Capacity = 931.51 GB, Used = 7.83 GB
nvme1: model: Samsung SSD 980 PRO 1TB, serial: S5GXNF0W920592A, FW rev: 5B2QGXA7, NVMe v1.3
  nvme1/1 (c3t002538B931C5FDEBd0): Size = 931.51 GB, Capacity = 931.51 GB, Used = 7.83 GB

[root@tmz1 ~]# nvmeadm list-logpages nvme0
DEVICE  NAME              SCOPE         FIELDS    DESC
nvme0   error             controller    rae       Error information
nvme0   health            controller,   rae       SMART / Health information
                          namespace
nvme0   firmware          nvm           --        Firmware Slot Information
nvme0   cmdeff            controller    --        commands supported and effects

[root@tmz1 ~]# nvmeadm -v get-logpage nvme0 health
nvme0: SMART/Health Information
  Critical Warnings
    Available Space:                        OK
    Temperature:                            OK
    Device Reliability:                     OK
    Media:                                  OK
    Volatile Memory Backup:                 OK
  Temperature:                              35C
  Available Spare Capacity:                 100%
  Available Spare Threshold:                10%
  Device Life Used:                         0%
  Data Read:                                0GB
  Data Written:                             7GB
  Read Commands:                            27859
  Write Commands:                           42000
  Controller Busy:                          0min
  Power Cycles:                             10
  Power On:                                 11581h
  Unsafe Shutdowns:                         4
  Uncorrectable Media Errors:               0
  Errors Logged:                            0
  Warning Composite Temperature Time:       0min
  Critical Composite Temperature Time:      0min
  Temperature Sensor 1:                     35C
  Temperature Sensor 2:                     47C
  Thermal Management Temp 1 Transition Count: 0
  Thermal Management Temp 2 Transition Count: 0
  Time for Thermal Management Temp 1:       0sec
  Time for Thermal Management Temp 2:       0sec

Se pueden hacer muchas cosas, como un borrado seguro del NVMe, actualizar el firmware. Puedes ver las opciones disponibles revisando el manual con man nvmeadm.