bisko.be - Dev

Cómo ejecutar Ollama con GPUs antiguas en CachyOS

Sat, 28 Feb 2026 00:00:00 GMT

TL;DR;

ollama-cuda en CachyOS viene (a día de hoy) con soporte únicamente para compute >= 7.5.

Si tienen GPUs antiguas con un compute menor, TIENEN QUE hacer una de estas 2 cosas:

Compilar ollama-cuda desde el código fuente, con soporte para los targets de compute más antiguos
Instalar ollama-vulkan

Yo elegí ollama-vulkan y funciona perfectamente.

Hora de la historia

Hoy me llegó la inspiración para apagar por fin mi VM de Windows 11 y migrarla a Linux.

Los requisitos eran poder ejecutar:

Ollama - para la magia de los modelos locales
Docker - para desarrollo remoto
Steam - para jugar
Jellyfin - para el archivo de videos caseros

Ahora me voy a centrar solo en Ollama, porque fue una experiencia interesante y me dejó preguntándome por qué las cosas no son más obvias.

La máquina tiene 2 GPUs:

GTX 1070 - 8GB
GTX 970 - 4GB

Quería ejecutar Ollama en ellas para jugar con modelos locales y ver cómo podría integrarlos en algunos proyectos. Por ejemplo: anonimizar datos de forma local, hacer una implementación no destructiva de OpenClaw que se ajuste a mis casos de uso, OCR local para los documentos que escaneo con el teléfono, o automatizar algunas cosas de la gestión cotidiana de una casa.

Así que, naturalmente, instalé ollama y ollama-cuda, ya que tengo 2 GPUs Nvidia, esperando que funcionara sin problemas, pues en Windows funcionaba perfectamente apenas unos minutos antes.

Arranqué Ollama, cargué qwen3:8b para un experimento rápido y… se estaba ejecutando en la CPU 🤔

Las GPUs eran perfectamente capaces de mantenerlo en la VRAM, pero por alguna razón Ollama prefería ejecutarlo en la CPU.

Después de intentar descifrarlo a partir de los logs, le pedí ayuda a Claude y llegó a una conclusión bastante desalentadora:

The logs tell the story clearly. Both your GPUs are detected but then filtered out because they fail CUDA initialization:

  "filtering device which didn't fully initialize" id=GPU-eb132a13-b9f4-40e3-d85d-60f211dfd21e ... library=CUDA
  "filtering device which didn't fully initialize" id=GPU-550263c8-37e2-2a25-c0b6-10cc7511ed20 ... library=CUDA

  The reason is the CUDA library bundled with Ollama 0.17.4 was compiled for these architectures only:

  CUDA.0.ARCHS=750,800,860,870,880,890,900,1000,1030,1100,1200,1210

  The minimum supported compute capability is 7.5 (Turing / RTX 20xx series). Your GPUs are older than that:

  ┌──────────┬────────────────────┬──────────────┐
  │   GPU    │ Compute Capability │ Architecture │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 1070 │ 6.1                │ Pascal       │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 970  │ 5.2                │ Maxwell      │
  └──────────┴────────────────────┴──────────────┘

  Neither is in the supported list, so CUDA initialization fails for both, and Ollama falls back to CPU-only inference.

  Your options:

  1. Downgrade Ollama to an older version that still included Pascal/Maxwell support (pre-0.6.x era had broader arch coverage, but check release notes for specifics).
  2. Build Ollama from source with CUDA_ARCHITECTURES="52;61;75;80;86" to include your GPU architectures.
  3. Upgrade GPUs to at least an RTX 2060 or newer (compute 7.5+).

Esto fue un poco decepcionante para mí, porque quiero aprovechar las GPUs al máximo antes de pasar a una nueva.

No quería compilar Ollama desde el código fuente, ya que debería funcionar directamente y me confundía mucho que no lo hiciera, cuando en la instalación de Windows sí soportaba esas arquitecturas.

¡Además, esas tarjetas aparecían como compatibles en el sitio web de Ollama!

Para resumir una larga historia de búsquedas en Google:

Resulta que ollama-cuda viene solo con los requisitos mencionados arriba… y la sugerencia era instalar ollama-vulkan.

¡Después de hacerlo, todo empezó a funcionar sin ningún problema!

[Linux] Recuperar una sesión desconectada de `apt dist-upgrade`

Wed, 23 Oct 2024 00:00:00 GMT

Hoy estaba actualizando mi instalación de Proxmox de forma remota a través de la consola integrada, pero olvidé lo que estaba haciendo y cerré la pestaña a medias.

Como resultado, no pude volver a conectarme, ya que los paquetes se seguían actualizando en segundo plano y la actualización había hecho una pregunta sobre si reemplazar un archivo y estaba esperando mi respuesta.

