blog.fidelramos.net - Software

Aventuras en vibe coding: Venice.ai KDE widget

2026-06-25T00:00:00+00:00

El problema

Vengo usando Venice.ai (enlace con referencia si te interesa apuntarte) desde hace tiempo para todas mis necesidades de inteligencia artificial. Me encanta porque a diferencia de la mayoría de plataformas de IA, es privado:

Cuando usas modelos propios de Venice (modelos libres que ejecutan en sus propios servidores) no guardan registro de los prompts, o sea que es un uso privado. La mayoría de proveedores guarda registros de todo, y peor aún son los que te identifican de forma personal, digamos con tu cuenta de Google, entonces pueden asociar todas tus conversaciones para hacer perfiles con un nivel de detalle muy peligroso.
Al usar modelos externos (GPT, Claude, Gemini, etc.) Venice actúa como proxy anonimizador, o sea que el modelo final no sabe quién está realizando la petición. Obviamente reciben el prompt completo y lo registrarán, pero mientras no dés información personal en él pues no deberían poder identificarte.

Otra cosa que me gusta es que tienen un sistema de tokens con el que disfruto de cuenta Pro (con 100 VVV), y también tengo créditos a gastar cada día (1 DIEM da $1 en créditos cada día, para siempre).

El problema entonces era que a veces estaba programando en Opencode y de repente veía el mensaje de que me había quedado sin créditos. Quería un widget en mi escritorio (KDE) para saber de un vistazo cuánto me queda por gastar en el día. En otro tiempo habría sido un proyecto enterrado en el baúl de los recuerdos, pero tras descubrir whatcable-linux cobré conciencia de que crear estos widgets estaba al alcance de mi mano.

Venice.ai KDE widget sobre un sol retro

Ejecución

Empecé un proyecto nuevo con Deepseek V4 Pro en Opencode. Como ya comenté en el artículo anterior había salido hace poco y prometía resultados similares a Claude Opus a una fracción de precio, así que quería probarlo con proyectos reales.

Lo primero fue generar un AGENTS.md con el objetivo y estructura del proyecto. Después le pedí documentar la API de Venice que íbamos a usar. Hasta ahí todo bien.

Lo siguiente era generar un widget estático que mostrase la información que necesitaba, pero sin interactuar con ninguna API por el momento. Aquí Deepseek falló estrepitosamente: los ficheros QML (el lenguaje propio de la librería Qt que utiliza KDE) que generaba ni siquiera compilaban, el widget no llegaba a cargar. Tras varios intentos tuve que desistir y cambiar a Claude Opus 4.7.

Opus descubrió que el problema era que el widget estaba siendo cacheado por KDE, de forma que aunque instalase una versión nueva seguía cargándose el antiguo. Probablemente Deepseek había arreglado el problema pero yo seguía viendo la versión antigua cacheada.

Opus encontró la forma de reiniciar Plasma para que cargase la nueva versión del widget, y con eso ya compilaba y se visualizaba. A partir de ahí el proceso fue mucho más iterativo.

Siguiente paso: conectar con la API real. Para simplificar pedí que leyese el token de una variable de entorno, Opus lo consiguió a la primera. ¡Ya veía mis datos reales! Como proyecto personal podía haber parado aquí, ya era útil y cubría lo que necesitaba, pero quería pulirlo un poco y publirlo por si otros quisieran usarlo.

Lo siguiente fue almacenar el token de forma segura, que no estuviese en texto plano en ninguna parte. Le pedí a Opus que explorase opciones:

Decidí avanzar con secret-tool porque aunque KWallet sea el sistema nativo de KDE, hace tiempo que se integra con libsecret (y por tanto con secret-tool). Opus lo tuvo en un intento (más un bug al arrancar).

El resto fue iterar en la interfaz de usuario, ajustando colores y posiciones un poco, e introducir algunas opciones de configuración, nada importante que destacar.

Resultado

Tras un fin de semana entero jugueteando, el resultado fue venice-kde-widget.

Venice.ai KDE widget

Lo uso todos los días y ha estado funcionando a las mil maravillas. :)

Lecciones

El problema inicial de que el widget era cacheado por KDE Plasma me hizo darme cuenta de que muchos modelos necesitan instrucciones más específicas que otros, son menos creativos. Si les hubiese pedido que pensasen opciones alternativas a por qué seguía fallando quizá lo habrían encontrado, pero yo mismo no pensé en la posibilidad de que estuviese cacheado. Opus fue el único suficientemente proactivo como para pensar "vamos a confirmar si el código que se está realmente ejecutando es el que tenemos en el repositorio". Fue más listo que yo, en definitivas cuentas.

Esa proactividad es algo sobre lo que Simon Willison escribía al respecto de Fable 5. Esta experiencia es indicativa que es algo que aplica a otros modelos, o sea Claude Opus 4.7 fue más proactivo que Deepseek V4 Pro. Me entra curiosidad de pensar si la proactividad puede ser algo medible entre modelos, y si hay estudios al respecto.

Otra lección es que para un proyecto con una tecnología tan minoritaria (widgets de KDE en QML) la mayoría de modelos no van a dar grandes resultados, les debe faltar entrenamiento. Quizás los resultados habrían sido mejores si les hubiese indicado que mirasen el código de otros widgets para que les sirviese de referencia. Opus acabó haciendo eso para algunos problemas que no conseguía resolver: miró al resto de widgets instalados en el sistema para analizar su código. Probablemente habría sido una buena idea haber buscado widgets similares y haber pedido un análisis antes de implementar. O mejor aún afinar un modelo programador con muchos ejemplos de widgets KDE, pero eso obviamente sería exagerado para un proyecto como este.

Los resultados en este proyecto, más los de pelican-copy-code en el artículo anterior, me han llevado a reducir el uso de Deepseek V4 Pro; es más barato pero no me compensa si me lleva a callejones sin salida con código que no funciona y hay que arreglar.

Seguí usando Kimi 2.6 como modelo por defecto, sobre todo por ser privado en Venice.ai. Eso cambió con GLM 5.2, pero esa será otra historia.

Tailscale autoalojado, Parte 4: Servicios web sólo en Tailscale

2026-06-04T00:00:00+00:00

Desde hace años tengo un servidor casero con varios servicios autoalojados (Immich, Jellyfin, Nextcloud...) detrás de una única instancia de Caddy utilizando caddy-docker-proxy (documentado en esta entrada). Algunos de estos servicios tienen usos públicos útiles, como por ejemplo compartir una carpeta en Nextcloud o un álbum en Immich; o conectarse a Jellyfin a través de un dispositivo externo (como un Smart TV). No obstante, la mayoría de mis interacciones son a través de dispositivos personales, así que tenerlos expuestos a la Internet pública supone un riesgo de seguridad considerable, dado que son puntos de entrada a mis sistemas internos.

Ahora que tengo Tailscale funcionando, la solución es hacer que el mayor número posible de servicios sean accesibles únicamente a través de la tailnet. Para lograrlo, ejecutaré dos instancias de Caddy en paralelo: una vinculada a la interfaz pública, para los servicios accesibles por Internet; otra vinculada a la interfaz de Tailscale, para los servicios exclusivos de la tailnet.

La solución con caddy-docker-proxy no fue obvia, pero tras superar varios escollos conseguí que funcionara sin recurrir a ningún truco sucio. En esta entrada detallo la configuración y las lecciones aprendidas.

La arquitectura

Dos instancias independientes de Caddy en Docker, ambas utilizando caddy-docker-proxy:

caddy-public: vinculada a la IP del servidor en la LAN, accesible desde Internet por el reenvío de puertos del router en los puertos 80 y 443. Gestiona los servicios públicos.
caddy-tailscale: vinculado a la IP Tailscale del host (100.x.y.z), accesible únicamente desde dispositivos de mi tailnet. Se encarga de los servicios privados.

Cada Caddy supervisa las etiquetas de Docker con un prefijo diferente, por lo que los servicios se incorporan a uno u otro (o a ambos, en raras ocasiones) utilizando el prefijo de etiqueta adecuado y uniéndose a la red de Docker correspondiente.

Los servicios privados utilizan DNS-01 (mediante Gandi, mi proveedor de alojamiento DNS) para obtener los certificados, dado que no son accesibles por Internet. Los servicios públicos siguen utilizando certificados individuales normales a través de HTTP-01.

Aquí dejo un pequeño diagrama general:

Internet ──► router:443 ──► host:LAN_IP:443 ──► caddy-public    ──► headscale
Tailnet  ──► host:TAILSCALE_IP:443          ──► caddy-tailscale ──► immich, jellyfin, nextcloud, etc.

¿Por qué dos Caddys y no uno solo con una lista de direcciones IP permitidas?

Lo pensé. Un único Caddy con un filtro remote_ip que restringiera ciertos nombres de dominio a 100.64.0.0/10 también funcionaría. Pero:

El puerto 443 seguiría siendo accesible desde Internet para esos dominios. Tendría que confiar en el filtrado de capa 7 para mantener en raya a atacantes de servicios que no deberían estar expuestos a la WAN en absoluto.
Los servicios privados necesitan certificados DNS-01 (porque Let's Encrypt no puede acceder a una dirección 100.x para HTTP-01), mientras que los servicios públicos no.
Se te olvida incluir una etiqueta en Docker y de repente un servicio interno queda expuesto a la Internet pública.

Dos Caddys independientes me proporcionan aislamiento a nivel de red: los servicios privados, literalmente, no están a la escucha en un socket accesible desde la WAN. Esa es una garantía mucho más sólida que "recibiendo peticiones pero rechazándolas".

La configuración de Docker Compose

Esta es la estructura básica (con algunas variables de entorno para mayor claridad):

services:
  caddy-public:
    build:
      context: .
      dockerfile: Dockerfile.caddy
    image: caddy-docker-proxy-gandi:local
    container_name: caddy-public
    restart: unless-stopped
    environment:
      - CADDY_INGRESS_NETWORKS=caddy_public
    ports:
      - "${LAN_IP:?LAN_IP must be set}:80:80"
      - "${LAN_IP:?LAN_IP must be set}:443:443"
    labels:
      caddy.email: ${CADDY_EMAIL}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${CADDY_FILES_PATH}/public:/data
    networks:
      - caddy_public
    dns:
      - 1.1.1.1
      - 9.9.9.9

  caddy-tailscale:
    build:
      context: .
      dockerfile: Dockerfile.caddy
    image: caddy-docker-proxy-gandi:local
    container_name: caddy-tailscale
    restart: unless-stopped
    environment:
      - CADDY_INGRESS_NETWORKS=caddy_tailscale
      - CADDY_DOCKER_LABEL_PREFIX=caddy_ts
      - GANDI_BEARER_TOKEN=${GANDI_BEARER_TOKEN}
    ports:
      - "${TAILSCALE_IP:?TAILSCALE_IP must be set}:80:80"
      - "${TAILSCALE_IP:?TAILSCALE_IP must be set}:443:443"
    labels:
      caddy_ts.email: ${CADDY_EMAIL}
      caddy_ts.acme_dns: "gandi {env.GANDI_BEARER_TOKEN}"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${CADDY_FILES_PATH}/tailscale:/data
    networks:
      - caddy_tailscale
    dns:
      - 1.1.1.1
      - 9.9.9.9

networks:
  caddy_public:
    name: caddy_public
  caddy_tailscale:
    name: caddy_tailscale

Algunos puntos que vale la pena destacar:

Espacios de nombres independientes para las etiquetas. CADDY_DOCKER_LABEL_PREFIX=caddy_ts indica al Caddy de tailnet que lea las etiquetas que empiecen por caddy_ts. El Caddy público utiliza el valor predeterminado caddy. Los servicios se incorporan a uno u otro Caddy mediante el prefijo, sin posibilidad de contaminación cruzada.
CADDY_INGRESS_NETWORKS: Cada Caddy está configurado para detectar únicamente los contenedores conectados a su propia red. Sin esto, cada Caddy intentaría actuar como proxy de todos los contenedores etiquetados que pudiera ver a través del socket de Docker, y entrarían en conflicto.
Volúmenes /data separados. Cada Caddy tiene su propio almacenamiento de certificados. Podrían compartir un mismo volumen, pero separarlos es más limpio y elimina un caso extremo.
Escucha en IP específicas, no en 0.0.0.0. Esto me costó un buen rato depurando (lo explico más abajo).
Las guardas :? en las variables de entorno. Compose usa silenciosamente 0.0.0.0 si la parte de la IP del host de una especificación de puerto está vacía. La sintaxis :? hace que, en cambio, falle de forma evidente y se pueda corregir. Después de tropezar dos veces con la misma piedra, pienso usar estas guardas en cualquier servicio que necesite estar vinculado a una IP específica.

Imagen de Caddy con el complemento DNS de Gandi

Utilizo Gandi como proveedor de DNS y, por suerte, Caddy cuenta con un complemento para ello. Sin embargo, la imagen lucaslorentz/caddy-docker-proxy no lo incluye, por lo que hay que compilarlos; no es posible añadirlos en tiempo de ejecución. He creado una pequeña imagen personalizada mediante un archivo Dockerfile.caddy:

ARG CADDY_VERSION=2

FROM caddy:${CADDY_VERSION}-builder AS builder

RUN xcaddy build \
--with github.com/lucaslorentz/caddy-docker-proxy/v2 \
--with github.com/caddy-dns/gandi

FROM caddy:${CADDY_VERSION}-alpine

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

CMD ["caddy", "docker-proxy"]

Gracias a dockerfile: Dockerfile.caddy en compose.yml, con docker compose build caddy-tailscale se realiza la compilación de la imagen.

Este patrón es habitual y está documentado para crear imágenes personalizadas de Caddy.

Un detalle clave es el CMD final. caddy-docker-proxy se ejecuta en un modo diferente al del servidor Caddy normal, y hay que anularlo explícitamente.

En Gandi creé un token de acceso personal con permiso para "Gestionar configuraciones técnicas de dominios". Lo incluí en .env como GANDI_BEARER_TOKEN.

Traslado de servicios a Tailscale Caddy

Ahora que DNS-01 debería funcionar, es el momento de trasladar mis servicios web a Tailscale.

Los cambios son sencillos: basta con ponerlos en la red caddy_tailscale, cambiar las etiquetas caddy por caddy_ts y ajustar los nombres de dominio a ts.fidelramos.net.

Por ejemplo, mi servicio Immich (muestro solo las partes relevantes):

immich-server:
  labels:
    caddy_ts: immich.ts.fidelramos.net
    caddy_ts.reverse_proxy: "{{upstreams 2283}}"
  networks:
    - caddy_tailscale
    - immich

Qué maravilla, ¿no te parece?

Configuración del DNS

No hay registros DNS públicos. En su lugar, utilizo la opción customDNS de Blocky (véase la Parte 2) para crear registros DNS que solo serán visibles para mis dispositivos de la red tailnet.

En la configuración de Blocky:

customDNS:
  customTTL: 1h
  filterUnmappedTypes: true
  rewrite:
    ts.fidelramos.net: tail   # permite "X.ts.fidelramos.net" como alias de "X.tail"
  mapping:
    # Nombres descriptivos para los servicios en tailnet
    immich.tail: 100.64.0.1
    jellyfin.tail: 100.64.0.1
    nextcloud.tail: 100.64.0.1

Esto me obliga a gestionar manualmente las entradas y las direcciones IP, pero al tratarse de una modesta red doméstica, los servicios cambian con poca frecuencia y es una solución razonable.

Verificación

Tras ejecutar docker-compose up -d, compruebo los registros de los contenedores para asegurarme de que todo va bien. Las dos instancias de Caddy se inician correctamente. caddy-tailscale emite nuevos certificados mediante el desafío DNS-01.

En el servidor compruebo que cada instancia de Caddy escucha en su IP asignada:

$ ss -tlnp | grep -E “:80|:443”
LISTEN 0 4096 192.168.1.50:80   0.0.0.0:*
LISTEN 0 4096 192.168.1.50:443  0.0.0.0:*
LISTEN 0 4096 100.64.0.1:80     0.0.0.0:*
LISTEN 0 4096 100.64.0.1:443    0.0.0.0:*

El router solo reenvía a la IP de la LAN, por lo que el Caddy de la tailnet es invisible para Internet.

Se puede acceder a los servicios públicos en https://<service>.fidelramos.net desde cualquier lugar. Solo se puede acceder a los servicios privados en https://<service>.ts.fidelramos.net desde dispositivos de mi tailnet.

Los problemas con los que me topé para que tú no tengas que hacerlo

Esta es la parte que me hubiera gustado que alguien me hubiera explicado, ya que me llevó bastante tiempo resolverla.

Compose recurre automáticamente a `0.0.0.0`

Si escribes ${TAILSCALE_IP}:80:80 y TAILSCALE_IP está vacío, Docker vincula 0.0.0.0:80. Entonces, ambos Caddys compiten por el mismo puerto y uno falla al iniciarse con el mensaje "el puerto ya está asignado".

Utilicé ${TAILSCALE_IP:?...} para que fallara de forma evidente si la variable de entorno no está definida.

Resolver esto fue bastante rápido, pero luego me topé con el siguiente problema...

Los contenedores fallidos dejan zombis

Cuando un contenedor no consigue vincular sus puertos, Docker lo deja en un extraño estado intermedio: NetworkMode está configurado correctamente, pero el contenedor en realidad no está conectado a ninguna red. docker inspect muestra "Networks": {}, y ip addr dentro del contenedor solo muestra lo. Un docker compose up -d posterior detecta que el contenedor "existe" y simplemente lo inicia sin arreglar nada. El resultado es un contenedor en ejecución que no tiene conectividad alguna.

La solución fue empezar de cero, con docker compose down, y luego docker compose up -d.

La conexión de `0.0.0.0:80` entra en conflicto con `100.x.y.z:80`

Aunque ambas IP sean "válidas", Docker trata 0.0.0.0 como un superconjunto. Tenía caddy-public vinculado a 0.0.0.0:80 y caddy-tailscale vinculado a 100.64.0.1:80, y se producían fallos intermitentes en el inicio dependiendo del orden.

La solución es fijar ambos a direcciones IP específicas (la IP de LAN para el público y la IP de Tailscale para tailnet).

Sin solapamientos, sin conflictos.

`caddy-docker-proxy` necesita la red del servicio

Tanto el filtro CADDY_INGRESS_NETWORKS de Caddy como el enrutamiento propiamente dicho requieren que el servicio al que se aplica el proxy se encuentre en la misma red de Docker que Caddy. Un servicio puede estar en redes adicionales (para su propia base de datos, etc.), pero necesita al menos la red de entrada de Caddy, o será invisible.

¿Lo volvería a hacer?

Sí. La configuración inicial fue sorprendentemente complicada porque se acumularon múltiples fallos, pero la arquitectura resultante es limpia y fácil de ampliar.

Cada nuevo servicio que añado pasa por la misma decisión sencillísima:

Público: etiquetas caddy.*, red caddy_public, registro DNS en Gandi.
Privado: etiquetas caddy_ts.*, red caddy_tailscale, registro DNS en Blocky.

No hay reglas de cortafuegos que mantener sincronizadas, ni middleware de autenticación por servicio, sin ese "solo lo expondré temporalmente" que acaba convirtiéndose en permanente.

La breve lección que se desprende de todo este ejercicio: Tailscale es excelente para hacer que los servicios "solo para mí" sean accesibles desde mis dispositivos, pero integrarlo con un proxy inverso basado en Docker presenta más dificultades que cualquiera de las dos tecnologías por separado. Vincular los listeners a direcciones IP específicas, generar un error claro cuando faltan variables de entorno y asignar a los contenedores resolutores DNS explícitos son los tres hábitos que me habrían ahorrado la mayor parte de los problemas.

Mejoras futuras: acceso limitado para otras personas

Con esta configuración, he perdido la posibilidad de compartir un álbum de Immich con mi familia o amigos, o de compartir una carpeta de Nextcloud enviando un enlace. Se trata de casos de uso realmente útiles que me gustaría recuperar de alguna manera.

En cuanto a mi familia, estudiaré la posibilidad de darles acceso a mi tailnet utilizando listas de control de acceso (ACL) para restringir el acceso de sus dispositivos únicamente a los servicios que necesiten.

Para compartir archivos, estoy investigando opciones como Filestash o FileBrowser Quantum, que son servicios diseñados específicamente para este caso de uso concreto. Lo que quiero es que la interfaz de usuario de administración completa solo sea accesible a través de la red de acceso restringido, y que sus puntos finales de uso compartido público sean enrutables por Internet.

Sea cual sea la solución a la que llegue, probablemente escribiré entradas de blog al respecto.

Aventuras en vibe coding: pelican-copy-code

2026-05-26T00:00:00+00:00

El problema

Me di cuenta que este blog usa muchísimos bloques de código, pero no es fácil copiarlos porque falta un botón de Copiar en cada bloque.

Busqué un plugin para Pelican que lo hiciese, convencido de que habría alguno ya hecho, ¡pero me sorprendí al no encontrar nada!

Me pareció un proyecto ideal para resolver rápidamente con IA. Podía solventar mi problema y crear un proyecto útil para la comunidad.

Ejecución

Mi objetivo era crear un nuevo proyecto publicable a PyPI, con estos requisitos:

Compatible con Pelican estable.
Instalable con pip y con autodescubrimiento. O sea debe ser un plugin Pelican de nueva generación, no necesita añadirse en la configuración de Pelican (pelicanconf.py), se instala con pip y a correr.
Ficheros estáticos de Javascript y CSS, sin npm ni similar.
Sin dependencias externas de Javascript ni CSS, sólo APIs estándar.
No debe necesitar cambios en las plantillas. Una vez activado el plugin inserta el botón automáticamente en todos los bloques.
Sin manipulación del DOM, el botón se inserta al generar el sitio Pelican.
Configurable.

Usé OpenCode (aislado, lo describo en este otro artículo), inicialmente con Kimi 2.6, después con Deepseek V4 Pro, y más adelante con Claude Opus 4.7. Comentaré los detalles en la sección de Lecciones.

El desarrollo fue a ratos en una tarde. Mientras hacía otras cosas iba al ordenador, le pedía el siguiente cambio en el modo de planificación, luego volvía, revisaba rápidamente y le daba el visto bueno para implementar.

Los cambios los iba probando en local en este blog. Simplemente instalé el plugin con uv en modo editable: uv add --editable ~/Code/pelican-copy-code

Es un proyecto muy pequeño así que no me molesté en generar ni mantener tests, linting, ni acciones de Github.

Resultados

El plugin es pelican-copy-code, publicado en Github y PyPI.

Es instalable directamente como se pretendía, está a un pip install pelican-copy-code de distancia.

Mejor que una captura de pantalla dejo este bloque de código con el que experimentarlo en vivo, sólo pasa el cursor por encima y haz click en "Copiar":

def swallow_airspeed(laden=False):
   return 24 if not laden else RuntimeError("African or European?")

class BlackKnight:
   def __init__(self):
       self.flesh_wounds = ["'Tis but a scratch!"]
   def is_defeated(self):
       return len(self.flesh_wounds) >= 4

print(swallow_airspeed(laden="coconut"))

Lecciones

Inicialmente usé Kimi 2.6 porque es mi modelo por defecto en Venice.ai. Es barato, rápido y privado (Venice.ai no guarda registros de las conversaciones en sus propios modelos).

Probé a cambiar a Deepseek V4 Pro porque era novedoso y decían que algo mejor para programar, comparable a Claude Opus 4.5. No noté demasiado cambio, para un proyecto tan pequeño probablemente cualquiera de los dos habría dado buenos resultados.

Sí es verdad que Kimi 2.6 cometió algunos errores en su implementación inicial, como por ejemplo algunos de los ajustes de configuración que le pedí incluir no tenían efecto, o sea el código no los usaba nunca. Fue algo fácil de corregir en sesiones separadas, pero me hizo abrir los ojos sobre lo importante que es la fase de pruebas.

También acabé haciendo algunas refactorizaciones a mano que probablemente me podría haber evitado si hubiese sido más específico en las instrucciones en AGENTS.md. Por ejemplo mantener las variables de configuración en orden alfabético, debería haber sido un requisito de estilo en AGENTS.md. También el agente puso algunas variables de configuración fuera del diccionario. Un error de estilo que un humano probablemente no habría cometido.

Cuando llegó la hora de probar el plugin por primera vez resultó que no funcionaba, daba un error por mal uso de las señales y los generadores. Se lo puse a Deepseek V4 Pro pero no lo consiguó arreglar. Ahí fue cuando cambié a Claude Opus 4.7, que al primer intento encontró el problema y lo arregló correctamente. Cobró sentido los consejos que había leído por ahí de usar a Opus como planificador y a otro modelo más barato para ejecutar los cambios. Se nota que es el modelo más avanzado, pero también mucho más caro que Kimi o Deepseek.

Cuando implementé el soporte de traducciones lo hice con Deepseek V4 Pro, y funcionó bien. Sin embargo duplicó código (las cadenas "Copy" y "Copied!" estaban duplicadas en dos ficheros distintos). Le pedí refactorizar para eliminar la duplicación, pero la propuesta no era nada buena, eliminaba la duplicación pero añadía más código con mal estilo. Una vez más cambié a Opus 4.7 que planteó una solución mucho mejor que realmente simplificaba el código.

Aventuras en vibe coding

2026-05-24T00:00:00+00:00

Voy a empezar una nueva serie de artículos sobre cómo estoy utilizando la IA para programar software o resolver problemas técnicos.

Los artículos tendrán esta estructura:

Problema
Ejecución
Resultado
Lecciones y descubrimientos

En este artículo no quiero entrar en consideraciones éticas, medioambientales o político-económicas de las IA, pero sí en mi experiencia como desarrollador. Las opiniones y estudios sobre el impacto de las IA en la productividad de los desarrolladores de software son dispares. Algunos dicen que puede multiplicar la productividad, otros que aunque dé la sensación de mejorar, en realidad disminuye. Tras estos meses de experiencia personal me inclino a pensar que son especialmente efectivas para quienes tienen profundos conocimientos técnicos.

Tuve mi primer ordenador a los 5 años (¡casi 40 años ya!), con el que empecé a aprender informática y a programar. Uso GNU/Linux desde 1998. Completé mi educación superior en Ingeniería Informática. He trabajado 15 años como ingeniero de software. Y con las IA me siento 10 veces más productivo.

Ojo que digo "me siento", porque no tengo métricas objetivas para decir cuánto más productivo realmente soy. Los estudios apuntan a que la mejora es de alrededor del 20%, pero las estadísticas suelen calcularse sobre proyectos grandes, que no es mi caso. Trabajando en proyectos nuevos o pequeños creo que las IAs son muy eficientes. En mi caso es indudable que estos proyectos no serían una realidad si no tuviese la ayuda de las IA.

Mi principal problema en los últimos años ha sido el tiempo.
Tiempo para aprender algo nuevo.
Tiempo para dedicarle horas a una única tarea.
Hay demasiadas cosas que hacer y estoy demasiado ocupado con la vida para hacerlo todo. Creo que esta es una experiencia común especialmente entre padres.

Por eso mis ideas se quedaban años como TODO en mis notas. Ahora estoy entrando en una rutina en la que echo un vistazo a esa lista, elijo una y la ejecuto satisfactoriamente en minutos u horas, a ratos sueltos durante un fin de semana. Esto es lo que pienso documentar en esta serie de artículos.

Dicho todo esto, no quiero ignorar las voces que avisan de los efectos negativos del uso (o abuso) de las IA. Personalmente espero que no me afecte negativamente, porque hago un uso relativamente reducido, pero procuraré ser introspectivo sobre mi estado mental.

También leo a muchos programadores que odian la IA, hasta el punto de abandonar sus carreras, porque lo que disfrutan es el escribir el código ellos mismos. Siento su dolor cuando tienen trabajos en los que les obligan a usar IA y están presionados a producir más y más rápido. Su día a día ha cambiado rápidamente y cuando antes pasaban la mayor parte del tiempo escribiendo código, ahora eso se ha invertido y tienen que dedicarse a generar, revisar, corregir y ajustar, lo cuál es mucho menos divertido y mentalmente estresante y agotador.

En mi caso escribir el código es secundario, me importa más el resultado final que el proceso. Por eso estoy feliz de tomar los atajos que me brinda la IA, mientras pueda mantener el control y tener un resultado más rápido con la calidad que busco.

Tailscale autoalojado, Parte 3: Syncthing sobre Tailscale

2026-05-18T00:00:00+00:00

Llevo años usando Syncthing para sincronizar archivos entre mi portátil, ordenador de sobremesa, teléfono, tablet y servidor. Es un programa fabuloso y ha sido muy fiable, con solo algún conflicto ocasional, pero nunca he perdido ningún dato. Al contrario, el control de versiones de Syncthing me ha salvado el pellejo más de una vez.

Syncthing tiene sus propias soluciones para descubrimiento y NAT traversal, para que los dispositivos que están detrás de un cortafuegos puedan verse entre sí y seguir conectándose. Sin embargo, eso depende de servidores externos para gestionar las conexiones, y podrían guardar metadatos. Incluso si no lo hacen, pueden degradar el rendimiento.

Ahora que tengo una tailnet interconectando todos mis dispositivos, no hay razón para seguir lidiando con nada de eso. Cada dispositivo ya tiene una dirección estable accesible desde cualquier otro dispositivo. Syncthing puede simplemente usarla, solo necesita algo de configuración.

Este artículo explica la reconfiguración de Syncthing para que use la tailnet en exclusiva, desactivando toda la maquinaria que ya no necesita.

Índice de contenidos

Objetivos
Por qué hacer esto
Reconfiguración de Syncthing
Verificación
Dificultades encontradas
Siguientes pasos

Objetivos

Los pares de Syncthing se comunican entre sí exclusivamente a través de la tailnet.
No depender de los servidores de descubrimiento global de Syncthing.
No depender de la red de retransmisión de Syncthing.
No hay necesidad de NAT traversal, lo gestiona Tailscale.
No hay puertos abiertos en el router, no hay necesidad de UPnP.
Todo sigue funcionando igual cuando estoy fuera de casa.

Por qué hacer esto

Hay varias pequeñas victorias que van sumando:

Privacidad. El descubrimiento global de Syncthing se comunica con un servidor central para anunciar (ID de dispositivo → IP pública). Con la tailnet, esa difusión es inútil y se puede desactivar.
Fiabilidad. Los relés son lentos y ocasionalmente inestables. Las conexiones directas a la tailnet son rápidas y consistentes, y el DERP de Tailscale ya proporciona un respaldo en la capa de red si no se puede establecer una ruta directa.
Simplicidad. La dirección de cada par se convierte en una IP de tailnet fija (o nombre MagicDNS). Dejo de ver problemas de conexión entre dispositivos.
Seguridad. Syncthing escucha en TCP/UDP 22000 y UDP 21027 por defecto. Si esos puertos están expuestos en la WAN, son un servicio expuesto a Internet. Desactivar todo excepto la ruta de la tailnet cierra esa puerta, reduciendo la superficie de ataque.

Reconfiguración de Syncthing

Syncthing viene con un montón de características para que funcione a través de Internet sin configuración:

Configuración	Predeterminado	Propósito	En tailnet
Sync Protocol Listen Addresses	`default`	Dónde aceptar conexiones entrantes	La IP tailnet del dispositivo
Permitir NAT traversal	Habilitado	UPnP / NAT-PMP to open ports in router	Deshabilitado
Descubrimiento global	Habilitado	Announce device ID → IP on public discovery servers	Deshabilitado
Descubrimiento local	Habilitado	LAN multicast to find peers	Deshabilitado
Habilitar retransmisión	Habilitado	Fallback traffic via public relay servers	Deshabilitado

El descubrimiento global y local, el NAT traversal y la retransmisión son innecesarios entre pares que están ya conectados por Tailscale.

Cambié la configuración en cada ordenador a través de la interfaz web de Syncthing (Acciones → Configuración → Conexiones):

Configuración web de Syncthing

Y en los dispositivos Android en la configuración de la aplicación Syncthing (dentro de Opciones de Syncthing):

Configuración de Syncthing en Android

Es posible que necesites reiniciar Syncthing después de guardar.

Acerca de las direcciones de escucha

Lamentablemente, Syncthing no admite vincularse a una interfaz específica, es decir, esto no funcionará:

tcp://%tailscale0:22000, quic://%tailscale0:22000

Hay que vincular a la IP de la tailnet:

tcp://100.64.0.1:22000, quic://100.64.0.1:22000

Si el dispositivo se vuelve a registrar en la tailnet y cambia su IP se romperá esta configuración, pero eso será lo suficientemente raro en mi caso como para que sea un compromiso razonable.

Una alternativa menos segura sería dejar esta configuración como default, lo que se vinculará a todas las interfaces, y luego confiar en el cortafuegos del dispositivo para bloquear las conexiones que no sean a través de la tailnet.

Configurar pares por dirección de tailnet

Con el descubrimiento global desactivado, los pares ya no pueden encontrarse automáticamente. La solución es actualizar la configuración de cada dispositivo para que apunte explícitamente a la dirección de tailnet del par:

Dispositivo → Editar → Direcciones:

tcp://homeserver.ts.fidelramos.net:22000

Los nombres de host de MagicDNS funcionan bien aquí porque Syncthing resuelve la dirección en cada intento de conexión, no solo al inicio (a diferencia de las direcciones de escucha). Si MagicDNS es inestable en un cliente en particular, se puede usar su IP de tailnet (p.ej. tcp://100.64.0.1:22000).

Hago este cambio entre cada par de dispositivos, en ambas direcciones.

Cortafuegos

Dado que Syncthing solo debe ser accesible a través de la tailnet, elimino las reglas existentes que permitían las conexiones de Syncthing en mi red pública.

En mi caso, uso firewalld, eliminé las reglas de las zonas public y home y dejé que trusted (que está asociada a la interfaz tailscale0) aceptara todo automáticamente:

# Cerrar los puertos de Syncthing previamente permitidos
$ sudo firewall-cmd --permanent --zone=public --remove-port=22000/tcp
$ sudo firewall-cmd --permanent --zone=public --remove-port=22000/udp
$ sudo firewall-cmd --permanent --zone=public --remove-port=21027/udp
$ sudo firewall-cmd --permanent --zone=home --remove-port=22000/tcp
$ sudo firewall-cmd --permanent --zone=home --remove-port=22000/udp
$ sudo firewall-cmd --permanent --zone=home --remove-port=21027/udp
$ sudo firewall-cmd --reload

Para comprobar:

sudo firewall-cmd --zone=public --list-all sudo firewall-cmd --zone=home --list-all

Ninguna zona debería listar el puerto 22000 en ningún lugar.

La zona trusted no necesita nada listado porque es permisiva por defecto.

Para las implementaciones de Syncthing basadas en Docker, vale la pena mencionar que una configuración como ports: ["22000:22000"] se salta firewalld. O bien se vincula a la IP de la tailnet (ports: ["100.64.0.1:22000:22000/tcp"]) o se utiliza la red del host. En este caso las instalaciones nativas son más sencillas.

Router

Solía tener el puerto TCP/UDP 22000 reenviado de mi router a mi servidor doméstico, y otros puertos para otros dispositivos en mi red doméstica. Ya no hace falta:

Elimino el puerto 22000 (TCP y UDP) de las reglas de reenvío de puertos del router.
Elimino reglas de cortafuegos en el router.

Menos puertos expuestos a Internet es bien.

Verificación

La interfaz web de Syncthing es mi primera comprobación. En cada dispositivo:

El par se muestra como Conectado.
El detalle de la conexión muestra algo como tcp://100.64.0.2:22000, es decir, una dirección de tailnet, no una pública.
Sin indicador de "relé".

Desde la línea de comandos en el servidor doméstico:

$ ss -tulpn | grep -E '22000|21027'
udp   UNCONN 0      0               100.64.0.4:22000      0.0.0.0:*    users:(("syncthing",pid=1526,fd=113))
tcp   LISTEN 0      4096            100.64.0.4:22000      0.0.0.0:*    users:(("syncthing",pid=1526,fd=110))

Syncthing sigue escuchando en el puerto 22000, pero en la IP de la tailnet.

Así está bien, firewalld asegura que solo la tailnet pueda alcanzarlo.

# La conexión a la IP pública falla
$ nc -zv 83.241.182.82 22000
nc: connect to 83.241.182.82 port 22000 (tcp) failed: Connection refused

# La conexión a la IP de la LAN falla
$ nc -zv 192.168.1.10 22000
nc: connect to 83.241.182.82 port 22000 (tcp) failed: Connection refused

# La conexión a la IP de la tailnet funciona
$ nc -zv 100.64.0.1 22000
Connection to 100.64.0.1 22000 port [tcp/snapenetio] succeeded!

Con Tailscale de nuevo activado, la misma comprobación a través de la dirección de tailnet debería tener éxito.

Dificultades encontradas

Sintaxis de la dirección de escucha `%tailscale0`

Como mencionaba anteriormente, no intentes vincular Syncthing a un nombre de interfaz. Usa la IP de la tailnet del dispositivo, o déjalo como default (pero configura bien el cortafuegos).

Los pares no se encuentran después de deshabilitar el descubrimiento

Obvio en retrospectiva, pero me pilló una vez: si la dirección de un par todavía está configurada como dynamic con todo el descubrimiento desactivado, no tiene forma de encontrar a nadie. Establece direcciones explícitas para cada par.

MagicDNS falla al inicio en un cliente lento

Si Syncthing intenta alcanzar, por ejemplo, homeserver.ts.fidelramos.net antes de que Tailscale esté activo en un dispositivo (por ejemplo, en un teléfono que se reinició), la conexión falla con un error de DNS. Lo intenta de nuevo unos segundos más tarde y tiene éxito. No hay nada que arreglar, es solo ruido en los registros.

Usar direcciones IP en lugar de nombres MagicDNS evita el reintento pero pierde la legibilidad y la resiliencia si un dispositivo se vuelve a registrar en Headscale.

Syncthing usando contenedores

Si ejecutas Syncthing en Docker, la sección ports: de tu archivo compose no debe exponer el puerto 22000 a la WAN. Mi recomendación: ejecútalo en el host en su lugar, o usa network_mode: host, o vincúlalo explícitamente a la IP de la tailnet. La publicación de puertos de Docker por defecto es 0.0.0.0 y omite firewalld.

Caché de anuncios de descubrimiento

Después de desactivar el descubrimiento global, otros usuarios de Syncthing que habían descubierto previamente mi dispositivo a través del servidor de descubrimiento público seguirían teniendo la IP pública obsoleta en caché durante un tiempo. Esto no es una fuga, es solo que intentarían conectarse a la IP antigua y fallarían. Puramente cosmético, y desaparece por sí solo en uno o dos días. No hay nada que hacer a menos que estés compartiendo carpetas con personas fuera de tu tailnet (y en ese caso, no deberías haber desactivado el descubrimiento global en primer lugar).

Siguientes pasos

Syncthing ahora se ejecuta completamente dentro de la tailnet, sin exposición a la WAN y sin depender de la infraestructura pública de Syncthing. He notado que los dispositivos se conectan más rápido, pero no he realizado ninguna prueba de rendimiento en las velocidades de transferencia.

En la Parte 4 haré lo mismo con mis servicios web: moveré la mayoría de mis aplicaciones de un dominio público <app>.fidelramos.net a <app>.ts.fidelramos.net solo para tailnet, utilizando una solución con doble caddy-docker-proxy de forma que sigan funcionando sus certificados automáticos.

Cómo aislo mis agentes IA

2026-05-14T00:00:00+00:00

He estado usando Opencode como mi agente de programación por IA. No tengo una larga lista de razones por las que lo elegí entre las muchas alternativas existentes, algo impropio de mí. Solo quería empezar con un sistema de agentes que cumpliera mis requisitos principales:

Debe ser completamente de código abierto.
Popular, lo que significa que probablemente durará. No quiero perder el tiempo aprendiendo a usar un programa solo para que desaparezca en unos meses.
Extensible y configurable.
Que soporte muchos proveedores de IA, incluida mi elección actual, Venice.ai (¡aquí hay un enlace con referencia para los interesados!)

Una de las cosas que no me gusta de Opencode es que no usa sandboxing, y eso no es un descuido sino una decisión consciente de diseño. Sí, Opencode pregunta antes de que un agente intente acceder a un archivo fuera del proyecto, pero el software de Opencode en sí no está restringido y tiene acceso al sistema completo.

Mi solución es simple: envuelvo Opencode con Firejail, que ya estoy usando para la mayoría de los otros programas en mis ordenadores. De esta manera, restrinjo Opencode para que no tenga acceso a lo que no debe (¡como mis claves SSH!) a nivel del kernel.

Opencode aislado no tiene acecso a mis claves SSH

Configuración de Firejail

Firejail ya integró un perfil de Opencode pero no está en una versión estable en el momento de escribir estas palabras. Por ahora, uso mi propio perfil de firejail en ~/.config/firejail/opencode.profile:

# Firejail profile for opencode
# Description: An open source AI coding agent.
# This file is overwritten after every install/update
quiet
# Persistent local customizations
include opencode.local
# Persistent global definitions
include globals.local

# allow executables in HOME, see disable-exec.inc
ignore noexec ${HOME}

# blacklisted by disable-programs.inc
noblacklist ${HOME}/.cache/opencode
noblacklist ${HOME}/.config/opencode
noblacklist ${HOME}/.local/share/opencode

# Allows files commonly used by IDEs
include allow-common-devel.inc

# Disable Wayland
blacklist ${RUNUSER}/wayland-*
# Disable RUNUSER (cli only; supersedes Disable Wayland)
blacklist ${RUNUSER}
# Remove the next blacklist if your system has no /usr/libexec dir,
# otherwise try to add it.
blacklist /usr/libexec

# disable-*.inc includes
include disable-proc.inc
include disable-write-mnt.inc
include disable-x11.inc
include disable-xdg.inc

mkdir ${HOME}/.cache/opencode
whitelist ${HOME}/.cache/opencode
mkdir ${HOME}/.config/opencode
whitelist ${HOME}/.config/opencode
mkdir ${HOME}/.local/share/opencode
whitelist ${HOME}/.local/share/opencode

# Commands that reduce access to resources.
caps.drop all
##caps.keep CAPS
##hostname NAME
# CLI only
ipc-namespace
machine-id
no3d
nodvd
nogroups
noinput
nonewprivs
noprinters
noroot
nosound
notv
nou2f
novideo
protocol unix,inet,inet6
seccomp
#tracelog

disable-mnt
private-cache
private-dev
private-etc alternatives,ca-certificates,crypto-policies,dconf,fonts,ld.so.cache,ld.so.preload,machine-id,pki,resolv.conf,ssl
private-tmp

dbus-user none
dbus-system none

env NO_BROWSER=true
restrict-namespaces

Este perfil utiliza un modelo de lista blanca (whitelist), por lo que Opencode solo tendrá acceso a esos directorios específicos y ni siquiera verá el resto. Eso significa que al invocar Opencode necesito incluir en la lista blanca el directorio del proyecto en el que quiero que trabaje. Lo hago así:

~/Code/someproject$ firejail --profile=opencode --whitelist=(pwd) /usr/bin/opencode

Como escribir todo eso se volvería rápidamente aburrido, tengo opencode configurado como un abbr, por lo que se expandirá automáticamente a lo anterior.

Un abbr es una construcción de fish shell que funciona como un alias, pero es editable al expandirse. Esto es muy útil en caso de que quiera editar el comando, como en este caso podría necesitar incluir en la lista blanca alguna ruta adicional.

Resultados y próximos pasos

He estado usando esta configuración durante un mes y ha sido sólida una vez que ajusté la configuración del perfil de Firejail. Ahora puedo usar agentes con la seguridad de que no exfiltrarán datos privados, o que un error en Opencode podría afectar a mis archivos o mi sistema.

A continuación, quiero extender esta configuración para poder usar Opencode con un modelo LLM local a través de llama.cpp, pero sin acceso a Internet. Quiero que esto funcione en proyectos altamente personales donde no confiaría ni siquiera en los modelos privados de Venice.ai, como la configuración de mi homelab.

También he desarrollado mis propios agentes de investigación en Opencode, para gestionar proyectos de investigación de larga duración como un conjunto de archivos Markdown que sirven como memoria. Utiliza una extensión del perfil de Firejail, además de configuración adicional de Opencode y prompts para el agente investigador y los subagentes buscadores. Sigo refinándolo, pero ya está demostrando ser útil, así que probablemente terminaré escribiendo una publicación al respecto.

Tailscale autoalojado, Parte 2: DNS con bloqueo de publicidad

2026-05-11T00:00:00+00:00

En la Parte 1 configuré Headscale e hice que todos los clientes de tailnet usaran Cloudflare DNS. Funcionó, pero podía ser mejor: cada dispositivo que se conecta a mi tailnet obtiene los servidores DNS que yo configure, así que bien podría ejecutar mi propio servidor DNS dentro de la red privada y conseguir bloqueo de anuncios, bloqueo de rastreadores y resolución de nombres interna esté donde esté, de forma transparente y cifrada.

En este artículo cambiaré Cloudflare por Blocky, un proxy DNS ligero con soporte incorporado para listas de bloqueo.

Elegí Blocky en lugar de Pi-hole o AdGuard Home porque es más simple, se configura en un único archivo YAML. No intenta ser un producto web completo, solo un servidor DNS que hace su trabajo y no molesta.

Podrías reemplazar fácilmente Blocky con algún otro servidor o proxy DNS de tu elección manteniendo las partes de Headscale y Tailscale.

Índice de contenidos

Objetivos
¿Por qué no usar solo el DNS privado de Android?
Arquitectura
Blocky en Docker Compose
Configuración de Blocky
Verificación desde el host:
Cambios en Headscale
Por qué es mejor que DoT en cada dispositivo
Inconvenientes encontrados
Qué sigue

Objetivos

Bloquear anuncios y rastreadores a nivel de DNS en cada dispositivo con Tailscale.
Usar DNS cifrado hacia los DNS globales (DoT ascendente), aunque el tráfico entre mis dispositivos y Blocky ya esté protegido por WireGuard. Eso evitará el espionaje de mi ISP.
Tener resolución de nombres interna, que, por ejemplo, homeserver.ts.fidelramos.net siga funcionando.
Sin configuración de DNS a nivel de dispositivo. Headscale envía la configuración y los clientes la usan automáticamente.

¿Por qué no usar solo el DNS privado de Android?

Android tiene una función incorporada de "DNS privado" que hace DoT a cualquier servicio de resolución público. Anteriormente estaba usando un servidor DNS privado de AdGuard (xxxxxxxx.d.adguard-dns.com). Intenté usarlo junto con Tailscale, pero no funciona: tan pronto como Tailscale envía cualquier configuración de DNS al cliente, Android enruta el DNS a través del túnel a través del resolvedor interno de Tailscale (100.100.100.100), que no habla DoT. La sonda de DNS privado de Android falla con "no se puede conectar" y la resolución de DNS se rompe en todo el dispositivo.

Puedes deshabilitar "Usar DNS de Tailscale" en la aplicación para recuperar el DNS privado, pero entonces pierdes MagicDNS.

Forzado a elegir, fui por el otro camino: ejecutar mi propio DNS en la tailnet y hacer que Headscale lo envíe a todos los clientes.

Arquitectura

  Dispositivo en la tailnet
        │
        │ DNS sin cifrar (dentro de túnel WireGuard)
        ▼
  Blocky  ──▶  listas de bloqueo (local)
        │
        │ DNS-over-TLS (DoT) a DNS global
        ▼
  Cloudflare / Quad9 / Google DNS / etc.

Los clientes se comunican por DNS sin cifrar con la IP de tailnet de Blocky. No hace falta cifrado porque la ruta completa va por un túnel WireGuard.
Blocky realiza el filtrado contra las listas de bloqueo que mantiene localmente.
Todo lo que no está bloqueado se resuelve por servicios DNS globales que Blocky contacta a través de DoT.
Blocky asociará algunos dominios locales de la tailnet a IPs internas.

Blocky en Docker Compose

Ejecuto Blocky en el mismo proyecto Docker Compose donde están todos los otros servicios de mi servidor doméstico.

compose.yml:

services:
  blocky:
    image: spx01/blocky:latest
    container_name: blocky
    network_mode: host
    restart: unless-stopped
    volumes:
      - ${BLOCKY_ROOT}/config.yml:/app/config.yml:ro
      - /var/log/blocky:/logs:rw
    environment:
      - TZ=${TZ}
    healthcheck:
      test: ["CMD", "/app/blocky", "healthcheck"]
      interval: 1m
      timeout: 10s
      retries: 3

Puntos a destacar:

network_mode: host. Esto es un poco perezoso por mi parte, pero abrir el puerto Docker solo a la IP de tailnet es más complicado de lo que parece. Blocky se configurará en la siguiente sección para que solo escuche en la interfaz de Tailscale, por lo que no creo que sea un gran riesgo de seguridad. Confío en que Blocky no vaya a escuchar en otras interfaces o puertos del sistema.
El archivo de configuración es de solo lectura dentro del contenedor. Es más seguro y me recuerda que el origen es mi configuración versionada en disco, y no lo que está en el contenedor.
Tuve que hacer chown 100 /var/log/blocky, ya que ese es el UID que usa el contenedor de blocky. Antes de hacerlo los registros de Docker de Blocky mostraban errores de permiso de escritura.

Configuración de Blocky

Esta es mi configuración con los nombres internos redactados. Consulta la documentación de Blocky para todos los detalles.

/var/opt/blocky/config/config.yml

# =================================================================
# Blocky config — Tailscale/headscale global resolver
# =================================================================

# ---------------------------------------------------------------
# Upstream resolvers (encrypted via DoT)
# ---------------------------------------------------------------
upstreams:
  init:
    strategy: blocking
  groups:
    default:
      - tcp-tls:dns.quad9.net:853
      - tcp-tls:one.one.one.one:853

# Explicit IPs for upstream resolution at startup
# (avoids chicken-and-egg when Blocky is itself the system resolver)
bootstrapDns:
  - upstream: tcp-tls:1.1.1.1:853
    ips:
      - 1.1.1.1
      - 1.0.0.1
  - upstream: tcp-tls:9.9.9.9:853
    ips:
      - 9.9.9.9
      - 149.112.112.112

# ---------------------------------------------------------------
# Client identification (static, since no DHCP on tailnet)
# Add a new entry here whenever you add a tailscale node
# ---------------------------------------------------------------
clientLookup:
  clients:
    homeserver:
      - 100.64.0.1
    laptop:
      - 100.64.0.2
    phone:
      - 100.64.0.3
    desktop:
      - 100.64.0.4

# ---------------------------------------------------------------
# Custom local DNS records for your tailnet nodes
# Add a new entry here whenever you add a tailscale node
# ---------------------------------------------------------------
customDNS:
  customTTL: 1h
  filterUnmappedTypes: true
  rewrite:
    ts.fidelramos.net: tail   # allows 'X.ts.fidelramos.net' as shortcut for 'X.tail'
  mapping:
    homeserver.tail: 100.64.0.1
    laptop.tail: 100.64.0.2
    phone.tail: 100.64.0.3
    desktop.tail: 100.64.0.4
    # Friendly names for services on tailnet (for Part 4)
    immich.tail: 100.64.0.1
    jellyfin.tail: 100.64.0.1
    nextcloud.tail: 100.64.0.1

# ---------------------------------------------------------------
# Blocking
# ---------------------------------------------------------------
blocking:
  denylists:
    ads:
      - https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt
      - https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
      - https://adaway.org/hosts.txt
      - https://v.firebog.net/hosts/AdguardDNS.txt
      - https://v.firebog.net/hosts/Easyprivacy.txt
    malware:
      - https://urlhaus.abuse.ch/downloads/hostfile/
      - https://v.firebog.net/hosts/Prigent-Malware.txt
    tracking:
      - https://v.firebog.net/hosts/Easyprivacy.txt
    smart-tv:
      - https://perflyst.github.io/PiHoleBlocklist/SmartTV.txt
    kids:
      - https://blocklistproject.github.io/Lists/porn.txt
      - https://blocklistproject.github.io/Lists/gambling.txt

  allowlists:
    ads:
      - |
        # Common false positives
        clients4.google.com
        clients2.google.com
        googleads.g.doubleclick.net

  clientGroupsBlock:
    default:
      - ads
      - malware
      - tracking
    # Per-client overrides by name (from clientLookup above)
    # phone:
    #   - ads
    #   - malware
    #   - tracking
    #   - smart-tv
    # kids-tablet:
    #   - ads
    #   - malware
    #   - kids

  loading:
    refreshPeriod: 24h
    downloads:
      timeout: 60s
      attempts: 3
      cooldown: 10s
    strategy: blocking
    maxErrorsPerSource: 5
  blockType: zeroIp
  blockTTL: 1m

# ---------------------------------------------------------------
# Caching
# ---------------------------------------------------------------
caching:
  minTime: 5m
  maxTime: 30m
  maxItemsCount: 0
  prefetching: true
  prefetchExpires: 2h
  prefetchThreshold: 5
  cacheTimeNegative: 30m

# ---------------------------------------------------------------
# Ports & binding
# Bind ONLY to tailnet IP so Blocky isn't exposed on LAN/WAN
# ---------------------------------------------------------------
ports:
  dns: 100.64.0.1:53
  tls: 100.64.0.1:853     # optional DoT for tailnet clients
  http: 127.0.0.1:4000    # metrics / API (local only)

# ---------------------------------------------------------------
# Logging & metrics
# ---------------------------------------------------------------
log:
  level: info
  format: text
  timestamp: true
  privacy: false

queryLog:
  type: csv-client
  target: /logs
  logRetentionDays: 7
  creationAttempts: 3
  creationCooldown: 2s

prometheus:
  enable: false
  path: /metrics

# ---------------------------------------------------------------
# Misc
# ---------------------------------------------------------------
# Block leaks of private-use TLDs to public resolvers
specialUseDomains:
  rfc6762-appendixG: true

A grandes rasgos:

DNS global sobre DoT: Cloudflare y Quad9 como servicios de resolución global, en paralelo, usando DNS-over-TLS para que el tráfico proveniente de Blocky esté cifrado.
Entradas DNS personalizadas: algunos nombres internos que quiero resolver en toda la tailnet sin tocar los extra_records de Headscale (esto lo cubriré en la Parte 4).
Bloqueo: una mezcla de listas generales y algunas listas de bloqueo específicas que me interesan. Iré ajustándolas, pero por ahora son un buen punto de partida.
Caché: habilitado, con valores predeterminados sensatos.
Métricas de Prometheus: desactivadas por ahora, no tengo un recolector de métricas en este momento, lo haré en mi nuevo servidor doméstico.

Arrancarlo:

$ sudo docker compose up -d
$ sudo docker logs -f blocky

Verificación desde el host:

La resolución por DNS funciona:

$ dig @100.64.0.1 example.com
; <<>> DiG 9.20.22 <<>> @100.64.0.1 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57184
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       172.66.147.243
example.com.            300     IN      A       104.20.23.154

;; Query time: 24 msec
;; SERVER: 100.64.0.1#53(100.64.0.1) (UDP)
;; WHEN: Sun May 10 16:30:57 WEST 2026
;; MSG SIZE  rcvd: 72

Dominio bloqueado (devuelve 0.0.0.0):

$ dig @100.64.0.1 doubleclick.net
; <<>> DiG 9.20.22 <<>> @100.64.0.1 doubleclick.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45469
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;doubleclick.net.               IN      A

;; ANSWER SECTION:
doubleclick.net.        60      IN      A       0.0.0.0

;; Query time: 1 msec
;; SERVER: 100.64.0.1#53(100.64.0.1) (UDP)
;; WHEN: Sun May 10 16:32:50 WEST 2026
;; MSG SIZE  rcvd: 49

Blocky solo se enlaza a la IP de tailnet, no hay puerto DNS expuesto a Internet:

$ sudo ss -ulnp | grep :53
UNCONN 0      0          100.64.0.1:53         0.0.0.0:*    users:(("blocky",pid=2984612,fd=15))

$ sudo ss -tlnp | grep -E ':53|:853'
LISTEN 0      4096      100.64.0.1:53         0.0.0.0:*    users:(("blocky",pid=2984612,fd=16))
LISTEN 0      4096      100.64.0.1:853        0.0.0.0:*    users:(("blocky",pid=2984612,fd=14))

Cambios en Headscale

Ahora, la magia de Tailscale: le digo a Headscale que envíe la IP de tailnet de Blocky como DNS global a cada cliente. Edita /var/opt/headscale/config/config.yaml, su bloque dns cambia de la siguiente manera:

dns:
  magic_dns: false
  override_local_dns: true        # que los clientes usen nuestro DNS, reemplazando su DNS del sistema
  base_domain: ts.fidelramos.net
  nameservers:
    global:
      - 100.64.0.1                # Blocky en la tailnet
  search_domains: []

Reinicia Headscale:

sudo docker compose restart headscale

Cada cliente tiene que obtener la nueva configuración:

Linux:

sudo tailscale up --login-server=https://headscale.fidelramos.net --accept-dns=true

Android: desconecta y vuelve a conectar Tailscale. También deshabilita el DNS privado de Android (Ajustes → Red → DNS privado → Desactivado), ya que entraría en conflicto.

Verifica desde un cliente Linux:

$ resolvectl status | grep -A2 tailscale0
# Debería mostrar 100.64.0.1 como el servidor DNS en tailscale0

$ dig example.com
# Debería resolver a través de Blocky

Por qué es mejor que DoT en cada dispositivo

El cifrado es o igual o mejor:

Dispositivo → Blocky: DNS sin cifrar, pero dentro de un túnel WireGuard. El ISP ve un flujo UDP al servidor doméstico, pero nada más.
Blocky → DNS global: DNS-over-TLS cifrado. El DNS global ve la consulta del servidor, pero no qué dispositivo original la hizo.

Y hay beneficios que no tendría con sólo DoT en cada dispositivo:

Autoconfiguración, sólo con conectarse por Tailscale.
Listas de bloqueo centralizadas. Cambio un archivo y todos los dispositivos se benefician.
Registros de consultas por cliente en un solo lugar. Blocky puede registrar consultas por IP de cliente.
Entradas DNS internas, las usaré en la Parte 4.
Funciona idénticamente en todas las plataformas, sin el baile del DNS privado de Android.
No es necesario cambiar la configuración del router. Mi router actual no me permite cambiar los DNS, así que esta es una forma ingeniosa de configurar el DNS en todos mis dispositivos sin tener que ir uno por uno.

Inconvenientes encontrados

Android "no se puede conectar" con el DNS privado configurado

Ya lo mencioné en la Parte 1, pero vale la pena repetirlo: con el DNS de Tailscale activo, la configuración de DNS privado de Android debe estar Desactivada o Automática. Configurar un nombre de host DoT estricto rompe el DNS por completo en el dispositivo mientras Tailscale está conectado.

La resolución de DNS se rompe en el servidor

Si el servidor usa 127.0.0.53 (systemd-resolved) y luego le pides que use Blocky para todo, y Blocky está en un contenedor que depende de DNS para iniciarse... puedes meterte en un callejón sin salida.

Al menos dos formas de evitarlo:

Deja el /etc/resolv.conf del host apuntando a un servicio de resolución externo (por ejemplo, Cloudflare) y solo envía Blocky a los clientes de tailnet. Esto es lo que yo hago: el propio host no usa Blocky, solo los dispositivos que se conectan a través de Tailscale.
O, fija la imagen de Blocky para que siempre esté disponible localmente y deja que Docker la inicie antes de que cualquier otra cosa necesite DNS.

Los clientes no usan el nuevo DNS

Headscale envía la configuración de DNS en cada actualización del mapa, pero algunos clientes (especialmente Linux con NetworkManager) necesitan un empujón. Ejecutar tailscale up de nuevo con --accept-dns=true fuerza una resincronización. En Android, apagar y encender suele ser suficiente.

Hay que deshabilitar MagicDNS

Si magic_dns se hubiera dejado habilitado en la configuración de Headscale, habría entrado en conflicto con Blocky DNS, ya que ambos intentarían usar el mismo puerto 53.

Decidí deshabilitar MagicDNS y mantener mapping en la configuración de Blocky de dominios e IPs. Es un proceso manual, pero mi tailnet es pequeña y no cambiará mucho, así que no me importa si eso implica una configuración más sencilla.

Una solución alternativa sería ejecutar el MagicDNS de Headscale en un puerto diferente y luego hacer que Blocky lo use.

Qué sigue

Con Blocky así configurado, cada dispositivo en mi tailnet tiene bloqueo de anuncios y DNS filtrado, a través de cualquier conexión a Internet en cualquier parte del mundo.

En la Parte 3 reconfiguraré Syncthing para usar exclusivamente la tailnet, deshabilitando todas sus funciones de descubrimiento y retransmisión orientadas a la WAN ahora que son innecesarias.

Tailscale autoalojado, Parte 1: Headscale y clientes

2026-05-05T00:00:00+00:00

Hace bastante que oigo a mucha gente hablar maravillas de Tailscale como solución para interconectar dispositivos, o en otras palabras, para crear tu propia VPN en malla (mesh). Sobre el papel pinta fenomenal: fácil de configurar, rápido y ligero, basado en un protocolo abierto (WireGuard), funciona en todas partes, resuelve el problema de NAT... Sin embargo, me echaba para atrás el entregar mis datos a una empresa, aunque solo fueran metadatos, y que requirieran información personal para registrarse. ¿No hay una solución soberana? ¡Pues sí, la hay! Y te contaré paso a paso cómo configurarla.

El artículo oficial sobre cómo funciona Tailscale me pareció muy bien explicado y aclaratorio. Si no conoces conceptos como plano de datos, plano de control, las diferencias entre redes hub-and-spoke y de malla, o NAT traversal, te recomiendo que le eches un vistazo. Después de todo, nuestro objetivo será autoalojar nuestro propio plano de control.

Esta es la primera entrada de una serie sobre cómo configurar una VPN de malla compatible con Tailscale autoalojada en mi servidor doméstico, sin dependencias en la nube y sin ninguna cuenta en servicios de terceros.

Objetivos

Establecer una VPN de malla entre mis dispositivos (teléfono, tableta, portátil, ordenador de escritorio, servidor doméstico) para poder acceder a cualquiera de elos desde cualquier otro desde cualquier lugar de forma segura.
Sin necesitar cuenta de terceros para iniciar sesión. Nada de Google, Apple, GitHub o Microsoft.
Sin servidores de terceros involucrados en la coordinación. Mis dispositivos hablan con mi servidor, y punto.
Funciona en Linux y Android (las plataformas que uso), utilizando clientes de código abierto. Vale la pena señalar que otros clientes son de código cerrado, pero no me importa porque no uso esas plataformas.
Fácil de mantener actualizado, tanto clientes como servidor.

¿Por qué no usar simplemente el servicio alojado de Tailscale?

Tailscale es un gran producto y quiero ser justo al respecto: el plano de datos está cifrado de extremo a extremo con WireGuard, por lo que Tailscale Inc. no ve el contenido del tráfico.

Pero:

Sí ven metadatos. Cada cliente contacta con el plano de control para obtener el mapa de red. Eso significa que Tailscale vería la IP pública de cada dispositivo que poseo, cada vez que se conectara, desde dondequiera que estuviera. Eso es un montón de historial de ubicaciones en los registros de una empresa que preferiría evitar si puedo. Y sí que puedo, así que lo haré.
La identidad depende de un tercero. La versión gratuita de Tailscale requiere iniciar sesión con Google, GitHub, Microsoft, Apple o un proveedor OIDC similar. Si alguno de ellos suspende mi cuenta, perdería el acceso a mi propia red. Amén de la pérdida de privacidad al saber que uso el servicio.
Es un servicio fuera de mi control. Si Tailscale sufre una caída, cambia los precios, modifica su producto o es adquirido, mi instalación se vería afectada.

Arquitectura

El núcleo de la arquitectura se basa en Headscale, una reimplementación de código abierto del servidor de coordinación de Tailscale. Elimina las tres preocupaciones anteriores. Los clientes oficiales de Tailscale funcionan con él sin cambios.

Arquitectura de una Tailnet con un Headscale autoalojado

Headscale se ejecuta en Docker Compose en mi servidor doméstico, detrás de Caddy para HTTPS.
Los clientes de Tailscale se ejecutan en cada dispositivo, configurados para usar mi instancia de Headscale como servidor de control. Cada cliente informa al servidor sobre su situación de red y, a cambio, obtiene conexiones a los otros nodos.
DNS en esta primera parte utiliza Cloudflare. En la segunda parte lo reemplazaré por un servidor DNS Blocky autoalojado con bloqueo de anuncios y rastreadores que usarán automáticamente todos los clientes de mi Tailnet.
Los clientes establecen túneles WireGuard directos entre pares; los relés DERP públicos de Tailscale se utilizan solo como respaldo.

Requisitos previos

Un dominio bajo mi control (fidelramos.net).
Una forma de que mi servidor doméstico sea accesible desde Internet en los puertos 80 y 443. Utilizo DNS dinámico porque mi ISP me da una IP pública dinámica. Mi servidor actualiza periódicamente un registro A que apunta headscale.fidelramos.net a mi IP actual. Si tienes una IP estática, pues mejor que mejor.
El router reenvía los puertos TCP 80 y 443, y el puerto UDP 41641 a mi servidor doméstico. Mi servidor está en la DMZ del router, así que esto es automático.
Mi servidor, ejecutando Debian con Docker y Docker Compose instalados y configurados.
Caddy con caddy-docker-proxy como proxy inverso. Ya escribí sobre esa configuración en esta entrada anterior. Es la forma más sencilla que he encontrado para tener un proxy inverso habilitado para HTTPS. Realmente me encanta.

Headscale en Docker Compose

Tengo un proyecto compose con otros servicios, incluido un servicio caddy con caddy-docker-proxy como se describe en la entrada ya mencionada.

Añadí un servicio headscale a compose.yml:

services:
  headscale:
    image: headscale/headscale:stable
    container_name: headscale
    restart: unless-stopped
    command: serve
    volumes:
      - ${HEADSCALE_ROOT}/config:/etc/headscale
      - ${HEADSCALE_ROOT}/data:/var/lib/headscale
    networks:
      - caddy
    labels:
      caddy: headscale.fidelramos.net
      caddy.reverse_proxy: "{{upstreams 8080}}"

Algunos puntos a destacar:

image: headscale/headscale:stable sigue la última versión estable. Lo combino con WUD para actualizaciones controladas (escribiré una futura entrada al respecto). Por supuesto, puedes hacer un docker compose pull manual.
No hay sección ports:. Headscale solo se alcanza internamente a través de Caddy.
Establezco mi HEADSCALE_ROOT en /var/opt/headscale, pero puedes usar el directorio que tenga sentido para ti.
Las dos etiquetas son todo lo que caddy-docker-proxy necesita para enrutar headscale.fidelramos.net al puerto 8080 del contenedor.

Configuración de Headscale

Lo puse en /var/opt/headscale/config/config.yaml, pero puedes ponerlo donde te funcione, solo ajusta el mapeo de volumen en la configuración de compose.

server_url: https://headscale.fidelramos.net
listen_addr: 0.0.0.0:8080
metrics_listen_addr: 0.0.0.0:9090
grpc_listen_addr: 0.0.0.0:50443
grpc_allow_insecure: false

noise:
  private_key_path: /var/lib/headscale/noise_private.key

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48
  allocation: sequential

derp:
  server:
    enabled: false
  urls:
    - https://controlplane.tailscale.com/derpmap/default
  auto_update_enabled: true
  update_frequency: 24h

disable_check_updates: true
ephemeral_node_inactivity_timeout: 30m

database:
  type: sqlite
  sqlite:
    path: /var/lib/headscale/db.sqlite

log:
  level: info
  format: text

dns:
  magic_dns: true
  override_local_dns: true
  base_domain: ts.fidelramos.net
  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1
  search_domains: []

unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"

policy:
  mode: file
  path: ""

Estos son los puntos más importantes:

server_url es la URL HTTPS pública para el plano de control. Debe ser accesible por los clientes.
base_domain es el sufijo utilizado por MagicDNS para los nombres de host de tailnet (por ejemplo, homeserver.ts.fidelramos.net). No debe ser igual ni padre de el dominio server_url, si no los clientes se confunden.
dns.nameservers.global son los servidores DNS que se envían a cada cliente. En esta configuración uso Cloudflare; en la Parte 2 lo cambiaré para usar una instancia de Blocky.
DERP está deshabilitado para el servidor y utiliza el mapa DERP público de Tailscale como relés de respaldo para los clientes. Usar sus DERP no filtra tráfico (es WireGuard retransmitido, siempre cifrado de extremo a extremo) pero es la única pieza no autoalojada, es un compromiso razonable para mi caso.

Registros DNS

Solo uno: un registro A para headscale.fidelramos.net que apunta a la IP pública de mi servidor doméstico (a través de DDNS). Ahí se conectan los clientes y es el dominio que Let's Encrypt verificará con HTTP-01 a través de Caddy.

ts.fidelramos.net (el base_domain) no obtiene un registro DNS público. Se resuelve completamente dentro de la tailnet por MagicDNS de Tailscale. Esto significa que solo mis clientes de Tailscale podrán acceder a estos dominios, y no se publicarán en ningún lugar.

Primera ejecución

En el proyecto Docker compose:

sudo docker compose up -d
sudo docker logs -f headscale

Una vez que los registros muestren que la API está escuchando y Caddy ha obtenido un certificado, confirmo que el plano de control es accesible:

curl https://headscale.fidelramos.net/health

Debería devolver {"status":"pass"}.

Creación de un usuario y claves de preautenticación

Headscale utiliza usuarios como espacios de nombres que poseen dispositivos. Creo uno para mí:

sudo docker compose exec headscale headscale users create fidel

Luego genero una clave de preautenticación cada vez que necesito registrar un nuevo dispositivo:

sudo docker compose exec headscale headscale preauthkeys create --user 1 --expiration 1h

La clave solo es válida por una hora. Suficiente para registrar un dispositivo y no tener que preocuparme por si se filtra.

Tailscale en Linux

Debian:

CODENAME=$(lsb_release --codename --short)
curl -fsSL https://pkgs.tailscale.com/stable/debian/$CODENAME.noarmor.gpg | \
  sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/debian/$CODENAME.tailscale-keyring.list | \
  sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt update
sudo apt install -y tailscale
sudo systemctl enable --now tailscaled

Fedora:

sudo dnf config-manager addrepo --from-repofile=https://pkgs.tailscale.com/stable/fedora/tailscale.repo
sudo dnf install tailscale
sudo systemctl enable --now tailscaled

Arch Linux y derivados:

pacman -S tailscale
sudo systemctl enable --now tailscaled

Para todos los sistemas, una vez que Tailscale esté habilitado, registro el dispositivo con Headscale usando una clave de preautenticación:

sudo tailscale up \
  --login-server=https://headscale.fidelramos.net \
  --auth-key=<preauth-key> \
  --hostname=$(hostname)

Para verificar:

# on client
tailscale status
# on server
sudo docker compose exec headscale headscale nodes list

El nodo debería aparecer en ambas listas, con una dirección 100.64.0.x.

Tailscale en Android

La aplicación de Android se comunica con Tailscale público por defecto y no hay una configuración obvia para cambiarlo. Considero esta ofuscación un patrón oscuro, pero comprensible ya que quieren tener un negocio exitoso. Aún así fue exasperante tener que buscar cómo hacerlo a pesar de saber que la opción estaba ahí escondida en algún lugar.

El truco es la opción de servidor alternativo, que está oculta:

Instala la aplicación Tailscale desde F-Droid, la Play Store o, mi forma elegida, a través de Obtanium usando https://pkgs.tailscale.com/stable/tailscale-android-universal-latest.apk como fuente.
Inicia la aplicación y cancela el intento de iniciar sesión en Tailscale.
Una vez que llegues a la pantalla con el botón Conectar, toca el engranaje para el menú de configuración, y después dale a Cuentas.
En el menú superior derecho de esa pantalla, elige Usar un servidor alternativo.
Introduce tu servidor Headscale (en mi caso https://headscale.fidelramos.net).
Inicia sesión. Se abrirá una página en el navegador con instrucciones sobre qué ejecutar en el servidor Headscale para registrar este cliente.
Como se indica, ejecuta el comando en el servidor headscale:

sudo docker compose exec headscale headscale nodes register \ --user 1 \ --key nodekey:abcdef...

Si quieres una guía visual, encontré este vídeo con instrucciones paso a paso:

Después del registro, activa el interruptor de conexión en la aplicación. tailscale status en un dispositivo Linux en la tailnet debería mostrar el teléfono, y debería aparecer en la lista de nodos de Headscale como se mencionó en la sección del cliente Linux.

Mencionaré una cosa específica de Android: Tailscale se añade como un servicio VPN, y al menos en mis dispositivos se marcó como siempre activo y también el bloquear conexiones sin VPN. Recomiendo dejar siempre activo habilitado, pero deshabilitar el bloqueo de conexiones sin VPN. Como Tailscale es una VPN solo entre tus dispositivos, si se cae no pierdes anonimato como con una VPN de reenvío de tráfico, simplemente pierdes el acceso a los pares de la VPN.

Configuración de VPN de Android

Otros clientes

Solo uso Linux y Android, así que eso es lo que he cubierto y probado. Para otras plataformas, los clientes de Tailscale funcionan de la misma manera, simplemente apúntalos al servidor alternativo y regístrate. El proyecto Headscale mantiene instrucciones actualizadas para macOS, iOS y Windows que no duplicaré aquí.

Dificultades encontradas

Recopilo aquí algunos problemas que encontré en el camino, por si le puedo ahorrar sufrimiento a alguien.

Clave incorrecta

Si pasas la clave incorrecta a headscale nodes register, obtendrías el siguiente error:

Cannot register node: node not found in registration cache

El valor esperado es la cadena nodekey:... de la URL del navegador del cliente, no una clave de preautenticación. Las claves de preautenticación se utilizan en el lado del cliente con tailscale up --auth-key=..., no en el servidor.

La caché de registro está en memoria y caduca después de ~15 minutos, así que si te tomas un descanso para comer entre el inicio de sesión del cliente y el comando del servidor, vuelve a activar el inicio de sesión en el cliente para generar una nueva.

El dispositivo Android aparece con nombre `invalid-...` en headscale

Headscale rechaza los nombres que no son etiquetas DNS válidas (espacios, caracteres unicode, etc.). Android envía el nombre de dispositivo legible por humanos, lo que a menudo falla esta verificación (por ejemplo, "Pixel 8 Pro" en mi caso). Headscale renombra el nodo automáticamente a invalid-<hash>.

Puedes renombrarlo en el servidor Headscale después del registro:

bash sudo docker compose exec headscale headscale nodes rename -i <node-id> pixel8pro

Puramente cosmético, pero MagicDNS no funcionará para el nombre original hasta que hagas esto.

Android "No conectado" sin error

Si la aplicación muestra la cuenta de Headscale pero se queda en "No conectado" cuando activas la conexión, algunas cosas que debes verificar en orden:

Comprueba sudo docker compose logs -f headscale mientras activas. Deberías ver al cliente accediendo a /ts2021. Si no aparece nada, no está llegando al servidor. Podría ser un problema de TLS (comprueba los registros de caddy), DNS, firewall...
Desde el navegador del teléfono, https://headscale.fidelramos.net/health debe tener éxito.
Comprueba que DERP se cargó: sudo docker compose exec headscale headscale debug derp debería listar las regiones. Si está vacío, el contenedor no puede alcanzar controlplane.tailscale.com para el mapa, primero corrige el DNS del contenedor o su salida a Internet.
DNS privado de Android: esto merece una sección propia.

El DNS privado de Android interfiere con el arranque de Tailscale

Estaba usando AdGuard DNS como DNS privado personalizado, pero se rompió cuando Tailscale se conectó, dejándome sin una configuración DNS válida, por lo que la mayoría de las conexiones a Internet no funcionaban.

Vi dos errores:

En la configuración de red de Android, DNS privado decía no se pudo conectar.
Poco después de configurar el DNS privado personalizado, saltaba una notificación: La red no tiene acceso a Internet. No se puede acceder al servidor DNS privado.

Afortunadamente, pude sortear este problema autoalojando mi propio DNS de bloqueo de anuncios y haciendo que todos mis clientes de Tailscale lo usaran. Esto acabó siendo una bendición, ya que ganaba control total sobre el DNS y ya no tendría que pagar por AdGuard DNS.

Esta solución se presentará en la próxima Parte 2 de esta serie de artículos.

MagicDNS no resuelve en un dispositivo específico

Después de cambiar la configuración de DNS de Headscale, los clientes necesitan obtener nuevas configuraciones.

En Linux, sudo tailscale up --login-server=... --accept-dns=true resincroniza.

En Android, activa y desactiva el interruptor de la VPN.

Desfase horario

El intercambio de ruido de Tailscale falla silenciosamente si hay una deriva de reloj significativa. Si nada más explica un problema de conexión, comprueba que NTP (sincronización de tiempo) esté funcionando en ambos extremos.

En Linux configura systemd-timesyncd, ntpd, chrony o similar.

En Android, pon la configuración de fecha/hora en "automático" en la configuración del sistema.

Siguientes pasos

Esta configuración ya es funcional: mis dispositivos pueden comunicarse entre sí a través de mi propio servidor de control, sin Tailscale ni cuentas o servicios de terceros. Puedo acceder desde cualquier parte a aplicaciones que antes solo eran accesibles a través de la LAN.

En la Parte 2, cambiaré el DNS de Cloudflare configurado actualmente por una instancia de Blocky autoalojada para obtener bloqueo de anuncios y rastreadores y conseguir resolución de nombres internos en cada cliente de la tailnet.

Pre-estableciendo conexiones maestras de SSH para Ansible, o cómo usar OnlyKey con Ansible sin morir en el intento

2026-04-07T00:00:00+00:00

Uso una OnlyKey como dispositivo de seguridad de hardware para varios propósitos:

Las contraseñas comunes se escriben automáticamente con solo pulsar un botón.
Como segundo factor en mi gestor de contraseñas (KeepassXC), usando HMAC aplicado a la contraseña.
Conexiones SSH.
Cifrado y firma GPG.

OnlyKey

Las conexiones SSH se manejan a través del onlykey-agent, y funciona bastante bien. Sin embargo, con Ansible se convierte en una pesadilla, ya que pide docenas y docenas de pulsaciones de teclas:

Parte de una sesión de Ansible con onlykey-agent

Este dolor de cabeza me estaba haciendo usar Ansible cada vez menos para mis automatizaciones, así que decidí encontrar una solución. El objetivo es necesitar solo una pulsación de OnlyKey por cada servidor, con un comportamiento bien definido y razonablemente seguro.

Me alegra decir que he logrado una solución razonable, que documento aquí con la esperanza de que sea útil para otras personas. Podría ayudar no solo a los usuarios de OnlyKey, sino a cualquiera con una configuración de SSH que requiera intervención manual en el momento de la conexión, y para la que por alguna razón la reutilización de conexiones SSH de Ansible no esté funcionando.

El problema

Ansible a menudo abre más de una sesión SSH por servidor durante su ejecución. Incluso con una buena configuración, es posible que sigas viendo conexiones repetidas para tareas, recopilación de información (fact gathering), escalada de privilegios y otras operaciones.

Cuando se usan claves SSH normales, todo esto es casi invisible. Se pierde rendimiento por las conexiones extras a la red y el cifrado adicional, pero funcionaría.

Con onlykey-agent, cada nueva autenticación SSH requiere confirmación física. Eso hace que todas las conexiones repetidas se convierte rápidamente en un auténtico coñazo.

Lo que observé

La solución a alto nivel es obvia: reutilizar las conexiones SSH.

Y la cuestión es que Ansible soporta la reutilización de conexiones mediante la multiplexación de conexiones de OpenSSH.

De forma resumida, OpenSSH puede establecer una conexión como maestra, dejar un socket abierto y hacer que las nuevas conexiones al mismo servidor/usuario/puerto lo reutilicen automáticamente.

Sin embargo, cuando intenté configurarlo con Ansible no funcionó, seguía recibiendo las mismas peticiones en la OnlyKey.

Cuando miraba el directorio de los sockets veía cómo se creaban, sólo para desaparecer momentos después.

Entonces probé la multiplexación SSH fuera de Ansible, y funcionó.

Configuré ControlMaster en ~/.ssh/config, y una vez que me conecté a un servidor con onlykey-agent pude abrir una nueva conexión sin otra petición de la OnlyKey.

Sin embargo, cuando cerraba la conexión, el socket desaparecía.

Supongo que Ansible está cerrando las conexiones por alguna razón, pero no he descubierto exactamente por qué ni cómo.

La solución

Aprovechando que las conexiones abiertas mantenían el socket abierto, planteé una solución que funcionase de forma consistente:

Configurar la multiplexación SSH normalmente.
Configurar Ansible para que use los mismos sockets.
Ejecutar Ansible dentro de un script que:
1. Lea la lista de servidores del inventario de Ansible.
2. Establezca una conexión maestra de SSH para cada servidor.
3. Mantenga vivo cada maestro con un sleep remoto.
4. Ejecute ansible-playbook con todos los argumentos originales sin cambios.
5. Termine las conexiones maestras al completar.

Configuración de SSH

Primero, asegúrate de que tu configuración de SSH habilite la multiplexación y use un control path estable.

Añade esto a ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/sockets/%h-%r-%p

Luego crea el directorio para los sockets:

mkdir -p ~/.ssh/sockets
chmod 0700 ~/.ssh/sockets

También me gusta configurar usuarios y puertos en la configuración de SSH, por ejemplo:

Host blog.fidelramos.net
    User fidel
    Port 22022

Configuración de Ansible

Usa un ansible.cfg como este:

[defaults]
transport = ssh

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ServerAliveInterval=30 -o ServerAliveCountMax=3
control_path_dir = ~/.ssh/sockets
control_path = %(directory)s/%%h-%%r-%%p
pipelining = True

transport = ssh fuerza el uso de OpenSSH en lugar de Paramiko, que no permite multiplexación SSH. Este debería ser el comportamiento predeterminado en las versiones recientes de Ansible.
control_path_dir y control_path hacen que Ansible use el mismo patrón de nomenclatura de sockets que SSH, para que reutilice los que el script ha establecido previamente.
pipelining = True reduce parte de la sobrecarga de SSH y la rotación de archivos temporales remotos. Esta es una buena idea incluso sin multiplexación para reducir el número de conexiones y acelerar la ejecución de Ansible.

El script

Aquí está el script completo.

Intencionadamente no intenta gestionar por sí mismo los nombres de usuario o puertos por servidor. Esos son aplicados por la configuración de SSH, y Ansible también los reutiliza.

El script pasa todos los argumentos a ansible-playbook exactamente como se proporcionan. Mira los ejemplos de uso más abajo.

También publiqué el script como un Gist.

`ansible-ssh-masters.sh`

#!/usr/bin/env bash
# ansible-ssh-masters.sh
#
# Establish one SSH master connection per host, keep it alive with a
# remote sleep, run ansible-playbook with all original arguments, then
# clean up only the masters this script started.
#
# Useful when SSH authentication has a per-connection human cost:
# hardware security keys, passphrase prompts, FIDO2/U2F, etc.
#
# Usage (timeout in seconds):
#   ANSIBLE_SSH_MASTERS_TIMEOUT=3600 ./ansible-ssh-masters.sh playbook.yml [args...]

set -euo pipefail

TIMEOUT_SECONDS="${ANSIBLE_SSH_MASTERS_TIMEOUT:-3600}"
SOCKET_DIR="${HOME}/.ssh/sockets"

PIDS=()
STARTED_HOSTS=()
ARGS=("$@")
INVENTORY="inventory"

GREEN='\033[0;32m'
YELLOW='\033[0;33m'
RED='\033[0;31m'
NC='\033[0m'

log()  { echo -e "${GREEN}[+]${NC} $*"; }
warn() { echo -e "${YELLOW}[!]${NC} $*"; }
err()  { echo -e "${RED}[-]${NC} $*" >&2; }

parse_inventory_arg() {
    local i
    for ((i=0; i<${#ARGS[@]}; i++)); do
        case "${ARGS[$i]}" in
            -i|--inventory)
                if (( i + 1 >= ${#ARGS[@]} )); then
                    err "Missing value after ${ARGS[$i]}"
                    exit 1
                fi
                INVENTORY="${ARGS[$((i + 1))]}"
                ;;
            --inventory=*)
                INVENTORY="${ARGS[$i]#--inventory=}"
                ;;
        esac
    done
}

cleanup() {
    echo
    log "Closing master connections..."

    local i pid host

    for i in "${!PIDS[@]}"; do
        pid="${PIDS[$i]}"
        host="${STARTED_HOSTS[$i]}"

        if kill -0 "$pid" 2>/dev/null; then
            if kill "$pid" 2>/dev/null; then
                wait "$pid" 2>/dev/null || true
                log "Closed master for ${host} (pid ${pid})"
            else
                err "Failed to kill master for ${host} (pid ${pid})"
            fi
        else
            warn "Master for ${host} was already gone (pid ${pid})"
        fi
    done

    log "Done."
}

trap cleanup EXIT INT TERM

parse_inventory_arg

mkdir -p "$SOCKET_DIR"
chmod 0700 "$SOCKET_DIR"

# Remove stale sockets (no process behind them)
find "$SOCKET_DIR" -maxdepth 1 -type s ! -exec fuser -s {} \; -delete 2>/dev/null || true

if ! ansible-inventory -i "$INVENTORY" --graph >/dev/null 2>&1; then
    err "Inventory could not be parsed: $INVENTORY"
    exit 1
fi

mapfile -t HOSTS < <(
    ansible-inventory -i "$INVENTORY" --graph |
    awk '
        /@/ { next }
        {
            line = $0
            gsub(/^[[:space:]|]+/, "", line)
            sub(/^--/, "", line)
            if (line != "") {
                print line
            }
        }
    ' |
    sort -u
)

if (( ${#HOSTS[@]} == 0 )); then
    err "No hosts found in inventory: $INVENTORY"
    exit 1
fi

log "Found ${#HOSTS[@]} hosts in inventory: $INVENTORY"
log "Per-host connection lifetime: ${TIMEOUT_SECONDS} seconds"
log "Establishing master connections (authentication may be required)..."
echo

count=0
for host in "${HOSTS[@]}"; do
    ((count+=1))

    if ssh -O check -o "ControlPath=${SOCKET_DIR}/%h-%r-%p" "$host" >/dev/null 2>&1; then
        log "[$count/${#HOSTS[@]}] ${host}: reusing existing master"
        continue
    fi

    warn "[$count/${#HOSTS[@]}] ${host}: connecting..."

    ssh \
        -o ControlMaster=yes \
        -o "ControlPath=${SOCKET_DIR}/%h-%r-%p" \
        -o ServerAliveInterval=30 \
        -o ServerAliveCountMax=3 \
        -o ForwardAgent=no \
        -o ForwardX11=no \
        -o ClearAllForwardings=yes \
        "$host" "sleep ${TIMEOUT_SECONDS}" &

    pid=$!

    for _ in $(seq 1 15); do
        if ssh -O check -o "ControlPath=${SOCKET_DIR}/%h-%r-%p" "$host" >/dev/null 2>&1; then
            break
        fi
        sleep 1
    done

    if ssh -O check -o "ControlPath=${SOCKET_DIR}/%h-%r-%p" "$host" >/dev/null 2>&1; then
        log "[$count/${#HOSTS[@]}] ${host}: master established (pid ${pid})"
        PIDS+=("$pid")
        STARTED_HOSTS+=("$host")
    else
        err "[$count/${#HOSTS[@]}] ${host}: failed to establish master"
        if kill -0 "$pid" 2>/dev/null; then
            if kill "$pid" 2>/dev/null; then
                wait "$pid" 2>/dev/null || true
            else
                err "[$count/${#HOSTS[@]}] ${host}: failed to stop failed SSH process (pid ${pid})"
            fi
        fi
    fi
    echo
done

echo
log "Running: ansible-playbook $*"

set +e
ansible-playbook "$@"
ANSIBLE_EXIT=$?
set -e

exit "$ANSIBLE_EXIT"

Make it executable:

chmod +x ansible-ssh-masters.sh

Captura de pantalla

ansible-ssh-masters en acción

Uso

Simplemente reemplaza ansible-playbook por ansible-ssh-masters.sh:

./ansible-ssh-masters.sh playbook.yml

En mi caso, antepongo onlykey-agent con la clave correcta:

onlykey-agent fidelramos.net -- ./ansible-ssh-masters.sh playbook.yml

También puedes iniciar una subshell de onlykey-agent y luego ejecutar ansible-ssh-masters.sh dentro:

onlykey-agent fidelramos.net -s
./ansible-ssh-masters.sh playbook.yml

Puedes pasar cualquier número de argumentos, o usar otras fuentes de inventario; se pasan tal cual a ansible-playbook:

./ansible-ssh-masters.sh -i production.ini playbook.yml --limit web --tags deploy -v

Para cambiar el tiempo máximo que pueden vivir las sesiones maestras, establece el tiempo de espera en segundos:

ANSIBLE_ONLYKEY_TIMEOUT=7200 ./ansible-ssh-masters.sh long-playbook.yml

Puntos clave de diseño del script

Voy a ahondar en algunas decisiones deliberadas de diseño.

1. Cerrar conexiones al finalizar o salir

Con el uso de trap, el script se asegura de que las conexiones se cierren tan pronto como ya no sean necesarias, o también si el script se interrumpe por alguna razón (Ctrl-C, proceso terminado o shell cerrada, por ejemplo).

2. Limpia lo que inició

El script solo mata los procesos maestros de SSH que creó.

No limpia todo el directorio de sockets. Puede haber otras sesiones de SSH o herramientas usando el mismo directorio de multiplexación.

3. Análisis de inventario flexible

El script detecta el uso del argumento -i/--inventory y lo analiza con ansible-inventory para obtener los servidores donde se ejecutará el playbook. Eso significa que cualquiera de los formatos de --inventory funcionará, no se limita a un archivo de inventario.

4. Usa la configuración de SSH como fuente de la verdad

En lugar de extraer datos de ficheros de configuración, utiliza transparentemente la configuración de SSH.

El script no intenta adivinar nombres de usuario, puertos o alias de servidor desde Ansible.

Todo eso se queda en la configuración de SSH, donde pertenece.

Notas de seguridad

Esta configuración mejora la usabilidad, pero a cambio de disminuir la seguridad mientras el script se está ejecutando.

El compromiso fundamental

Después de autenticar un servidor con OnlyKey, esa conexión maestra de SSH permanece abierta durante el tiempo de vida configurado o hasta que el script termina.

Eso significa que:

Las sesiones SSH posteriores pueden reutilizar la conexión maestra..
No hace falta interactuar con la OnlyKey mientras esa conexión maestra siga viva.

Ese es el objetivo de la solución, pero también significa que es aún más importante proteger tu sesión local durante esa ventana temporal.

Si hubiese otros programas corriendo en el ordenador con acceso al directorio de sockets SSH podrían obtener acceso directo al servidor remoto. Y esa es precisamente una de las principales razones para usar un dispositivo de seguridad de hardware como OnlyKey.

Cosas que hace esta configuración para limitar el riesgo

Los sockets viven en ~/.ssh/sockets.
El directorio tiene permisos 0700, o sea sólo para el usuario propietario.
El reenvío del agente SSH (Agent forwarding) está desactivado.
El reenvío de X11 (X11 forwarding) está desactivado.
El script cierra las conexiones al terminar.
El tiempo de espera es explícito y finito en caso de que la limpieza automática falle por alguna razón.

Además, personalmente uso Firejail para aislar (sandbox) la mayor parte del software que se ejecuta en mi ordenador. Mi configuración de Firejail bloquea el acceso a ~/.ssh para la mayoría de los programas, así que me siento un poco más seguro con este enfoque.

Por qué la limpieza automática se mantiene activada

El script siempre cierra todas las conexiones maestras cuando termina (vía trap). Esta es una decisión de diseño para incrementar la seguridad.

Sería aún más simple dejar las conexiones abiertas hasta que se agotase su tiempo establecido. Esto también haría que se pudiese ejecutar Ansible más veces sin nuevas autenticaciones.

Personalmente no quería eso, y no lo recomendaría como opción predeterminada ya que reduce aún más la seguridad, pero ya es cuestión de cada cuál el equilibrar la facilidad de uso con la seguridad.

Cuanto menos tiempo permanezcan abiertas las conexiones, menos probable es que puedan ser aprovechadas por un atacante o software malicioso.

Reflexiones finales

Me entristece no haber podido llegar al fondo de por qué la reutilización de conexiones de Ansible no funcionaba correctamente, pero no pude dedicar más tiempo a esa investigación.

Me alegra haber encontrado esta solución alternativa, que es un punto medio razonable entre comodidad y seguridad. Si esto no hubiera funcionado, estaba a punto de volver a las claves SSH normales, lo que habría reducido considerablemente la seguridad de mis servidores.

Si, como yo, tienes una forma engorrosa para conectar por SSH, espero que este script te ayude a disfrutar más de Ansible.

Si has llegado hasta aquí y tienes una idea de cómo solucionarlo Como $DEITY manda, ¡por favor deja un comentario!

DNI electrónico en Firefox en Linux

2026-03-30T00:00:00+00:00

Hace muchos años que tengo el DNI electrónico (o DNIe) en mi cartera, y no pocas veces he intentado hacerlo funcionar en Linux para autenticarme en las páginas de la administración pública. Siempre me encontraba con algún problema que me hacía desistir.

Hace poco me tocó renovarlo y pensé en probar otra vez, a ver si caía la breva. ¡Y sí que cayó! Al fin lo pude hacer funcionar sin paquetes extraños ni complicaciones, con un lector de tarjetas baratito.

Voy a dejar los pasos que he seguido para configurarlo en Arch Linux. Dejaré comentarios sobre los paquetes equivalentes en Debian/Ubuntu y Fedora, porque el resto de la configuración debería ser la misma para todos.

Índice de contenidos

Qué necesitas
Paso 1: Instalar los paquetes necesarios
Paso 2: Activar el servicio pcscd
Paso 3: Comprobar que el lector y la tarjeta se detectan
- Verificar que OpenSC reconoce el DNIe
Paso 4: Configurar Firefox
Paso 5: Probar el acceso
Solución de problemas
¿Y qué hay de las firmas?
Resumen

Qué necesitas

Un lector de tarjetas inteligentes compatible con el estándar CCID (la mayoría lo son). Por 10€ hay muchos para elegir.
Tu DNIe con los certificados activos. Si no los has activado o han caducado, debes renovarlos en un Punto de Actualización del DNIe (PAD) en una comisaría de policía.
El PIN de tu DNIe, que configuraste al obtenerlo o renovar los certificados. Cuando lo renuevas te dan un papel con el PIN.
Firefox instalado de forma nativa. Si usas Flatpak o Snap probablemente tengas problemas porque limitan el acceso a los dispositivos y ficheros del resto del sistema. Lo comento más abajo en la sección de Solución de problemas.

Aprovecho para comentar que Chrome y derivados (Chromium, Brave...) también funcionan con los mismos paquetes, pero la forma de configurarlos es diferente, no tienen interfaz gráfica como la de Firefox. Vamos eso a mí no me asusta, simplemente uso Firefox para las páginas del gobierno por su extensión Multi-Account Containers que da un buen aislamiento entre sesiones.

En este artículo hay instrucciones para configurar Chrome/Chromium/Brave.

Paso 1: Instalar los paquetes necesarios

Necesitamos:

pcscd / pcsc-lite: el demonio que gestiona la comunicación con lectores de tarjetas.
ccid: el driver genérico para lectores CCID.
opensc: el middleware PKCS#11 que permite a las aplicaciones acceder a los certificados guardados en la tarjeta. Soporta el DNIe de forma nativa.
pcsc-tools: utilidades de diagnóstico como pcsc_scan.

Arch Linux

sudo pacman -S ccid opensc pcsc-tools

Debian / Ubuntu

sudo apt update
sudo apt install pcscd pcsc-tools opensc libccid

Fedora

sudo dnf install pcsc-lite pcsc-tools opensc ccid

Paso 2: Activar el servicio pcscd

sudo systemctl enable pcscd.service
sudo systemctl start pcscd.service

Opcionalmente se puede habilitar la activación bajo demanda mediante el socket, para que se inicie cuando haga falta:

sudo systemctl enable pcscd.socket
sudo systemctl start pcscd.socket

Paso 3: Comprobar que el lector y la tarjeta se detectan

Lo primero es comprobar que el lector de tarjetas es reconocido por pcscd.

Conecta el lector USB e inserta el DNIe. Luego ejecuta:

pcsc_scan

Deberías ver una salida similar a:

Scanning present readers...
0: ACS ACR38U-CCID 00 00

Reader 0: ACS ACR38U-CCID 00 00
  Event number: 0
  Card state: Card inserted,
  ATR: 3B 7F 96 00 00 ...

Si en su lugar ves "Waiting for the first reader...", el sistema no detecta el lector. En ese caso:

Comprueba que el lector aparece en la salida de lsusb.
Inspecciona los mensajes del kernel con dmesg | tail -30 tras conectar el lector.
Asegúrate de que el servicio pcscd está corriendo con systemctl status pcscd.service.
Prueba otro puerto USB.

Verificar que OpenSC reconoce el DNIe

opensc-tool -n

Debería devolver DNIe o DNIE. A continuación, comprueba que los certificados son legibles:

pkcs11-tool --module /usr/lib/opensc-pkcs11.so -O

Este comando listará los objetos almacenados en la tarjeta: certificados de autenticación y firma, y sus claves asociadas. Si te pide el PIN, introdúcelo.

Para un volcado más detallado:

pkcs15-tool -D

Paso 4: Configurar Firefox

Abre Firefox.
Ve a Ajustes → Privacidad & Seguridad.
Baja hasta la sección Certificados y haz clic en Administrar dispositivos de seguridad....
Haz clic en Cargar.
Rellena los campos:
Nombre del módulo: OpenSC PKCS#11
Nombre del archivo del módulo: /usr/lib/opensc-pkcs11.so
Haz clic en Aceptar.

Administrador de dispositivos de seguridad en Firefox

Nota sobre la ruta en sistemas de 64 bits: en la mayoría de distribuciones actuales la ruta es /usr/lib/opensc-pkcs11.so. En algunas instalaciones de Fedora o Debian puede estar en /usr/lib64/opensc-pkcs11.so o /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so. Puedes encontrar la ruta exacta con:

bash find /usr/ -name "opensc-pkcs11.so" 2>/dev/null

Paso 5: Probar el acceso

Visita cualquier sede electrónica que ofrezca identificación con certificado, como por ejemplo:

Agencia Tributaria: https://sede.agenciatributaria.gob.es
Seguridad Social: https://sede.seg-social.gob.es
DGT: https://sede.dgt.gob.es

El navegador te pedirá seleccionar un certificado y a continuación el PIN del DNIe. Tras introducirlo, deberías acceder autenticado.

Solución de problemas

Firefox dice "No se puede añadir el módulo"

Verifica que la librería existe y que todas sus dependencias están satisfechas:

ls -la /usr/lib/opensc-pkcs11.so
ldd /usr/lib/opensc-pkcs11.so | grep "not found"

Si ldd muestra alguna dependencia como "not found", instala el paquete que la proporciona.

Los certificados no aparecen aunque la tarjeta se detecta

Certificados caducados: los certificados del DNIe tienen una validez limitada. Si han caducado debes renovarlos en un PAD en una comisaría de policía.
Reinicia Firefox: cierra completamente Firefox, inserta el DNIe y vuelve a abrirlo. A veces no detecta una tarjeta insertada después de cargar el módulo.
Reinicia pcscd: desconecta el lector de tarjetas, reinicia con sudo systemctl restart pcscd.service y vuelve a conectarlo.

El PIN se bloquea

Tras tres intentos fallidos el DNIe se bloquea permanentemente. Para desbloquearlo es necesario acudir a una comisaría de policía. Asegúrate de recordar el PIN antes de intentar usarlo.

Firefox instalado con Flatpak o Snap

Las versiones Flatpak y Snap de Firefox corren en un entorno limitado (sandbox) que impide el acceso a los dispositivos del sistema y al socket de pcscd. La solución más sencilla (aunque no la más segura) es instalar Firefox desde los repositorios nativos de la distribución:

Arch Linux: sudo pacman -S firefox
Debian/Ubuntu: sudo apt install firefox (o firefox-esr)
Fedora: sudo dnf install firefox

Si tienes Firefox instalado a través de Snap puedes probar a conectarlo a pcscd con:

sudo snap connect firefox:pcscd

A algunas personas parece que les funciona, pero otros tienen problemas, como el acceso a la librería /usr/lib/opensc-pkcs11.so. Hay un bug abierto en Mozilla desde 2021 que documenta que cargar módulos PKCS#11 del sistema host no funciona de forma fiable con Snap.

Flatpak sí ofrece más herramientas para resolver la situación:

# Acceso al socket de pcscd
flatpak override --user --filesystem=/run/pcscd org.mozilla.firefox

# Acceso a la librería de OpenSC
flatpak override --user --filesystem=/usr/lib/opensc-pkcs11.so:ro org.mozilla.firefox

# Acceso a dispositivos (lector USB)
flatpak override --user --device=all org.mozilla.firefox

¿Y qué hay de las firmas?

Esta configuración permite autenticarse en una página web, pero los navegadores no gestionan el firmado de documentos digitales. Para eso hace falta instalar y configurar AutoFirma.

Lo bueno es que la parte de pcscd y opensc es común, así que una vez funcionando no debería ser difícil. Pero no lo he probado aún, lo dejo como ejercicio para el lector. :o)

Resumen

La configuración se reduce a tres cosas: instalar opensc, ccid y pcscd; arrancar el servicio; y cargar /usr/lib/opensc-pkcs11.so como módulo de seguridad en Firefox. No se necesita software propietario ni paquetes específico del DNIe.

Anunciando Reflex, un tema para Pelican

2026-02-16T00:00:00+00:00

Me complace anunciar la disponibilidad pública de mi tema para Pelican: Reflex. Está publicado en PyPI, esa deber'ia ser la mejor forma de instalarlo para la mayoría de los usuarios.

Cuando empecé este blog, me decidí por Pelican porque tenía mucha experiencia con Python, así que me resultaría más fácil involucrarme y contribuir. Luego eché un vistazo a todos los temas de Pelican y me decanté por el tema Flex de Alexandre Vizenzi porque cumplía todos mis requisitos:

Minimalista y bonito.
Diseño flexible para distintas pantallas (responsive).
Soporte para archivos, categorías y etiquetas.
Soporte de Pygments para resaltado de código.
Soporte para modos claro/oscuro.

Como era inevitable, al final me topé con algunas funciones que echaba en falta y pequeños retoques que quería implementar. Esa es la belleza del software libre, y empecé a contribuir en Flex. Sin embargo, algunos de los cambios que quería hacer eran demasiado profundos y no encajaban en Flex, ya que el proyecto estaba en modo de mantenimiento. Después de pensarlo un poco, decidí hacer un fork del tema para introducir mis cambios más rompedores, y así es como nació Reflex.

Las principales diferencias con Flex por ahora son:

Instalable vía PyPI (o sea que funciona pip install pelican-theme-reflex).
Estilo para la tabla de contenidos creada por la extensión de Markdown toc.
Estilos para los elementos HTML figure y figcaption.
Soporte para analíticas de tráfico con Shynet (ver mi artículo sobre comentarios autoalojados).
Documentación en el propio repositorio en lugar de en la wiki de Github.
Visualización de banderas de idioma para los idiomas alternativos del artículo.
Icono de la red social X.
Mejoras en la experiencia de desarrollo: soporte para gulp watch para ver cambios al instante, chequeos de pre-commit, AGENTS.md para el desarrollo con IA, flujos de trabajo con GitHub Actions renovados.
Estilos de Pygments y FontAwesome actualizados.
Mejoras de accesibilidad.
Actualizada la integración de comentarios de Isso, con soporte para resaltar los comentarios del autor y notificaciones de respuesta por defecto.

No tengo grandes planes para Reflex, principalmente implementaré los cambios que me parezcan útiles para este blog. Estoy abierto a nuevas integraciones e ideas, ¡así que bienvenidos sean los colaboradores!

Para ver los errores conocidos y las funcionalidades planeadas, echa un vistazo a las incidencias abiertas. Para cualquier pregunta, no dudes en abrir un hilo de discusión.

Si usas Reflex, anímate a añadir tu sitio a la lista de usuarios de Reflex, ¡me encantaría saber de ti!

Actualización del 19 de febrero de 2016: Se publicó Reflex 3.1.0 con algunas mejoras adicionales.

Casa Autoalojada, Parte 1: Diseño y planificación

2026-01-25T00:00:00+00:00

Quienes hayan estado atentos al blog sabrán que he comprado una casa y he estado planeando su reforma integral. Como friki de la informática, lo que más me ilusiona es la oportunidad de implementar la casa inteligente, la red y el servidor doméstico de mis sueños.

Tengo una idea clara de lo que quiero conseguir: un homelab de código abierto que sustituya los ecosistemas cerrados de la nube por servicios locales. Domótica, cámaras de seguridad y videoportero, contactos y calendarios, reproductores multimedia, colección de fotos, documentos y más, todo funcionando en mi propia casa y totalmente bajo mi control. Hay que tener en cuenta que ya tengo un homelab, donde algunos de estos servicios llevan años funcionando. Este nuevo proyecto lo sustituirá por completo, ¡será más grande y mejor! Os recomiendo leer ese artículo si tenéis la oportunidad, ya que explica las razones que me llevaron a empezar a autoalojar servicios y el contexto histórico de cómo he llegado hasta aquí.

En esta serie de artículos entraré en todos los detalles técnicos, empezando por el diseño al que he llegado tras meses de investigación.

La configuración es completamente personal y subjetiva, adaptada a mis necesidades y gustos particulares, así que no os lo toméis como una recomendación. ¡Espero que sea una lectura entretenida y que aprendáis algo interesante!

Mis objetivos son:

Todo local: La domótica, las cámaras, la multimedia y los datos personales deben funcionar sin ninguna dependencia de la nube. El acceso a Internet podría caerse y todo seguiría funcionando localmente. Además, puedo confiar en que mis datos no saldrán de mi casa.
Aislamiento estricto: Los dispositivos domóticos (IoT) y las cámaras se tratan como hostiles: no tienen salida a Internet y su acceso a los servicios internos es limitado a lo necesario. La conectividad con la nube debe evitarse siempre que sea posible.
Basado en estándares y código abierto: ONVIF, RTSP, IPv6, WireGuard, ZFS, Proxmox, TrueNAS, IPFire, Home Assistant, Frigate, Nextcloud, Jellyfin, Immich... evitar las cajas negras cerradas.
Coste: Aunque el montaje completo no será barato en absoluto, buscaré hardware de servidor reacondicionado y daré prioridad a dispositivos de bajo consumo. El sistema tendrá muchas responsabilidades, así que necesito hardware fiable y de calidad.
Preparado para el futuro: Hasta 10 GbE mediante cableado Cat6a, servidores con muchos núcleos, espacio para ampliación, IPv6 en todas partes.

Otros artículos de la serie:

Parte 1: Diseño y planificación
Próximamente, ¡mantente al tanto para no perderte las novedades!

1. Visión general

El homelab constará de múltiples componentes montados en un bastidor (rack) de 42U en 19 pulgadas estándares en una sala dedicada en el sótano de la casa.

Red y seguridad principales
- Quiero tener el control de la red doméstica: impedir el acceso a Internet de la domótica y las cámaras y limitar el acceso a los servicios internos.
- Un servidor dedicado con IPFire proporcionará enrutamiento, cortafuegos, IDS (detección de intrusos) y VPN.
- Switch y puntos de acceso WiFi de UniFi.
- VLANs para una segmentación estricta del tráfico (LAN, IoT, cámaras, invitados, gestión).
Servidor de aplicaciones
- Migraré los servicios autoalojados que funcionan en mi servidor doméstico actual, y los ampliaré.
- Proxmox VE en un servidor tipo Dell PowerEdge.
- Mezcla de máquinas virtuales y contenedores LXC para los servicios.
Almacenamiento
- Tengo considerables necesidades de almacenamiento, ya que mantengo una gran colección de fotos y una biblioteca multimedia local.
- TrueNAS correrá en una máquina virtual en Proxmox, controlando directamente un grupo de discos duros dedicado.
- ZFS para redundancia, instantáneas y replicación.
Cámaras y videoportero
- Cámaras y videoportero Dahua con ONVIF/RTSP/IPv6 y audio bidireccional.
- Switch PoE dedicado.
- Frigate para grabación tipo NVR y detección de objetos.
- Coral TPU para inferencia eficiente.
Resiliencia energética
- Paneles solares y baterías mantendrán en funcionamiento al menos la infraestructura principal.
- Un SAI proporcionará respaldo crítico para mantener la red y las cámaras en funcionamiento y permitir un apagado controlado del servidor de aplicaciones.

Para los que disfrutan con un pequeño diagrama:

Diagrama del rack

Servicios autoalojados

Entre los servicios que planeo desplegar se encuentran:

TrueNAS, detallado más abajo en la sección de Almacenamiento.
Home Assistant para domótica e integración de todas las plataformas y fuentes de datos.
Frigate NVR para las cámaras, detección de objetos y comunicación con el timbre (también integrado en Home Assistant).
Nextcloud como nube personal (contactos, calendario, archivos, notas, etc.).
Immich como biblioteca de fotos.
Jellyfin para la reproducción de vídeo.
Music Assistant para la reproducción de música.
Paperless-ngx para gestionar documentos.
AdGuard Home para bloquear anuncios en toda la casa.
Servicios auxiliares: monitorización, comprobaciones de disponibilidad, registros, orquestación de copias de seguridad, NTP...

Mi intención es dar acceso a la mayoría de estos servicios a mi familia. Eso amortizaría los costes de montaje y mantenimiento, a la vez que les aportaría más privacidad a sus vidas.

2. Red

La red es la base de todo lo demás, es clave para el rendimiento, seguridad y comodidad del sistema.

Aprovechando la oportunidad que brinda una reforma integral, voy a instalar cables Ethernet Cat6a por toda la casa. Cada división tendrá al menos un puerto RJ-45 en una toma de pared, y algunas varias, dependiendo del uso previsto. Los cables Cat6a garantizan velocidad de 10 GbE, que en un futuro serían alcanzables simplemente sustituyendo el switch, las tarjetas de red y los puntos de acceso WiFi; el cableado ya estaría listo. Inicialmente las conexiones serán a 2,5 GbE, con la excepción de dos a 10 GbE para los dos ordenadores de sobremesa.

Todos los cables irán por las paredes hasta la sala de servidores, a paneles de conexiones montados en el rack.

Como router y cortafuegos instalaré IPFire en un servidor dedicado, que será el núcleo de la instalación. Un switch UniFi y varios puntos de acceso WiFi UniFi agregarán el tráfico y lo delimitarán en VLANs. Habrá un switch secundario para las cámaras de seguridad, que se tratará en la sección Cámaras y timbre.

Router/cortafuegos IPFire

IPFire es un software de router y cortafuegos de código abierto basado en GNU/Linux. Lo instalaré en un servidor en rack pequeño, de bajo consumo pero robusto, con estos requisitos (ideales):

Al menos 2 tarjetas de red SFP+ (una para la WAN, otra para la LAN, y opcionalmente otra para gestión dedicada o DMZ).
CPU suficiente para sostener hasta 10 Gbps de velocidad WAN.
Dos unidades SSD o NVMe para configurarlas en espejo para mayor redundancia.
Fuentes de alimentación dobles para redundancia energética.
El menor consumo posible, especialmente en reposo.

Todavía estoy investigando opciones para este servidor. IPFire ofrece sus propios dispositivos, pero se me hacen carísimos para lo que ofrecen, así que estoy buscando servidores en rack.

Lo mejor que he encontrado hasta ahora es la Supermicro X10SDV-7TP8F, una placa base system-on-chip con una CPU Intel Xeon D-1587. Cumple varios de los requisitos: potencia de cálculo suficiente para una WAN de 10 Gbps; bajo consumo de energía (10W en reposo, 45W TDP); 2 tarjetas de red SFP+ de 10 GbE integradas. Le faltan las dobles fuentes de alimentación y doble disco, pero nada es perfecto.

El equipo con IPFire se conectará directamente al router del proveedor de Internet (en modo puente) o a una ONT dedicada.

Se encargará de estas responsabilidades:

Terminar la conexión WAN (PPPoE o DHCP, dependiendo del proveedor).
Proporcionar un cortafuegos con estado (stateful) tanto para IPv4 como para IPv6.
Realizar DHCP y DNS para las redes internas.
Gestionar túneles VPN WireGuard para el acceso remoto a la red doméstica.
Detección de intrusos (IDS)

Quiero que IPv6 sea un ciudadano de primera clase: IPFire obtendrá un prefijo delegado del proveedor y lo dividirá entre las VLAN internas. Esto, junto con una política de denegación por defecto, facilitará la apertura de servicios al exterior de forma controlada y segura, sin las molestias y el impacto en el rendimiento del NAT de IPv4.

Switching y WiFi de UniFi

Conectado a IPFire habrá un switch UniFi Pro HD 24 PoE que:

Agregará todos los segmentos cableados (habitaciones, rack, cámaras, puntos de acceso WiFi).
Proporcionará PoE para los puntos de acceso y potencialmente otros dispositivos.
Implementará etiquetado de VLAN y segmentación de cortafuegos a nivel de capa 2/3 en cooperación con IPFire.

Busqué y rebusqué switches para montar en rack, y ningún otro se acercaba en especificaciones a este UniFi por un precio comparable. Tiene 4 puertos SFP+ de 10 GbE para conectar los servidores IPFire y de aplicaciones, 2 puertos RJ-45 de 10 GbE para mis ordenadores de sobremesa y 22 puertos RJ-45 de 2,5 GbE con PoE. La mayoría de los otros switches de 24 puertos que encontré solo tienen puertos de 1G, sin 10 GbE. El tener 2,5 GbE en todas las conexiones va a darle un buen rendimiento a toda la red por mucho tiempo.

Switch UniFi Pro HD 24 PoE

Para los puntos de acceso WiFi consideré los puntos de acceso de Grandstream, que según dicen son de buena calidad, pero los descarté porque no disponen de banda de 6 GHz, que es la novedad del estándar WiFi 7. Finalmente me decidí por los puntos de acceso WiFi de UniFi (muy probablemente el U7 Pro), porque funcionan con un solo cable Ethernet (2,5 GbE para el U7 Pro, pero en el futuro podría actualizar a un PA con 10 GbE), y se pueden gestionar junto con el switch UniFi.

Los puntos de acceso permitirán un roaming sin interrupciones por toda la casa y tendrán múltiples SSID:

SSID principal: Para dispositivos de confianza (portátiles, móviles y tabletas de la familia).
SSID IoT: Para dispositivos inteligentes inalámbricos, mapeado a la VLAN de IoT.
SSID de invitados: Aislado de los servicios internos, solo con acceso a Internet.

UniFi U7 Pro

Proxmox ejecutará un UniFi Network Server en una máquina virtual, que permitirá la configuración del switch y los puntos de acceso sin conexión a la nube. Estoy confiando que Ubiquiti no me la líe con futuros cambios que requieran conectividad en la nube, me enfadaría mucho si lo hicieran. Este riesgo es la razón por la que elegí no usar cámaras UniFi, por ejemplo. En el peor de los casos, solo tendría que reemplazar el switch y los puntos de acceso, es un riesgo calculado.

Diseño de VLAN y modelo de confianza

La red se dividirá en zonas de confianza:

Interna (de confianza): Ordenadores, móviles y tablets de la familia.
IoT: Dispositivos de domótica (enchufes, interruptores, electrodomésticos, TV, aire acondicionado...).
Cámaras: Cámaras de seguridad y el videoportero.
Invitados: Para visitas; solo Internet, sin acceso a LAN/IoT/Cámaras.
Gestión: Ordenador personal, Proxmox, switches, router, puntos de acceso, gestión fuera de banda (IPMI, iDRAC).

Una vista de pájaro de las reglas de enrutamiento/cortafuegos:

Interna: Puede acceder a servicios: Home Assistant, Frigate, recursos compartidos del NAS, etc.
IoT: Conexión a Home Assistant; sin acceso directo a Internet, excepto para un puñado de puntos finales en lista blanca si es absolutamente necesario; sin acceso a datos personales.
Cámaras: Conexión a Frigate; sin acceso a Internet en absoluto, no quiero que los datos de mis cámaras se exfiltren; sin acceso a datos personales.
Invitados: Solo acceso a Internet; sin acceso a ningún servicio interno.
Gestión: Solo accesible desde un pequeño conjunto de dispositivos de confianza para administración de sistemas.

Las reglas de cortafuegos y enrutamiento serán aplicadas conjuntamente por IPFire y el switch UniFi, asegurando que el tráfico de las cámaras y del IoT nunca llegue a Internet, y que los invitados nunca lleguen a nada interno.

VPN WireGuard

Para un acceso externo seguro, configuraré Wireguard en IPFire:

Cada dispositivo (portátil, móvil, tableta) dispone de su propio par de claves pública y privada, y una IP virtual.
Los dispositivos conectados por WireGuard aterrizan en una subred que tiene acceso controlado a la LAN y a la gestión.
Esto evitará abrir los servicios internos a Internet, y en su lugar sólo es necesaria una única ruta auditable: WireGuard → IPFire → servicios internos.
WireGuard tiene funciones limitadas, pero por eso mismo su superficie de ataque es mucho menor que la de otras VPN.

Esto debería permitir el control remoto completo de Home Assistant, las cámaras y las tareas de administración sin exponer esos servicios directamente a Internet.

3. Servidor de aplicaciones

El núcleo del homelab se ejecutará en Proxmox VE, instalado en un único equipo de servidor con gestión remota adecuada y redundancia.

Proxmox es un sistema operativo seguro y robusto basado en Linux que simplifica la ejecución de servicios virtualizados o en contenedores. Esto proporciona una serie de beneficios:

Código abierto: Puede parecer obvio, pero evita la dependencia de un proveedor.
Mezcla de VMs y contenedores: Ambos se pueden gestionar a través de la misma interfaz.
Seguridad a través del aislamiento: Si un servicio se ve comprometido, el atacante no obtendría acceso a todo el sistema, sino solo a los datos y la red a la que tenga acceso.
Portabilidad y pruebas: Podría tener una instancia de Proxmox de preproducción, por ejemplo en mi ordenador de sobremesa, como banco de pruebas para nuevos servicios. Cuando estén listos, se pueden migrar a la instancia de Proxmox de producción.
Actualizaciones más seguras: Hacer una instantánea de las máquinas virtuales es una forma fácil de probar una actualización de software y revertirla si se encuentran problemas.
Copias de seguridad: Además de las instantáneas de ZFS, Proxmox tiene su propio servidor de copias de seguridad de código abierto, para respaldos incrementales y deduplicados.
Disponibilidad y clústeres: No lo voy a usar, porque lo considero excesivo para mi caso de uso, pero es posible tener redundancia y conmutación por error automática de las instancias de Proxmox.

Proxmox y consideraciones sobre licencias

La licencia de Proxmox es por CPU instalada. Para reducir los costes recurrentes, estoy buscando servidores de una sola CPU, pero con suficientes núcleos para ejecutar todos los servicios previstos y tener margen para crecer en el futuro.

Las CPU modernas ya alcanzan los cientos de núcleos en un sólo zócalo, lo que es más que suficiente para un homelab.

Opciones de hardware para el servidor

El formato objetivo es un servidor en rack reacondicionado, con estas características:

CPU de bajo consumo con al menos 24 núcleos, idealmente 32 o más.
Al menos 128 GB de RAM ECC. ECC es fundamental en este servidor para evitar la corrupción silenciosa de datos. La RAM DDR5 sería ideal, pero con la actual escasez de memoria me conformaré con DDR4.
Espacio en el chasis para al menos 8 HDD, idealmente 10 o 12 para tener margen de crecimiento si es necesario.
Soporte para doble almacenamiento NVMe, o como mínimo SSD.
Al menos una tarjeta de red SFP+ de 10 GbE.
Fuentes de alimentación dobles redundantes.
Gestión remota compatible con IPMI.

La serie Dell PowerEdge tiene una amplia gama de modelos y son fáciles de encontrar reacondicionados, así que son mi punto de partida:

Basados en Intel
- R730: Antiguo pero muy común y barato. Doble zócalo para Intel Xeon, hasta 3 TB de DDR4, 10 GbE a través de una NDC (Network Daughter Card) opcional, sin NVMe, gestión por iDRAC (todos los PowerEdge).
- R740 / R750: Generaciones más nuevas con CPUs más eficientes, más núcleos, NVMe, mejor PCIe (Gen 3/4 según el modelo), mejor iDRAC...
Basados en AMD
- R7415: AMD EPYC de un solo zócalo (1ª generación); excelente densidad de núcleos y ancho de banda de memoria con un menor consumo y coste que los componentes equivalentes de Intel, y diseñados como plataformas de un solo zócalo.
- R7515: AMD EPYC de 2ª y 3ª generación de un solo zócalo, hasta 64 núcleos.
- R7525: Como el R7515 pero con doble zócalo. No es un factor decisivo porque Proxmox solo cobra por zócalo de CPU en uso, por lo que puede ser una opción si el precio es justo.

Las plataformas AMD EPYC de un solo zócalo parecen particularmente atractivas para Proxmox porque:

Ofrecen un mayor número de núcleos que Intel y más ancho de banda de memoria en un solo socket, evitando sobrecostes en la licencia.
Las plataformas EPYC son conocidas por su gran rendimiento en virtualización y su alta densidad de E/S.

Dell PowerEdge R7515

Un Dell PowerEdge R7415 o R7515 parece la mejor opción, pero lo compararé con ofertas similares de otros proveedores:

Supermicro AS-2014S-TR: muy similar, pero tiene más líneas PCIe y más bahías de disco con espacio para 12 HDD, por lo que permitiría la expansión del NAS si fuera necesario.
HPE ProLiant DL385 Gen10 Plus: Doble socket; hasta 28 unidades de disco. Excesivo.
Lenovo ThinkSystem SR665: Admite CPUs AMD EPYC de un solo socket con el sufijo "P". Según se informa, son difíciles de encontrar reacondicionados, y los de un solo socket aún más, por lo que no es mi primera opción.

Una cosa que me hace reacio a elegir HPE es que no ofrecen descargas gratuitas de actualizaciones de BIOS o firmware sin un contrato de soporte, que es prohibitivamente caro para un usuario doméstico. Ya me pasó con mi actual HPE Microserver Gen10, así que probablemente me decante por Dell o Supermicro para el próximo, ya que tienen descargas gratuitas sin contrato.

Mi elección final dependerá de la disponibilidad local y el precio de las unidades reacondicionadas, pero espero conseguir uno de esos fantásticos Dell PowerEdge con un AMD EPYC.

Redundancia y fiabilidad

El servidor Proxmox se trata como el nodo de infraestructura principal, no es un juguete. Aunque mi casa inteligente está diseñada para que siga funcionando incluso si Home Assistant se cae, dado que todos mis servicios personales se ejecutarán en este hardware, es de suma importancia que se mantenga activo y en buen estado.

Con esto en mente, estos son los pasos que tomaré para garantizar la disponibilidad del servidor de aplicaciones:

Fuentes de alimentación dobles: Conectadas a enchufes separados, para que un fallo en una sola fuente de alimentación o en un circuito eléctrico no tumbe el servidor.
SAI: Conectado al menos a un SAI, para energía de emergencia y apagado controlado. Más detalles en la sección Electricidad y resiliencia más abajo.
Grupo de arranque / VMs: 2 unidades NVMe en un grupo ZFS espejado (coloquialmente llamado "RAID1 en ZFS"). Esto proporciona redundancia para el host de Proxmox, los servicios y la configuración, de modo que si una unidad falla, el sistema seguirá funcionando (y la unidad defectuosa podría intercambiarse en caliente por una nueva y ZFS reconstruiría el grupo automáticamente).
Puertos de red dobles: Usar al menos dos tarjetas de red: una para gestión; otra para el tráfico de las VMs y el almacenamiento. Podría también agregar enlaces de red para tener conexiones redundantes, lo que significaría 2 para gestión y/o 2 para tráfico.
Gestión remota: IPMI, iDRAC, iLO o equivalente para permitir la gestión fuera de banda, el acceso a la BIOS y el control remoto de la alimentación.
Consola física para acceso de emergencia: tendré una consola barata (monitor y teclado) a mano para conectarme directamente al servidor si fuese necesario.

4. Almacenamiento

Tengo grandes necesidades de almacenamiento, así que desde el principio planteo montar un buen NAS, con velocidad, redundancia y fiabilidad.

¿Por qué no Synology?

Inicialmente consideré un NAS de Synology. En particular, el RS1221+ parecía ser exactamente lo que estaba buscando.

Synology RS1221+

Los productos de Synology son populares por una buena razón: son fáciles de gestionar y tienen un ecosistema muy rico. Sin embargo, sus recientes políticas y decisiones empresariales los han hecho menos atractivos, y para mí en particular son factores decisivos:

Una postura cada vez más restrictiva sobre los discos de otras marcas, con modelos que:
- Advierten, se quejan o degradan la experiencia de usuario cuando se usan discos que no son de Synology.
- En algunos casos, limitan el soporte o la funcionalidad según el proveedor del disco.
Cambios progresivos para dificultar el cambiar de proveedor, algo que va en contra de la filosofía abierta y basada en estándares de este homelab.

Dadas estas preocupaciones, tomé la decisión de evitar Synology y en su lugar usar plataformas abiertas y hardware genérico sobre el que tendría control total.

TrueNAS

TrueNAS es probablemente el sistema operativo de código abierto más conocido y especializado para NAS. Es robusto, que es la característica número uno que uno quiere para su almacenamiento.

Solo funciona con ZFS, que es lo que quiero usar para mi capa de datos, y su interfaz de usuario simplifica la gestión, la monitorización y las alertas. Por mucho que me guste la tecnología y meterme en fregaos, ya voy a tener bastante trabajo montándolo todo, así que agradezco todo lo que me facilite la vida sin comprometer los principios.

Consideré openmediavault (OMV) porque es un competidor directo, también de código abierto y basado en Linux. Lo descarté porque es más flexible (por ejemplo ZFS es opcional y no de serie), y está pensado para gente que busca ejecutar aplicaciones en su NAS, pero yo no lo necesito porque tendré un servidor de aplicaciones separado para ese propósito.

Así que empecé a considerar montar un servidor separado para TrueNAS. Dadas mis necesidades de almacenamiento me haría falta otra máquina potente (al menos 64 GB de RAM, y otra tarjeta de red de 10 GbE). Como todo en la vida, tiene sus pros y sus contras:

Pros:
- Clara separación de responsabilidades: almacenamiento en una máquina, computación en otra.
- Buen aislamiento de fallos: si el nodo de computación falla, el almacenamiento sigue funcionando.
Contras:
- Mayor coste inicial: otro chasis de servidor, más fuentes de alimentación, más tarjetas de red.
- Mayor consumo eléctrico en el día a día.
- Para un homelab familiar parece excesivo.

Había dos alternativas sobre las que había leído:

Proxmox tiene soporte para ZFS, por lo que podría hacer también de NAS.
- Configuración manual de ZFS, una cosa más que aprender.
- Sin monitorización ni alertas de serie.
- Acceso directo al hardware, sin pérdida de rendimiento por virtualización.
Ejecutar una máquina virtual de TrueNAS dentro de Proxmox:
- TrueNAS se ejecuta como una máquina virtual con acceso directo al conjunto de discos duros, pasando directamente el HBA en PCIe al que estarán conectados.
- Los discos duros están dedicados a TrueNAS; Proxmox no los toca.
- ZFS se utiliza en la capa de TrueNAS para redundancia, instantáneas y replicación.
- La pérdida de rendimiento es <5% según comentarios de usuarios.
- TrueNAS disfrutará de la alta disponibilidad del servidor de aplicaciones (doble fuente de alimentación, doble NVMe, redes redundantes...)

Tras analizar las opciones con sus pros y sus contras, mi decisión es optar por TrueNAS como máquina virtual, me parece el mejor compromiso en cuanto a mantenibilidad, reducción del número de equipos, coste inicial, consumo eléctrico y fiabilidad del sistema. Dejar que Proxmox gestione los discos duros debería funcionar, pero perdería más tiempo y me quedaría sin la monitorización y las alertas integradas de TrueNAS.

Diseño del almacenamiento

A grandes rasgos:

IPFire (rápido):
- Registros de red (accesos al cortafuegos, informes del IDS, conexiones VPN, etc.).
Pool de Proxmox (muy rápido, redundante):
- Dos SSD NVMe en espejo ZFS para:
  - El host de Proxmox.
  - Máquinas virtuales y contenedores.
  - Configuración, bases de datos y metadatos.
- El sistema seguirá funcionando si falla un disco.
Pool de TrueNAS (lento, redundante):
- Múltiples discos duros en un pool ZFS.
- Inicialmente planeo 8 discos duros en RAIDZ2, idealmente con espacio para ampliar hasta 12.
- Tolerancia al fallo de hasta 2 discos simultáneamente.
- Almacena:
  - Las fotografías de Immich.
  - Los vídeos de Jellyfin.
  - La música de Music Assistant.
  - Los datos de Nextcloud.
  - Los documentos de Paperless.
  - Las grabaciones de las cámaras.
  - Las copias de seguridad de Proxmox.
Instantáneas y replicación:
- TrueNAS tomará instantáneas periódicas de los datos.
- Las instantáneas de datos críticos (Nextcloud, Immich, Paperless, algunas grabaciones de Frigate) se replicarán a una copia de seguridad remota (fuera de casa).

Esta combinación proporciona tanto redundancia local como copias de seguridad externas, lo cual es esencial: RAID/ZFS no es una copia de seguridad.

5. Cámaras y timbre

Las cámaras son una parte integral de este homelab, pero también una importante preocupación de seguridad y privacidad. Quiero tener cámaras tanto fuera como dentro de la casa, pero tengo que asegurarme por completo de que nadie esté espiando a través de ellas. También quiero tener un videotimbre que suene en mi smartphone aunque esté fuera de casa, pero tiene que funcionar sin conexión a la nube.

Primero haré que un instalador pase cables Ethernet por las paredes para las cámaras, de modo que estarán conectadas y alimentadas a través de PoE. Hay una amplia gama de cámaras y timbres PoE disponibles.

Plan inicial: ¿UniFi o Reolink?

Al principio dudaba si optar por cámaras UniFi, porque son de buena calidad (aunque caras), su software y aplicaciones son de lo mejor y ya estoy planeando entrar en su ecosistema con el switch y los puntos de acceso. Sin embargo, Ubiquiti ha intentado en el pasado obligar a usar una cuenta en su nube para UniFi Protect, así que no puedo confiar en que sus sistemas sigan funcionando de forma exclusivamente local, que es uno de mis objetivos declarados.

Habiendo descartado las cámaras UniFi, mi otra opción era Reolink por su buena relación calidad-precio y su perfecta integración con Home Assistant. El Reolink RLN16-410 es un NVR con 16 puertos PoE, por lo que las cámaras se conectarían y grabarían directamente en él. Eso simplificaría la configuración y se integraría con Home Assistant.

Sin embargo, después de investigar un poco, acabé descubriendo que Reolink no tiene soporte para IPv6 en absoluto, y no hay planes para añadirlo. La falta total de soporte para IPv6 es especialmente problemática en una red donde IPv6 es un ciudadano de primera clase. Con el tiempo, los servicios y los proveedores de internet dependerán más de IPv6, y mantener un ecosistema de cámaras solo con IPv4 crea fricciones y deuda técnica innecesarias. Sin ningún tipo de promesa de que IPv6 será soportado en el futuro, me arriesgaría a tener que reemplazar todas las cámaras y el NVR en algún momento, así que volví a buscar alternativas.

Frigate y cámaras Dahua

Mi solución final es dejar de depender de sistemas cerrados y en su lugar tener el excelente Frigate NVR gestionando las cámaras directamente. Frigate se ejecutará como una máquina virtual en el servidor Proxmox.

Buscando un fabricante de cámaras que respete los estándares y tenga soporte para IPv6, encontré Dahua:

Soporte de estándares:
- ONVIF para descubrimiento y control básico.
- RTSP para los flujos de vídeo y audio.
- Soporte de IPv6.
Capacidades de audio bidireccional que respetan los estándares.
Un amplio ecosistema y documentación de la comunidad de self-hosting.

Instalaré:

12 cámaras Dahua, una mezcla de interiores y exteriores.
1 videoportero Dahua con audio bidireccional.

Todas las cámaras y el timbre estarán conectados mediante cableado Cat6a con PoE, asegurando una buena señal y haciendo que sean más difíciles de manipular e interferir.

Frigate almacenará las grabaciones en TrueNAS a través de NFS o SMB, por lo que se beneficiarán automáticamente de la redundancia de sus discos duros, las instantáneas de ZFS y las rutinas de copia de seguridad.

Diseño de red para las cámaras

Todas las cámaras se conectarán a un switch Ethernet dedicado en el rack de capa 2 con PoE. Este switch se conectará a un único puerto del switch UniFi, de esa manera éste podrá etiquetar todas las cámaras en una VLAN dedicada:

Recibirán direcciones solo en la VLAN de cámaras (tanto IPv4 como IPv6).
El cortafuegos IPFire bloqueará cualquier salida a Internet.
Solo se podrá acceder a ellas desde:
- Frigate (para la ingesta de vídeo y la comunicación bidireccional con el videoportero).
- Un conjunto muy pequeño de sistemas de administración (para configuración).

La principal desventaja de este enfoque es que el switch secundario solo podrá usarse para conectar las cámaras, porque será el router UniFi el que gestione la VLAN, pero debería ser lo suficientemente barato como para que tener algunos puertos sin usar no sea un problema.

Detección de objetos

Frigate NVR tiene detección de objetos integrada:

Frigate se ejecuta como una máquina virtual en Proxmox.
Recibe los flujos RTSP de las cámaras Dahua y el videoportero.
Realiza detección de movimiento y de objetos (personas, coches, etc.).
Gestiona la grabación basada en eventos, las instantáneas y las políticas de retención.

Para una detección de objetos eficiente, Frigate soporta aceleración hardware:

Se conectará un Coral TPU por USB o PCIe al servidor Proxmox.
Proxmox pasará el dispositivo a la máquina virtual de Frigate.
Como dispositivo de hardware especializado, el TPU tiene un bajo consumo de energía pero es capaz de procesar múltiples flujos de vídeo en tiempo real.
Es mucho más eficiente y rentable que usar una tarjeta gráfica para un despliegue de esta escala.

Videoportero

El videoportero puede verse como una cámara normal, pero además quiero poder hablar con quien llame a la puerta. Frigate puede gestionar el audio bidireccional con el timbre Dahua, permitiendo una comunicación exclusivamente local y que preserva la privacidad, sin ninguna nube del fabricante.

Recuerda que todas las cámaras solo serán accesibles a través de la red local, pero cuando esté fuera mis dispositivos se conectarán a través de la VPN de Wireguard y operarían como si estuvieran en casa.

Cuando alguien llame al timbre se activará un evento en Home Assistant, y ahí podré realizar todo tipo de acciones, desde enviar una notificación a nuestros teléfonos, hacer sonar un timbre en casa si estamos presentes, reproducir un mensaje grabado o incluso hacer que una IA converse con el visitante.

6. Electricidad y resiliencia

La planificación de la alimentación eléctrica tiene dos partes separadas:

Reducir el consumo de energía, tanto en el día a día normal como en caso de emergencia (p. ej. en un apagón).
Asegurar los datos y la degradación gradual de los servicios en caso de pérdida de energía.

Sobre el consumo de energía

La casa tendrá una instalación solar completa:

Un montón de paneles solares que deberían cubrir las necesidades de la casa la mayoría de los días del año.
Suficientes baterías para cubrir el consumo de la casa la mayoría de las noches del año.
La red eléctrica probablemente solo será necesaria en días nublados de invierno o días de consumo excepcional. No planeo ser completamente independiente de la red eléctrica.
Un circuito de emergencia permitirá que las baterías y los paneles proporcionen electricidad en caso de un apagón de la red.

Con este sistema instalado, el rack debería estar correctamente alimentado en la mayoría de situaciones. Sin embargo, me puedo imaginar algunos casos en los que podría quedarse corto:

Varios días nublados en invierno podrían agotar las baterías por completo. No sabré el rendimiento con seguridad hasta que nos mudemos y empiece a recopilar estadísticas. Esto significa que no puedo depender solo de las baterías solares para alimentar el rack.
Un apagón prolongado de la red (como el de 2025) podría ser problemático, especialmente en invierno.

Como protección contra estos casos extremos, mi plan es instalar un SAI en el rack y programar los servicios para esa eventualidad.

Emergencia de alimentación: SAI y estrategia de apagado

Los componentes críticos estarán conectados a un SAI (Sistema de Alimentación Ininterrumpida):

El router IPFire.
El switch principal UniFi.
El switch PoE de las cámaras.
El servidor Proxmox.

Tengo dos objetivos:

Mantener la red + cámaras + servicios principales funcionando el mayor tiempo posible durante un corte de luz.
Asegurar que el servidor Proxmox se apague limpiamente antes de que la batería del SAI se agote, para mantener los datos a salvo.

El flujo de apagado sería algo así:

El SAI se comunica por USB o SNMP con un agente de monitorización (ya sea en Proxmox o en un pequeño dispositivo auxiliar).
Al activarse la batería del SAI (y lo mismo si hay un apagón de la red y el sistema depende de las baterías solares) se activa un modo de ahorro de energía en todos los sistemas y se me notifica.
Al alcanzar un umbral de batería baja:
- Proxmox inicia el apagado ordenado de las VM no críticas por orden de prioridad (p. ej., Jellyfin, Music Assistant, Immich y Nextcloud primero).
Al alcanzar un umbral de batería crítico:
- Proxmox apaga todas las VM para evitar la pérdida de datos.
- El host de Proxmox se apaga.
La red y las cámaras permanecen activas mientras el SAI pueda mantenerlas.

Esto protege la integridad de los datos mientras se mantiene cierto nivel de vigilancia y capacidad de resolución de problemas remota.

7. Copias de seguridad y recuperación

La redundancia no es una copia de seguridad. Tiene que haber una copia externa de los datos críticos en caso catástrofe en la casa:

Copias de seguridad regulares de las VM de Proxmox (configuración + imágenes de disco) al NAS.
Replicación de las copias de seguridad de Proxmox a una ubicación externa.
Copia de seguridad de los conjuntos de datos críticos del NAS a la ubicación externa:
- Colección de fotos (Immich), con la base de datos de metadatos.
- Archivos y datos de Nextcloud (calendario, contactos...), y su base de datos.
- Documentos de Paperless y su base de datos.
- Clips de eventos de Frigate (al menos metadatos y grabaciones críticas, p. ej., detecciones de objetos o alertas).

Las pruebas de restauración periódicas formarán parte del modelo operativo: una copia de seguridad solo es tan buena como la última prueba de restauración exitosa. El plan es probar la restauración de al menos una VM y un conjunto de datos periódicamente para asegurar que las herramientas y los procedimientos realmente funcionan.

8. Operaciones, monitorización y prácticas de seguridad

La facilidad de mantenimiento es una preocupación clave para mis sistemas. Disfruto trasteando con todo esto, es un hobby, pero una vez todo esté montado y configurado mi expectativa es que funcione sin problemas durante meses. Esa es la experiencia con mi homelab actual, y lo que busco con el nuevo.

Las prácticas operativas que planeo para mantener el sistema:

Monitorización:
- Comprobaciones básicas de disponibilidad para los servicios principales, por ejemplo con Uptime Kuma, con notificaciones en tiempo real.
- Monitorización de recursos de CPU/RAM/disco/red, con alertas para estar al tanto de posibles cuellos de botella.
- Alertas de SMART y de scrub de ZFS para el almacenamiento.
- Alertas de intrusión de IPFire.
Estrategia de actualización:
- Solo versiones estables.
- Tomar instantáneas de Proxmox y de las VM antes de actualizaciones críticas.
- Actualizar primero los servicios menos críticos, luego los componentes principales.
Seguridad:
- Cortafuegos con política de denegación por defecto.
- VLANs para IoT y cámaras sin salida a Internet.
- El menor número posible de servicios expuestos a Internet, y esos con mínimos permisos y acceso a datos.
- Solo VPN para el acceso remoto a Home Assistant, Frigate y cualquier otro servicio de la casa que no esté expuesto a Internet.
- Mínima superficie de ataque en IPFire y Proxmox:
  - Solo puertos necesarios abiertos.
  - Administración solo a través de dispositivos de confianza (ordenadores de sobremesa y portátiles).
  - Claves y contraseñas robustas.
  - MFA (autenticación de múltiples factores) donde sea compatible.
  - Software actualizado.

9. Próximos pasos

Este artículo recoge el diseño objetivo al que he llegado después de meses de investigación. La implementación se llevará a cabo por etapas, que sin duda acabarán solapándose:

Adquirir el servidor para el router/cortafuegos, instalar IPFire y comenzar la configuración básica de enrutamiento/cortafuegos.
Adquirir el servidor de aplicaciones e instalar Proxmox VE.
Adquirir e instalar el rack, los paneles de parcheo, los switches una vez que la sala de servidores dedicada de la casa esté lista.
Instalar los servidores y conectarlo todo; conectar todos los cables de red; conectar los dispositivos al SAI para la alimentación; arrancar los servidores.
Adquirir e instalar los discos duros en el servidor de aplicaciones; configurar la VM de TrueNAS en Proxmox.
Configurar la monitorización, el registro de eventos y las alertas.
Poner en marcha Home Assistant, integrar los dispositivos inteligentes principales y empezar a definir automatizaciones.
Desplegar Frigate e integrar todas las cámaras Dahua y el timbre.
Desplegar Nextcloud, Immich, Jellyfin, Music Assistant, Paperless, apuntándolos al almacenamiento de TrueNAS.
Servicios de apoyo para monitorización, registro de eventos, alertas, etc.
Adquirir y configurar el SAI.

Cada uno de estos pasos generará su propio conjunto de notas, fragmentos de configuración y reflexiones del tipo "ojalá hubiera sabido esto antes". Por eso este artículo está etiquetado como "Parte 1", porque tengo la intención de seguir documentando cómo este homelab evoluciona del diseño a la realidad.

Suscríbete para estar al tanto de los nuevos artículos.

¿Tienes alguna idea, sugerencia o comentario? ¡Déjame un comentario abajo!

Respaldo automático periódico de los paquetes instalados en el SO

2025-12-08T00:00:00+00:00

Hace un tiempo me pasé a yadm para gestionar mis dotfiles. Una de las características que más me gustan es su soporte para el arranque (bootstrap). He estado añadiendo operaciones de configuración idempotentes.

Mi última incorporación es un script que crea archivos de copia de seguridad con todos los paquetes instalados en el sistema operativo. En caso de desastre, si tengo que reinstalar el sistema operativo, solo tengo que pasarle al gestor de paquetes la última lista respaldada para ese host. Para la copia de seguridad de los datos estoy trabajando en una configuración aparte, ese será tema para un futuro artículo.

En cuanto al script, es sencillo y está adaptado a mis sistemas. Solo es compatible con APT (uso Debian en mis servidores sin interfaz gráfica) y pacman (uso Arch Linux en mi ordenador de sobremesa), pero añadir DNF u otros gestores de paquetes debería ser bastante fácil. Lo escribí en fish shell, porque ahora es mi shell preferida.

Puedes ver el commit en mis dotfiles para ver todos los cambios, pero los reproduciré a continuación tal y como estaban en el momento de escribir este artículo.

El script principal lo he puesto en ~/.local/bin/backup_installed_packages_list.fish:

#!/usr/bin/env fish

function get_hostname
    if type -q hostname
        hostname
    else if type -q hostnamectl
        hostnamectl --static
    else if test -f /etc/hostname
        read -l host_from_file < /etc/hostname
        echo $host_from_file | string trim
    else
        echo "Error: cannot reliably get hostname" >&2
        exit 2
    end
end

set current_hostname (get_hostname)
set current_date (date +%Y-%m-%d)
set backup_dir "$HOME/Backups/$current_hostname/packages"
set temp_file (mktemp)

function save_if_changed -a input_file -a suffix
    set -l target_file "$backup_dir/$current_date$suffix.txt"

    # regex matches YYYY-MM-DD followed optionally by suffix, ending in .txt
    set -l pattern
    if test -z "$suffix"
        set pattern '^\d{4}-\d{2}-\d{2}\.txt$'
    else
        set pattern "^\d{4}-\d{2}-\d{2}$suffix\.txt\$"
    end

    # find the most recent backup file that matches the specific pattern
    set -l latest_backup_name (ls -1 $backup_dir 2>/dev/null | string match -r $pattern | sort | tail -n 1)

    if test -n "$latest_backup_name"
        set -l latest_backup_path "$backup_dir/$latest_backup_name"

        if cmp -s $input_file $latest_backup_path
            echo "No changes in package list compared to $latest_backup_path. Skipping."
            rm $input_file
            return
        end
    end

    # if we reach here, either no backup exists or content is different
    mv $input_file $target_file
    echo "Installed packages backup saved: $target_file"
    notify-send \
        --urgency=normal \
        --wait \
        --icon=backup \
        "New backup of installed OS packages: $target_file"
end

mkdir -p $backup_dir

if type -q apt
    # https://www.debian.org/doc/manuals/debian-reference/ch10.en.html#_backup_and_recovery_policy
    dpkg --get-selections > $temp_file
    save_if_changed $temp_file ""
else if type -q pacman
    # https://wiki.archlinux.org/title/Migrate_installation_to_new_hardware#List_of_installed_packages
    pacman -Qqen > $temp_file
    save_if_changed $temp_file ""
    pacman -Qqem > $temp_file
    save_if_changed $temp_file "_aur"
else
    echo "Error: Neither apt nor pacman found." >&2
    rm $temp_file
    exit 1
end

Creé la función de ayuda get_hostname porque mi instalación de Arch Linux no tenía disponible el comando hostname, solo hostnamectl.

notify-send es muy útil para recibir notificaciones de escritorio, lo he estado usando con frecuencia en mis nuevos scripts, sobre todo en los que se ejecutan en segundo plano como este. Ten en cuenta que requiere tener instalado libnotify (libnotify-bin en instalaciones basadas en Debian). Yo lo instalo como un paquete común en mi configuración de arranque de yadm.

Luego defino las unidades de servicio y temporizador de systemd, en ~/.config/systemd/user/backup-installed-packages.service y ~/.config/systemd/user/backup-installed-packages.timer:

[Unit]
Description=Backup list of installed OS packages
After=graphical-session.target

[Service]
Type=oneshot
ExecStart=%h/.local/bin/backup_installed_packages_list.fish
StandardOutput=journal
StandardError=journal

[Unit]
Description=Timer to backup list of installed OS packages

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Y después activa el temporizador:

$ systemctl --user daemon-reload
$ systemctl --user enable --now backup-installed-packages.timer

Activo el temporizador de systemd en mi archivo de arranque de yadm.

Educación responsable en informática

2025-11-09T00:00:00+00:00

Mi hija mayor va a cumplir pronto 7 años y le he prometido un regalo: su primer ordenador. Secretamente espero que desarrolle un interés por la informática similar al mío. No porque quiera reproducir mi infancia en ella (aunque, por supuesto, me gustaría compartir algunos de mis pasatiempos y pasiones, como cualquier padre), sino porque creo que es importante aprender cómo funcionan las computadoras y el software: eso es la alfabetización digital.

Piensa en cuán digitales son nuestras vidas hoy en día. El gobierno, la banca, las compras, los juegos, las relaciones sociales, el trabajo, las películas, los programas, los videos, la música, los ligues... todo sucede cada vez más en la red. La privacidad digital puede ser tan importante como la privacidad física, y deberías cuidarla, pero eso es difícil si no entiendes cómo funcionan los sistemas o qué alternativas existen. Además, existen amenazas en línea como estafas, phishing, virus, troyanos, malware, adware, spyware, ransomware, vulnerabilidades de seguridad y rootkits. También está el robo de identidad, la ingeniería social, las filtraciones de datos y la necesidad de herramientas como gestores de contraseñas, cortafuegos y cifrado.

Cuando yo era joven, los ordenadores eran el futuro, pero para mis hijos son el presente. ¿Cómo será su futuro? Mi bola de cristal está en el taller, pero identifico algunas tecnologías clave que probablemente darán nueva forma a nuestras sociedades:

La IA en sus diferentes formas.
La robótica.
Las criptomonedas.
La impresión 3D.
La Realidad Aumentada y la Realidad Virtual.
La energía solar/eólica, la autosuficiencia energética.

Creo que, como padres, tenemos que preparar a nuestros hijos para el mundo en el que viven y probablemente vivirán, no para el mundo en el que crecimos nosotros. Por eso investigaré, planificaré y desarrollaré formas responsables de exponer a mis hijos a estas y otras tecnologías. Considero que la informática es la base de todo lo demás, al igual que aprender matemáticas es importante para muchas otras disciplinas, por lo que es mi primer paso en este viaje.

Un poco de historia personal

Cuando tenía 4 años (casi 5), pedí a los Reyes Magos una consola Nintendo NES, porque esos videojuegos me parecían chulísimos. Sin embargo, los Reyes Magos tenían otros planes para mí y, en su lugar, me trajeron mi primer ordenador, un ZX Sinclair Spectrum+. Al principio me sentí un poco decepcionado cuando abrí mi regalo y vi que no era la consola que había pedido, sino un bloque negro con un teclado de teclas cuadradas. Mi decepción se disipó rápidamente y se convirtió en éxtasis en cuanto mi padre lo conectó al televisor y se cargó el primer juego. Me quedé enganchado.

Fidel jugando con su ZX Spectrum+

Jugué a todos los juegos que podía conseguir. Todavía puedo oír el sonido de los juegos cargándose desde el reproductor de casetes. Algunos de mis juegos favoritos de aquella época eran: Manic Miner, Jet Pac, Sacred Armor of Antiriad, Pipe Mania, Gaunglet, Arkanoid, Chuckie Egg y Thanathos, por nombrar algunos. También fue una época dorada para los videojuegos españoles, empresas como Opera Soft, Topo Soft y Dinamic crearon joyas que fueron muy populares en España y en el extranjero. Recuerdo haber jugado a La Abadía del Crimen, Abu Simbel Profanation y Fernando Martín Basket Master, entre otros. Estos juegos eran bien difíciles, lejos de la dopamina fácil de los juegos móviles modernos o de los que pagas para ganar. Mejoraron mis reflejos y mi concentración, me iniciaron con el inglés y me enseñaron a ser perseverante y no rendirme.

Pero al final los videojuegos solo fueron una puerta de entrada, y el verdadero destino que daría forma a mi vida fue la programación. Mi padre siempre ha sido un amante de la ciencia ficción. Había leído tantas novelas de ciencia ficción que sabía que los ordenadores iban a ser muy importantes en el futuro. Se había comprado un par de libros para aprender BASIC, el lenguaje de programación compatible con el ZX Spectrum (aparte del ensamblador, por supuesto), junto con el ordenador. Tenía pensado aprender él, pero en cuanto le vi teclear, me interesé, me enseñó cómo hacerlo y mi curiosidad hizo el resto. Intenté copiar los programas de ejemplo, algunos de los cuales ocupaban muchas páginas, y fue toda una revelación ver que, de alguna manera, ese texto especial le decía al ordenador qué tenía que hacer. Luego intenté hacer algunas modificaciones y me maravilló cómo cambiaba el comportamiento cuando ajustaba esta o aquella variable. No escribí ningún programa complicado (ten en cuenta que sólo tenía entre 5 y 8 años), pero la semilla ya había germinado.

Unos años más tarde, cuando quedó claro que me gustaba lo de los ordenadores, mi padre me compró mi primer PC IBM: un sensacional AMD 286 a 12 MHz con 1 MB de RAM, una unidad de disquete de 5¼ pulgadas y un disco duro de 40 MB (¡en una época en la que la mayoría de los ordenadores domésticos no tenían disco duro!). Esto me abrió un mundo nuevo de posibilidades.
Aprendí MS-DOS, mi primer sistema operativo.
Aprendí sobre AUTOEXEC.BAT y CONFIG.SYS y cómo modificarlos para arañar esos preciosos KB de RAM disponible para ejecutar mis juegos.
Aprendí a usar editores hexadecimales para hackear partidas guardadas y conseguir dinero o recursos extra.
Un día conseguí una copia de Borland Turbo C y un curso de C, y aprendí C de forma autodidacta, y más tarde algo de ensamblador x86. Mi mente de 12 años tuvo que esforzarse un poco con los condicionales, los bucles y, sobre todo, los punteros, pero al final lo entendí todo. Ya podía llamarme programador.

Con estos antecedentes, estudié Ingeniería Informática en la universidad y fui el mejor estudiante del campus. Empecé a usar Linux en 1999 y, desde 2003, lo uso en exclusiva. Conseguí un trabajo como programador en 2007, justo después de graduarme. Y en 2012 conseguí un gran trabajo en Silicon Valley, sin duda el mayor salto en mi carrera.

Fidel en su PC

No quiero terminar este viaje nostálgico sin recordar algunos de los muchos, muchos juegos a los que jugué en mi ordenador. No voy a defender que todos los juegos sean obras de arte, pero creo que son una experiencia más positiva de lo que la mayoría de los adultos piensan. Hoy en día existe la preocupación por el daño que las pantallas pueden causar a los niños, pero según mi experiencia, el problema no son las pantallas en sí, sino lo que se hace con ellas. A menudo me han elogiado por mi buen nivel de inglés, que aprendí principalmente jugando a videojuegos con un diccionario siempre a mano. También aprendí mucho de los juegos. Cuando se es niño, se adquieren conocimientos y habilidades con facilidad, y la mayoría de los juegos ofrecen contenidos educativos, acertijos o mejoran los reflejos y la motricidad fina.

En fin, aquí va una lista inevitablemente incompleta de mis juegos favoritos de la década de los 90:

Los juegos de aventura me enseñaron a resolver acertijos, el humor y a apreciar las narrativas, los guiones y la construcción de mundos. Títulos como Monkey Island 1 y 2, LOOM, Indiana Jones and the Fate of Atlantis, Day of the Tentacle, Sam and Max Hit the Road, Legend of Kyrandia 1 y 2, Simon the Sorcerer, Space Quest 1-6, King's Quest 1-6, Discworld, Full Throttle, The Dig y muchos otros.
Me gustaban mucho los juegos de rol, porque también jugaba a muchos juegos de rol de mesa. La serie Eye of the Beholder, Dungeon Master 2, Ultima Underworld, Fallout 1 y 2, Anvil of Dawn, Wizardry VII, The Elder Scrolls, Dark Sun...
Estrategia: Civilization I y II, Colonization, Sim City, Sim City 2000, Sim Ant, Sim Earth, Master of Orion 1 y 2, Master of Magic, Star Control 2, Dune 2, Stronghold, Warcraft, Starcraft, Age of Empires, UFO Enemy Unknown, X-COM Terror from the Deep, Command & Conquer, Theme Park, Theme Hospital, The Settlers, Heroes of Might & Magic, Mad TV...
Puzzles: Gobliiins 2 y 3, Lemmings 1 y 2, The Incredible Machine, Chip's Challenge, Blockout, Tetris...
Arcade: Pac-Man, Doom 2, Duke Nukem 3D, Golden Axe, Raptor, Tyrian, Arkanoid, Descent 1 y 2, Grand Theft Auto, Pinball Fantasies, Tomb Raider, One Must Fall 2097, Cannon Fodder 1 y 2...
Plataformas: Bubble Bobble, Prince of Persia, Commander Keen, Rick Dangerous 2, Rayman...
Carreras: Lotus Turbo Challenge, WipeOut, Carmageddon, Destruction Derby, IndyCar Racing, Test Drive...
Deportes: Advantage Tennis, Skate or Die, Ski or Die, Summer Games, Winter Games, 4D Sports Boxing, NBA Jam, PC Futbol, FIFA 94-98, Sensible Soccer, NBA Live, NHL Hockey...
Simuladores de vuelo: Microsoft Flight Simulator 4 y 5, F-19 Stealth Fighter, F-15 Strike Eagle II, X-Wing, Tie Fighter, Strike Commander, Privateer 1 y 2, Comanche Maximum Overkill, Secret Weapons of the Luftwaffe...

Echando la vista atrás, creo que la clave fue pasar tiempo delante del ordenador. Si lo haces durante el tiempo suficiente, acabas aprendiendo informática.

Es como esta cita de Terry Crews:

Ve al gimnasio, ni siquiera hagas ejercicio. Solo VE. Porque el hábito de ir al gimnasio es más importante que el ejercicio. Porque no importa lo que hagas. Puedes divertirte, pero mientras te diviertas, seguirás haciéndolo.

Un ordenador adecuado

La herramienta más importante para aprender informática es, por supuesto, un ordenador. Un ordenador adecuado. ¿Qué quiero decir con adecuado? En pocas palabras, es aquel que ofrece al usuario control absoluto:

Instalar un sistema operativo diferente.
Instalar cualquier software que se desee (siempre que sea compatible con el sistema operativo y el hardware, por supuesto).
Reproducir cualquier tipo de archivo multimedia (otra vez, limitado sólo por el hardware).
Programar software sin restricciones, acceder al hardware en su totalidad.

Esta definición descarta todos los teléfonos móviles y tabletas populares, tanto Android como iOS. No por las pantallas táctiles, fíjate que eso no está entre los requisitos. La cuestión es ser amo y señor de tu propio dominio.

iOS ha sido cerrado desde el principio. Sus usuarios intercambian soberanía por comodidad. Puedes instalar las aplicaciones que Apple te permite instalar, y punto. Son dispositivos cómodos, con gran calidad, interfaces pulidas y una buena experiencia de usuario, eso no lo discuto, pero sus usuarios están a merced de Apple. La programación de aplicaciones también está restringida, ya que se necesita un ordenador Mac para programar y una cuenta de desarrollador de Apple ($99 al año) si se quiere distribuir.

Android comenzó como código abierto, con Linux como base, pero desde entonces ha sido corrompido por Google. Prácticamente todos los dispositivos Android son ahora cerrados debido a Google Play Services, un componente del sistema con acceso root (es decir, sin restricciones) que, aunque no forma parte del sistema operativo Android básico, es una dependencia necesaria para que la mayoría de las aplicaciones Android funcionen. Google también quiere obligar a los desarrolladores a registrarse.

Si aún no estás convencido, otros han argumentado mejor que yo por qué es importante tener control sobre nuestros dispositivos informáticos:

Vale, vale, entonces nada de teléfonos móviles ni tabletas. ¿Y entonces qué? ¿Son seguros los ordenadores tradicionales? En general sí, aunque también hay tendencias preocupantes en las que no quiero entrar ahora mismo. Siguen siendo el baluarte de la libertad informática, y es fundamental que lo sigan siendo.

Opciones

Hoy en día hay más opciones que nunca para comprar un ordenador, así que voy a ser muy específico con mi opinión.

Como defensor del software libre, descarté en primer lugar todos los sistemas de código cerrado. Eso significa que nada de Windows ni macOS. Creo que es importante que los niños aprendan los principios que subyacen al software libre y valoren no solo su ética, sino también su practicidad. El uso de software libre nos permite controlar nuestras vidas digitales y, a medida que esas vidas se amplían, ese control se vuelve más importante.

Alguna de las innumerables distribuciones de GNU/Linux servirá (más adelante hablaré de ello). Por tanto mi primer requisito para el hardware es que sea perfectamente compatible con Linux. Esto no es difícil hoy en día, hace 20 años era otro cantar.

Otro punto para mí es que no quiero darles un portátil a mis hijos. Prefiero un ordenador de sobremesa para que no intenten llevárselo a todas partes. Esto hará que el tiempo que pasan frente al ordenador sea más intencional y más fácil de controlar.

Para los ordenadores de sobremesa hay una amplia gama de opciones, desde torres de tamaño completo o reducido hasta mini PC y ordenadores con teclado. Sabía que quería algo pequeño y asequible para empezar, alrededor de 200€.

Mientras investigaba, el formato del ordenador dentro del teclado me hizo sentir nostalgia por mi ZX Spectrum+. Me enamoré al instante de la Raspberry Pi 400, pero deseaba un poco más de potencia. Busqué alternativas similares y encontré la Orange Pi 800, la PineTab2 y la CutiePi, Juno Tab 2 y RaspPad 3, pero ninguna me convenció por diferentes motivos. Entonces Raspberry Pi anunció la Pi 500, que parecía estupenda, salvo por la falta de compatibilidad con NVMe. Decidí esperar y mi paciencia se vio recompensada: recientemente se ha lanzado la Raspberry Pi 500+. ¡Tiene NVMe, 16 GB de RAM y un teclado mecánico!

Raspberry Pi 500+ vs. ZX Spectrum+

Próximos pasos

¡Acabo de conseguir la Raspberry Pi 500+ y estoy muy ilusionado! Estuve tentado de enseñársela a mi hija, pero voy a esperar hasta su cumpleaños. Mientras tanto la voy a preparar para que tenga la mejor primera experiencia posible, con la esperanza de que se produzca la magia.

La Raspberry Pi 500+ viene con Raspbian OS preinstalado, que es una buena opción, pero tengo que evaluarlo para las necesidades de una niña de 7 años:

Sin cuenta root (por ahora).
Sin acceso a Internet y con un filtro muy estricto más adelante.
Software educativo.
Software creativo (pintura, música, vídeo, impresión...)
Entornos de programación.
Videojuegos apropiados para su edad.

Así que mi siguiente paso es investigar distribuciones GNU/Linux aptas para niños. Espero que el requisito de compatibilidad con Raspberry Pi reduzca la búsqueda. No creo que encuentre una distribución que se ajuste perfectamente a mis requisitos, pero solo quiero encontrar una buena configuración básica.

Una de las conclusiones que he sacado de todo esto es que, dado lo entusiasmado que estoy con la idea de educar a los niños en informática, podría ser mi vocación. Estoy seguro de que a otros padres les gustaría enseñar a sus hijos a utilizar el ordenador de forma responsable, pero quizá no tengan el tiempo o los recursos necesarios. Tengo pensado documentar mis esfuerzos y crear recursos para ayudarles y guiarles; este artículo es el primer paso.

¡Mantente atento a las novedades!

Comentarios autoalojados

2025-02-10T00:00:00+00:00

Hace unos días recibí un email de un lector y compañero bloguero, para hacerme saber que seguía mi blog y también me dio un toque de atención sobre mi resolución de Año Nuevo de escribir al menos un artículo cada mes de 2025, y que ya estaba empezando a incumplir.

Me encanta recibir mensajes así, porque si una persona se toma la molestia de enviarme un email seguro que hay otras 99 que lo han pensado pero no lo han hecho. Por eso tras recibir el email decidí dar prioridad a algo que tenía pendiente desde hacía tiempo: añadir comentarios al blog. Y ojo, spoiler: objetivo conseguido.

Quería que fuese algo rápido, por lo que en vez de buscar la opción perfecta iba a optimizar por la que me tomase menos tiempo para implementarla. Eso significaba empezar probando con las opciones ya integradas en el tema Reflex que uso en el blog (heredero de Flex):

Disqus: probablemente la plataforma más popular para comentarios en la web. Es muy cómoda y potente, pero totalmente cerrada y muy seguramente espía y vende nuestros datos.
Isso: software autoalojado al estilo Disqus.

Quienes me conocen pensarán que habría saltado de cabeza para Isso, pero sinceramente mi primer intento fue con Disqus, porque habría sido lo más rápido: abrir una cuenta, poner una clave en las opciones de Pelican y a correr. Bueno pues mi gozo en un pozo porque resulta que ¡Disqus ya no tiene plan gratuito! No me importa pagar por servicios que merezcan la pena, pero no por los comentarios en este humilde blog, así que me olvidé de Disqus y me puse a mirar los detalles de Isso.

Lo que vi de Isso me gustó:

Autoalojado en mi propio dominio.
Programado en Python: instalación sencilla en un virtualenv y me facilitaría colaborar con el proyecto llegado el caso.
SQLite como base de datos, no hace falta un servidor MariaDB o Postgres. Esta fue una de las principales razones por la que elegí Shynet para las analíticas del blog.

Lo único que no me gustó de Isso es que el desarrollo parece algo parado, hay varios PRs que llevan meses esperando merge. Pero no parece ser un proyecto muerto, tengo la esperanza de que siga habiendo nuevas versiones al menos para mantenerlo al día en cuanto a compatibilidad y seguridad.

Por cierto que acabé descubriendo Remark42 como alternativa, después de haber desplegado Isso en mi servidor. Pinta muy bien tanto en funcionalidades como en estado de desarrollo, pero personalmente habría seguido eligiendo Isso por estar ya integrado en el tema de mi blog.

Detalles técnicos

Instalé Isso en el mismo servidor que alberga este blog, un humilde VPS de 2 GB de RAM. No necesité más que seguir la documentación oficial, pero por si alguien tiene interés dejo aquí el proceso:

Instalar isso y un servidor WSGI (yo prefiero gunicorn):

# create new user for isolation
adduser --disabled-password isso

# install isso
su - isso
virtualenv venv
source venv/bin/activate
pip install isso gunicorn

Crear el fichero de configuración de isso en /home/isso/isso.cfg:

# https://isso-comments.de/docs/reference/server-config/

[general]
dbpath = /home/isso/comments.db
host = https://blog.fidelramos.net/
notify = smtp

[server]
listen = http://localhost:8081/

[smtp]
host = localhost
port = 25
security = none
to = <notification_email@example.com>
from = isso@blog.fidelramos.net
timeout = 5

[hash]
salt = Eech7co8Ohloopo9Ol6baimi
algorithm = pbkdf2:10000:6:sha256

[admin]
enabled = true
password = <PASSWORD>

Configurar el proxy inverso con Caddy añadiendo una sección en /etc/caddy/Caddyfile:
```
isso.fidelramos.net {
    reverse_proxy localhost:8081
    encode zstd gzip
}
```

Añadir una unidad de servicio de systemd en /etc/systemd/system/isso.service para ejecutar isso automáticamente. La documentación de Isso incluye otros sistemas de init.

[Unit]
Description=isso commenting system
Documentation=man:isso(8)

# Require the filesystems containing the following directories to be mounted
RequiresMountsFor=/home/isso

ConditionPathIsDirectory=/home/isso
ConditionPathIsReadWrite=/home/isso

ConditionFileIsExecutable=/home/isso/venv/bin/gunicorn

# Start only if there is a conf file
ConditionPathExistsGlob=/home/isso/isso.cfg

[Service]

Environment=ISSO_SETTINGS="/home/isso/isso.cfg"
ExecStart=/home/isso/venv/bin/gunicorn -b localhost:8081 -w 4 --preload -n gunicorn-isso --log-file /home/isso/isso.log isso.run

#UMask=0007
Restart=on-failure
TimeoutSec=1
User=isso

LimitNOFILE=16384
LimitNPROC=16384
LimitLOCKS=16384

# ensures that the service process and all its children can never gain new
# privileges.
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Añadir registros A y/o AAAA a tu DNS (isso.fidelramos.net en mi caso) apuntando al servidor.

Activar e iniciar isso, y recargar caddy:

shell
systemctl enable isso
systemctl start isso
systemctl reload caddy

Ahora puedo acceder a isso.fidelramos.net/admin.

Añadir la configuración necesaria en pelicanconf.py:

ISSO_URL = "//isso.fidelramos.net"
ISSO_OPTIONS = {
    "vote": "false",
}

Desplegar el blog. ¡Ya hay comentarios!

El futuro

Estoy deseoso de ver cuánto uso tendrán los comentarios. Seguro que me animan a escribir más.

Me preocupa el spam, porque Isso no tiene ningún sistema automático de filtrado. No quiero anticiparme a resolver un problema antes de que se manifieste, pero veremos cuánto dura la paz...

¿Llegaste a leer hasta aquí? ¡No puedes irte sin dejar un comentario!

Reemplazando Nginx con Caddy en Docker Compose

2023-11-09T00:00:00+00:00

El servidor principal de mi homelab ejecuta varios servicios, pero el corazón de todo es una configuración de Docker Compose. Varios servicios están expuestos a Internet a través de un servidor web de proxy inverso.

Antes estaba usando tres imágenes de Docker para ejecutar Nginx, dirigir el tráfico a otros servicios y generar certificados Letsencrypt para los dominios necesarios:

nginx con el servidor Nginx real en funcionamiento.
nginx-proxy para generar configuraciones de Nginx.
docker-letsencrypt-nginx-proxy-companion: para automatizar la provisión y renovación de certificados LetsEncrypt.

La parte relevante de la configuración en compose.yml lucía así:

services:
  nginx:
    image: nginx
    labels:
        com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: "true"
        UFW_MANAGED: "true"
    container_name: ${NGINX_WEB:-nginx}
    restart: always
    ports:
      - "${DOCKER_HTTP:-80}:80"
      - "${DOCKER_HTTPS:-443}:443"
    volumes:
      - ${NGINX_FILES_PATH}/conf.d:/etc/nginx/conf.d
      - ${NGINX_FILES_PATH}/vhost.d:/etc/nginx/vhost.d
      - ${NGINX_FILES_PATH}/html:/usr/share/nginx/html
      - ${NGINX_FILES_PATH}/certs:/etc/nginx/certs:ro
      - ${NGINX_FILES_PATH}/htpasswd:/etc/nginx/htpasswd:ro
    logging:
      driver: ${NGINX_WEB_LOG_DRIVER:-json-file}
      options:
        max-size: ${NGINX_WEB_LOG_MAX_SIZE:-4m}
        max-file: ${NGINX_WEB_LOG_MAX_FILE:-10}

  nginx-gen:
    image: nginxproxy/docker-gen
    command: -notify-sighup ${NGINX_WEB:-nginx} -watch -wait 5s:30s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf
    container_name: ${DOCKER_GEN:-nginx-gen}
    restart: always
    volumes:
      - ${NGINX_FILES_PATH}/conf.d:/etc/nginx/conf.d
      - ${NGINX_FILES_PATH}/vhost.d:/etc/nginx/vhost.d
      - ${NGINX_FILES_PATH}/html:/usr/share/nginx/html
      - ${NGINX_FILES_PATH}/certs:/etc/nginx/certs:ro
      - ${NGINX_FILES_PATH}/htpasswd:/etc/nginx/htpasswd:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./nginx.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro
    logging:
      driver: ${NGINX_GEN_LOG_DRIVER:-json-file}
      options:
        max-size: ${NGINX_GEN_LOG_MAX_SIZE:-2m}
        max-file: ${NGINX_GEN_LOG_MAX_FILE:-10}

  nginx-letsencrypt:
    image: nginxproxy/acme-companion
    container_name: ${LETSENCRYPT_CONTAINER:-nginx-letsencrypt}
    restart: always
    volumes:
      - ${NGINX_FILES_PATH}/conf.d:/etc/nginx/conf.d
      - ${NGINX_FILES_PATH}/vhost.d:/etc/nginx/vhost.d
      - ${NGINX_FILES_PATH}/html:/usr/share/nginx/html
      - ${NGINX_FILES_PATH}/certs:/etc/nginx/certs:rw
      - /var/opt/acme.sh:/etc/acme.sh
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      NGINX_DOCKER_GEN_CONTAINER: ${DOCKER_GEN:-nginx-gen}
      NGINX_PROXY_CONTAINER: ${NGINX_WEB:-nginx}
    logging:
      driver: ${NGINX_LETSENCRYPT_LOG_DRIVER:-json-file}
      options:
        max-size: ${NGINX_LETSENCRYPT_LOG_MAX_SIZE:-2m}
        max-file: ${NGINX_LETSENCRYPT_LOG_MAX_FILE:-10}

Para dirigir tráfico a un servicio sólo necesitaba definir las variables de entorno VIRTUAL_HOST y LETSENCRYPT_HOST. Por ejemplo, esta era la configuración de mi servicio de Nextcloud (solo mostraré las partes relevantes):

services:
  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud
    environment:
      VIRTUAL_HOST: ${NEXTCLOUD_HOST}
      LETSENCRYPT_HOST: ${NEXTCLOUD_HOST}
      LETSENCRYPT_EMAIL: ${LETSENCRYPT_EMAIL}

Además de la configuración de servicios en Docker Compose, también necesitaba una plantilla de configuración de Nginx (ese es el nginx.tmpl que puedes ver en la configuración), y otros ficheros con ajustes específicos para algunos servicios (como por ejemplo aumentar el tamaño máximo de las peticiones HTTP para mi instancia de Nextcloud).

Ya había reemplazado el servidor web Nginx que aloja este blog por Caddy, así que quería hacer lo mismo con el servidor casero. Decidí usar caddy-docker-proxy porque era similar a nginx-proxy, por lo que simplificaría la migración. Lo que no me esperaba es cuán más simple se iba a volver.

La configuración anterior fue reemplazada por:

services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:ci-alpine
    restart: unless-stopped
    ports:
      - "${DOCKER_HTTP:-80}:80"
      - "${DOCKER_HTTPS:-443}:443"
    networks:
      - default
      - webproxy
    labels: # Opciones globales
      caddy.email: ${CADDY_EMAIL}
      UFW_MANAGED: "true"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      # este volumen es necesario para mantener los certificados
      # de lo contrario, se emitirán nuevos al reiniciar
      - ${CADDY_FILES_PATH}:/data

Redirigir a un servicio ahora es solo cuestión de agregar algunas etiquetas:

services:
  nextcloud:
    image: nextcloud:latest
    container_name: nextcloud
    labels:
      caddy: ${NEXTCLOUD_HOST}
      caddy.reverse_proxy: "{{upstreams 80}}"
      caddy.request_body.max_size: ${NEXTCLOUD_MAX_UPLOAD}

¡Y listo!

Caddy gestiona automáticamente los certificados TLS, así que no es necesario ningún servicio adicional. No puede ser más fácil.

También pude eliminar los archivos de configuración de Nginx, en su lugar los reemplacé con un par de etiquetas en los contenedores que requerían alguna configuración especial.

Antes de terminar este artículo, quiero destacar lo bien que nginx-proxy y su acme-companion habían estado funcionando durante años con un mantenimiento mínimo. Su estabilidad y compatibilidad hacia atrás fueron increíblemente sólidas, ¡mis felicidades y agradecimientos a su creador!

Analítica web en tu servidor y respetuosa con la privacidad

2022-05-27T00:00:00+00:00

Todo empezó con un anhelo: quería tener algunas analíticas básicas de este blog para saber qué tal va, qué artículos son populares y de dónde viene el tráfico (los referrers). Pero hete aquí mi problema: soy un obseso de la privacidad, me preocupa mucho el rastreo online masivo (sólo echa un vistazo a las extensiones de navegador web que utilizo), así que me negaba en rotundo a utilizar un servicio que recopilase la información de mis visitantes.

Sabía que había sistemas de analítica web de software libre. Conocía Piwik, que lleva muchos años funcionando, pero nunca había tenido el tiempo ni la necesidad de mirarlos en detalle. Hasta ahora.

Ojo que este artículo no presenta en absoluto una lista completa, hay muchísimas más opciones disponibles, recopiladas en esta enorme lista. Cada programa tiene sus pros y sus contras, pero espero que este artículo te ayude a elegir y dar el salto hacia analíticas más respetuosas con la privacidad de los internautas, o al menos a abandonar Google Analytics y elegir una opción en la nube basada en software libre.

Índice de contenidos

Mis requisitos
Matomo (anteriormente Piwik)
Plausible
Shynet
Open Web Analytics (OWA)
Conclusiones y mi elección

Mis requisitos

Mi búsqueda tenía unos parámetros específicos para cada proyecto:

Debe ser software libre y con posibilidad de alojarse en un servidor propio.
Despliegue sencillo, cuantos menos componentes mejor. SQLite si es posible, para no necesitar servidor de BD. A evitar Redis o Memcached. Estaría bien tener opción de despliegue sin Docker.
Uso razonable de recursos. Mis páginas no suelen recibir mucho tráfico, así que pienso reutilizar el servidor virtual de 2 GB de memoria que hospeda este blog.
Tecnología que pueda entender, manipular y colaborar. Yo prefiero proyectos en Python, pero eso ya depende de las capacidades de cada uno.
Ligero y no demasiado intrusivo. Sólo necesito saber qué artículos son vistos y cuándo, además de saber de qué otras páginas vienen los usuarios. No necesito analíticas avanzadas.
Mantenido activamente.

Matomo (anteriormente Piwik)

Página de inicio

GPLv3. Servicio en la nube (SAAS) con opción auto-hospedada gratuita y libre.
Documentación de instalación.
- Necesita un servidor web (Apache, Nginx, etc.)
- Necesita MySQL.
- La configuración de Matomo se realiza en la propia aplicación.
De los requisitos para alojar Matomo:
- <100k páginas/mes: un servidor para aplicación y BD. 2 CPU, 2 GB RAM, 50GB disco SSD.
- ~1M páginas/mes: un servidor para aplicación y BD. 4 CPU, 8 GB RAM, 250GB disco SSD.
- ~10M páginas/mes: dos servidores para aplicación y BD. 8 CPUs, 16 GB RAM, 400GB disco SSD
- ~100M páginas/mes: tres o más servidores para aplicación, BD y balanceador de carga. 16 CPUs, 32 GB RAM, 1 TB disco SSD.
Backend en PHP. Frontend en VueJS y TypeScript. Repositorio código y guía para desarrolladores.
Amplia gama de métricas recopiladas. Dispone de plugin para Wordpress.
Unos 10 commits por semana, múltiples contribuidores.

Plausible

Página de inicio

AGPLv3. Servicio en la nube (SAAS) con opción auto-hospedada gratuita y libre, pero esta última va con retraso en nuevas características (2 nuevas versiones cada año).
Documentación oficial de instalación. En resumen: necesita docker-compose, PostgreSQL y Clickhouse.
De la documentación de requisitos de Plausible:

The server must have a CPU with x86_64 architecture and support for SSE 4.2 instructions. We recommend using a minimum of 4GB of RAM but the requirements will depend on your site traffic.
Backend en Elixir/Phoenix. Frontend en React y Tailwind. Repositorio de código y guía para desarrolladores.
Script de rastreo de menos de 1 KiB. Sin cookies. No pude encontrar una lista concreta de métricas, pero parece menos completo que Matomo u OWA.
Actividad semanal, normalmente condensada en pull requests largos.

Shynet

Página de inicio

Apache License Version 2.0. Sólo permite hospedaje propio.
Despliegue sencillo con Docker o docker-compose, de otra forma sería un despliegue manual indocumentado. Soporta cualquier BD que soporte Django, incluyendo SQLite. Servidor de caché opcional.
Bajo consumo de recursos, en su forma más básica con SQLite sólo un proceso Python ejecutando Django, unos 100 MiB de RAM.
Backend en Python/Django. Usa su propio plugin de TailwindCSS para frontend. Fácil de recrear desde el código fuente usando Docker. Repositorio de código y guía para desarrolladores.
Script de rastreo de menos de 1 KiB. Sin cookies. Rastreo con pixel de 1x1 si javascript está desactivado. Lista bien definida de métricas capturadas, todo bastante básico.
No tiene un fuerte desarrollo de nuevas características, pero las dependencias se mantienen actualizadas y el desarrollador principal responde rápido a los problemas y pull requests (lee las conclusiones para más detalles).

Open Web Analytics (OWA)

Página de inicio

GPLv2. Sólo permite hospedaje propio.
De la documentación de instalación de OWA y los requisitos técnicos:
- Sólo soporta proyectos PHP.
- Sistema de instalación en la propia aplicación.
- Sólo soporta oficialmente Apache 2.x. Nginx supuestamente funciona pero necesita configuración manual sin documentar.
- Necesita MySQL con strict mode desactivado.
Sus requisitos exactos no están claros.
Backend en PHP. Webpack para frontend. Múltiples repositorios: repositorio base, repositorio del plugin de Wordpress, repositorio del SDK para PHP.
Tracking muy detallado, incluyendo mapas de calor y grabación de sesiones Domstream, pero sólo para aplicaciones PHP. Dispone de plugins de integración dedicados para WordPress y MediaWiki.
Activamente mantenido, pero aparentemente por un único desarrollador.

Conclusiones y mi elección

Teniendo en cuenta mi lista de requisitos la elección para este humilde blog estaba clara: Shynet gana de calle, es justo lo que buscaba. Para páginas más grandes tanto Plausible como Matomo parecen ser buenas opciones. Yo diría que el primero tiene mejor tecnología fundacional (se liberó en 2019) pero Matomo lleva más tiempo funcionando (2007), está más curtido y parece recopilar más datos. Plausible tiene una página comparándolo con Matomo. OWA podría ser buena opción para páginas en PHP o Wordpress.

El poder trastear con Shynet, el punto 4 en mi lista de requisitos, me vino bien en cuanto empecé a configurarlo en mi servidor porque el soporte de SQLite estaba roto. Afortunadamente pude arreglarlo y desplegarlo en el servidor en el que estás leyendo este artículo. Por esto es que me encanta el software libre.

Otro problema con el despliegue fue que el servidor no tenía Docker instalado, y quería mantenerlo así, por lo que aproveché la oportunidad para aprender sobre Podman. Me encantó su capacidad para ejecutar contenedores sin usar root (rootless containers), eso mejora muchísimo la seguridad. El único problema que tuve era que necesitaba cambiar los permisos del volumen de datos, porque de otra forma el proceso Django de Shynet no era capaz de escribir la base de datos SQLite porque los ficheros del volumen pertenecían a root dentro del contenedor. Este artículo lo explica muy bien, básicamente sólo hace falta usar podman unshare.

Para terminar, he aquí una captura de pantalla de los datos de Shynet para este blog (¿no es fabuloso poder compartir esto sabiendo que no se vulnera la privacidad de nadie?):

blog.fidelramos.net en mi instancia de Shynet

Extensiones de navegador web que uso

2022-02-23T00:00:00+00:00

Este artículo enumera las extensiones de navegador web que utilizo y por qué. Lo mantendré actualizado de vez en cuando.

Actualmente uso Brave como mi navegador web principal, y es el que recomiendo a todo el mundo. Ofrece una gran experiencia por defecto, con características como un bloqueador de anuncios integrado, integración con Tor incorporada, pestañas verticales y agrupadas, una cartera de criptomonedas decente, soporte para IPFS, videollamadas integradas. La experiencia lista para usar es mejor que las alternativas en mi opinión, especialmente para los usuarios habituales que no saben o no quieren trastear con su software.

Anteriormente usaba Firefox. Aprecio que sea el único navegador importante con su propio motor de renderizado (Gecko) que no está basado en el hegemónico WebKit que es la base de prácticamente todos los demás navegadores web. Como desarrollador web sé lo peligroso que es tener un monocultivo en torno a un único motor de navegador web, que es lo que sufrimos a finales de los 90 y principios de los 2000 con Internet Explorer.

Intento tener cuidado con las extensiones de navegador que instalo, ya que tienen un acceso profundo a los datos del navegador. Esto significa que un complemento malicioso o comprometido puede convertirse rápidamente en una pesadilla si consigue, por ejemplo, robar las credenciales de mi cuenta de correo electrónico (aunque el 2FA debería mitigar ese riesgo). Por esta razón sopeso cuidadosamente la utilidad de los complementos frente a ese riesgo. Los que utilizo suelen ser populares, con miles de usuarios y a menudo seleccionados por los editores.

Sin más dilación, estos son los complementos que estoy usando actualmente en Brave:

KeepassXC-Browser: Uso KeepassXC para almacenar mis contraseñas y secretos, esta es la extensión oficial para navegadores web, con autocompletado de formularios. Funciona bastante bien aunque no tanto como competidores como Lastpass o 1Password, pero no les confiaría mis datos más íntimos a terceros.

En Firefox solía usar estas extensiones:

uBlock Origin: el mejor bloqueador de anuncios que existe (que yo sepa, si conoces alguno mejor por favor házmelo saber). Usa poco procesador y memoria, normalmente ahorra más que consume, dado que las páginas web cargan más rápido sin toda la mierda que suelen incluir (anuncios, rastreadores, etc.). Especialmente en móvil se puede notar mucho. Solía instalar otro puñado de extensiones para mejorar la privacidad (NoScript, ClearURLs, PrivacyBadger, HTTPSEverywhere y DecentralEyes), pero tras leer este artículo en Arkenfox aprendí que son superfluas si se configura bien uBlock Origin. Y déjame decirte una cosa más: mi Firefox vuela después de eliminar esas extensiones.
Firefox Multi-Account Container: Firefox tiene soporte de serie para contenedores, esta extensión es necesaria para gestionarlos. Es oficial del propio equipo de Firefox, así que tiene mi plena confianza. ¿Qué son los contenedores? Son una forma de categorizar pestañas, para aislar la información a la que pueden acceder. Por ejemplo, configuro la web de mi banco para abrirse siempre en el contenedor Banking, de forma que un potencial atacante que consiga ejecutar código que aproveche un agujero de seguridad en otra pestaña no debería tener acceso salvo que también hubiese sido abierta en el mismo contenedor Banking. También uso contenedores para aislar el rastreo cuando inicio sesión en ciertos servicios, por ejemplo tengo un contenedor Google donde inicio sesión en Google, pero en todos los demás contenedores estoy desconectado. Tengo un puñado de contenedores: Gov para páginas del gobierno, Personal para las aplicaciones web alojadas en mis propios servidores, Shopping siempre que compro algo...
Sidebery: un gestor de pestañas para Firefox. Si eres como yo y tienes no ya docenas, sino cientos de pestañas abiertas, esta extensión lo cambia todo. Tener tantas pestañas abiertas se convierte en una ventaja en vez de un inconveniente. Las pestañas se organizan jerárquicamente como un árbol; se pueden agrupar las pestañas de diferentes formas (grupos y paneles); hacer que las pestañas se abran en un panel determinado según el contenedor en el que se abren (mira la extensión Firefox Multi-Account Container que menciono más arriba); descargar de la memoria pestañas o paneles completos. Es configurable hasta el hartazgo, y esto lo dice alguien que es un loco de configurarlo todo al detalle. Sigo descubriendo nuevas características útiles que mejoran mi uso y disfrute del navegador web.
Skip Redirect: detecta redirecciones en ciertas páginas y se las salta, para evitar rastreos innecesarios. Por ejemplo si te fijas al buscar algo en Google, cuando vas a un resultado la dirección es la web destino, sino que apunta a Google, y luego te redirecciona al destino. Esta extensión extrae el destino para evitar que Google (o muchos otros servicios) sepa qué resultados visitas.

Actualizaciones:

2022-11-19: Reemplacé Metamask por Tally Ho; añadí Sidebery.
2023-01-20: Añadí Skip Redirect; eliminé NoScript, ClearURLs, PrivacyBadger, HTTPSEverywhere, DecentralEyes.
2023-04-20: Actualicé Tally Ho a Taho, cambiaron de marca el 21 de febrero de 2023.
2026-03-31: Ahora uso Brave como mi navegador web principal.

Descubrimiento de Nextcloud CardDAV y CalDAV con entradas DNS

2022-02-17T00:00:00+00:00

Tengo una instancia propia de Nextcloud que almacena muchos de mis datos personales, incluyendo mis contactos y mis calendarios. Recientemente tuve the reinstalar DAVx5 en mi teléfono, y me sorprendió que la cuenta de Nextcloud daba error al intentar añadirla.

Los registros de error de DAVx5 mostraban que estaba haciendo peticiones HTTP a las URL /.well-known/caldav y /.well-known/carddav, como describe el RFC 6764. Nextcloud devolvía respuestas correctas HTTP 301 redirigiendo a la dirección real para los servicios DAV de la instancia Nextcloud, pero por alguna razón DAVx5 no estaba procesando las redirecciones correctamente.

Leyendo la documentación de DAVx5 sobre descubrimiento de servicios mencionan que el standard DAV también permite definir entradas DNS de tipo SRV y TXT que apunten a los servicios exactos a ser usados para CardDAV y CalDAV, así que decido probar suerte porque parecía más sencillo que debuggear DAVx5 or ponerme a mirar en la configuración de Nextcloud y/o del servidor web.

Añado estas entradas DNS a fidelramos.net:

_caldavs._tcp 10800 IN SRV 0 1 443 cloud.fidelramos.net.
_caldavs._tcp 10800 IN TXT "path=/remote.php/dav/"
_carddavs._tcp 10800 IN SRV 0 1 443 cloud.fidelramos.net.
_carddavs._tcp 10800 IN TXT "path=/remote.php/dav/"

path lo encuentro simplemente mirando a dónde redirigen /.well-known/caldav y /.well-known/carddav en mi instancia de Nextcloud.

DAVx5 conectó con éxito una vez creadas las entradas DNS, pero tuve que usar fidelramos.net como URL base, en vez de cloud.fidelramos.net como usaba antes.

Desbloqueando en el arranque una partición cifrada con LUKS con una memoria USB

2019-10-13T00:00:00+00:00

El caso de uso que quería resolver era: tengo un servidor sin monitor con un disco duro cifrado por software usando LUKS, y quiero ser capaz de reiniciarlo sin tener que escribir la contraseña en un teclado. La solución que implementé fue crear un fichero con una clave LUKS en una memoria USB, de forma que si se conecta al iniciar el sistema el fichero se usará para desbloquear la partición LUKS en vez de la contraseña.

Antes de empezar quiero mencionar someramente las implicaciones de seguridad de esta solución:

Quienquiera obtenga acceso al dispositivo USB será capaz de descifrar el dispositivo objetivo. Considera los requisitos de seguridad de la memoria USB: guardarla en una caja fuerte, esconderla, llevarla siempre contigo...
Idealmente la memoria USB se usaría exclusivamente para este propósito, dado que si se conecta a otros sistemas estos podrían leer y filtrar la clave de cifrado.
Estamos obviamente reduciendo la seguridad del sistema a cambio de ganar usabilidad. A veces este es el equilibrio que buscamos, otras veces no tanto. Solo tú puedes juzgar el valor de lo que estás protegiendo, las potenciales formas de ataque y qué medidas de seguridad son apropiadas.

Bien, manos a la obra. Asumiremos que tienes una memoria USB ya formateada y montada (p.ej en /mnt) en el ordenador con el dispositivo LUKS que quieres desbloquear en el arranque. El primer paso será crear un fichero con información aleatoria:

# dd if=/dev/urandom of=/mnt/key bs=4096 count=1

A continuación añadimos la clave generada a LUKS, para que pueda ser utilizada para desbloquear la partición raíz:

# cryptsetup luksAddKey /dev/sda3 /mnt/key

/dev/sda3 es un ejemplo, debes mirar cuál es la partición raíz en tu sistema.

El siguiente paso será actualizar /etc/crypttab, que define los volúmenes cifrados que son gestionados por LUKS. Tu fichero crypttab debería tener una entrada similar a esta:

cryptroot UUID=452ac6ac-8bbb-484f-b508-a11a5585e031 none luks

Tenemos que actualizar esta línea para usar el script passdev que viene proporcionado de serie por cryptsetup. passdev se encarga de esperar a que un dispositivo determinado aparezca como disponible, entonces lo monta y lee la clave de un fichero. Es buena idea referirse a la memoria USB utilizando un dispositivo que no vaya a cambiar de forma inesperada. Yo uso /dev/disk/by-label/<LABEL>, que es un enlace simbólico al dispositivo basado en la etiqueta de la partición. Tras actualizar la línea en /etc/crypttab debería lucir así:

cryptroot UUID=452ac6ac-8bbb-484f-b508-a11a5585e031 /dev/disk/by-label/FIDELRAMOS.NET:/key:20 luks,keyscript=/lib/cryptsetup/scripts/passdev

Deja el nombre de mapeado original (cryptroot en este ejemplo) y el mismo UUID, de otra forma se romperá el arranque dado que estos datos se referencian en /etc/fstab. Solo cambia none y añade el keyscript.

El último paso es regenerar la imagen de initramfs para que incluya el script passdev, si no fallará el arranque.

# update-initramfs -k all -u

¡Y ya está! Al reiniciar el sistema debería detectar la memoria USB, montarla automáticamente y usar el fichero clave para desbloquear la partición raíz. Si la memoria USB no se detecta por cualquier razón en 20 segundos debería pasarse a leer la clave por teclado.

blog.fidelramos.net - Software

Aventuras en vibe coding: Venice.ai KDE widget

El problema

Ejecución

Resultado

Lecciones

Tailscale autoalojado, Parte 4: Servicios web sólo en Tailscale

La arquitectura

¿Por qué dos Caddys y no uno solo con una lista de direcciones IP permitidas?

La configuración de Docker Compose

Imagen de Caddy con el complemento DNS de Gandi

Traslado de servicios a Tailscale Caddy

Configuración del DNS

Verificación

Los problemas con los que me topé para que tú no tengas que hacerlo

Compose recurre automáticamente a 0.0.0.0

Los contenedores fallidos dejan zombis

La conexión de 0.0.0.0:80 entra en conflicto con 100.x.y.z:80

caddy-docker-proxy necesita la red del servicio

¿Lo volvería a hacer?

Mejoras futuras: acceso limitado para otras personas

Aventuras en vibe coding: pelican-copy-code

El problema

Ejecución

Resultados

Lecciones

Aventuras en vibe coding

Tailscale autoalojado, Parte 3: Syncthing sobre Tailscale

Objetivos

Por qué hacer esto

Reconfiguración de Syncthing

Acerca de las direcciones de escucha

Configurar pares por dirección de tailnet

Cortafuegos

Router

Verificación

Dificultades encontradas

Sintaxis de la dirección de escucha %tailscale0

Los pares no se encuentran después de deshabilitar el descubrimiento

MagicDNS falla al inicio en un cliente lento

Syncthing usando contenedores

Caché de anuncios de descubrimiento

Siguientes pasos

Cómo aislo mis agentes IA

Configuración de Firejail

Resultados y próximos pasos

Tailscale autoalojado, Parte 2: DNS con bloqueo de publicidad

Objetivos

¿Por qué no usar solo el DNS privado de Android?

Arquitectura

Blocky en Docker Compose

Configuración de Blocky

Verificación desde el host:

Cambios en Headscale

Por qué es mejor que DoT en cada dispositivo

Inconvenientes encontrados

Android "no se puede conectar" con el DNS privado configurado

La resolución de DNS se rompe en el servidor

Los clientes no usan el nuevo DNS

Hay que deshabilitar MagicDNS

Qué sigue

Tailscale autoalojado, Parte 1: Headscale y clientes

Objetivos

¿Por qué no usar simplemente el servicio alojado de Tailscale?

Arquitectura

Requisitos previos

Headscale en Docker Compose

Configuración de Headscale

Registros DNS

Primera ejecución

Creación de un usuario y claves de preautenticación

Tailscale en Linux

Tailscale en Android

Otros clientes

Dificultades encontradas

Clave incorrecta

El dispositivo Android aparece con nombre invalid-... en headscale

Android "No conectado" sin error

El DNS privado de Android interfiere con el arranque de Tailscale

MagicDNS no resuelve en un dispositivo específico

Compose recurre automáticamente a `0.0.0.0`

La conexión de `0.0.0.0:80` entra en conflicto con `100.x.y.z:80`

`caddy-docker-proxy` necesita la red del servicio

Sintaxis de la dirección de escucha `%tailscale0`

El dispositivo Android aparece con nombre `invalid-...` en headscale

`ansible-ssh-masters.sh`