blog.fidelramos.net

Omarchy y el punto óptimo de seguridad

2026-09-01T00:00:00+00:00

Omarchy, la distribución Linux omakase creada por David Heinemeier Hansson (el creador de Ruby on Rails), está ahora mismo en boca de la comunidad del software libre. Algunos la aman, otros la odian.

Yo lo digo claro: me declaro fan de Omarchy. Hay muchas cosas que me encantan a primera vista: el optimismo; la actitud de "sí se puede" (we can fix everything); unir a la gente; volver a hacer divertidos a los ordenadores; distanciarse de la política; enfocarse en el rendimiento... Vamos, si es que hasta me encanta la experiencia por defecto: el gestor de ventanas tiling moderno; el acceder a todo con el teclado; hasta la estética. Yo estoy entre la audiencia a la que va dirigida Omarchy, sería un usuario feliz haciendo muy pocos cambios.

Este artículo, sin embargo, se centra en las razones técnicas por las que todavía no voy a instalar Omarchy. Se resume en lo que llamo el punto óptimo de la seguridad.

El punto óptimo de la seguridad

Me tomo en serio la seguridad y la privacidad, porque creo que nuestras vidas digitales pesan cada vez más. Quiero proteger mis datos, ser consciente de dónde se alojan, quién tiene acceso a qué, y no dárselos a terceros cuando puedo evitarlo. Para eso invierto muchas horas a mis prácticas de seguridad y privacidad: leer, aprender, planificar e implementar cambios. Pero aparte de ese tiempo las decisiones que tomo añaden fricción y complicaciones a mi día a día, porque definen el cómo interactúo con mis dispositivos. Encontrar el punto óptimo adecuado de seguridad y privacidad para mí es algo a lo que le llevo dando vueltas muchos años.

Me gusta pensar en la intersección de mis datos y mis dispositivos como círculos, donde los de más confianza tienen acceso a los datos más íntimos.

Zonas de confianza de los datos

Según este diagrama, tengo que confiar más en la integridad de mi ordenador que en la de mis dispositivos móviles (móvil, tablet). Eso hace que no solo la elección del SO, sino cómo lo configuro y lo uso, sea una decisión clave.

La evolución de mi punto óptimo

Para entender cómo ha ido cambiando mi particular punto óptimo de seguridad, voy a repasar la historia de mis sistemas operativos de cabecera:

ZX Spectrum (finales de los 80)
↓
MS-DOS (principios de los 90)
↓
Windows (finales de los 90)
↓
Debian (los 2000)
↓
Kubuntu (principios de los 10)
↓
Qubes OS (finales de los 10)
↓
Arch Linux (los 20 hasta ahora)

Empecé con la informática en un ZX Spectrum+ en 1988; eran solo juegos y un poco de BASIC. Unos años después pasé a un IBM PC con MS-DOS, y eventualmente Windows 3.11. Sin Internet en casa, y prácticamente sin datos personales en los dispositivos (solo algún trabajo del cole), nadie pensaba en la privacidad; o más bien se daba por sentada.

Luego, con Windows 95, llegó Internet primero a través de módem, y más tarde por ADSL. Empecé a participar en comunidades online, a bajarme música, vídeos y software. Era un adolescente, pero por suerte lo bastante sensato como para usar un apodo y no publicar nombres ni direcciones en público.

El salto de Windows a Debian (después de trastear con otras distros de Linux) fue casi inevitable tras leer la filosofía del software libre. Me di cuenta de que no podía fiarme del software de código cerrado, y cada vez me sentía más incómodo con Windows. Cuando cambié sobre todo eché de menos mis juegos (solo unos pocos conseguí hacer funcionar con Wine), pero decidí pasarme a las consolas para quitarme el gusanillo. Mi soberanía digital era más importante.

Debian es una distro increíble, y sigue siendo mi elección para servidores a día de hoy. No obstante sus versiones tables se quedan anticuadas para su uso en escritorio, ese siempre ha sido un punto en contra para los que buscamos software reciente. Sí, usaba backports, y acabé corriendo sid, pero eso significaba más inestabilidad y roturas de vez en cuando. Por eso acabé cambiando a Ubuntu (al final me quedé con su sabor Kubuntu), y me fue bien por bastantes años.

En 2016 un amigo me presentó Qubes OS, y me flipó sus mejoras de seguridad. Si no conoces Qubes OS, quizá quieras leer su introducción para darte cuenta de lo distinto que puede ser un SO de escritorio. Si te da pereza, el resumen es este: en un SO tradicional todo el software que corre tiene acceso completo al ordenador, a todos sus archivos y dispositivos; en Qubes OS, en cambio, hay un componente del SO (lo que llaman Dom0) con un mínimo de software de confianza, y luego todo, absolutamente todo lo demás, corre en máquinas virtuales independientes y aisladas. Eso significa que si alguna vez ejecutas software malicioso (virus, troyanos, spyware, ransomware, ataques de cadena de suministro...), no tomaría automáticamente el control del ordenador y todos sus datos. Romper las barreras de una máquina virtual no es imposible, pero es bastante más difícil que otras opciones de aislamiento. Por eso se consideran el estándar de oro de la seguridad del software, amén de ejecutar en otro hardware independiente, claro.

Al final me pillé un portátil nuevo en 2017 e instalé Qubes OS. Lo usé con éxito varios años. Me sentía empoderado, con confianza para ejecutar cualquier software con la tranquilidad de que no podía joder el ordenador ni acceder a datos que no debiera. Sin embargo, el día a día se hizo pesado y acabó siendo demasiado para mí. La lentitud, incluso con VMs aceleradas por hardware, hacía penosas todas las tareas diarias: navegar por la web, abrir imágenes o PDFs, y sobre todo mi trabajo fotográfico se resintió mucho. Después de unos años decidí que tanta seguridad no estaba justificada para mis necesidades personales, y que había inclinado demasiado la balanza en esa dirección.

Eso me llevó a mi última transición. Me pillé un ordenador de sobremesa nuevo y me quedé con Arch Linux por su amplitud de software al día y su maleabilidad para configurarlo como quisiese. Implementé algunas prácticas de seguridad que me acercarían a mi punto óptimo de seguridad, privacidad y UX, como Secure Boot de extremo a extremo basado en UKI y sandboxing ligero de software. Uso KDE porque me resulta familiar y es muy configurable, pero los gestores de ventanas tiling modernos me tiran mucho; simplemente ahora mismo no puedo justificar el tiempo de montar uno.

Qué voy a buscar en mi futuro SO de escritorio

Ahora mismo estoy a gusto, con un ecosistema personal cómodo y lo bastante seguro para lo que necesito. Pero la mente del hacker no para, y siempre estoy pensando en cómo se podría mejorar.

Esta es mi lista de deseos de lo que me gustaría ver en mi próximo SO de escritorio:

Buen UX de serie. Rápido. Fluido. Agradable en el día a día. Todo con el teclado. Bonito. Omarchy ya cumple este punto para mí, eso fue lo que me motivó a escribir este artículo.
Software en sandbox. La mayoría de los programas deberían ejecutarse en un sandbox por defecto, de una forma abstraída del usuario para que la UX no se resienta. No me importa que me pregunte por permisos; la mayoría sólo serían una vez por cada programa, me parecen un compromiso aceptable para la seguridad. Habría una interfaz cómoda para gestionar los permisos, incluyendo a qué archivos o directorios tiene acceso cada programa (lectura y/o escritura).
Actualizaciones auditadas. Después de implementar revisión con IA para la actualización de mis paquetes de Emacs he estado pensando cuánto me gustaría tener lo mismo pero para todo el SO. Quiero alguna garantía de que el software se ha auditado antes de aterrizar en mi máquina. No es una proposición sencilla, hay muchos retos que superar, porque es mucho software y sería muy costoso, pero creo que podría haber soluciones vía crowdfunding. Me parece que podría ser una killer app para Linux, porque un SO de código cerrado no podría competir en este terreno: tienes inevitablemente que fiarte de un tercero y no puedes fiarte solamente del código. Estoy planeando un artículo para desarrollar esta idea, y quizá trabaje en ello como proyecto futuro si nadie más lo hace primero.
Configuración declarativa. La verdad es que me arrepiento un poco de no haberme subido al carro de NixOS en vez de decidirme por Arch Linux. La reproducibilidad, la capacidad de compartir configuraciones complejas y de deshacer errores es algo muy potente. Además, los agentes de IA simplifican hacer cambios. Lo cual me lleva al siguiente punto.
AI integrada. Como ya saben los lectores de mi blog, ya he abrazado la IA y la uso a saco. Estoy plenamente convencido de que ha venido para quedarse y que hay que integrarla y construir sistemas nuevos a su alrededor para que nos sirvan mejor. La uso para programar, investigar, depurar, aprender, crear... Sin embargo constreñir a las IAs para satisfacer mis objetivos de seguridad y privacidad no ha sido tan sencillo como me gustaría. Quiero que mis agentes tengan acceso restringido solo a lo que necesitan para hacer el trabajo. Quiero ver un plan de ejecución que pueda revisar y aprobar. No voy a fiarle a una IA mis datos más personales a menos que corra en mis propias instalaciones. Mi SO ideal integraría la IA, pero debidamente en sandbox para cubrir estos y probablemente otros casos de uso. Omarchy ya integra IA, es puntero en ese aspecto, pero le pediría que estuviese mejor aislada.

Ahora mismo estoy liado con otros proyectos que demandan mi atención, incluida una reforma gorda de la casa y poner en marcha mi nuevo homelab. Estas movidas me van a entretener varios meses, durante los cuales preferiría no distraerme cambiando mi ordenador principal a otro SO. Sin embargo, cuando la casa y el homelab estén en marcha pienso revisitar mi elección de SO de escritorio. Cuando llegue el momento regresaré a esta lista de deseos y veré cómo está el panorama de las distros Linux.