Así que podía entrar por SSH, pero no podía hacer nada, porque seguía esperando una respuesta en una consola a la que no me podía conectar, ya que la interfaz no se abría.

Después de buscar un poco, me topé con un hilo de Serverfault que mencionaba el uso de reptyr para tomar el control de la sesión de terminal por SSH.

Dejo aquí exactamente lo que hice para recuperar la sesión y terminar la actualización:

De este comentario:

git clone https://github.com/nelhage/reptyr
cd reptyr
make install

Esto instaló reptyr en la máquina.

Luego busqué todas las sesiones abiertas con ps ax | grep pts para encontrar el proceso que andaba buscando.

Después encontré el proceso más alto en el árbol de llamadas que tuviera un pts asignado y me adjunté a él mediante su PID:

reptyr -T 1390511

¡Y así pude terminar la actualización! 🎉

[Linux] Syncthing – sistema de archivos de solo lectura al ejecutarlo como servicio

Wed, 06 Apr 2022 00:00:00 GMT

Llevo un tiempo usando Syncthing para sincronizar mi copia de trabajo con un servidor de desarrollo local, unos cuantos meses ya.

Al principio lo usaba iniciando sesión y ejecutándolo manualmente desde la línea de comandos. Funcionaba bien, así que no lo pensé dos veces cuando pasé a ejecutarlo como servicio. Arrancó, sincronizó algunos datos, todo iba bien.

Hasta que dejó de ir bien, ¡por supuesto! 🙂

Resulta que no me di cuenta de que en los logs estaban apareciendo un montón de errores que decían que el sistema de archivos del servidor de desarrollo era de solo lectura, y eso hacía que Syncthing no sincronizara nada.

Pensé que era un bug y que simplemente mostraba Out of Sync en las carpetas, pero que en realidad sí estaba sincronizando. Pues me equivocaba.

Después de depurar durante varias horas y de no encontrar ninguna pista en los foros con unas cuantas búsquedas en Google, llegué a un artículo sobre Syncthing en la ArchWiki, que mencionaba justo mi caso:

read-only file system error on /etc although run as root

Era exactamente mi caso de uso, salvo que la carpeta problemática no era /etc, sino /usr/local/src.

Bueno, después de leer lo que decía, resulta que si ejecutas Syncthing (o cualquier cosa) mediante systemd y tienes ProtectSystem configurado en full para el servicio, algunos directorios se vuelven de solo lectura por defecto. /usr es una de esas rutas.

Para solucionarlo, hay que añadir una nueva línea en la configuración del servicio y reiniciarlo (y hacer daemon-reload):

ReadWritePaths=/usr/local/src

Después de esto, Syncthing debería funcionar bien.

[Linux] Ejecutar varios comandos en varios servidores en paralelo

Mon, 19 Apr 2021 00:00:00 GMT

Tengo en casa un clúster de Raspberry Pi con Docker Swarm. Para no perder el control, todas usan la misma configuración: usuarios, versiones de Docker, etc.

A veces algunas actualizaciones requieren ejecutar lo mismo en todos los nodos del clúster, por ejemplo, crear una nueva red macvlan de Docker.

Para hacerlo, hay que ejecutar los mismos comandos en todos los nodos manualmente, entrando por ssh a cada uno, ejecutando los comandos y pasando al siguiente.

Como intento reducir mi trabajo a la larga y tener todo lo más organizado posible, empecé a buscar formas de ejecutar comandos en todos los nodos al mismo tiempo.

Iteración 1: un script de Python a medida

La primera iteración consistió en crear un script de Python propio. Por un lado, quería aprender un poco mejor Python; por otro, no encontraba una forma buena de ejecutar los comandos de manera más nativa.

Como cabe esperar (oigan, todavía tengo poca experiencia con el lenguaje 🙂), se convirtió en un desastre enorme muy rápido y se rompía con facilidad.

Tenía que encontrar otra manera de hacerlo, sin tener que volver a aprender lo que hice hace 3 semanas y lo que se rompió la última vez.

Iteración 2: `pssh`

