Nezzontli - Spanish

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>


Detección de inundaciones
2025-11-02T00:00:00+00:00
Introducción y Justificación</h2>
El estado de Hidalgo</strong> enfrenta una problemática crítica y recurrente de riesgo hídrico, manifestada en inundaciones por desbordamiento de ríos y presas. Esta situación se agrava por la falta de sistemas de monitoreo constante y la ausencia de un Sistema de Alerta Temprana (SAT)</strong> robusto y accesible para la población en las zonas de riesgo.</p>
Cada temporada de lluvias intensas, miles de familias mexicanas, particularmente en Hidalgo, son afectadas por estos desbordamientos, resultando en la pérdida de vidas y bienes materiales. Un ejemplo trágico y emblemático fue la inundación del río Tula en septiembre de 2021</strong>, donde el desbordamiento alcanzó hasta dos metros de altura</strong>, afectando a más de 2,500 viviendas</strong> y cobrando la vida de 17 personas</strong> en el Hospital General de Zona (HGZ) No. 5 del IMSS en Tula de Allende 1</a>, 2</a>.</p>
Los municipios identificados con mayor vulnerabilidad a este tipo de fenómenos incluyen Tula de Allende</strong>, Huehuetla</strong>, Tianguistengo</strong>, y otras zonas de la Huasteca y la Sierra Hidalguense 3</a>, 4</a>. Además, la gestión de embalses como la Presa La Esperanza</strong> (que ha alcanzado el 100% de su capacidad) y la Presa Tejocotal</strong> (con riesgo de desbordamiento en temporadas de alta precipitación) subraya la necesidad urgente de un monitoreo en tiempo real 5</a>.</p>
Propuesta de Solución: Sistema de Detección de Inundaciones Basado en Meshtastic/LoRa</h2>
Se propone la implementación de un Sistema de Detección y Alerta Temprana de Inundaciones (SAT-I)</strong> utilizando la tecnología de red mallada Meshtastic</strong> sobre la infraestructura de radio de largo alcance y baja potencia (LoRa</strong>). Este sistema está diseñado para operar de manera autónoma y resiliente, incluso ante la caída de las redes de comunicación convencionales (telefonía móvil o Wi-Fi) 6</a>.</p>
Componentes y Funcionamiento</h3>

Detección de Nivel de Agua:</strong></li>
</ol>

Se emplearán sensores ultrasónicosicos de grado industrial</strong> con una precisión de hasta ±1 cm</strong> para la medición constante del nivel del agua en ríos o presas.</li>
Estos sensores se integrarán en una cápsula hermética</strong> de protección, asegurando su resistencia a la corrosión y a las condiciones ambientales extremas.</li>
</ul>

Comunicación Autónoma (Meshtastic/LoRa):</strong></li>
</ol>

Los datos de los sensores serán transmitidos a través de módulos LoRa</strong> que ejecutan el firmware</em> Meshtastic</strong>. Esta tecnología utiliza ondas de radio de largo alcance y bajo consumo, permitiendo la comunicación off-grid</em> (fuera de la red eléctrica o de telecomunicaciones) a distancias de varios kilómetros.</li>
La naturaleza de red mallada (mesh)</strong> de Meshtastic permite que cada nodo actúe como repetidor, extendiendo el alcance y la redundancia del sistema. En caso de que un nodo falle, la información puede ser retransmitida por otros nodos en la red.</li>
</ul>

Alerta Temprana y Aplicaciones Adicionales:</strong></li>
</ol>

El sistema no solo detectará desbordamientos inminentes, sino que también puede ser adaptado para detectar sequías</strong> mediante el monitoreo de niveles mínimos, facilitando la gestión hídrica en presas o zonas rurales.</li>
La alerta se puede emitir a dispositivos portátiles (como smartphones</em> con la aplicación Meshtastic) o a sistemas de alarma locales, garantizando una evacuación temprana</strong> de la población.</li>
</ul>
Requerimientos Mínimos para el Prototipo</h3>
Para la implementación inicial de un nodo de monitoreo y su repetidor se requiere:</p>
Componente</th> Cantidad</th> Función</th></tr></thead>