Omarchy está mejorando a un ritmo alucinante, su base de usuarios y el número de contribuidores crecen por miles. La mayoría de las mejoras que leo parecen centrarse en el escritorio y la UX, pero ojalá esta humilde lista dé que pensar sobre la arquitectura del SO en términos de seguridad y privacidad.

Sea como sea les deseo el mejor de los éxitos al proyecto y la comunidad Omarchy, su positividad es algo muy necesario en estos tiempos que corren.

¿Tienes ideas o comentarios? Déjame uno aquí abajo, o puedes mencionarme en X.

Añadir nuevos git trailers a Magit

2026-08-12T00:00:00+00:00

Los trailers de Git no son más que líneas de texto al final de un commit que registran algunos metadatos. Algunos de los más comunes son Co-Authored-By (co-escrito con), Reported-By (reportado por), Reviewed-By (revisado por) o Signed-Off-By (aprobado por).

Magit tiene una forma cómoda de añadir trailers: basta con pulsar C-c TAB o C-c C-i en la vista de commit. Magit mostrará entonces un menú transient con algunas opciones:

Menú de inserción de trailer de Magit

Hoy en día se está volviendo habitual usar el trailer Assisted-by: para acreditar a los agentes de IA de programación, y yo quería empezar a usarlo, ya que ahora hago la mayor parte de mi código con ayuda de IA. Magit no soporta este trailer (¡por ahora!), pero hice que mi IA averiguara cómo añadirlo.

En esta pequeña guía os mostraré cómo añadir un nuevo tipo de trailer a Magit, para que quede a solo un C-c TAB de distancia. Usaré el ejemplo de Assisted-by, pero podéis adaptarlo a otros si os hiciese falta. Al usarlo pide un valor (texto libre, p. ej. Kimi K3 o venice/zai-org-glm-5-2) y lo añade al buffer de commit como Assisted-by: <value>, después de cualquier otro trailer existente.

Recuerda los valores introducidos anteriormente, que se ofrecerán como opciones de completado. Como bonus también mostraré cómo configurar el paquete savehist incluido en Emacs para conservar ese historial entre sesiones.

Configuración de Magit