Buscando por internet me topé con [pssh](https://linux.die.net/man/1/pssh), que puede ejecutar cosas en paralelo mediante SSH.

Pensándolo bien, fue bastante fácil ponerlo en marcha.

El problema era que, para ejecutar algunas cosas, necesitaba hacerlo con sudo. Pasar contraseñas de un lado a otro no era lo ideal, así que tuve que buscar de nuevo cómo enviar la contraseña de sudo cuando el servidor remoto la pidiera.

Resulta que es bastante fácil si das con el comentario de StackOverflow adecuado.

La versión resumida es:

stty -echo; printf "Password: "; read PASS; stty echo; echo "${PASS}" | \
pssh -h <HOSTFILE> -o /tmp/output -t 0 -I "`cat ./commands.sh`"

Hay que escribir -I "`cat ./commands.sh`" exactamente así (entre comillas y comillas invertidas); de lo contrario, no ejecuta bien los comandos. La contraseña se enviará como un comando aparte y no se tomará como entrada de sudo.

La otra trampa es que, por la manera en que está montado todo esto, hay que ejecutar sudo con el parámetro -S para que lea bien la contraseña.

Adivinando la contraseña numérica de un archivo zip usando solo utilidades de línea de comandos

Mon, 14 Sep 2020 00:00:00 GMT

Hoy recibí mi factura mensual de mi proveedor de internet y algo me pareció extraño.

La factura, incluida en el correo, venía en un archivo ZIP con contraseña.

Sin mencionar lo extraño que resulta en estos días recibir un adjunto en forma de archivo ZIP (spam, malware, phishing, etc.), la contraseña que eligieron me pareció muy débil.

Es la fecha de nacimiento del titular de la cuenta en el formato YYMMDD.

Hice un cálculo muy burdo mentalmente mientras estaba en el gimnasio y resultó en muy pocas combinaciones posibles. Después de usar una herramienta en línea para calcular cuántos días han pasado (ya que no todas las combinaciones resultarían en una fecha válida) desde el 1900-01-01, resulta que las combinaciones son solo 44,075 (hasta el 2020-09-14).

Sabiendo que las herramientas optimizadas que usan el poder de las GPU para descifrar hashes pueden hacer millones de intentos por segundo, quise ver qué tan rápido se podía adivinar la contraseña sin usarlas y utilizando solo la CLI de Linux/macOS (ya que solo tenía acceso a un VPS en el gimnasio).

Se me ocurrió el siguiente código que funciona en macOS:

echo {1..44000} | xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" | xargs -P 16 -I{} sh -c 'unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255'

El comando es bastante simple en su funcionamiento, aunque parece complicado.

echo {1..44000} genera los números del 1 al 44,000 y los pasa al siguiente paso.

xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" – toma la entrada del primer paso y genera fechas en el formato YYMMDD aprovechando la funcionalidad de date para “aumentar” una fecha con una cantidad específica. En este caso tomaría X días a partir de la fecha actual, donde X es el número generado en el primer paso. De esta forma podemos generar fechas desde hoy hasta los años 1900.

El tercer paso es el más interesante, así que lo voy a dividir en dos partes:

xargs -P 16 -I{} sh -c '...'

Esto toma las fechas generadas en el paso 2 y ejecuta un comando sobre cada una de esas fechas. -P 16 aquí significa que va a ejecutar esto en 16 procesos paralelos, para hacer que el procesamiento de los datos sea más rápido. El mismo truco se aplica en el paso 2 para acelerar la generación de fechas.

La segunda parte es donde ocurren los intentos:

unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255

Lo que hace esto es primero intentar descomprimir el archivo zip usando la contraseña generada en el paso 2. Si tiene éxito, imprime (echo) la contraseña adivinada y luego exit 255 obliga a xargs a detener la ejecución. No queremos seguir adivinando si ya se encontró la contraseña.

En resumen, fue una muy mala decisión elegir esto como contraseña para el archivo, porque ejecutar el comando anterior toma solo unos 10 segundos para adivinar la contraseña correcta de mi factura. No mucho más para cualquier otra persona.

Cómo lidiar con el código espagueti en PHP: usar funciones anónimas para extraer fragmentos de código de plantillas

Sat, 08 Aug 2020 00:00:00 GMT

Hace poco he estado ayudando a un amigo a entender un código y a modificarlo para que funcione bien con llamadas asíncronas al backend. Un extra sería poder escribirlo de una forma más modular y reutilizable.

El código es un plugin de WordPress escrito con un enfoque muy legacy: una mezcla de lógica de negocio y de frontend en un solo lugar. Manipulaciones de datos hechas en medio del código de la plantilla y cosas por el estilo.

Básicamente, lo que se veía en los sitios PHP a principios de los 2000, antes de todas esas estupendas incorporaciones de programación orientada a objetos al lenguaje y de un montón de frameworks maduros.

El caso en el que estuve trabajando hoy era el siguiente: tienes una tabla que muestra un montón de entradas. Necesitábamos añadir varios filtros a la tabla y hacer que funcionara vía AJAX para refrescar rápidamente la interfaz, sin recargar toda la página de administración de WordPress.

Filtrar los datos fue fácil: un array_filter rápido en línea para filtrar los datos antes de pasarlos al código de la plantilla (para mantener el mismo estilo de código, esto también estaba en el archivo de la plantilla 😇).

El problema llegó cuando empezamos a trabajar en hacer que la tabla pudiera renderizarse mediante AJAX.

Está en medio de un montón de otro código de plantilla y de negocio. Si queríamos limitar la salida vía AJAX solo a la tabla, teníamos pocas formas de lograrlo.

La primera sería envolver el HTML anterior y posterior a la tabla en ENORMES sentencias if para asegurarnos de que no se renderice.

Otra sería extraer la plantilla a un archivo aparte e incluirlo en la acción AJAX que definiríamos en el código del plugin.

¡Las funciones anónimas al rescate!

Pensando en cómo resolver esto de la manera más sencilla posible, intenté definir una función normal de PHP que contuviera el código de la tabla, pero había un problema.

El código se ejecuta dentro de un método de una clase. Hay referencias a $this en la plantilla de la tabla. Si no queremos cambiar demasiado el código, tendríamos que pasar $this como argumento de la función. Pues bien, eso no funciona, porque no se puede pasar $this como parámetro 🤷‍♂️.

Me decepcionó un poco pensar que tendríamos que reescribir un montón de cosas en la plantilla, y había bastantes referencias que queríamos tener en cuenta para que todo siguiera funcionando.

Entonces recordé que el sitio no corre en PHP 5.2, sino en PHP 7, así que las funciones anónimas estarían soportadas.

Y tienen una característica muy útil: puedes definir qué variables del ámbito que hace la llamada se pasarán a la función cuando esta se invoque. Por ejemplo:

$table_function = function() use ( $pages, $current_page, $items ) {
    // ... Table render code
}

Esto te permite hacer referencia directamente a $pages o $items en el cuerpo de la función.

¡Lo genial es que también puedes pasar $this como una variable en el ámbito de la función!

¡Así pudimos extraer por completo el código de renderizado de la tabla a una función separada que podemos llamar de forma aislada durante la llamada AJAX!

Por supuesto, hay que tener mucho cuidado con las variables usadas dentro del cuerpo de la función, ya que tienen que estar definidas, así que hay que fijarse bien desde dónde se puede llamar a la función AJAX.

En nuestro caso, esto significará que añadiremos una pequeña acción en la clase principal que seguirá haciendo el require del archivo, pero tendremos más control para desactivar todas las demás salidas que se producirían.

Arduino/ESP32: Cómo desactivar el watchdog de tareas

Wed, 29 Apr 2020 00:00:00 GMT

Últimamente he estado jugando con la funcionalidad multinúcleo del ESP32 y con la asignación de tareas a núcleos específicos.

Estaba usando AutoConnect para permitir la conexión WiFi sin guardar las credenciales en el código y para ofrecer actualizaciones OTA desde la interfaz web.

Era para un proyecto que iba a controlar unos ventiladores PWM de CPU de 4 pines que tengo en el armario de mi servidor, para enfriar el aire de su interior. Para eso quería dividir la lógica en dos tareas.

Una tarea para manejar las APIs, la lectura de sensores, las actualizaciones, el WiFi, etc., y otra para manejar la interrupción y el control PWM de los ventiladores.

Todo iba bien, las tareas se crearon, pero al ejecutar el código, si ponía el ESP32 en el modo en el que hay que conectarse a él para indicarle que se conecte a tu red WiFi, empezaba a mostrar un comportamiento extraño: reiniciaba el controlador cada pocos segundos y no lograba que la conexión funcionara.

Fue un rato molesto, porque tuve que desmontar el controlador de su lugar y conectarlo por USB para cargarle un firmware nuevo.

Después de hacer eso noté que el error venía del watchdog:

Task watchdog got triggered. The following tasks did not feed the watchdog in time:

IDLE (CPU 1)
Tasks currently running:
CPU 0: ManageTask
CPU 1: ControllerTask

Investigando un poco, parece que esto lo dispara el Task Watchdog del ESP32, que se encarga de asegurar que las tareas tengan su turno de ejecución en la CPU.

Además, parecía que AutoConnect no era muy flexible al trabajar dentro del contexto de una tarea, en comparación con ejecutarlo fuera de una, directamente con el resto del código y la funcionalidad.

Después de buscar un poco y probar distintas cosas, parece que la forma más fácil de salir de esta situación es simplemente desactivar el watchdog y esperar que las cosas se ejecuten a tiempo 🙂 La tarea no es crítica, así que no pasa nada si tarda más en completar lo que está haciendo.

Para desactivar el watchdog, hay que hacer dos cosas:

Primero, incluir el encabezado esp_task_wdt.h. Para eso, agrega #include <esp_task_wdt.h> a tu sección de includes.

Segundo, hacer que el watchdog no reinicie el controlador y que espere más tiempo. Para ello, hay que añadir esp_task_wdt_init(30, false); al inicio del código de tu tarea.

void manage_core_task(void *pv_parameters) {
    esp_task_wdt_init(30, false);
    // .... rest of the code ...
}

Esto establecerá el tiempo de espera del watchdog en 30 SEGUNDOS y desactivará el reinicio del controlador si se dispara.

Si quieres que el controlador se reinicie de todos modos cuando se dispare el watchdog, cambia el segundo parámetro de la llamada a la función de false a true.

Configurar una YubiKey para firmar commits de Git

Wed, 08 Jan 2020 00:00:00 GMT

He estado usando una YubiKey como llave de autenticación de dos factores y para firmar mis commits de Git. Hasta hace unos días usaba una YubiKey 4. Como mi computadora actual no tiene ningún puerto USB-A, durante el último año he tenido que andar con adaptadores de USB-A a USB-C en la mochila, y usar la llave ha sido una molestia. Por eso decidí que ya era hora de pasarme a mi YubiKey 5C “nueva” y así no tener que lidiar más con esos adaptadores.

En realidad ya tenía la llave desde hace tiempo, porque la pedí junto con una YubiKey 4 de reemplazo que conseguí por el problema del TPM de Infineon que ellos identificaron, pero apenas ahora decidí que era el momento de cambiar a la llave nueva.

La otra razón para hacerlo ahora es que mis viejas llaves GPG caducaron y tuve que volver a emitirlas, así que puedo aprovechar para usar la llave y firmar mis commits de Git.

La locura de GPG

Si has lidiado con llaves GPG en el pasado (o lo haces actualmente), sabes que puede ser bastante difícil ponerlas en marcha de forma correcta y segura si nunca lo has hecho. Mantener las llaves maestras sin conexión, ir moviendo llaves públicas, reemitir las llaves cuando caducan, quizás firmarlas con llaves anteriores para verificarlas, revocar llaves… No es fácil seguir las mejores prácticas ni siquiera en teoría. Cuando toca llevarlas a la práctica, todo se complica muchísimo.

La mayoría de los tutoriales en línea te mandan a generar las llaves desde la línea de comandos, navegando menús con un patrón de diseño poco común, y son un auténtico dolor de cabeza para ponerlas a funcionar. Casi todos dicen que uses una máquina sin conexión, como una Raspberry PI, y/o que generes las llaves maestras y las subllaves sin conexión y mantengas la llave maestra fuera de tu computadora.

🤯

Llevo casi 4 años lidiando con esto cada inicio de enero. Temo el momento en que aparece el siguiente error, avisándome de que mis llaves de firma han caducado.

error: gpg failed to sign the data
fatal: failed to write commit object

Este año decidí que era hora de intentar que el proceso fuera mucho más sencillo, usar la generación de certificados integrada y evitarme todo el lío de generar llaves GPG y demás.

Generación de llaves en la YubiKey

Con esto todavía tenemos que usar la interfaz de línea de comandos, pero es un poco más evidente porque tiene menos pasos.

Primero tenemos que configurar nuestra tarjeta/dispositivo.

Configuración de la tarjeta/dispositivo

Ejecuta gpg --card-status en la terminal y deberías ver algo como esto:

Reader ………..: Yubico Yubikey 4 OTP U2F CCID
Application ID …: <Serial number>
Version ……….: 2.1
Manufacturer …..: Yubico
Serial number ….: <Device serial number>
Name of cardholder: unspecified
Language prefs …: en
Sex …………..: unspecified
URL of public key : \[not set\]
Login data …….: <e-mail or nothing>
Signature PIN ….: not forced
Key attributes …: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 9

Si ves algo parecido y no aparece ningún error, puedes continuar.

Ejecuta gpg --card-edit

Llegarás a una interfaz de línea de comandos que muestra la misma información del inicio y, al final, un prompt gpg/card>.

Escribe admin y presiona Enter.

Ahora puedes escribir help para saber cómo cambiar la información del titular y los PIN de la tarjeta.

Algo que DEBES hacer es cambiar los PIN predeterminados de la tarjeta. Hay dos. El primero es el PIN que usas para acceder a las llaves de la tarjeta. El segundo es el PIN de “Admin” o PUK (Personal Unblocking Code, código personal de desbloqueo).

Para hacerlo, escribe passwd y verás un menú:

gpg/card> passwd  
gpg: OpenPGP card no. <Serial number> detected

1 - change PIN  
2 - unblock PIN  
3 - change Admin PIN  
4 - set the Reset Code  
Q - quit

Escribe 1 y sigue las indicaciones para actualizar tu PIN. El PIN predeterminado es 123456.

Cuando termines, elige 3 para cambiar el PIN de Admin. El predeterminado es 12345678.

Una vez cambiados ambos PIN, vuelve al menú principal para terminar de actualizar la información de la llave.

Los comandos que puedes usar son:

name – para cambiar el nombre del titular
login – para cambiar el correo electrónico o el login del titular

Después de eso podemos pasar a la generación de las llaves propiamente dicha.

Generación de llaves

Ahora sí toca generar las llaves.

Para ello, escribe generate.

Se te preguntará Make off-card backup of encryption key? (Y/n), pero, como se menciona en la documentación de YubiKey, esto es solo un respaldo parcial y no creará una copia completa de las llaves secretas, así que da igual si respondes Yes o No. Yo respondo No(n).

Si ya hay llaves guardadas en la tarjeta, se te preguntará si quieres reemplazarlas:

gpg: Note: keys are already stored on the card!

Replace existing keys? (y/N)

Asegúrate de no reemplazar algo importante de lo que no tengas respaldo y continúa con Y. Si hay algo importante, es mejor abandonar todo el proceso con Ctrl+C.

Se te pedirá el PIN de la tarjeta que configuraste antes.

Luego tendrás que elegir durante cuánto tiempo serán válidas las llaves:

Please specify how long the key should be valid.
        0 = key does not expire
      <n> = key expires in n days
     <n>w = key expires in n weeks
     <n>m = key expires in n months
     <n>y = key expires in n years
 Key is valid for? (0)

Si quieres que las llaves sean válidas solo por 1 año, escribe 1y.

Se te pedirá que confirmes la fecha de caducidad. Revisa que todo esté bien y confirma.

Después se te pedirá que ingreses la información del propietario de la llave:

Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: <Your name>
Email address: <Your e-mail>
Comment: <Comment is optional>
 You selected this USER-ID:
     "<Your name> <comment> <your e-mail>
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Type `O` to confirm if everything seems correct.

Luego se te pedirá el PIN de Admin o PUK. Es necesario porque se realizará una operación de escritura en la tarjeta.

Si todo está bien, la YubiKey empezará a parpadear y seguirá así un buen rato (en mi caso, unos cinco minutos).

Cuando termine verás el siguiente mensaje:

gpg: key <Short ID> marked as ultimately trusted
gpg: revocation certificate stored as '/Users/bisko/.gnupg/openpgp-revocs.d/<LONG ID>.rev' public and secret key created and signed.

Anota el <Short ID>, porque lo usaremos más adelante.

En este punto puedes salir del prompt de GPG con quit o Ctrl+C.

Ahora toca guardar la llave pública, para poder reutilizar la llave en otra computadora.

Para ello, ejecuta el siguiente comando:

gpg --armor --export <Short ID> > <Short ID>.asc

Esto exportará la llave pública a un archivo llamado <Short ID>.asc. Lo usarás en el futuro si quieres poder usar la YubiKey en otra computadora o si pierdes tu configuración de GPG.

Para restaurar la llave pública en tu llavero, tienes que hacer lo siguiente:

gpg --import < <Short ID>.asc
gpg: key <Short ID>: public key "Your Name <your@email>" imported
gpg: Total number processed: 1
gpg: imported: 1

Una nota muy importante. Si se trata de una instalación nueva de GPG o de otra computadora, GPG no reconocerá por sí solo las llaves que están en la tarjeta. Necesitas ejecutar gpg --card-status para que lea la tarjeta y detecte las llaves que contiene.

Configurar Git para firmar

Para configurar Git de modo que firme tus commits, debes agregar lo siguiente a tu ~/.gitconfig.

En la sección [user], tienes que agregar (o actualizar) la siguiente línea:

signingkey = 0x<Short ID>

Luego, si quieres firmar todos tus commits, agrega lo siguiente al final del archivo:

[gpg]
  program = /usr/local/bin/gpg
[commit]
  gpgsign = true

Con esto Git firmará todos tus commits.

Para configurar GitHub, tienes que agregar tu llave pública a tu perfil. Para ello, ve a GitHub -> Settings -> SSH and GPG keys -> New GPG key.

Verás un cuadro de texto donde debes pegar todo el contenido del archivo <Short ID>.asc que generamos antes.

Si quieres copiar el contenido del archivo (en macOS) puedes hacer lo siguiente:

cat <Short ID>.asc | pbcopy

Esto copiará el contenido completo del archivo al portapapeles.

Pega eso en el cuadro de texto de GitHub y haz clic en el botón Add GPG key.

Después de eso puedes intentar hacer un commit y un push a GitHub, y deberías ver la bonita etiqueta Verified.

Depuración

A veces las cosas no funcionan a la primera. Para reunir más información puedes probar lo siguiente:

Firmar con GPG

Primero intenta firmar algo con la llave:

gpg -s <file>

Si esto falla, intenta averiguar por qué; yo no soy ningún experto como para ayudarte con eso.

Revisa la salida de Git con GIT_TRACE=1 git commit -am “test”

Esto te mostrará exactamente lo que hace Git mientras intenta hacer el commit y firmarlo. Te dará una pista de por qué podría estar fallando la firma.

De ahí también puedes ver que Git ejecuta el siguiente comando:

/usr/local/bin/gpg --status-fd=2 -bsau <Key ID>

Puedes intentar ejecutarlo manualmente para ver si te da un error más útil.

e1000e eth0: Detected Hardware Unit Hang

Wed, 18 Dec 2019 00:00:00 GMT

Hace poco mi servidor doméstico y host de máquinas virtuales empezó a perder la conectividad de red de forma aleatoria. Desde fuera parecía que seguía funcionando, pero no podía acceder a él de ninguna forma remota. Según el switch, el adaptador ethernet parecía estar encendido, así que el problema debía estar en algún lugar del software.

No sería la primera vez que un driver es el culpable de que se cuelgue una conexión de red. En el pasado me han fastidiado unos drivers de WiFi con errores, tanto en equipos con Linux como con Windows.

Después de escarbar un poco en los registros del sistema, me topé con lo siguiente:

vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state

Luego reiniciaba el adaptador de red y, al rato, volvía a hacerlo, hasta que la máquina se quedaba completamente sin conexión.

Buscando respuestas en línea, encontré este hilo de ServerFault.

Causa

Leyendo distintas fuentes y listas de reportes de errores, parece que la mejor manera de reproducir el problema es someter al dispositivo a un alto consumo de ancho de banda, por ejemplo transmitiendo grandes cantidades de datos que saturen la interfaz.

En mi caso solía ocurrir cuando transmito contenido multimedia desde el servidor Plex local a algún dispositivo. Por la forma en que está configurada la red, la máquina virtual con Windows que ejecuta Plex tiene que obtener el archivo multimedia de un recurso compartido NFS en otro dispositivo, transcodificarlo en la VM y luego enviarlo al dispositivo de reproducción.

Todo esto suma mucho tráfico de red, normalmente entre 40 y 100 Mbit/s, dependiendo del dispositivo que reproduce el archivo y de la calidad del archivo original.

El mismo problema se manifestó al transmitir juegos con Steam Link a nuestro Apple TV. La conexión es por cable, pero no es raro que la red se caiga. Creo que está relacionado con el mismo problema, pero estaré pendiente para ver si vuelve a ocurrir después de la solución.

Posible solución

Parece que una posible solución es desactivar GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) y GRO (Generic Receive Offload) en la interfaz de red*:

ethtool -K eth0 gso off gro off tso off

Ya lo apliqué en mi configuración y estoy esperando para ver si de verdad resuelve el problema a largo plazo.

Notas al pie

* Estas opciones sirven para delegar la segmentación de paquetes al controlador de la interfaz de red y así reducir el uso de CPU de la máquina. Pueden encontrar más detalles en este artículo de Wikipedia.

Snippets: cómo ejecutar un registro de imágenes Docker local/privado en un swarm

Fri, 11 Oct 2019 00:00:00 GMT

Hoy intentaba generar una imagen de Docker a partir de un proyecto de Node.js y quería desplegarla en mi swarm local de pruebas.

Por desgracia, si se construye una imagen de Docker local, esta se almacena y es accesible solo en el nodo donde fue creada, y los demás nodos del swarm no pueden acceder a ella.

La forma de solucionarlo es subir la imagen a un registro de Docker (Docker registry) desde el cual todos los nodos del swarm puedan descargarla.

Creando el registro

Para instanciar un servicio de registro en el swarm, ejecuten:

docker service create —name registry —publish 5000:5000 registry:latest

Esto creará el servicio de registro y lo ejecutará en el swarm, haciéndolo accesible para todos los nodos del swarm.

Subiendo una imagen al registro

Para subir una imagen al registro hay que hacer dos cosas: etiquetar la imagen y luego subirla.