Módulos LoRa/Meshtastic</strong></td> 2</td> Nodos de comunicación autónoma (uno para el sensor, otro como receptor/gateway).</td></tr>
Sensores Ultrasónicos</strong></td> 2</td> Medición precisa (±1 cm) del nivel del agua.</td></tr>
Retransmisor Autónomo</strong></td> 1</td> Nodo adicional con alimentación solar para extender el alcance de la red mallada.</td></tr>
</tbody></table>
Consideraciones de Despliegue</h3>
El despliegue del sistema debe ir precedido por un estudio topográfico</strong> detallado. Este estudio es crucial para:</p>

Determinar la ubicación óptima de los nodos y retransmisores para maximizar el alcance de la red LoRa.</li>
Establecer los umbrales de alerta basados en la topografía de la zona y los niveles históricos de desbordamiento.</li>
</ul>
Todos los retransmisores deben ser autónomos</strong> y alimentados por paneles solares</strong>, aprovechando la eficiencia energética y el bajo consumo de la tecnología LoRa.</p>
Escalabilidad y Aplicaciones Adicionales: Beneficios para la Agricultura</h2>
La arquitectura modular y resiliente del sistema SAT-I basado en Meshtastic/LoRa permite una escalabilidad inmediata para integrar otros sensores y fuentes de datos, ampliando su utilidad más allá de la prevención de inundaciones. Dado que Hidalgo es un estado con una importante vocación agrícola</strong>, esta escalabilidad ofrece beneficios directos para el sector primario.</p>
Integración de Sistemas Meteorológicos para Predicción de Lluvias</h3>
Se propone la integración de estaciones meteorológicas autónomas</strong> (alimentadas por energía solar y equipadas con sensores de precipitación, temperatura y humedad) que también utilicen la red Meshtastic/LoRa para la transmisión de datos.</p>
Dato Adicional</th> Beneficio para la Prevención de Inundaciones</th> Beneficio para la Agricultura</th></tr></thead>

Precipitación Acumulada</strong></td> Permite modelar la saturación del suelo y predecir el caudal de los ríos con mayor precisión, mejorando la anticipación de la alerta.</td> Ayuda a los agricultores a optimizar el riego y a planificar la siembra y cosecha en función de la disponibilidad hídrica.</td></tr>
Temperatura y Humedad</strong></td> Ofrece contexto para la predicción de tormentas intensas y fenómenos hidrometeorológicos.</td> Facilita la gestión de plagas y enfermedades, y optimiza las condiciones de cultivo para especies específicas.</td></tr>
</tbody></table>
Al enviar estos datos a través de la red mesh, se crea un sistema de información ambiental descentralizado y robusto</strong>. La combinación de la predicción meteorológica</strong> (datos de lluvia) con el monitoreo hidrológico en tiempo real</strong> (nivel de agua) proporciona una herramienta de análisis mucho más completa para la prevención de desastres.</p>
Conclusión</h2>
La integración de sensores de precisión con la red de comunicación resiliente Meshtastic/LoRa ofrece una solución autónoma y autosuficiente</strong> para la detección temprana de riesgos hídricos en Hidalgo. Este enfoque no solo aborda la vulnerabilidad de las redes convencionales, sino que proporciona una herramienta vital para la salvaguarda de la población</strong> y la protección de sus bienes ante un desbordamiento inminente.</p>

Referencias (Bibliografía)</h2>

Redacción. (2022, 7 septiembre). A un año de la inundación en Tula: las damnificadas enfrentan daños emocionales y falta de apoyo</em>. Corriente Alterna UNAM.</a></li>
Gaceta UAEH. (s.f.). Inundaciones en el Valle del Mezquital, una tragedia anunciada</em>. Universidad Autónoma del Estado de Hidalgo.</a></li>
Milenio Digital. (2025, 12 mayo). Estos son los municipios de Hidalgo con mayor riesgo de inundaciones</em>. Milenio.</a></li>
La Jornada. (2025, 10 octubre). Lluvias desbordan ríos en Hidalgo causando graves inundaciones en 7 municipios</em>.</a></li>
Yahoo Noticias. (2025, 30 junio). Hidalgo se mantiene en alerta por intensas lluvias y presas al límite</em>.</a></li>
Zona Industrial. (s.f.). Meshtastic - Guía para tu Red Mesh</em>.</a></li>
YoLink. (s.f.). YoLink LoRa - Sensor de fugas de agua de hasta 1/4 de milla</em>.</a></li>
</ol>

Nezzontli - Spanish

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>

Detección de inundaciones

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>