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.

Cómo ver los detalles de la batería de un portátil Linux

En la mayoría de los ordenadores portátiles con Linux se pueden ver detalles de la batería examinando el directorio /sys/class/power_supply/BATT/. Por ejemplo:

root@jcea:/home/jcea# cd /sys/class/power_supply/BATT/
root@jcea:/sys/class/power_supply/BATT# cat charge_full
4261000
root@jcea:/sys/class/power_supply/BATT# cat voltage_now
7850000
root@jcea:/sys/class/power_supply/BATT# cat capacity
98
root@jcea:/sys/class/power_supply/BATT# cat charge_full
4261000
root@jcea:/sys/class/power_supply/BATT# cat charge_full_design
6000000
root@jcea:/sys/class/power_supply/BATT# cat charge_now
4194000

Lo que puedes ver depende de tu versión de Linux y del sistema de gestión de batería de tu portátil.

"piadm" or how to boot SmartOS from the local hard disk

SmartOS is a hypervisor that traditionally boots from a USB device, a CD-ROM/DVD or PXE. That is nice and convenient because you can easily upgrade and even downgrade safely without touching the hard disk, test new versions with no consequences, and you always have a bootable system whatever you do.

But this convenience requires physical access to the hardware or plugging extra devices (USB) into remote hosted machine, usually something you have to pay for as an extra. I overcame those by playing dangerously, as I documented in:

Nice hacks of mine.

Since a couple of years ago, SmartOS has been able to officially install itself and boot from the hard disk. Welcome to the new piadm command.

First, some reading you might find interesting and useful:

Leer más…

Cómo encontrar ficheros duplicados

Guardo muchísimos documentos en PDF y a veces conviene revisar si tengo alguno duplicado. Esto puede serte útil para buscar archivos duplicados en general:

jcea@jcea:~$ sha256sum *.pdf | sort | uniq -d -w 32

Este código calcula el hash SHA256 de los PDF y nos muestra los duplicados. El proceso puede llevar su tiempo si tienes muchos ficheros o son muy largos.

Cómo ver los datos de sincronización de tiempo en un sistema operativo con "systemd"

En entornos Linux que utilicen Systemd es común que el protocolo NTP lo gestione Systemd, así que hay que aprender a plegarse al signo de los tiempos.

Veamos cómo ver detalles de sincronización de tiempo con Systemd:

jcea@jcea:~$ timedatectl status
               Local time: mar 2023-08-22 15:44:17 CET
           Universal time: mar 2023-08-22 14:44:17 UTC
                 RTC time: mar 2023-08-22 14:44:17
                Time zone: Europe/Madrid (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

jcea@jcea:~$ timedatectl timesync-status
       Server: 2620:2d:4000:1::41 (ntp.ubuntu.com)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: 4FF33C32
    Precision: 1us (-25)
Root distance: 785us (max: 5s)
       Offset: -48.589ms
        Delay: 31.949ms
       Jitter: 20.555ms
 Packet count: 40
    Frequency: +16,668ppm

How to force a reconfiguration on SmartOS

From time to time we would like to be able to force SmartOS hypervisor to reconfigure again without deleting the complete HardDisk.

It is simple. Just create the following ZFS property in the zones/var dataset: smartdc:factoryreset=yes. Then reboot the SmartOS machine.

If you are curious, check the details in the file /lib/svc/method/fs-joyent. The relevant lines are:

# A machine is reset to its original unsetup state (i.e. a 'factory reset')
# when the smartdc:factoryreset ZFS user property is set on the var dataset.
reset=$(zfs get -H -o value smartdc:factoryreset ${SYS_ZPOOL}/var)
if [ "${reset}" == "yes" ]; then
    destroy_zpools
fi

Cómo cerrar una conexión SSH colgada y otras secuencias de escape SSH

A veces se nos queda una conexión SSH colgada. Esto es típico tras volver de una hibernación o si estamos atravesando un cortafuegos o un NAT con un timeout bajo y la conexión SSH tiene poca actividad.

En esos casos la conexión SSH puede parecer colgada y tenemos que esperar a que la sesión se caiga por timeout SSH.

SSH se puede configurar con un tiempo keepalive corto para mantener el cortafuegos o el NAT contento y, también, para detectar la caída rápidamente tras la vuelta de la hibernación, pero en este artículo vamos a hacerlo de otra manera.

Si estamos en una sesión SSH, podemos pulsar la tecla de línea nueva (la tecla puede etiquetarse como enter, intro o return), luego la virguilla (es decir, ~) y finalmente el signo de interrogación cerrada (es decir, ?). Veremos algo de este estilo:

Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

Aquí vemos algunas secuencias de escape interesantes que conviene conocer. Especialmente nos interesa la secuencia ~., que corta la conexión SSH. Obsérvese también que para enviar una virguilla (~) al servidor hay que pulsarla dos veces.

Recuerda que las secuencias de escape de SSH deben teclearse al principio de la línea. Si no funciona, asegúrate de pulsar la tecla enter primero.