Aquí tienen un ejemplo de cómo construir y etiquetar la imagen de una sola vez:

docker build . -t localhost.localdomain:5000/:latest

Y así se sube al registro:

docker push localhost.localdomain:5000/:latestUsando la imagen en un servicio/contenedor/etc.

Para usar la imagen en un servicio o un contenedor, se especifica la ruta completa de arriba, es decir, localhost.localdomain:5000/<image-name>:latest.

Los nodos del swarm tendrán acceso a la imagen y podrán descargarla y ejecutarla.

Nota importante sobre la dirección del registro

En la mayoría de los tutoriales en línea, la URL del registro aparece como localhost:5000. Por desgracia, esto no funciona y normalmente se agota el tiempo de espera al intentar usarla. ¡Si la cambiamos por localhost.localdomain, funcionará!

No sé por qué ocurre esto, si tanto localhost como localhost.localdomain se resuelven a 127.0.0.1.

Snippets: Reasignar la tecla del signo de sección del teclado de Apple a la comilla invertida ( § a ` )

Wed, 31 Jul 2019 00:00:00 GMT

Llevo un tiempo usando teclados de Apple, pero cuando vives en Europa no es fácil conseguir los de distribución estadounidense a los que estoy acostumbrado.

En macOS hay una forma “fácil” de reasignar el teclado con un simple comando de terminal:

watch -n1 -x hidutil property -m ’{“ProductID”:592, “VendorID”:1452}’ —set ’{“UserKeyMapping”:[{“HIDKeyboardModifierMappingSrc”:0x700000035,“HIDKeyboardModifierMappingDst”:0x700000064}]}’

Lo que hace este fragmento de código es cambiar la asignación de la tecla de sección ( § ) para que escriba la tecla de comilla invertida/tilde ( `/ ~ ).

