Nezzontli - Server

Servidor personal: Debian + Docker, no FreeBSD

2026-07-16T00:00:00+00:00

Contexto</h2>
Este post reemplaza una entrada anterior que describía el plan original: FreeBSD, jails, bastilleBSD. Ese plan no se ejecutó así. Lo que terminó corriendo en la máquina reusada (hostname `pcale</code>) es Debian 13 (Trixie)</strong> con todo containerizado en Docker</strong>, un stack por servicio en docker-compose.yml</code> separados, sin hypervisor ni jails.</p>`
`La razón del cambio fue práctica: Docker Compose me da aislamiento por servicio sin la curva de aprendizaje adicional de jails/bhyve, y el ecosistema de imágenes ya resueltas (linuxserver, imágenes oficiales) redujo tiempo de instalación a casi cero comparado con compilar todo desde ports.</p>`

Infraestructura base</h2>

SO:</strong> Debian 13 (Trixie), kernel 6.12.x</li>
Actualizaciones:</strong> unattended-upgrades</code> para parches de seguridad automáticos</li>
Todo lo demás vive en contenedores</strong> — cada servicio tiene su propio docker-compose.yml</code> bajo /home/ale/<servicio>/</code>, así config, volúmenes y upgrades quedan aislados por app</li>
</ul>
Acceso y red</h2>
No hay puertos abiertos al público en el router. El acceso normal es vía Tailscale</strong>: cada servicio interno se publica con un hostname propio y HTTPS real usando Tailscale Services:</p>
tailscale</span></span> serve --</span>service</span>=</span>svc:<</span>nombre></span> -</span>-bg --</span>https</span>=</span>443 http://localhost:<</span>puerto></span>
</span></span>tailscale</span></span> serve --</span>service</span>=</span>svc:<</span>nombre></span> -</span>-bg --</span>http</span>=</span>80 http://localhost:<</span>puerto></span>
</span></span></code></pre>
Esto da URLs como https://nextcloud.tail32b955.ts.net</code>, con certificado válido, sin recordar puertos. Un par de servicios sí salen a internet público, pero vía Cloudflare Tunnel</strong> (cloudflared</code>, conexión saliente únicamente, nada expuesto en el router) — el caso principal es PeerTube en tube.richard69.lat</code>.</p>
Perímetro:</strong></p>

SSH solo con clave, llave de seguridad física (YubiKey), X11Forwarding</code> desactivado</li>
ufw</code> en default-deny, la mayoría de servicios restringidos a LAN (192.168.68.0/24</code>) + Tailscale (100.0.0.0/8</code>)</li>
fail2ban</code> en el jail de SSH (maxretry 3, ban 24h)</li>
Vaultwarden llegó a tener un hostname público en el tunnel; se sacó por completo y ahora es Tailscale-only</li>
</ul>
Servicios corriendo</h2>
Nube y datos personales</strong></p>

Nextcloud</strong> — almacenamiento personal, también sirve como fuente de la biblioteca de Calibre-web (apunta directo a Documents/Libros</code> sin duplicar archivos)</li>
Immich</strong> — fotos</li>
Vaultwarden</strong> — gestor de contraseñas (servidor compatible con Bitwarden), solo por Tailscale</li>
Calibre-web</strong> — lector/biblioteca de ebooks</li>
</ul>
Media</strong></p>

Jellyfin</strong> — servidor de medios (películas, series, música)</li>
qBittorrent + Radarr + Sonarr + Prowlarr</strong> — el stack *arr completo: indexers → búsqueda → descarga → importación, aterrizando directo en la biblioteca de Jellyfin, que se refresca sola al importar</li>
Navidrome</strong> — streaming de música</li>
spotiflac</strong>, AudioMuse AI</strong> — utilidades de música</li>
PeerTube</strong> — instancia propia y federada de video (tube.richard69.lat</code>), con una imagen parcheada a mano (ver abajo)</li>
</ul>
Todo el lado de descargas (qBittorrent, Radarr, Sonarr, Prowlarr, spotiflac) corre con network_mode: container:mullvad-exit-vpn</code>, compartiendo el namespace de red de un único contenedor gluetun</a>, así ese tráfico —y solo ese— sale por un exit de Mullvad vía WireGuard.</p>
Un extra que armé sobre esto: un script que convierte un canal de PeerTube seguido en una biblioteca de Jellyfin de archivos .strm</code> (punteros a la URL del HLS del video original). Jellyfin los reproduce en directo desde la instancia origen sin que el archivo toque el disco del servidor.</p>
Utilidades</strong></p>

Glance</strong> — dashboard único: bookmarks, RSS, clima, chequeos de salud de cada servicio, buscador</li>
4get</strong> — metabuscador privado, también el buscador embebido en Glance</li>
ntfy</strong> — notificaciones push self-hosted (alertas del servidor, watchdog de la VPN, etc.)</li>
Uptime Kuma / Beszel</strong> — monitoreo, con umbrales de alerta mandando a ntfy</li>
Prosody</strong> — mensajería XMPP</li>
Forgejo</strong> — Git self-hosted (donde vive este mismo blog)</li>
</ul>
Problemas encontrados (y soluciones)</h2>
network_mode: container:X</code> no se re-resuelve solo.</strong> Docker fija esa referencia a un container ID</em> en el momento de crear el contenedor. Si gluetun se recrea (docker compose up --force-recreate</code>, o cualquier reinicio del stack), todo lo que comparte su netns (qBittorrent, Radarr, Sonarr, Prowlarr, spotiflac) queda apuntando a un namespace huérfano. El síntoma es engañoso: el contenedor se ve Up (healthy)</code> y su proceso interno escucha bien desde adentro, pero nada llega desde afuera. Fix: force-recreate de cada contenedor afectado, no alcanza con docker restart</code>.</p>
*La ruta de descarga de un arr no puede ser su propia root folder.</em></em> Si la categoría de qBittorrent apunta al mismo path que el root folder de Radarr/Sonarr, la app no puede distinguir “todavía bajando” de “ya importado” y tira DownloadClientRootFolderCheck</code>. Solución: carpetas de staging separadas (/media/downloads/movies</code>, /media/downloads/shows</code>), Radarr/Sonarr importan por hardlink desde ahí al root folder real.</p>
ntfy en iOS necesita un base-url</code> alcanzable.</strong> iOS no puede recibir contenido completo en el push directamente (limitación de APNs) — el teléfono hace polling al base-url</code> del propio servidor después de recibir un push genérico de “new message”. Si ese base-url</code> apunta a un dominio muerto, la notificación queda vacía sin ningún error visible en ningún lado.</p>
PeerTube solo acepta thumbnails remotos en JPEG.</strong> El validador de videos federados de PeerTube rechaza en silencio cualquier video cuyo thumbnail remoto sea PNG o WebP. Lo resolví con un parche chico horneado en una imagen Docker custom — hay que reconstruirla (no solo docker compose pull</code>) en cada actualización de PeerTube o el parche desaparece sin avisar.</p>
Qué falta por hacer</h2>

Cloudflare Access delante de Uptime Kuma si algún día se tunelea al público</li>
Reglas de ufw</code> para un par de servicios más nuevos (4get, AudioMuse) que hoy solo responden desde localhost</li>
Un manual real de recuperación ante desastres — por ahora ese conocimiento vive en mis notas, no en un documento</li>
</ul>
Idea central</h2>
El objetivo cambió de “aprender FreeBSD a fondo” a “tener servicios propios corriendo de forma confiable, con el mínimo de superficie expuesta al público”. Docker Compose y Tailscale resultaron el camino más corto ahí. FreeBSD y jails siguen siendo un proyecto que me interesa, pero para otro momento — ver el post de OpenBSD</a> para la versión de “control total” aplicada a algo más chico (el hospedaje de este mismo sitio).</p>
Referencias</h2>

Documentación de Tailscale</a></li>
gluetun</a></li>
Glance</a></li>
Servarr Wiki</a></li>
Documentación de PeerTube</a></li>
</ul>



Uso de OpenBSD para hospedaje de página web
2026-02-03T00:00:00+00:00
Contexto y motivación</h2>
Decidí migrar el hospedaje de mi página web a OpenBSD como un ejercicio deliberado de control, simplicidad y seguridad.

No fue una decisión basada en rendimiento, escalabilidad comercial ni automatización extrema, sino en comprensión total del sistema.</p>
OpenBSD obliga a entender cada archivo de configuración, cada servicio activo y cada permiso. No oculta complejidad: la expone. Ese fue el motivo central de esta migración.</p>
El objetivo era claro: un servidor auditable, predecible y mínimo.</p>
Infraestructura y VM</h2>
El servidor corre en una máquina virtual alquilada (VPS) de bajo costo, suficiente para contenido estático y servicios mínimos.</p>
Características generales de la VM:</p>

1 vCPU</li>
1–2 GB de RAM</li>
Almacenamiento SSD</li>
IP pública dedicada</li>
Acceso root inicial para bootstrap</li>
</ul>
El proveedor no es relevante: OpenBSD no depende de features del host. El sistema se mantiene portable y reproducible.</p>
Elección del stack</h2>
El stack fue elegido conscientemente para reducir superficie de ataque:</p>

Sistema operativo: OpenBSD</li>
Servidor web: httpd (nativo)</li>
HTTPS: acme-client (Let’s Encrypt)</li>
Generador estático: Zola</li>
Tema: Duckquill (modificado)</li>
Repositorio: Git + GitHub</li>
Acceso remoto: SSH con YubiKey (OpenPGP)</li>
Servicio oculto: Tor (mirror .onion)</li>
</ul>
No hay nginx, no hay docker, no hay paneles web, no hay Node en producción. Solo binarios del sistema base y archivos de texto.</p>
Migración a OpenBSD</h2>
La migración incluyó:</p>

Instalación limpia de OpenBSD</li>
Configuración manual de red y DNS</li>
Creación explícita de usuarios</li>
Uso exclusivo de doas (sin sudo)</li>
Servicios deshabilitados por defecto</li>
</ul>
Separación clara entre: sistema (/etc), contenido (/var/www), claves (/etc/ssl, /etc/acme). Nada se dejó “por default” sin entenderlo.</p>
Servidor web con httpd</h2>
El servidor web se configuró usando httpd nativo, sin módulos externos.</p>
Configuración base simplificada:</strong></p>
server "nezzontli.xyz" {
</span>    listen on * port 80
</span>    root "/htdocs"
</span>
</span>    location "/.well-known/acme-challenge/*" {
</span>        root "/acme"
</span>        request strip 2
</span>    }
</span>}
</span>
</span>server "nezzontli.xyz" {
</span>    listen on * tls port 443
</span>    root "/htdocs"
</span>
</span>    tls {
</span>        certificate "/etc/ssl/nezzontli.xyz.fullchain.pem"
</span>        key "/etc/ssl/private/nezzontli.xyz.key"
</span>    }
</span>}
</span></code></pre>
HTTPS con acme-client</h2>
OpenBSD incluye acme-client en base, lo que elimina dependencias externas.</p>
Flujo real:</strong></p>

Configurar httpd solo en HTTP</li>
Resolver DNS correctamente (A records apuntando a la VM)</li>
Ejecutar: doas acme-client -v nezzontli.xyz</code></li>
Verificar creación de certificados en /etc/ssl</li>
Habilitar TLS en httpd</li>
Reiniciar servicio</li>
</ol>
No se usan scripts externos. La renovación se maneja vía cron del sistema.</p>
Problemas encontrados (y soluciones)</h2>
1. Error 404 en ACME challenge</h3>
Causa:</strong> httpd no estaba sirviendo correctamente /var/www/acme.</p>
Solución:</strong></p>
doas</span></span> mkdir -</span>p</span> /var/www/acme</span>
</span>doas</span></span> chown -</span>R</span> web:web /var/www</span>
</span></code></pre>
2. DNS no propagado</h3>
Durante el primer intento, el dominio resolvía a múltiples IPs antiguas: dig nezzontli.xyz +short</code></p>
Solución:</strong> Esperar propagación completa y eliminar registros conflictivos.</p>
3. Confusión con DNSSEC</h3>
DNSSEC no es requisito para Let’s Encrypt HTTP-01. DNSSEC es independiente de TLS. No se activó en esta etapa.</p>
Generación del sitio con Zola</h2>
El sitio es 100% estático.</p>
Flujo básico:</strong></p>
zola</span></span> build</span>
</span>doas</span></span> rsync -</span>a</span> --</span>delete</span> public/ /var/www/htdocs/</span>
</span></code></pre>
No hay generación en runtime. No hay escritura desde el servidor web.</p>
Mirror Tor (.onion)</h2>
Se configuró un Hidden Service de Tor como mirror del sitio.</p>
/etc/tor/torrc:</strong></p>
HiddenServiceDir /var/tor/hidden_service/
</span>HiddenServicePort 80 127.0.0.1:80
</span></code></pre>
httpd escucha solo en localhost para Tor:</strong></p>
server "*" {
</span>    listen on 127.0.0.1 port 80
</span>    root "/tor"
</span>}
</span></code></pre>
Build específico para Tor:</strong></p>
zola</span></span> build --</span>base-url</span> http://<</span>onion></span>.onion</span>
</span>doas</span></span> rsync -</span>a</span> --</span>delete</span> public/ /var/www/tor/</span>
</span></code></pre>
Integración Tor Browser (Onion-Location):</strong></p>
<</span>meta</span> http-equiv</span>=</span>"</span>onion-location"</span></span></span> content</span>=</span>"</span>http://<onion>.onion"</span></span></span>></span></span>
</span></code></pre>
Automatización del despliegue</h2>
Script único para clearnet + Tor:</p>
#</span></span>!/bin/sh</span>
</span></span>set</span></span> -</span>e</span></span>
</span>
</span>ONION_URL</span>=</span>"</span>http://<onion>.onion"</span></span></span>
</span>
</span>git</span></span> pull</span>
</span>
</span>zola</span></span> build</span>
</span>doas</span></span> rsync -</span>a</span> --</span>delete</span> public/ /var/www/htdocs/</span>
</span>
</span>zola</span></span> build --</span>base-url</span> "</span>$</span>ONION_URL</span></span>"</span></span></span>
</span>doas</span></span> rsync -</span>a</span> --</span>delete</span> public/ /var/www/tor/</span>
</span></code></pre>
Instalado en: /usr/local/bin/update-site</code></p>
Control de acceso: SSH + YubiKey</h2>
Acceso remoto sin contraseñas persistentes:</p>

Clave OpenPGP en YubiKey</li>
PIN + touch físico</li>
gpg-agent como SSH agent</li>
ssh-ed25519</li>
</ul>
La clave privada nunca toca el disco.</p>
Control de versiones y firmas</h2>
Repositorio alojado en GitHub:</p>

Git puro</li>
Commits firmados</li>
Modelo de confianza por defecto</li>
Sin CI obligatorio</li>
</ul>
El servidor no compila desde hooks remotos: el despliegue es consciente y manual.</p>
Estructura del proyecto</h2>
site/
</span>├── config.toml
</span>├── content/
</span>├── templates/
</span>├── static/
</span>├── public/
</span>└── scripts/
</span></code></pre>
En servidor:</strong></p>
/var/www/
</span>├── htdocs/
</span>├── tor/
</span>└── acme/
</span></code></pre>
Qué falta por hacer</h2>
Pendientes reales:</strong></p>

Hardening adicional de httpd</li>
Documentar bootstrap completo desde cero</li>
Monitoreo mínimo (sin agentes invasivos)</li>
Publicar configs como referencia reproducible</li>
Auditoría de headers de seguridad</li>
</ul>
Idea central</h2>
Este proyecto no busca conveniencia ni velocidad de desarrollo.</p>
Busca:</strong></p>

Comprensión</li>
Control</li>
Auditabilidad</li>
Reducción de estados implícitos</li>
</ul>
OpenBSD no acelera el trabajo. Elimina errores silenciosos. Ese es el valor.</p>

Nezzontli - Server

Servidor personal: Debian + Docker, no FreeBSD

Qué falta por hacer</h2> Cloudflare Access delante de Uptime Kuma si algún día se tunelea al público</li> Reglas de ufw</code> para un par de servicios más nuevos (4get, AudioMuse) que hoy solo responden desde localhost</li>

Referencias</h2> Documentación de Tailscale</a></li> gluetun</a></li> Glance</a></li> Servarr Wiki</a></li> Documentación de PeerTube</a></li> </ul>

Uso de OpenBSD para hospedaje de página web

Problemas encontrados (y soluciones)</h2>

2. DNS no propagado</h3> Durante el primer intento, el dominio resolvía a múltiples IPs antiguas: dig nezzontli.xyz +short</code></p> Solución:</strong> Esperar propagación completa y eliminar registros conflictivos.</p>

Idea central</h2> Este proyecto no busca conveniencia ni velocidad de desarrollo.</p> Busca:</strong></p> Comprensión</li> Control</li> Auditabilidad</li> Reducción de estados implícitos</li> </ul> OpenBSD no acelera el trabajo. Elimina errores silenciosos. Ese es el valor.</p>

Referencias</h2>

Documentación de Tailscale</a></li>
gluetun</a></li>
Glance</a></li>
Servarr Wiki</a></li>
Documentación de PeerTube</a></li> </ul>

2. DNS no propagado</h3>
Durante el primer intento, el dominio resolvía a múltiples IPs antiguas: `dig nezzontli.xyz +short</code></p>`
`Solución:</strong> Esperar propagación completa y eliminar registros conflictivos.</p>`

Idea central</h2>
Este proyecto no busca conveniencia ni velocidad de desarrollo.</p>
Busca:</strong></p>

Comprensión</li>
Control</li>
Auditabilidad</li>
Reducción de estados implícitos</li> </ul>
OpenBSD no acelera el trabajo. Elimina errores silenciosos. Ese es el valor.</p>