(use-package magit
  :preface
  (defvar my-git-commit-assisted-history nil
    "History of values entered for `my-git-commit-assisted'.")
  (defun my-git-commit-assisted ()
    "Insert an \"Assisted-by\" trailer crediting an AI coding agent.
Prompt for the agent description (free text, e.g. \"Claude Opus 4.7\"),
offering previously entered values as completion."
    (interactive)
    (let ((value (completing-read "Assisted by: "
                                  my-git-commit-assisted-history
                                  nil nil nil
                                  'my-git-commit-assisted-history)))
      (when (string-empty-p value)
        (user-error "Empty agent description"))
      ;; NOTE: `git-commit--insert-trailer' is a private API; magit
      ;; offers no public function for inserting an arbitrary trailer.
      (git-commit--insert-trailer "Assisted-by" value)))
  :config
  ;; C-c TAB A or C-c C-i A inserts the trailer
  (transient-append-suffix 'git-commit-insert-trailer 'git-commit-test
                           '("A" "Assisted" my-git-commit-assisted))
  (add-to-list 'git-commit-trailers "Assisted-by"))

Cómo funciona:

transient-append-suffix añade el comando a git-commit-insert-trailer (C-c TAB), justo después de la entrada integrada "Co-developed", de modo que aparece como A en el menú de trailers.
El valor se pide con completing-read en el minibúfer, así que podéis usar vuestro sistema de completado configurado (yo uso vertico) para elegir entre los candidatos, o escribir texto libre.
La inserción pasa por el mismo helper interno que Magit usa para Signed-off-by, de modo que el trailer se coloca después de los trailers existentes y antes de la sección de comentarios/diff, independientemente de la disposición del buffer.
Añadir "Assisted-by" a git-commit-trailers hace que el token se resalte con font-lock como los integrados. Esto es necesario porque los valores son texto libre; Magit solo resalta tokens arbitrarios cuando tienen la forma Name <email>.
Una nota para quienes usen versiones antiguas de Magit: el menú de trailers solía llamarse git-commit-insert-pseudo-header; ahora es un alias obsoleto de git-commit-insert-trailer.

Bonus: recordando los valores entre sesiones con savehist

Emacs olvida el historial de completado cuando termina la sesión, lo cuál es un fastidio porque normalmente estaremos introduciendo los mismos valores una y otra vez. Activando savehist-mode, las variables de historial del minibúfer se guardan automáticamente una vez usadas, así que a menudo no hace falta nada más que tener el modo activado. Si prefieres ser explícito (o si solo guardas una lista blanca estableciendo savehist-save-minibuffer-history a nil), registradla como variable adicional:

(use-package savehist
  :config
  (setq savehist-additional-variables
        '(my-git-commit-assisted-history))
  (savehist-mode +1))

El orden importa: savehist-mode restaura las variables una sola vez al activarse, así que si lo ponéis antes de establecer savehist-additional-variables, veréis que las nuevas variables (my-git-commit-assisted-history en mi caso) se guardan en el archivo de savehist, pero no se restauran cuando Emacs arranca de nuevo. Pregúntame cómo lo sé.

Reflexiones finales

No me gusta tener que usar una variable privada como git-commit--insert-trailer, es algo que podría romperse en cualquier momento. En este caso me parece aceptable porque es un uso muy localizado y en una funcionalidad no crítica que no me importaría que se rompiera. Si ocurriese procuraré actualizar este artículo.

En cuanto a Assisted-by, planeo usarlo mucho; quiero ser honesto sobre mi uso de IA.

¿Usas Assisted-by u otros trailers en tus commit?

Higiene de la cadena de suministro en Emacs: revisando actualizaciones mediante IA

2026-08-08T00:00:00+00:00

Emacs no tiene sandbox. Cada paquete que instalas ejecuta código Lisp arbitrario con todos tus privilegios: acceso a tus archivos, credenciales y red. Esto hace que me dé mucho miedo instalar paquetes nuevos o actualizar los existentes.

Los paquetes que usamos la mayoría de usuarios de Emacs no son verificados: MELPA los compila a partir de algún commit de un repositorio (normalmente sin firma criptográfica), muchos paquetes están mantenidos por una sola persona y nadie audita lo que incluye cada actualización. Si secuestran la cuenta de un mantenedor o este vende el repositorio a un nuevo propietario, M-x package-upgrade-all se convierte en una vía directa para ejecutar código de forma remota en tu máquina. Incluso existe un vector más sutil y propio de este ecosistema: la redirección de recetas. Un cambio de una sola línea en una receta de MELPA puede hacer que el nombre de un paquete existente apunte silenciosamente a otro repositorio.

La solución no es dejar de actualizar, sino hacerlo de forma deliberada: fijar cada paquete a un commit exacto y revisar los diffs antes de fusionar nada.

Revisar los diffs a mano no solo es engorroso, sino que exige un alto nivel de conocimientos de Emacs Lisp. Mi solución consiste en recurrir a un LLM para que realice una primera auditoría de seguridad de los cambios antes de que lleguen a ejecutarse.

En este artículo muestro la configuración que utilizo, basada en straight.el, Magit y gptel.

Índice de contenidos

Resumen de la configuración
Paso 1: verificar la instalación de straight.el
Paso 2: fijar las versiones conocidas
Paso 3: revisar los diffs antes de fusionar
Paso 4: revisión del diff mediante un LLM
Flujo de trabajo para las actualizaciones
Limitaciones y reflexiones finales

Resumen de la configuración

El script de arranque de straight.el se verifica mediante una suma SHA-256 precalculada antes de evaluarlo.
Cada paquete (y cada repositorio de recetas) queda fijado a un commit y registrado en un archivo (lockfile) sometido a control de versiones.
Primero se descargan las actualizaciones: git fetch obtiene los cambios entrantes, mientras que git merge y la actualización propiamente dicha solo se ejecutan cuando los cambios superan la revisión.
Una vista personalizada de Magit muestra los diffs de todos los cambios descargados pero aún no fusionados en todos los repositorios de straight.
Un comando personalizado de gptel revisa el diff completo mediante un LLM.
Si los cambios son seguros, straight.el los fusiona y actualiza el archivo de versiones.

gptel revisando una actualización de paquetes de straight.el

Paso 1: verificar la instalación de straight.el

straight.el se instala descargando y evaluando install.el durante el arranque. Esta es una puerta abierta a ejecución de código remoto, así que mi early-init.el fija su SHA-256 a un valor conocido y detiene el proceso si no coincide:

;; SHA-256 of straight.el's install.el; update after reviewing changes at
;; https://github.com/radian-software/straight.el/commits/develop/install.el
(defconst my-straight-install-el-sha256
  "e29e07d52d16d4136971f0a822cb6a1a6e1e764a1cb9fe67cccbc7c048aba553")

(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name
        "straight/repos/straight.el/bootstrap.el"
        (or (bound-and-true-p straight-base-dir)
            user-emacs-directory)))
      (bootstrap-version 7))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/radian-software/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      ;; verify bootstrap script against its pinned checksum before eval
      (require 'url-http)
      (when url-http-end-of-headers
        (delete-region (point-min) url-http-end-of-headers)
        (delete-region (point-min)
                       (progn (skip-chars-forward " \t\n") (point))))
      (let ((checksum (secure-hash 'sha256 (current-buffer))))
        (unless (string= checksum my-straight-install-el-sha256)
          (error "straight.el bootstrap checksum mismatch!")))
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

Paso 2: fijar las versiones conocidas

straight.el instala los paquetes clonando sus repositorios Git, lo que facilita su revisión. El archivo de versiones (lockfile) registra el estado de todos:

M-x straight-freeze-versions escribe el commit exacto de cada paquete en straight/versions/default.el, tanto de los paquetes como de los los repositorios de recetas, MELPA entre ellos.
Añade el archivo de versiones al repositorio. Revisar git diff straight/versions/default.el después de una actualización te permite ver exactamente qué ha cambiado.
M-x straight-thaw-versions restaura esas revisiones si alguna vez necesitas volver atrás.

Paso 3: revisar los diffs antes de fusionar

La clave para actualizar de forma segura es separar la descarga de los cambios de su fusión. M-x straight-fetch-all descarga los nuevos commits del repositorio remoto sin modificar ningún checkout. Después reviso, repositorio por repositorio, lo que cambiaría antes de que M-x straight-merge-all aplique nada.

A continuación, uso una función personalizada de Magit que muestra en una única vista combinada el diff de todos los repositorios que tienen commits entrantes en el upstream:

;; https://magit.vc/
(use-package magit
  :bind (("C-c v U" . my-straight-incoming-diffs))
  :preface
  (defun my-straight-repo-behind-p (repo)
    "Return non-nil if REPO's current branch is behind its upstream."
    (let* ((default-directory repo)
           (lines (magit-git-lines "status" "--porcelain=2" "--branch")))
      (seq-some (lambda (line)
                  (string-match-p "^# branch\\.ab [+][0-9]+ -[1-9]" line))
                lines)))
  (defun my-straight-incoming-diffs ()
    "Concatenate the full patches of all incoming upstream changes.
Create a `diff-mode' buffer listing, for every straight.el checkout
that is behind its upstream, the incoming commits with author and
date, followed by the net patch that merging would apply.  The
buffer is left writable so hunks can be trimmed before feeding it
to a reviewing agent."
    (interactive)
    (let* ((repos (magit-list-repos-1
                   (expand-file-name "straight/repos" user-emacs-directory)
                   1))
           (behind (seq-filter #'my-straight-repo-behind-p repos)))
      (if (null behind)
          (message "No incoming upstream changes")
        (with-current-buffer (get-buffer-create "*straight-incoming-diffs*")
          (erase-buffer)
          (dolist (repo behind)
            (let* ((default-directory repo)
                   (branch (magit-git-string "rev-parse" "--abbrev-ref"
                                             "HEAD"))
                   (upstream (magit-git-string "rev-parse" "--abbrev-ref"
                                               "@{upstream}"))
                   (commits (magit-git-lines
                             "log" "--format=%h  %ad  %an <%ae>  %s"
                             "--date=short" "HEAD..@{upstream}"))
                   (n (length commits)))
              (insert (make-string 80 ?=) "\n")
              (insert
               (format "%s  (%s <- %s, %d commit%s)\n"
                       (file-name-nondirectory (directory-file-name repo))
                       (or branch "HEAD") (or upstream "?")
                       n (if (= n 1) "" "s")))
              (insert (make-string 80 ?-) "\n")
              (insert (string-join commits "\n") "\n\n")
              (magit-git-insert "diff" "HEAD...@{upstream}")
              (insert "\n")))
          (diff-mode)
          (goto-char (point-min))
          (pop-to-buffer (current-buffer))))))
  (defun my-straight-incoming-diffs-after-fetch (&rest _)
    "Show incoming full diffs after an interactive `straight-fetch-all'."
    (when (eq this-command 'straight-fetch-all)
      (condition-case err
          (my-straight-incoming-diffs)
        (error (message "my-straight-incoming-diffs failed: %S"
                        (error-message-string err))))))
  :init
  ;; automatically show the incoming diffs after fetching all remotes
  (with-eval-after-load 'straight
    (advice-add 'straight-fetch-all
                :after #'my-straight-incoming-diffs-after-fetch)))

Paso 4: revisión del diff mediante un LLM

Salvo que el diff sea muy sencillo, se lo paso a un LLM para que revise el código. Utilizo gptel, KWallet para guardar los secretos y Venice (enlace de referido) para la inferencia de IA:

;; API key from KWallet via the freedesktop Secret Service API; or put
;;   machine api.venice.ai login apikey password <your-key>
;; in ~/.authinfo.gpg and drop the secrets: entry.
(setq auth-sources '("secrets:kdewallet" "~/.authinfo.gpg" "~/.authinfo"))

(use-package gptel
  :bind (("C-c a R" . my-gptel-review-malicious-code))
  :preface
  (defvar my-gptel-review-system-prompt
    "You are a meticulous security reviewer auditing third-party code
before it is merged or used. The user will show you one or more git
diffs, each preceded by the list of incoming commits with author and
date.

Scan for anything that could act maliciously once merged or called:
- backdoors, remote code execution, persistence mechanisms
- credential, token, key or data exfiltration (also covert channels)
- unexpected network activity, downloads or connections to new hosts
- obfuscation designed to hide behavior (heavy encoding, dead stores)
- tampering with build, installation or packaging scripts
- anomalous commit authorship: new maintainer, changed email address,
  commits by someone unrelated to the project

For every finding, state: severity (high/medium/low), the file and
hunk, and a one-paragraph rationale.  Close with an overall verdict:
whether the changes look safe to merge.  If nothing is suspicious,
say so plainly and briefly; do not invent findings."
    "System prompt for `my-gptel-review-malicious-code'.")
  (defun my-gptel-review-malicious-code ()
    "Review the region, or the whole buffer, for malicious code.
Send the text to the LLM with a security-audit system prompt and
show the response in the *gptel-review* buffer."
    (interactive)
    (require 'gptel)
    (let* ((text (buffer-substring-no-properties
                  (if (use-region-p) (region-beginning) (point-min))
                  (if (use-region-p) (region-end) (point-max))))
           (buffer (get-buffer-create "*gptel-review*"))
           (marker (with-current-buffer buffer
                     (erase-buffer)
                     (org-mode)
                     (goto-char (point-min))
                     (point-marker))))
      (pop-to-buffer buffer)
      (gptel-request
       (format
        "Review the following content from %s for malicious code or \
exploits.\n\n%s"
        (buffer-name) text)
       :system my-gptel-review-system-prompt
       :stream t
       :buffer buffer
       :position marker)))
  :config
  (setq gptel-backend
        (gptel-make-openai "Venice"
          :host "api.venice.ai"
          :endpoint "/api/v1/chat/completions"
          :key #'gptel-api-key   ; auth-source, see above
          :stream t
          :models '(kimi-k3
                    claude-opus-5
                    openai-gpt-56-sol
                    grok-4-5
                    zai-org-glm-5-2
                    deepseek-v4-flash-0731))
        gptel-model 'deepseek-v4-flash-0731))

Utiliza C-c a R para revisar el búfer completo o la región seleccionada. La auditoría se muestra progresivamente en un búfer de Org llamado *gptel-review*: cada hallazgo incluye la gravedad, el archivo y el hunk, una justificación y un veredicto final.

Flujo de trabajo para las actualizaciones

Descargo los nuevos cambios a todos los paquetes con M-x straight-fetch-all.
Echo un vistazo a los cambios.
Ejecuto C-c a R sobre el búfer completo con los diff.
Espero a que termine la revisión de la IA.
Ejecuto M-x straight-merge-all cuando estoy conforme.
Reinicio Emacs y compruebo que todo funciona (straight.el habrá reconstruido los paquetes).
Ejecuto M-x straight-freeze-versions y registro los cambios al archivo de versiones en mi repositorio Git.

Limitaciones y reflexiones finales

La auditoría por IA es un segundo par de ojos, no una garantía. Las IA cometen errores, pueden pasar cosas por alto, y un adversario hábil puede escribir código que parezca inofensivo. En el caso de los paquetes críticos, sigue siendo buena idea leer el diff personalmente. Considera la auditoría como una herramienta de triaje: un hallazgo de gravedad «alta» significa que debes examinarlo más de cerca, no que el modelo tenga razón.
Los diffs salen de tu máquina. Venice afirma aplicar una política de retención cero de datos, pero, si tu modelo de privacidad no lo permite, puedes configurar gptel para que utilice un servidor local. El código es el mismo; solo cambia el proveedor de gptel.

Sé que esta configuración no es perfecta, pero me da mucha más tranquilidad al instalar o actualizar paquetes. Emacs es la pieza central de mi entorno informático y necesito poder confiar plenamente en él.

¿Se te ocurre algún punto ciego, limitación o posible mejora? ¡Déjame un comentario!

Revisión de mis propósitos para 2026

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

Llegamos al ecuador de 2026, y es buen momento para revisar mi progreso con mis propósitos de Año Nuevo de 2026.

Gastar menos tiempo en tareas ❌

Fallo. Y no porque el plan fuese malo, sino porque sinceramente no lo he seguido (¿aunque quizá por eso era malo?).

De todas las ideas la única que suelo seguir es apuntar las tareas del día en un post-it. A veces me funciona y a veces no, porque me distraigo y no me enfoco en terminarlas. Vamos el problema que ya había reconocido y pretendía atajar, pero sin éxito.

Voy a probar algo diferente: en vez de tener 10 tareas en un post-it pretendiendo que las haré en el día, y al final sólo hago una, cada día voy a poner una única tarea en la que enfocarme para terminarla. Mientras no la termine no trabajaré en nada más. Si la termino el resto del día pues haré lo que me plazca, y al día siguiente otra tarea con ese nivel de intensidad.

Fotografía ⚠

Lo clasifico como parcial, pero creo que es más éxito que fracaso.

Por un lado estoy echando menos fotos en general, tanto con el móvil como con la cámara. El usar mucho menos mi cámara fotográfica hace que casi no haya gastado tiempo en edición y postprocesado, eso es de lo que más esfuerzo me consumía en el pasado, días o semanas después de eventos como las navidades o los viajes.

Por otro lado he reducido el tiempo para organizar mis fotos. Pensando en la organización en Immich ya he dejado de etiquetar mis fotos manualmente, sólo las organizo en álbumes y reviso el etiquetado de caras (que es automático en Digikam).

Lo que más he fallado es que no he impreso ningún álbum en lo que llevamos de año, pese a tener el álbum de 2025 casi terminado desde hace meses. Ese empujón final es la procrastinación que tanto me cuesta superar. Pero estoy decidido a terminarlo pronto, y después de eso trabajaré en el resto de álbumes, procurando ir más rápido.

No Morir ✅

Exitazo. Y no sólo porque sigo vivo.

He bajado de 90kg a 83kg en 3 meses, y sin pérdida de masa muscular. Todos los pantalones me quedan grandes, esa es la auténtica prueba del algodón.

La grasa corporal ha bajado notablemente, y la grasa visceral, mi principal objetivo a mejorar dado que está correlacionada con problemas cardiovasculares, va reduciéndose aunque aún no está en niveles óptimos. Ha bajado del 10% inicial al 7% medido hoy. Pienso continuar para intentar bajarla hasta niveles sanos (idealmente del 2% al 4%).

El principal cambio ha sido encontrar una dieta que me funciona, me gusta y es sostenible en el tiempo. Estas son las claves:

Ayuno intermitente todas las mañanas. A partir de 12 horas de ayuno el cuerpo empieza a movilizar grasas para crear cetonas, lo cuál debe estar ayudando con la pérdida de peso.
Por la mañana sólo café negro.
Almuerzo después de la 1. Una variedad de recetas, por lo general altas en proteínas, reducidas en grasas y con más carbohidratos los días de gimnasio.
Merienda sobre las 4:30: avena con leche de soja, semillas trituradas, yogur skyr, proteína whey, colágeno, frutos del bosque.
Cena entre las 7 y las 8, frecuentemente una tortilla con claras de huevo, ensalada con mejillones o atún, u otras recetas altas en proteína. Pieza de fruta.
Las tres comidas en un intervalo corto de tiempo hacen que coma menos, porque si me hartase en el almuerzo no me entraría la merienda, e igual con la cena. Sirviéndome el almuerzo pienso en el cuenco de la merienda y me modero. Las comidas proteicas también sacian más.
Como ya he dicho, alta proporción de proteínas. Apunto a 1,6-1,8g de proteína por kilo de peso corporal.
Muy muy ocasional consumo de alcohol, por salud en general pero también por las calorías vacías que contiene.
Ayunos prolongados ocasionales. Habitualmente practico un ayuno de 24 a 36 horas una vez por semana, y un ayuno de unos 3 días una vez cada 3 a 6 meses. Por un lado creo que la autofagia es beneficiosa para el cuerpo. Por otro en mi caso la restricción calórica me ayuda a perder peso.

Tengo pendiente hacerme un análisis de sangre lo más completo posible, y continuaré las mediciones con mi nutricionista, pero me siento muy bien y contento de al fin encontrar un método que particularmente me funciona.

Otros aspectos que mencionaba en el post anterior, como el sueño, también van bien. Tengo una rutina regular y mi puntuación de sueño suele estar en 90 con bastante REM. Quiero conseguir un medidor de CO2 para ver si se acumula en la habitación o hay que airear más. También control de la temperatura.

Portugués ✅

He mejorado bastante mi portugués estos meses. Ya mantengo conversaciones de forma natural, aunque sé que sigo cometiendo errores, pero los portugueses son muy agradecidos y no protestan nunca.

Hace 2 meses me presenté al examen CIPLE (equivalente a nivel A2) y lo aprobé con nota "muy buena".

Blog ✅

Estoy escribiendo con más frecuencia, eso es indudable vista la cadencia de los últimos meses.

Me gustaría escribir de otros temas, pero lo más fácil es seguir escribiendo de temas técnicos, que me apasionan y no son normalmente controvertidos (con excepción de la IA, pero al que no le guste que no lea).

Self-hosting ⚠

Lo pongo como éxito parcial porque aunque he montado algún servicio nuevo (como Tailscale autoalojado), aún no he configurado ni Home Assistant ni Paperless, que eran los principales que mencioné en mis propósitos.

Contaré este objetivo como éxito si para final de año tengo montado mi nuevo servidor, con todos los servicios actuales migrados, más Home Assistant y Paperless por lo menos.

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!

Propósitos de Año Nuevo para 2026

2026-01-08T00:00:00+00:00

Otro año que pasa, y lo que originalmente no pensaba convertir en tradición ha acabado como una que no falta: publicar mis propósitos para el nuevo año. Siempre fallo en algunos de los propósitos, pero me gusta el esfuerzo de reflexión y el tenerlos presente todo a lo largo del año.

Siguiendo el formato del año pasado, empezaré por revisar cómo han ido mis propósitos de 2025, para entonces plantear los de este año:

Revisión de 2025

Lo que he cumplido:

Familia y amigos: éxito. Tuve dos fines de semana con mis amigos y me lo pasé bomba. Espero que podamos repetir este año, a poder ser más veces, pero es complicado alinear los calendarios de todos. También le compré a mi hija su primer ordenador, y estoy en proceso de enseñarle a usarlo. Hemos viajado como turistas con los niños y ya se han acostumbrado, se portan como campeones.
Perder peso: éxito. Perdí una talla de pantalón, pero sigo sin estar en mi momento más delgado. Pero he ganado músculo y mejorado mi nivel cardiovascular, por lo que me doy por contento con los resultados.
Nueva casa: éxito por ahora. Las reformas al fin han comenzado, aunque con retraso respecto a mis expectativas iniciales. Aún es pronto para saber si todos los esfuerzos de planificación habrán merecido la pena, pero por ahora avanza a buen ritmo y va según lo previsto.
Inteligencia Artificial: éxito parcial. Uso Perplexity y Venice.ai casi a diario para hacer investigaciones o resolver problemas (por ejemplo errores con el sistema operativo, o de programación). También he jugado un poco con generación de imágenes y vídeos, pero sólo con servicios online, eso lo considero un fallo porque quería hacerlo en local. Tampoco he probado aún a usar agentes para programación, necesitaría ejecutarlos o bien en local o de una forma razonablemente privada.

Lo que no he cumplido:

Blog: fallo. No conseguí mi objetivo de al menos un artículo mensual en el blog. Tiendo a escribirlos largos y encima me obceco en revisarlos y perfeccionarlos una y otra vez. Tengo 3 artículos casi listos pero nada que los termino y publico. Al menos estoy contento con la calidad de los que he publicado.
Home labbing: en pausa. Con el retraso de la nueva casa no he podido empezar aún a montar el nuevo servidor, y no quiero dedicarle demasiado tiempo al antiguo, porque tendré que acabar migrándolo todo. No obstante he montado dos nuevos servicios que ahora uso casi a diario: Jellyfin e Immich.

Gastar menos tiempo en tareas

Como supongo que le pasa a mucha gente, siento que me ahogo en tareas por hacer, sobre todo las que no avanzan mis objetivos vitales. Mi propósito es poner en práctica el conocimiento teórico que tengo sobre productividad personal a ver si encuentro un sistema que me sirva.

Para empezar necesito plantear mejor mis objetivos. Hay multitud de sistemas: SMART, PACT, WOOP, FAST... Sólo en el proceso de escribir este artículo ya me voy perdiendo analizándolos en detalle para decidir cuál es el mejor para mí. Tengo que decidir uno rápido, aplicarlo a mis resoluciones de este año y seguir adelante.

Luego en el día a día pienso seguir este proceso:

Cada mañana plantear las tareas que pretendo acometer.
Interrupciones que vayan a tomar menos de 5 minutos, hacerlas en el momento.
Interrupciones más largas y con cierta urgencia apuntarlas en una lista y hacerlas todas o al final del día o al principio del día siguiente, para que no me interrumpan.
Interrupciones más largas y no inmediatamente urgentes apuntarlas en otra lista que tenga un día dedicado en la semana.

Soy bastante procrastinador, así que necesito todos los trucos posibles para no dejar las cosas para más tarde. Algunos que tengo que aplicar en serio son:

Dividir tareas grandes en varias pequeñas. Completar tareas segrega dopamina, así que más cortas mejor.
Empezar por la tarea más difícil o desagradable, y al terminarla darme una recompensa.
Retomar una práctica formal de meditación, 15 minutos al día.
Comunicar a alguien las tareas más importantes, para rendirle cuentas.
Mantener a raya mi perfeccionismo, plantear cuál es el nivel de calidad apropiado para lo que esté haciendo.

Fotografía

Hace muchos años que me gusta la fotografía, pero reconozco que he invertido demasiado tiempo procesando y organizando mi colección fotográfica. Estoy simplificando mi proceso fotográfico para disponer de más tiempo para otros objetivos.

En este sentido hace meses que hago la mayoría de fotos con el móvil, la "cámara grande" la saco sólo para retratos y ocasiones puntuales. Obviamente echo de menos la calidad y precisión de la cámara profesional, pero se me iba demasiado tiempo en el postprocesado.

Aparte estoy en proceso de migración de Digikam a Immich. La idea es que las fotos del móvil se suban directa y automáticamente a Immich, y que sea ahí donde edite los metadatos. Tengo un artículo casi terminado sobre la filosofía y detalles detrás de esta migración, por lo que no me voy a extender más por ahora.

Por último a principios del año pasado, aunque no lo pusiese como resolución, decidí empezar a hacer álbumes de fotos. Hice uno grande con las fotos familiares de 2024, y me encantó el resultado. También hice uno de una sesión de fotos que tuve con mi familia y mis padres, y le regalé una copia a ellos. Pienso seguir haciéndolos porque me encantaba ver los álbumes de fotos con mis padres y escuchar las historias cuando era pequeño, y me gustaría hacer lo mismo con mis hijos. Como objetivo medible, antes de que termine el año quiero tener impreso al menos el álbum de 2025 y el de 2023.

No morir

Me siento inspirado por Bryan Johnson y su movimiento Don't Die. La mayoría de lectores es probable que ni siquiera lo conozcan, y los que lo conozcan o echen un primer vistazo a sus ideas apuesto a que piensan que es un multimillonario loco y egoísta que busca su inmortalidad. Pero a mi modo de ver es un pionero que experimenta con su propio cuerpo para encontrar lo que funciona, algo de lo que nos beneficiaremos el resto. Lo que a él le cuesta $2 millones al año en un futuro estará al alcance de cualquiera, al igual que tantas medicinas y tratamientos actuales de las que no podían disfrutar ni reyes ni las personas más ricas del pasado.

En fin, sin entrar en más filosofía, no busco ni mucho menos el replicar su estilo de vida, sino más bien el reflexionar sobre las principales causas de muerte prematura y atajarlas. Para ello y como primer paso mi propósito es adoptar varias de las recomendaciones de Bryan Johnson:

Redoblar mis esfuerzos para perder peso.
Reducir el consumo de alimentos procesados y ultraprocesados, así como el azúcar y otros antinutrientes. Que sean algo muy ocasional.
Reducir el alcohol al mínimo. He podido comprobar con mi smartwatch que afecta muy negativamente a mi sueño, me impide alcanzar la fase REM. Y aparte están los demás efectos negativos que no estaré midiendo.
Horario regular para dormir. En mi caso será de 11:00pm a 7:15am.
Cenar a las 7pm, 4 horas antes de dormir.
Fuera pantallas a las 10:30pm.
Leer de 10:30pm a 11:00pm.

Sobre la pérdida de peso, estoy experimentando a ver si encuentro una dieta que me funcione y sea sostenible.

Por un lado suelo hacer ayunos prolongados de 3-4 días dos veces al año. Aunque el efecto sobre la pérdida de peso es limitado, sobre todo los hago por los indicios de que son sanos para el cuerpo en general, por efectos como la autofagia.

También he probado a hacer ayuno intermitente estricto, comiendo sólo en una ventana de 6-7 horas. Mi implementación ha sido cenar sobre las 7 de la tarde; por la mañana sólo café negro; romper el ayuno con un almuerzo a eso de la 1; batido de proteína a media tarde. Voy al gimnasio justo antes del almuerzo, y aunque no me ha dado ningún bajón probablemente no sea ideal ir en ayuno.

El tercer experimento es aumentar la cantidad de proteína en mi dieta, hasta los 1,8g de proteína por kg de peso. Esto ayuda a crear y mantener masa muscular y también a saciarse más y comer menos. Sin embargo es difícil combinar esto con el ayuno intermitente, así que estoy probando sin el ayuno.

Mi métrica principal es bajar el porcentaje de grasa visceral, que está correlacionada con problemas cardiovasculares. Si alcanzo el intervalo considerado sano sería la mejor medida de éxito. Otra métrica más simple sería bajar al menos hasta los 85 kg manteniendo o mejorando mi nivel físico (cardio y resistencia). No porque 85 kg sea mi peso ideal, sino porque ahora peso 90 kg, sería un buen progreso.

Portugués

Llevo 4 años viviendo en Portugal, y ya me defiendo bastante bien con el portugués. El acento de los portugueses es difícil, porque hablan rápido y se "comen" letras (¡como los andaluces, vaya!), pero ya les entiendo casi todo. Mi pronunciación ha mejorado bastante y tengo suficiente vocabulario y expresiones como para tener conversaciones largas en portugués. Meto bastantes palabras en español, pero me entienden y por lo general agradecen el esfuerzo.

Mi propósito es buscar clases de portugués, al menos un día a la semana, para mejorar de verdad. Probablemente busque un profesor particular, porque cunde mucho más el tiempo, siempre me da coraje cuando una clase en grupo va al ritmo del más lento de la clase.

Blog

El propósito perenne: escribir más en el blog. No podía faltar.

No creo que el año pasado me equivocase al identificar las razones por las que me cuesta publicar más, pero está claro que eso no ha sido suficiente para corregirme. Quizá me lea el libro Atomic Habits, que viene muy recomendado para establecer nuevos hábitos.

Una motivación adicional de la que me di cuenta hace unos meses es el carácter autobiográfico del blog. Me ilusiona que mis hijos puedan leerlo en un futuro, es una ventana a mis pensamientos, mis intereses, mis preocupaciones. Quiero verter más personalidad e historia en mis futuros artículos.

Algo que, aunque no lo parezca, me ayudó el año pasado fue usar la tablet para escribir los artículos. Me es mucho más asequible coger la tablet cuando tengo 5 minutos de inspiración que sentarme en el ordenador 5 minutos. O me la llevo fuera de casa y escribo cuando tengo unos minutos muertos esperando. Uso Markor para escribir los artículos, se sincronizan al ordenador con Syncthing, y cuando están listos le doy los últimos ajustes en el ordenador y los publico.

Self-hosting

En cuanto esté lista la nueva casa estaré muy entretenido montando mi nuevo servidor casero, me dará para meses y toda una nueva serie de artículos en este blog. Pero mientras tanto no me voy a quedar de brazos cruzados con mi servidor actual, tengo al menos tres ideas que quiero implementar pronto:

Home Assistant, para ir aprendiendo cómo funciona y que no me pille de novato al montarlo en la nueva casa, que va a tener domótica en cada rincón.
Paperless-ngx, un sistema de organización del papeleo. Pienso hacer que el escáner guarde los ficheros directamente en el servidor, para que Paperless los procese y archive automáticamente. Creo que va a ser un sistema útil y que ahorrará tiempo una vez montado, en apoyo de mi resolución de perder menos tiempo en tareas.
Backup remoto de mis dispositivos y datos críticos, eso no puede pasar de este año. Ya tengo backup local, pero no me da suficiente tranquilidad, aparte de que no está automatizado.

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!

Revisión de mis propósitos para 2025

2025-07-17T00:00:00+00:00

Estamos aproximadamente (bueno venga, ya bien pasado) a mitad del año, así que es buen momento para evaluar el progreso de mis propósitos para 2025.

Familia y amigos ✅

Al igual que en 2024, este es mi propósito principal, el que no quiero fallar bajo ningún concepto, es la base de todo lo demás.

Les dedico mucho tiempo a mis hijos. Estoy ahí cuando se levantan y cuando se acuestan. Los he llevado al colegio todos los días, y los he recogido muchos otros. Juego mucho con ellos, leemos libros, les enseño todo tipo de cosas, vamos a parques...
He introducido a mi hija mayor a programar con Scratch. Por ahora no hace nada sola, pero le voy presentando conceptos y sobre todo busco que gane interés y le guste. Tengo pendiente montarle un ordenador propio (una Raspberry Pi 500 es mi primera opción ahora mismo), entonces podría experimentar por su cuenta.
Hicimos un viaje en familia a Colombia de casi 3 semanas, y salió a pedir de boca. También fuimos unos dias a la sierra, y hasta hicimos 10 kilómetros de senderismo. Definitivamente los niños ya están listos para viajar más, así que iremos planeando más viajes en los meses venideros, algunos más cortos y otros más largos.
Estuve un fin de semana frikeando con amigos. Pura risoterapia con mucho juego de mesa y videojuegos a 4 jugadores. Todos nos quedamos con ganas de más, así que deseando repetir.
He apoyado a mi pareja en sus objetivos vitales, y ha realizado un progreso increíble en menos de un año.

Resumiendo, incluso aunque el año terminase hoy, creo que daría este propósito por cumplido; pero voy a seguir teniéndolo presente, debe ser una constante y no algo en lo que se trabaje sólo la mitad del año y te olvides la otra mitad.

Perder peso ⚠

Mi objetivo de perder una talla de pantalón lo conseguí a principios del año: se me rompió el pantalón que usaba a diario y cuando fui a comprar uno nuevo el que me quedaba bien era de una talla menos.

No obstante el camino no ha sido recto, ha habido temporadas en el año en las que he ganado bastante peso, y luego lo he soltado. Tampoco he conseguido en lo que va de año el alcanzar mi peso mínimo histórico, aunque creo que tengo más músculo que nunca, así que el peso magro debe ser mayor.

En cualquier caso, tengo que encontrar y mantener una rutina que me funcione, y evitar grandes saltos de peso.

No podré considerar este propósito como exitoso si no termino el año con varios kilos menos de los que tenía al terminar 2024.

Blog ❌

Este propósito es fácil de comprobar que no se está cumpliendo: este es el tercer artículo de 2025, cuando debería ser al menos el séptimo. Y la cosa es que llevo meses con dos artículos en borrador, pero nunca me siento a terminarlos, me distraigo con otros temas.

Las distracciones vienen por dos flancos: por un lado creo que mi capacidad de concentración se ha mermado por el uso del teléfono móvil, y eso que no uso ninguna plataforma de contenidos cortos tipo TikTok o Instagram; pero por otro lado muchas veces inetnto enfocarme con el blog u otro asunto, sólo para ser interrumpido escasos minutos (¡o segundos!) después con alguna petición.

Escribo estas líneas en verano, y con los niños en casa no es momento de enfocarse en grandes proyectos (véase el primer propósito), pero a partir de septiembre procuraré bloquear tiempo todos los dias y poner límites a las interrupciones para poder concentrarme.

Aunque no vaya a cumplir el propósito de un artículo al mes, voy al menos procurar terminar el año con 12 artículos o más, distribuidos como de cualquier forma según el tiempo disponible lo permita. Mi esperanza es ganar una inercia que continúe en 2026.

Nueva casa ✅

El proceso de reforma de la nueva casa ha ido acumulando retrasos, entre planificación, presupuestos y, lo más doloroso por la impotencia, burocracia.

Personalmente puedo estar tranquilo de haberle dedicado todo el tiempo y esfuerzo que necesitaba por mi parte, de forma que los retrasos no me son imputables.

Espero que la construcción comience dentro de poco, entonces tendré que estar bien encima para supervisar los trabajos.

Home-labbing y domótica ⚠️

Dado que la reforma de la casa aún ni ha comenzado no he podido avanzar mucho en este aspecto.

He dedicado bastante tiempo a investigar diferentes opciones, depurando la instalación que pretendo hacer.

Voy a instalar Home Assistant en mi actual apartamento, aunque no tenga casi nada que automatizar, para irlo aprendiendo y jugar con él un poco.

Inteligencia Artificial ⚠️

He seguido informándome de las novedades en IA (lo cual podría ser perfectamente un trabajo a tiempo completo), y experimentando con algunas cosas, pero menos de lo que me habría gustado.

Hace más de un año que utilizo Venice.ai (enlace con referral), tanto para consultas textuales como para generar imágenes. Me gusta mucho que se basa en modelos de software libre, con una buena interfaz, pero sobre todo que es privado, o sea que no registra conversaciones. Puede usarse gratuitamente y sin registro, pero para los modelos más potentes hace falta la suscripción Pro.

En local utilizo ollama, pero la verdad es que sólo ocasionalmente. Mi propósito era encontrar flujos de trabajo que utilizase a diario, pero no es el caso a día de hoy.

Para generar imágenes estuve probando StabilityMatrix, pero tuve dificultades para ejecutarlo con firejail. Tras varias semanas atascado decidí abandonarlo y centrarme en ComfyUI, que es de los entornos más potentes y creo que continuará siendo desarrollado en el futuro. También tuve algunas dificultades debido a firejail, pero las conseguí superar y finalmente lo tengo funcionando.

Tengo en mente un proyecto que automatice crear LoRAs de personas a partir de un conjunto de fotografias con caras reconocidas. Mi idea es poder apuntarlo a mi colección fotográfica en Digikam o Immich, seleccionar una o más personas con caras reconocidas en la base de datos, y que genere un LoRA para esas personas extrayendo las caras de las fotografias para el entrenamiento. Así después podría generar imágenes que usen a esas personas específicamente.

Voy a procurar escribir artículos sobre todo esto, así me motivo y además progreso con el propósito del blog.

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!

Propósitos de Año Nuevo para 2025

2025-01-06T00:00:00+00:00

Hace un año publiqué mis propósitos para 2024. Lo hice sin intención de convertirlo en una tradición anual, era más bien para desahogarme. No obstante unos amigos me hicieron recientemente reflexionar sobre los propósitos que he cumplido y los que no (esa presión social que yo mismo buscaba en mi publicación), así que voy a aprovechar para dejar esas reflexiones por escrito.

Antes de pasar a la revisión de 2024 y a los propósitos de 2025 debo reconocer que el haber publicado mi lista de propósitos me ayudó a tenerlos en mente todo el año. Incluso aunque muchos no los haya cumplido, los tenía presentes y era consciente de cuándo dejaba alguno de lado.

Lo que he cumplido en 2024

Enfocarme en mis hijos: éxito. No hay mucho que añadir, si hay un propósito que tenía claro era éste.
Amistades: éxito. Siento que he recuperado o reforzado amistades que estaban en peligro, y no me preocupo tanto por las que parecen perdidas (¡aunque nunca sea tarde!).
Experimentar con IA: éxito parcial. Monté un nuevo ordenador con una tarjeta gráfica potente, y he podido "jugar" con distintos modelos para distintas tareas: consultas textuales, generación y reconocimiento de imágenes, generación y análisis de código. No he experimentado con algunos temas que me interesan, como embeddings, ControlNet, sistemas de generación de vídeo o reconocimiento y generación de voz. También me ha faltado integrarlas en mi flujo de trabajo.
Moderar esfuerzos ideológicos: éxito. El preocuparme menos le ha venido muy bien a mi salud mental, aunque no puedo evitar sentirme triste de no poder debatir y hablar de según qué temas con la gente. Siempre he sido intelectualmente muy curioso y activo y el guardarme mis ideas no me sienta bien.
Redes sociales y mensajería: éxito parcial. He reducido mi uso de redes sociales. Las que consulto lo hago desde el ordenador, no tengo ninguna en el móvil. A veces pasan días sin ver ninguna. No obstante no he conseguido cumplir mi propósito de no mirar la mensajería durante el día ni desactivar las notificaciones.

Lo que no he cumplido en 2024

Consultoría: fracaso. Las trabas burocráticas me hicieron tomar la decisión de cerrar la empresa. Quizá fue una racionalización post-hoc, pero también pensé que quizá no tenía que seguir haciendo lo mismo que siempre sólo porque se me dé bien. Necesito encontrar el cruce entre mis habilidades y mis motivaciones.
Criptomonedas: fracaso. No he colaborado con ningún proyecto, de hecho me he distanciado un poco del mundillo para enfocarme en los otros propósitos. No obstante he colaborado con diferentes proyectos de software libre aunque no relacionados con criptomonedas, sobre todo algunos que utilizo personalmente a diario.
Más blog: rotundo fracaso. Ni un sólo artículo en 2024 después de publicar el de los propósitos. Y ha sido por falta de ideas, porque tengo muchas, las voy anotando y desarrollando entre mis notas. Pero después no me siento a escribir artículos, aunque ya los tenga casi terminados en la cabeza. Creo que mi barrera principal es el temor a ser juzgado, sobre todo si publico temas personales o ideológicos en vez de sólo técnicos.

Mis propósitos para 2025

Familia y amigos

Un éxito de 2024 que tengo intención de mantener este año y siguientes.

Entre muchas otras cosas, quiero enseñar informática y programación a mis hijos. Los ordenadores han sido una piedra angular en mi vida y quiero que ellos tengan al menos la oportunidad de conocerlos, ya veremos si les enganchan como a mí.

También quiero empezar a viajar más con ellos ahora que el más pequeño ya no es un bebé. El mundo es un lugar a la vez muy grande y muy pequeño, me gustaría que tuviesen una cultura global.

Me gustaría tener la oportunidad al menos una vez al año de pasar unos días de frikeo con amigos.

Perder peso

Quienes me conocen saben que gano peso con facilidad. Hago levantamiento de peso y algo de cardio, y eso me mantiene si no delgado, al menos no muy gordo. Pero bastan 2 semanas de navidades para ganar 5 o 6 kilos.

Mi plan es hacer un esfuerzo consciente por regular mi dieta y perder peso de forma sana y progresiva durante el año. Lo he hecho en el pasado, pero esta vez quiero bajar de mi anterior peso mínimo histórico.

Consideraré este propósito un éxito si pierdo una talla de pantalón, o si se ve el más ligero atisbo de tableta de chocolate. ¡Ojo!, tener unos abdominales marcados es un esfuerzo tremendo que no estoy dispuesto a realizar, no nos volvamos locos.

Blog

Como expliqué antes, el blog ha estado abandonado durante 2024, y eso que tenía muchas ideas para artículos.

Mi propósito es superar mis limitaciones y realmente escribir en el blog, tanto sobre temas técnicos como ideológicos.

Por poner una métrica de éxito tangible, apuntemos a un mínimo de un artículo al mes, idealmente dos.

Nueva casa

El año pasado compramos nuestra primera casa, y necesita bastante reforma. Eso no es un problema de por sí, es algo que sabíamos y buscábamos, para poder renovarla a nuestro gusto.

Quiero estar disponible y enfocado para controlar el proceso y que quede lo mejor posible.

Home-labbing y domótica

Relacionado con la nueva casa: pienso aprovechar para montar un nuevo servidor que reemplace a mi actual, que ya se queda pequeño.

También planeo instalar una variedad de sensores por la casa, y gestionar las automatizaciones con Home Assistant.

Quién sabe, lo mismo sale algún negocio de estas pasiones. ¡O al menos espero que dé para algunos buenos artículos en el blog! guiño

Inteligencia Artificial

Me siguen fascinando los avances en IA, creo que con la tecnología actual ya es algo con un potencial enorme, lo que faltan son productos orientados al usuario final, y esos acabarán llegando.

En 2024 pude experimentar lo que mi tiempo disponible me permitía, pero en 2025 quiero ir más allá y encontrar integraciones y flujos de trabajo que me sean útiles.

Aunque no sea una prioridad inicial, me gustaría tener hardware en el nuevo servidor orientado a inferencia local. Así podría ofrecer servicios de IA a la familia, con datos completamente privados.

Propósitos de Año Nuevo para 2024

2024-01-01T00:00:00+00:00

Llevo varios meses reflexionando sobre la vida, quizá estoy viviendo mi particular crisis de la mediana edad.

Este año 2024 quiero poner de mi parte para corregir aquello que esté en mi mano (y preocuparme menos por lo que no), de ahí esta lista de propósitos de Año Nuevo.

Publicar estos propósitos tiene un propósito doble:

Que la gente entienda mis prioridades y las razones que las motivan.
Mantener mi enfoque a lo largo del año gracias a la presión social.

Enfocarme en mis hijos

En el momento de escribir este artículo mis hijos tienen 5 años y 17 meses, y los quiero más que a nada, me alegran todos los días.

Este último año ha sido difícil combinando mi último trabajo con el nacimiento de mi segundo hijo, mi salud mental se resintió al esforzarme en mantener mi productividad habitual.

En este año 2024 mi enfoque será primero en mis hijos, y procuraré no sentirme culpable de lo que no me llegue el tiempo para hacer.

Amistades

He ido perdiendo el contacto con diversos amigos, creo que fundamentalmente por dos razones:

La distancia, primero cuando viví en San Francisco, y ahora en Lisboa. Con varios amigos intenté mantener el contacto, pero no reciprocaron.
Siento que algunos amigos me han dado de lado por mis ideologías. No puedo estar seguro pero me entristece pensar que sea el caso.

Procuraré dedicar mis esfuerzos a las amistades que merecen la pena, quienes me demuestran que me respetan y que les importo tanto como ellos a mi. Sin rencores con el resto, la vida cambia y es complicada para todos.

Consultoría

Este año organizaré mi servicio de consultoría y que se convierta en una fuente de ingresos. Mi objetivo es ayudar a empresas y proyectos que se beneficien de mis 16 años de experiencia en desarrollo web.

En las próximas semanas montaré una página web y buscaré mis primeros clientes.

Experimentar con IA

Me interesan mucho los nuevos avances en Inteligencia Artificial, procuraré dedicarle tiempo a aprender y experimentar.

Generación de imágenes y vídeos. Tengo varios proyectos personales en mente, pero aparte quiero sentarme con mi hija y que ella aprenda a generar imágenes e interactuar con las IAs. Creo que será algo importante para su futuro.
LLMs (Large Language Models) para distintos temas: programación, chat, embeddings.
Generación de voz. Quiero clonar mi voz y la de mi familia con modelos locales.
Traducciones. Un primer objetivo es automatizar la traducción de los artículos de mi blog, con revisión manual.

Criptomonedas

Las criptomonedas me apasionan desde hace muchos años, pero nunca me he involucrado como desarrollador, cosa de la que me arrepiento.

Este año quiero empezar a colaborar como programador en proyectos afines, sobre todo aquellos que se centran en criptomonedas como medios de pago.

También haré más esfuerzos en usar criptomonedas en el día a día, inspirado por Joel Valenzuela.

Moderar esfuerzos ideológicos

Quienes me conocen desde hace tiempo saben que mi ideología ha cambiado radicalmente en los últimos 10 años. Sospecho que muchos lo vean como una traición a mis principios, o el haberme convertido en otra persona. A mi modo de ver es una evolución natural producto de educarme y reflexionar sobre temas a los que no había estado expuesto con anterioridad.

Lo que no anticipaba era el esfuerzo mental y emocional de oponerse al zeitgeist hegemónico, es algo que me ha pasado factura en cuanto a felicidad y salud mental. Sería fácil plegarme a la mayoría y volver al redil, evitar discusiones y peleas, pero creo que me sentiría mal conmigo mismo por la deshonestidad intelectual.

Mi propósito es por un lado preocuparme menos sobre mi pureza, pero por otro ser firme cuando toque debatir. Una cosa son las ideas que tenga y otra es que no quiera o pueda dedicarle mayores esfuerzos en sostenerlas en oposición a casi toda la sociedad.

Sí que me enfocaré en educar a mis hijos en los valores que quiero ver en el mundo.

Redes sociales y mensajería

Hace ya tiempo que reduje mi uso de redes sociales considerablemente, eliminando aplicaciones de mi teléfono móvil por ejemplo, pero este año quiero ir un paso más allá para poder enfocarme de verdad:

Consultaré mensajes y redes sociales sólo dos veces al día: por la mañana con el café y por la noche cuando se acuesten mis hijos.
Eliminaré absolutamente todas las notificaciones. Si alguien me necesita urgentemente ya me llamará, si no puede esperar.
Dedicaré las redes sociales sólo a los temas funcionales que me interesan (software libre, criptomonedas, IA), y reduciré los temas ideológicos.

Más blog

Quiero escribir más en mi blog, de todos los temas que me interesan, y también alguna entrada personal como esta. Necesito dejar el perfeccionismo a un lado y escribir más rápido, sin pensármelo tanto.

Para empezar con buen pie, esta entrada la escribí en 2 horas de reloj.

Empiezo a pensar en lo que será mi legado (sí, definitivamente estoy en una crisis de mediana edad), y mi blog puede convertirse en una ventana a mi vida y mis intereses para mis hijos.

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!

Anuncio público: mi apuesta de BTC con tripu

2023-05-06T00:00:00+00:00

Haciendo eco a la apuesta sobre los futuros precios relativos entre Bitcoin y el dólar estadounidense que Balaji y Medlock cerraron públicamente el 2023-05-02 (confirmación de Balaji; confirmación de Medlock), hoy tripu y yo acordamos los siguientes términos para nuestra particular apuesta:

El objeto de la apuesta es si Bitcoin (BTC) alcanza un precio de 1 millón en dólares estadounidenses al menos una vez en los próximos 90 días.
Si al menos dos fuentes de confianza anuncian que BTC superó la cotización de $1 millón en cualquier punto antes de las 23:59:59 UTC del 2023-08-04, Fidel ganaría la apuesta. En caso contrario, tripu ganaría la apuesta.
Consideramos fuentes fiables los medios habituales de noticias e información financiera: Google Finance, Yahoo Finance, Bloomberg, el New York Times, etc.
Fidel apuesta 500€ (quinientos euros) en dinero fiat. tripu apuesta 0.019195752 BTC (500€ en BTC usando el precio de cierre de 26.170,33€ en 2023-05-05). Quién pierda la apuesta pagará su parte al ganador, no más tarde de un mes después de que se resuelva la apuesta.
Tanto Fidel como tripu publican este texto por duplicado (excepto ediciones triviales, como intercambiar nuestros nombres) en nuestros respectivos blogs hoy (2023-05-06).
Cada uno enlazará al artículo del otro, y a copias archivadas de ambos en archive.org o archive.ph.
Somos caballeros (y amigos) y por tanto consideramos suficientes estos términos.

Enlaces:

Artículo de tripu: https://blog.tripu.info/btc-bet
Este artículo en archive.org:https://web.archive.org/web/20230507142041/https://blog.fidelramos.net/es/cryptocurrency/btc-bet
Artículo de tripu en archive.org: https://web.archive.org/web/20230507134521/https://blog.tripu.info/btc-bet/

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

Mi proceso fotográfico con software libre

2022-03-31T00:00:00+00:00

En este artículo presento una guía paso a paso de mi proceso fotográfico. No voy a meterme en todos los detalles de todos los programas que menciono, dado que ya tienen su propia documentación y manuales, me limitaré a resaltar las operaciones que realizo.

Mis objetivos principales son:

Control total sobre todos mis datos, sin servicios externos.
Uso exclusivo de software libre.
Rapidez en las operaciones habituales: descarga de nuevas fotos, edición, post-procesado.
Organizar la colección con metadatos.
Sincronización y backup automáticos.
(A futuro) Acceso y compartición transparente de las fotos.

Índice de contenidos

1. Descargar fotos con Digikam
2. Revisar con Geeqie
3. Procesado de RAW con RawTherapee
4. Organizar en Digikam
5. Replicación con Syncthing
6. Copia de seguridad con restic
Epílogo
Actualizaciones

1. Descargar fotos con Digikam

Uso el fantástico programa Digikam para organizar mi colección de fotos (181708 fotos y 3127 vídeos en 2198 álbumes a fecha de marzo 2022). Descargo las fotos de mis cámaras con Digikam porque tiene un filtro muy útil "Sólo elementos nuevos" (Only new items), de forma que cuando conecto la cámara sólo veo los nuevos contenidos.

Tengo dos colecciones de fotos en Digikam: Fotos y Fotos por ordenar. La primera son las fotos que ya están procesadas y organizadas, y se sincroniza con mi servidor casero; la segunda es donde descargo las nuevas fotos para procesarlas y organizarlas, y luego las muevo a Fotos cuando están listas.

La mayoría de mis fotos están clasificadas en álbumes por fecha, y Digikam también es de ayuda para esto porque se pueden seleccionar las fotos a descargar por fecha, haciendo click en el título de sección, luego uso la opción "Descargar seleccionadas" (Download Selected).

Importar desde cámara en Digikam

Digikam entonces pregunta dónde descargarlas, y ahí directamente puedo crear un nuevo álbum:

Crear nuevo álbum en Digikam durante la importación

Le pongo la categoría, descripción y fecha al álbum directamente, para que no se me olvide hacerlo después:

Ventana de nuevo álbum en Digikam

2. Revisar con Geeqie

Cuando se han descargado todas las fotos cambio a Geeqie para verlas y borrar las malas (desenfocadas, borrosas, sobreexpuestas o subexpuestas, etc.) Lo llevo usando desde que se llamaba GqView, hay muchos otros visores de imágenes pero ya estoy acostumbrado a éste.

En este punto necesito mencionar que en mis cámaras uso el modo JPEG+RAW, aunque siempre postprocese el RAW y borre los JPEG creados por la cámara. La razón es que me gusta poder hacer zoom al 100% para ver los detalles de las fotos y borrar las malas lo antes posible, y las imágenes RAW normalmente tienen las previsualizaciones a tamaño reducido (por ejemplo los ficheros RAW creados por mi Sony A7 III tienen una previsualización de 1616x1080 píxeles, lo que es pequeño para una pantalla 4K).

Hay dos características imprescindibles para mí en esta fase:

Agrupar los ficheros para ver sólo los JPEG, pero borrar todos los ficheros de un grupo.
Mantener el zoom y la posición de la vista cuando se cambia de imagen.

El agrupado de ficheros significa que por defecto Geeqie sólo muestra el fichero JPEG, mientras que los ficheros RAW y potencialmente otros (por ejemplo sidecars como XMP o PP3) se ocultan, pero pueden verse expandiendo el grupo con un click. De esta forma cuando se borra un grupo se borran todos los ficheros, no sólo el JPEG. Geeqie reconoce la mayoría de ficheros sidecar, pero si es necesario se puede configurar en las Preferencias:

Configuración del agrupado de sidecar en Geeqie

La otra característica que necesito es el poder hacer zoom al 100% en una foto, cambiar a la foto siguiente o anterior para compararlas, y que la vista se mantenga en la misma posición, es decir que no se resetee a la esquina superior izquierda o algo así como hacen otros visores. Geeqie tiene este comportamiento por defecto, combinado con sus atajos de teclado (Z para zoom 100%, X para zoom ajustado a la ventana, AvPág y RePág para cambiar de imagen) me funciona muy bien.

Quiero mencionar que soy consciente de que Digikam tiene una funcionalidad para ver las fotos y compararlas por parejas (Lightroom en inglés): se ve una imagen a la izquierda, la siguiente en la derecha, y cuando se cambia el zoom o se mueve la vista ambos paneles se mantienen en sincronía. Pinta perfecto pero tiene un gran inconveniente para mí: cuando borro una foto no borra el fichero RAW asociado, lo deja huérfano. No he encontrado una forma de resolver esto en Digikam, lo que puedo hacer es ejecutar un comando para borrar todos los ficheros huérfanos, o echar las fotos sólo en formato RAW (pero entonces perdería resolución de previsualización). Por esta razón sigo usando Geeqie.

Digikam Lightroom

3. Procesado de RAW con RawTherapee

Actualmente proceso la mayoría de mis fotos con RawTherapee, un fabuloso software libre que es a la vez fácil de usar y produce fotos de muy alta calidad. En el pasado he usado también Darktable, pero aunque tiene más funcionalidades me costaba más tiempo y esfuerzo lograr los resultados que suelo buscar, sobre todo porque la reducción de ruido de RawTherapee funciona mucho mejor.

En cualquier caso, abro el directorio con el álbum en RawTherapee, aplico un perfil base a todas las fotos y luego aplico perfiles parcialmente para aclarar (sharpen) imágenes con bajo ruido, aplicar una leve reducción de ruido a las imágenes con ISO intermedio y reducción de ruido agresiva para aquellas con ISOs elevados. Uso el filtrado para primero seleccionar sólo los ficheros RAW y luego aplico subfiltros por ISO.

Filtrado en RawTherapee

Perfiles de procesado en RawTherapee

Después aplico corrección a la distorsión de lente a todas las fotos. La detección automática de lente me falla por alguna razón que desconozco, así que uso el proceso en grupo (Batch Edit), selecciono todas las fotos en el álbum y selecciono manualmente la cámara y lente.

Correción de distorsión de lente en RawTherapee

Lo siguiente es revisar las fotos una por una, haciendo ajustes: exposición, balance de blancos, recorte, etc. No voy a entrar en detalles porque es edición normal con RawTherapee. Si te interesa saber más no dudes en enviarme un mensaje y consideraré hacer un artículo o vídeo al respecto.

Cuando todo está listo pongo las fotos en la cola (Queue) y las exporto al mismo directorio donde están los ficheros RAW (%p1/%f como la plantilla en Output Location). Cuando necesito retocar alguna foto después del revelado (normalmente en GIMP) entonces uso formato TIFF, dado que JPEG es un formato con pérdida y perdería calidad si se vuelve a modificar.

Cola en RawTherapee

4. Organizar en Digikam

Cuando RawTherapee ha terminado de guardar las fotos borro los JPEG generados por la cámara, luego vuelvo a Digikam y refresco (Refresh) el álbum para ver los nuevos ficheros.

Lo siguiente es agrupar las fotos por nombre, para ver sólo los JPEG y no los RAW. En el álbum selecciono todos los ficheros (CTRL+A) y luego con un click derecho en cualquier imagen Agrupar → Agrupar seleccionados por nombre de fichero.

Agrupar ficheros en Digikam: antes y después

A continuación uso la detección de caras para que Digikam reconozca las caras de las personas en las fotos. Selecciono todas las fotos (CTRL+A), click derecho y Escanear caras (Scan for Faces). Cuando el proceso termina voy a la pestaña de Personas (People) en la izquierda para revisar los resultados, aceptar los buenos y corregir los malos.

Después reviso las etiquetas. La organización por etiquetas es algo personal, pero yo aprovecho que las etiquetas en Digikam tienen una estructura jerárquica, de forma que por ejemplo uso etiquetas para la localización como place → Colombia → Zapatoca. En este punto también me aseguro que todas las personas estén etiquetadas, dado que el reconocimiento facial falla a veces, y me gusta tener etiquetado a todo el mundo para poder filtrar más adelante de forma efectiva.

Etiquetas en Digikam

Para acelerar el etiquetado le asigno atajos de teclado a las etiquetas que uso más habitualmente. Es sólo cuestión de editar las propiedades de una tag con un click derecho y luego asignarle el atajo deseado:

Editar etiqueta en Digikam

El último paso es puntuar las fotos con 1 a 5 estrellas. Hago doble click en la primera foto del álbum, uso los atajos de teclado para asignarle la puntuación deseada (de CTRL+1 a CTRL+5, esos son atajos por defecto) y las teclas de cursor atrás y adelante para cambiar de foto. El significado de las puntuaciones es también algo personal, pero esta es la lógica que uso yo para mi colección:

1 estrella: Mala calidad o duplicado. No merece la pena verse salvo que busque algo específico. Si le estuviese mostrando el álbum a alguien probablemente excluiría esta foto.
2 estrellas: Mi puntuación por defecto en caso de duda. No tiene mala calidad y puede ser interesante, pero tampoco es fundamental para el álbum.
3 estrellas: Una foto representativa del álbum en el que se encuentra, es decir que si le mostrase a alguien sólo las fotos de 3 o más estrellas vería lo mejor del álbum sin tener que aguantar demasiadas fotos.
4 estrellas: Buena foto: enfocada, buena iluminación y composición. Si me puede interesar buscar una foto como independiente de su álbum eso significa que es de 4 estrellas.
5 estrellas: Gran foto, o bien por sus características artísticas y técnicas o porque tiene un significado especial para mí (buena foto de mi hija, por ejemplo). Foto de la que me siento orgulloso.

Esta organización me permite luego filtrar mi colección para encontrar lo que quiera, por ejemplo todas las fotos con todos los miembros de mi familia con 4 estrellas o más, y quizá filtrar por fecha también.

Cuando termino de organizar el álbum lo muevo de mi colección Fotos por organizar a Fotos sólo arrastrándola en Digikam. Una vez movidas se replicarán automáticamente a mi servidor casero.

5. Replicación con Syncthing

Uso Syncthing para replicar mis datos entre mis diferentes dispositivos (ordenador, servidor, teléfono móvil). Funciona a la perfección, lo recomiendo encarecidamente.

Especificamente para mi proceso fotográfico sincronizo dos directorios entre mi ordenador y mi servidor casero:

El directorio con las fotos ya organizadas.
El directorio con las bases de datos de Digikam en formato SQLite. Lo tengo separado de la colección de fotos por motivos históricos, porque antes tenía las fotos en un disco duro magnético mientras que mi disco principal era un NVMe, de forma que el rendimiento era mucho mejor si las bases de datos estaban en este último.

Configuro ambos directorioes como "sólo enviar" (send-only) en el ordenador, y "sólo recibir" (read-only) en el servidor:

Configuración de directorio en Syncthing

También configuro el control de versiones en el servidor, para tener facilidad de recuperación en caso de borrados o alteraciones erróneas:

Versionado de ficheros en Syncthing

Mi servidor casero tiene 4 discos duros, uno de los cuales está configurado como paridad usando SnapRAID para tolerancia a errores. Puedes encontrar más detalles sobre la configuración de mi servidor casero en mi artículo sobre mi homelab (en inglés).

6. Copia de seguridad con restic

Mi servidor casero hace una copia de seguridad incremental cada semana a Wasabi usando restic. La copia de seguridad incluye mi colección de fotos completa, además de cualquier otro dato personal que no sería recuperable en caso de catástrofe. Puedes ver mi script de backup con restic y ajustarlo a tus necesidades. Uso Ansible para generar las listas de ficheros incluidos y excluidos. El script es ejecutado por cron cada semana, de noche.

¿Por qué restic? Cuando estaba investigando las opciones disponibles leí muy buenas opiniones que decían que hacía las cosas bien, y la verdad es que me ha funcionado sin demasiados problemas. Si tuviese que implementarlo todo otra vez me gustaría investigar Borg como alternativa, pero es posible que volviese a elegir restic.

¿Por qué Wasabi? Tiene una API compatible con S3 y de los precios más baratos que pude encontrar, más que Backblaze, sobre todo contando conque no tiene costes para el envío o recepción de datos.

Por supuesto la copia de seguridad va cifrada.

Epílogo

Este proceso es la evolución de 20 años de fotografía digital. Espero que hayas podido aprender algo nuevo que puedas aplicar a tu propio proceso fotográfico. Actualizaré este artículo a medida que haga cambios a las herramientas que uso.

Quizá te estés preguntando sobre el último de los objetivos que mencioné al principio del artículo: "acceso y compartición transparente de las fotos". Estoy trabajando en la creación de un software de galería web que dé acceso a mi colección fotográfica completa y que permita navegar utilizando los metadatos de Digikam. El software se ejecutaría en mi servidor casero, donde ya se alojan las fotos y se sincronizan todas las nuevas. Esto significa que tras organizar las fotos en Digikam estarían disponibles para su acceso desde cualquier dispositivo de mi elección manteniendo el control sobre mis datos y sin tener que subirlos a ningún otro servicio. Pienso liberar el software con licencia libre cuando sus funcionalidades básicas funcionen, sigue el blog por RSS o sígueme en redes sociales si te interesa estar al tanto de su lanzamiento.

Si tienes cualquier comentario o sugerencia me encantaría oírlo, no dudes en mencionarme o enviarme un mensaje por redes sociales, o un email. Puedes ver mis datos de contacto en mi página web.

Actualizaciones

2022-04-05: Corregido el nombre de RawTherapee. Gracias por los desternillantes comentarios, Hacker News.
2024-01-01: Incluido enlace al artículo del homelab.

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

Omarchy y el punto óptimo de seguridad

El punto óptimo de la seguridad

La evolución de mi punto óptimo

Qué voy a buscar en mi futuro SO de escritorio

Añadir nuevos git trailers a Magit

Configuración de Magit

Bonus: recordando los valores entre sesiones con savehist

Reflexiones finales

Higiene de la cadena de suministro en Emacs: revisando actualizaciones mediante IA

Resumen de la configuración

Paso 1: verificar la instalación de straight.el

Paso 2: fijar las versiones conocidas

Paso 3: revisar los diffs antes de fusionar

Paso 4: revisión del diff mediante un LLM

Flujo de trabajo para las actualizaciones

Limitaciones y reflexiones finales

Revisión de mis propósitos para 2026

Gastar menos tiempo en tareas ❌

Fotografía ⚠

No Morir ✅

Portugués ✅

Blog ✅

Self-hosting ⚠

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

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`