La parte watch -n1 -x lo repite cada segundo, porque a veces macOS pierde la configuración, normalmente cuando el equipo entra en suspensión o cuando el teclado se desconecta y se vuelve a conectar.

Ten en cuenta que en algunas versiones de macOS la utilidad watch no viene instalada y hay que obtenerla con algo como Homebrew o MacPorts.

El código anterior funciona con el teclado externo de Apple con USB y distribución europea con letras búlgaras. Puede que haga falta un pequeño ajuste en los valores hexadecimales de las teclas para otros tipos de teclados.

Una variación del comando funciona bien para el mismo tipo de teclado en la propia MacBook Pro. Solo tienes que intercambiar la posición de los valores 0x700000035 y 0x700000064.

He pensado en escribir una herramienta que haga esto automáticamente por mí, pero a estas alturas creo que vale más la pena invertir en un teclado nuevo con la distribución correcta 🙂

Cómo reiniciar el control remoto del Apple TV

Sun, 17 Feb 2019 00:00:00 GMT

Anoche, durante la visita de unos invitados, logré sumergir nuestro control remoto del Apple TV bajo el agua. La falta de sueño y los vasos inestables dan como resultado accidentes.

El control funcionaba bien anoche, pero hoy dejó de funcionar. No responde a ninguna acción. Intenté golpearlo contra mi mano y sacudirle el agua. No sirvió de nada.

Pensamos que ya estaba perdido y empezamos a buscar en las alacenas la bolsa de arroz.

Entré a internet, más que nada en broma, para ver si podía intentar “reiniciarlo”.

Una guía muy útil me indicó mantener presionados los botones de Subir volumen y Menú durante 2-3 segundos para restablecer el control y ponerlo en modo de emparejamiento.

¡Me sorprendí muchísimo cuando de verdad funcionó!

Así que, si algo parece sospechoso, intenten primero restablecer el control. Si no funciona, entonces pueden probar con el arroz y la intervención de hardware.

TL;DR;

Mantengan presionados Menú + Subir volumen durante 2-3 segundos
Esperen unos segundos
Intenten interactuar con el Apple TV

bisko.be - Dev

Cómo ejecutar Ollama con GPUs antiguas en CachyOS

TL;DR;

Hora de la historia

[Linux] Recuperar una sesión desconectada de `apt dist-upgrade`

[Linux] Syncthing – sistema de archivos de solo lectura al ejecutarlo como servicio

[Linux] Ejecutar varios comandos en varios servidores en paralelo

Iteración 1: un script de Python a medida

Iteración 2: pssh

La versión resumida es:

Adivinando la contraseña numérica de un archivo zip usando solo utilidades de línea de comandos

Cómo lidiar con el código espagueti en PHP: usar funciones anónimas para extraer fragmentos de código de plantillas

Arduino/ESP32: Cómo desactivar el watchdog de tareas

Configurar una YubiKey para firmar commits de Git

La locura de GPG

Generación de llaves en la YubiKey

Configuración de la tarjeta/dispositivo

Generación de llaves

Configurar Git para firmar

Depuración

Firmar con GPG

e1000e eth0: Detected Hardware Unit Hang

Snippets: cómo ejecutar un registro de imágenes Docker local/privado en un swarm

Snippets: Reasignar la tecla del signo de sección del teclado de Apple a la comilla invertida ( § a ` )

Cómo reiniciar el control remoto del Apple TV

Iteración 2: `pssh`