Migré el blog a FreeBSD después de mantenerlo 10 años en Ubuntu 16.04

(crocidb.com)

1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp

El VPS de DigitalOcean basado en Ubuntu 16.04 LTS tenía el problema de haber quedado sin soporte y la carga de seguridad que eso implica, pero mantuvo un uptime de 1491 días hasta el momento del retiro
El nuevo servidor se movió a un VPS de Hetzner en Alemania con FreeBSD 14.3, usando una configuración más potente que el servidor anterior de $13 al mes por menos de 6 euros mensuales
Con Jails y Bastille se creó un entorno aislado por sitio, donde el Jail de Caddy se encarga del SSL y del reverse proxy hacia cada Jail con nginx
En las pruebas de carga, el nuevo servidor con FreeBSD mostró entre 3 y 11 veces más throughput de solicitudes tras ajustar kern.ipc.somaxconn para soportar 10,000 conexiones concurrentes
La migración requirió aprender sobre redes y configuración de FreeBSD, pero fue más fácil de lo esperado gracias a la configuración centralizada y a la calidad de la documentación

Contexto de la migración

El blog anterior estuvo funcionando más de 10 años en un VPS de DigitalOcean, usando Ubuntu 16.04 LTS en el datacenter de Nueva York
- Ubuntu 16.04 LTS llevaba al menos 5 años fuera de soporte y ya no podía recibir actualizaciones de los repositorios de paquetes de apt
- Un sistema viejo está en desventaja en términos de seguridad, y en el pasado un blog separado de WordPress sufrió un ataque en un VPS antiguo donde insertaron enlaces de casino y apuestas
Además del blog, el servidor anterior alojaba algunos sitios más, pero la mayoría eran sitios estáticos
- Incluso el blog más popular normalmente tenía apenas unos miles de pageviews al mes, salvo algunos posts que se volvieron virales en Hacker News
- El servidor entregaba archivos estáticos con nginx/1.10.3, y la configuración por sitio estaba en /etc/nginx/sites-available
- El blog se generaba con Hugo, y el flujo de despliegue anterior era: escribir localmente → commit y push al repositorio → entrar por SSH al servidor → hacer pull del repositorio → ejecutar hugo
El VPS anterior también se había usado al principio para pruebas y programación, así que todavía conservaba bastante software viejo
- Aun así seguía funcionando correctamente, y al momento del retiro tenía un uptime de 1491 días, es decir, casi 4 años sin reiniciar
El nuevo servidor se movió a un VPS de Hetzner en Alemania, con mejores especificaciones y a menos de la mitad del costo mensual
- El servidor anterior de DigitalOcean tenía 2 GB de RAM, 1 vCPU, 50 GB de disco, 2 TB de tráfico mensual y costaba $13 al mes
- Incluso el servidor más barato de Hetzner tenía el doble de memoria y CPU que el anterior, un poco menos de almacenamiento, pero 10 veces más tráfico
- La configuración final elegida en Hetzner era aún más potente por menos de 6 euros al mes

Por qué elegir FreeBSD

Se eligió FreeBSD para probar un sistema nuevo en un entorno real de producción
- Entre sus ventajas estaban el diseño integrado, la estabilidad, la seguridad y Jails
Jails es una función de virtualización y contenedorización incluida en FreeBSD desde hace más de 25 años
- Permite ejecutar “mini sistemas” en una especie de sandbox sin acceso al sistema host
- Mientras que soluciones de contenedores como Docker encajan mejor para empaquetar programas y suelen ser más efímeras e inmutables, Jails se parecen más a subsistemas o mini VM que comparten el mismo kernel
ZFS también era una opción atractiva como sistema de archivos para servidor
- Ofrece integridad de datos y snapshots, con ciertas similitudes con Btrfs en Linux
- ZFS se consideró mucho más maduro que Btrfs, y con snapshots frecuentes se puede depender menos del sistema pagado de snapshots o backups del proveedor del VPS
La arquitectura objetivo era tener un Jail por sitio, con las herramientas de build y nginx necesarias dentro de cada uno
- El Jail del servidor web principal se encargaría del reverse proxy conectado al exterior
- La idea era que, si un Jail específico era comprometido, se pudiera borrar y recrear

Instalación de FreeBSD e incorporación de Bastille

La pantalla de creación de VM en Hetzner tenía imágenes de sistema operativo limitadas, así que BSD no aparecía directamente
- Se tomó como referencia el video de instalación en Hetzner del canal oficial de YouTube de FreeBSD
- Hetzner ofrece una imagen ISO de FreeBSD, pero había que montarla desde la pestaña ISO Images de la consola después de crear la VM
- Se usó la ISO de FreeBSD 14.3 y se configuró el sistema siguiendo el flujo de instalación del video oficial
Se eligió Bastille para facilitar la administración de Jails
- Varias etapas necesarias para crear un Jail manualmente se pueden hacer con el comando bastille
- Algunos comandos de ejemplo son bastille list, bastille create y bastille console
- La instalación y activación se hizo siguiendo la documentación de inicio de Bastille

pkg install bastille
sysrc bastille_enable="YES"

Red y estructura de reverse proxy

Toda la pila usa un único Jail de Caddy para manejar todos los dominios y certificados SSL, y hacer reverse proxy del tráfico hacia los Jails de cada sitio
- Cada Jail de sitio solo incluye las herramientas necesarias para construir y servir ese sitio
- Se puede ver como una estructura parecida a varias máquinas virtuales dentro de la misma red
La interfaz de red virtual interna se creó como bastille0

sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"

Se clonó una interfaz loopback, se le dio el nombre bastille0 y se le asignó la red 10.0.0.1/24
Los Jails funcionan sobre esta interfaz de red
Las solicitudes HTTP y HTTPS externas se envían al Jail de Caddy usando reglas de PF (Packet Filter)
- En /etc/pf.conf se configuraron la interfaz externa vtnet0, la interfaz interna bastille0 y tailscale1
- El tráfico de los puertos 80 y 443 se redirige a 10.0.0.5, que será el servidor Caddy

ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state

PF y la puerta de enlace se activaron con los siguientes comandos

sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Configuración de Caddy y de los Jails por sitio

Aunque el servidor anterior llevaba mucho tiempo usando nginx, en la nueva configuración se eligió Caddy para automatizar la gestión de certificados SSL
- En el entorno anterior con nginx, los certificados se renovaban periódicamente con certbot, y eso se había olvidado varias veces
Antes de crear el Jail de Caddy, se hizo el bootstrap del release de FreeBSD en Bastille

bastille bootstrap 14.3-RELEASE

El Jail de Caddy se creó con la IP 10.0.0.5

bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy

El nombre del Jail es caddy, el release es 14.3-RELEASE y la interfaz es bastille0
Se puede verificar su estado con bastille list y entrar al shell del Jail con bastille console caddy
La instalación de Caddy y la activación del servicio se hicieron dentro del Jail

pkg install caddy
sysrc caddy_enable="YES"
service caddy start

El archivo de configuración de Caddy está en /usr/local/etc/caddy/Caddyfile dentro del Jail
- Si se quiere administrar el archivo desde el host, se puede montar un directorio del host dentro del Jail
- En el ejemplo se usa nullfs con la opción de solo lectura ro para impedir que Caddy modifique la configuración

bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

Despliegue del sitio y del blog

El primer objetivo de despliegue fue es.cro.to, y el sitio se administra en este repositorio de GitHub
- El repositorio se guarda en /usr/local/www/escroto en el host, y ese directorio se monta en modo solo lectura dentro del Jail del sitio
- Todos los sitios se organizaron bajo /usr/local/www en el host
El Jail escroto se creó usando la plantilla nginx de Bastille

bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx

La IP asignada es 10.0.0.11
La página por defecto de nginx se sirve desde /usr/local/www/nginx, como es habitual en FreeBSD
El directorio del sitio en el host se montó en el Jail en modo solo lectura

bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0

Se usa un script de despliegue para evitar que el directorio .git del repositorio quede expuesto por la web

rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git

El despliegue de una nueva versión consiste en actualizar el repositorio en el host y luego ejecutar el script de despliegue dentro del Jail

cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh

La configuración de Caddy redirige permanentemente cro.to a es.cro.to y hace proxy de es.cro.to hacia 10.0.0.11

cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}

El blog usa Hugo y se administra en este repositorio de GitHub
- El repositorio se clona en /usr/local/www/blog en el host
- El Jail blog se creó de forma similar a escroto, con la IP 10.0.0.12

bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0

Hugo se instaló dentro del Jail blog

bastille pkg blog update
bastille pkg blog install gohugo

El script de despliegue del blog vacía el web root de nginx y genera la salida de Hugo en /usr/local/www/nginx

rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx

Antes de mover el DNS, se hizo una prueba conectando crocidb.cro.to al nuevo servidor del blog en lugar del dominio anterior

crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

Benchmarks y pruebas de carga

Antes de cambiar los registros DNS, se comparó la capacidad de carga del servidor anterior crocidb.com y del nuevo crocidb.cro.to
- Como los visitantes del blog llegan sobre todo desde Norteamérica, y luego desde Europa y Sudamérica, el nuevo servidor en Alemania podría aumentar un poco la latencia para algunos usuarios
- El interés principal era la velocidad al servir un sitio estático y la capacidad para soportar mucha carga
También se usaron herramientas gratuitas en línea como GTMetrix, Pingdom y WebPageTest, pero la diferencia entre ambos servidores fue mayormente de latencia
Como herramientas de benchmark HTTP se usaron wrk y hey
- Ambas generan grandes volúmenes de solicitudes concurrentes y recopilan latencia, respuestas con error, throughput por segundo y otros datos
Al ejecutar wrk desde otro VPS dentro de Hetzner, el nuevo servidor mostró una ventaja clara

wrk -t4 -c100 -d30s --latency https://crocidb.com/

La configuración fue 4 hilos, 100 conexiones concurrentes y 30 segundos de ejecución
El servidor anterior tuvo una latencia promedio de 89.63ms, 833.41 solicitudes por segundo y 8.29MB/s de throughput
El nuevo servidor tuvo una latencia promedio de 6.75ms, 12260.10 solicitudes por segundo y 130.80MB/s de throughput
La máquina de prueba estaba en el mismo datacenter que el nuevo servidor, así que no era una comparación totalmente justa
También se intentó ejecutar wrk desde varias regiones usando Proton VPN, pero los resultados fueron peores de lo esperado
- El promedio del servidor anterior fue de unas 300 solicitudes por segundo, y el del nuevo de unas 800
- Al final se cambió el enfoque: en lugar de una VPN para consumidores, se levantaron VPS reales en varias regiones

Pruebas regionales con VPS de Vultr

Se eligió Vultr para usar una infraestructura distinta de la de DigitalOcean y Hetzner, donde estaban los servidores
- Para reducir el trabajo manual, las regiones se limitaron a London, São Paulo, Silicon Valley y Tokyo
- En cada región se creó la VM Fedora más barata y se ejecutaron las pruebas
Se concluyó que hey era la herramienta más adecuada para la prueba final

./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log

La configuración fue de 1,000,000 solicitudes totales, 10,000 solicitudes concurrentes, timeout de 10 segundos, duración total de 5 minutos y uso de HTTP/2
La carga fue muy superior al tráfico real de un blog
En la primera ejecución, el nuevo servidor con FreeBSD no pudo manejar 10,000 conexiones concurrentes y falló al inicio
- Al revisar el tamaño de la cola de sockets con netstat -Lan, todo aparecía en 128
- Como el valor por defecto de kern.ipc.somaxconn era 128, se aumentó así

sysctl kern.ipc.somaxconn=16384

En la prueba desde São Paulo, ambos servidores devolvieron bastantes errores, pero el servidor con FreeBSD sí respondió a las 1,000,000 solicitudes esperadas, mientras que el de Ubuntu no logró responder ni 20,000
- El servidor anterior con Ubuntu completó alrededor del 7% del total
- El nuevo servidor con FreeBSD completó cerca del 94%
- En Tokyo la tasa de éxito del nuevo servidor fue un poco menor, pero no se consideró algo especialmente preocupante
En solicitudes por segundo, el nuevo servidor fue entre 3 y 11 veces mejor que el anterior
- En los percentiles de latencia, el nuevo servidor aumentó de manera más lineal hasta alrededor del 90%, lo que lo hacía más predecible
- Incluso bajo alta carga, la mayoría de las regiones del mundo pudieron recibir el contenido de la página principal del blog en menos de 3.5 segundos
Los resultados de Tokyo no se analizaron a fondo
- El análisis por fases de solicitud en hey sugería que el tráfico hacia Japón podía ser más lento
- Los valores de DNS dial-up y lookup del segundo dominio parecían anormalmente bajos, con la posibilidad de que un registro CNAME influyera
- Los valores de resp wait y resp read también parecían extrañamente altos, pero como solo se contaban las solicitudes exitosas, era posible que el servidor anterior respondiera rápido al principio y luego prácticamente dejara de aceptar nuevas solicitudes

Cambio final y lecciones clave

Aunque los benchmarks no respondieron todo, el resultado fue lo suficientemente satisfactorio como para mover los registros DNS al nuevo servidor
- Desde entonces, este blog opera oficialmente sobre el servidor de Hetzner con FreeBSD
Configurar una máquina para hosting de sitios con FreeBSD implicó varias horas de experimentos, cambios, builds y errores, pero fue menos complejo de lo esperado
- También se pudo haber usado un servicio de hosting web que cumpliera los requisitos; un ejemplo mencionado es OpenBSD Amsterdam
- Otra opción habría sido usar Proxmox para tener contenedores y un dashboard de administración
- Como alternativa dentro del mundo FreeBSD, también se mencionó Sylve
- Aun así, hacerlo manualmente fue una decisión satisfactoria porque dejó mucho aprendizaje
El servidor Ubuntu anterior también fue muy sólido
- Durante 10 años manejó bien la carga de los sitios, y sus últimos 4 años transcurrieron sin reinicios
- Funcionó de forma estable sin requerir demasiado esfuerzo de configuración
La configuración de FreeBSD resultó más sencilla de lo esperado, y gustaron mucho tanto su enfoque de centralizar la configuración del sistema como la calidad de la documentación en línea
Para montar una máquina propia de hosting para el blog hizo falta conocimiento de redes más allá de lo que normalmente conoce un desarrollador de videojuegos
- Aprender otro sistema fue entretenido, y la próxima vez quizá se pruebe con OpenBSD o NetBSD
- La conclusión final es que, dado que la mayor parte del tráfico del blog viene del crawling de sistemas de IA, la utilidad práctica de todo este trabajo es limitada

1 comentarios

GN⁺ 3 시간 전

Comentarios en Hacker News

Mi mayor error fue el alto uptime
arjie.com estuvo funcionando más de 10 años en un VPS de Hetzner, así que cuando Hetzner quiso apagar la máquina subyacente, no tenía ni idea de qué había configurado mi yo adolescente
Tengo respaldos, pero el sitio lleva 10 años caído
Ahora hago las cosas de forma que se puedan mover, y de hecho las he movido varias veces para comprobar que funcionen
- Es cierto eso de que “mi mayor error fue el alto uptime”
  También recuerdo la época en que el uptime de una máquina se veía como una medalla de honor
  No es que con la edad me haya vuelto mucho más sabio, pero ahora me fijo en el uptime del servicio
  Antes, registros DNS como MX ya iban en esa dirección, y los clústeres viejos eran bastante crípticos, pero dejaron lecciones como split brain, así que todavía me toca explicar por qué los clústeres de 2 nodos en Proxmox se rompen y por qué recomiendan un witness adicional
  VMware también estaba equivocado cuando hace años tapó el problema de los clústeres HA de 2 nodos con una gran solución temporal, y si ese método sigue por ahí, probablemente sigue estando mal
  Un alto uptime significa que no aplicaste parches, y a todos nos encanta parchear
- Me hace pensar en el Santuario de Ise en Japón
  Cada 20 años lo desmantelan por completo y lo reconstruyen, y en Breakneck de Dan Wang, que leí hace poco, explican que esa práctica de reconstrucción preserva conocimientos que de otro modo se perderían con el tiempo
  Wang contrasta el Santuario de Ise con Notre Dame, y cree que una de las razones por las que reconstruir el techo de Notre Dame fue tan difícil puede haber sido la pérdida de conocimiento
  No conozco lo suficiente de ambas construcciones como para saber si es una comparación justa, pero el principio en sí me gusta
  En el libro es solo una pequeña analogía, pero en general lo recomiendo muchísimo
- En una VM, el alto uptime significa poco
  Reiniciar toma solo unos segundos, y las actualizaciones se pueden hacer sin downtime cambiando el DNS a una nueva instancia
  Con máquinas físicas que no se pueden replicar fácilmente, la historia es distinta
- Empecé a meter la configuración en un gran repositorio de playbooks de Ansible
  No hace falta administrar todo completamente con Ansible; más bien dejo ahí la configuración inicial y todavía manejo bastante a mano
- A veces también dejo Architectural Decision Records incluso para proyectos personales
  Se siente un poco ridículo, pero ayuda más seguido de lo que uno esperaría
Para uso personal o de hobby, casi siempre manejo todo con Caddy al frente + Docker Compose
Si es un sitio simple, Caddy sirve el contenido directamente; si es una “web app”, casi siempre la contenedorizo y dejo que Caddy haga la terminación TLS y el proxy inverso hacia la app bajo Docker
Normalmente uso una estructura ~/apps/appname, con el archivo de Docker Compose y el directorio de datos montado dentro de cada directorio de app
Después de compose down, puedo sacar los datos por (s)ftp para archivarlos a largo plazo o mover el sitio/servicio
En algún momento tuve varias VM en un servidor dedicado, pero luego me pasé a VPS separados de OVH, y si quieres correr correo en OVH tienes que evitar las VM de zona local, porque no permiten hosting de mail
Supongo que depende del entorno
- En un proyecto empecé a usar Traefik, y fue una mejora clara frente a nginx proxy manager
  NPM también es excelente y su GUI web está bien, pero con Traefik basta con poner en el archivo de Docker Compose el comportamiento que quieres y listo
- Mi setup en casa es parecido
  Solo que Unraid corre los contenedores, y uno de ellos es una herramienta de la familia nginx diseñada para actuar como proxy inverso de los demás servicios
- Yo también lo hago casi igual
  Solo estoy pensando si pasarme de Debian a algo más tipo Flatcar, orientado a contenedores e inmutable como sistema/OS
  FreeBSD tiene ventajas técnicas interesantes, pero para bien o para mal, el valor por defecto de mucho software open source es Docker, y no tengo ni el tiempo ni las ganas de mover todo a jails de FreeBSD
Hace unas semanas hice exactamente lo mismo
El servidor no se había actualizado desde más o menos 2015, y todavía tenía instalado un blog de Ghost y node 0.10 de esa época
Yo fui más brusco: solo hice un respaldo y luego solté al agente Hermes (Gemini 3.1 Pro)
Hizo todas las actualizaciones y parches necesarios, y hasta migró a equivalentes actuales
Después también avancé bastante en endurecer el servidor y quitar servicios que ya no usaba, y sin asistencia de IA probablemente lo habría seguido posponiendo
- Incluso sin IA, actualizar en sí es bastante fácil
  El problema real es el riesgo de que algo se rompa, y ahí es donde los respaldos ayudan a mitigar
Me divertí usando FreeBSD en servidores personales
Tenía algo cool, limpio, simple y como de “punk rock”
Pero terminé dejándolo por un punto de dolor importante: PM2 tenía bugs en FreeBSD y era la herramienta que usaba para gestionar procesos; traté de reemplazarlo corriendo daemons con rc.d, pero configurar logs era demasiado difícil; y el firewall exigía demasiada configuración manual para ajustarlo incluso a buenas prácticas de seguridad como qué hacer con ICMP, así que extrañé plantillas tipo los valores por defecto de UFW
- FreeBSD sí incluye plantillas base de ese tipo
  Están implementadas con IPFW, no con PF
  Mira la clave firewall_type en rc.conf: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
  Si quieres configurar fácilmente un firewall para una sola máquina, puedes usar firewall_type=client, o si vas a hospedar algo, firewall_type=workstation
  En este último caso, firewall_myservices y firewall_allowservices controlan qué puertos se abren y qué redes/IP pueden acceder
  Para un gateway NAT muy simple, basta con firewall_type=simple y firewall_simple_(iif|inet|oif|onet)(_ipv6)? para definir los nombres de interfaz hacia el ISP y hacia la red interna, además de los rangos IPv4/IPv6
  Qué hace exactamente cada opción está implementado en /etc/rc.firewall: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
- Me pregunto si usabas PM2 para supervisión
  Para los logs de daemons rc.d, a la manera Unix, si son mensajes simples puedes usar logger(1), o redirigir a un archivo y manejar el tamaño con newsyslog(8)
  Para el firewall, recomiendo The Book of PF[0]
  El PF de FreeBSD tiene diferencias de sintaxis respecto al pf de OpenBSD, pero alcanza perfectamente para entender cómo funciona un firewall y qué reglas te conviene usar
  [0]: https://nostarch.com/book-of-pf-4e
- PM2 siempre tuvo bugs, sin importar en qué OS lo usaras
  Al principio es comodísimo, pero al mismo tiempo siempre fue software desagradable de usar, y jamás logré que la actualización de variables de entorno en despliegues funcionara como se suponía
- Mi principal dolor era que no aguantaba un corte de energía
  Si se iba la luz, después del reinicio exigía correr manualmente fsck en el sistema de archivos
Cambiando un poco de tema, me pregunto cuál es hoy la distro Linux gratuita con el ciclo de soporte más largo
Durante un tiempo usé CentOS 7 para VM pequeñas, porque tenía actualizaciones de seguridad durante muchísimo tiempo y además minimizaba el riesgo de que una actualización rompiera algo
Por lo que vi buscando un poco, ahora Alma/Rocky parecen ser la mejor opción y ofrecen 10 años de soporte
Aunque me pregunto si realmente están bien mantenidas
- Yo también corrí CentOS en servidores durante más de 10 años buscando estabilidad a largo plazo y tranquilidad mental
  Pero cuando pasa tanto tiempo, el ecosistema se desalinea muchísimo y mantener actualizadas las aplicaciones sobre ese OS se vuelve cada vez más difícil
  Paquetes de infraestructura como glibc, la combinación Python/Apache o GCC se van volviendo incompatibles poco a poco con stacks de aplicaciones modernos
  Después, incluso subir de versión del sistema fue doloroso, no solo porque me había acorralado con una mezcla rara de paquetes, sino porque la ruta de actualización en sí misma siempre fue más bien de “mejor esfuerzo”
  Creo que me rendí pasando de 6 a 7, y al final entendí que lo que yo necesitaba era Fedora
  Con actualizaciones cada año o cada seis meses no tienes que pelear con los paquetes de la distro, la configuración se mantiene al día y funcionando, las actualizaciones mayores de la distro son fluidas y el downtime es mínimo
  No pienso volver nunca más a una “distro de servidor”
- Alma ya no es compatible a nivel de código fuente con RHEL, así que tiene un poco más de margen
  Por ejemplo, puede sacar más rápido actualizaciones de kernel para corregir vulnerabilidades de escalación de privilegios
  Rocky respondió mientras esperaba a que bajara el cambio desde RHEL ofreciendo un repositorio de seguridad opcional con mitigaciones para exploits
  Viendo los incidentes recientes, ambas parecen estar bastante bien mantenidas
- No veo bien por qué no usar una distro rolling release en un servidor personal
  Todos los servicios van en contenedores, y al OS base lo dejas autoactualizarse tan seguido como haga falta
  Yo elegí openSUSE MicroOS, y como actualiza y reinicia casi a diario, tengo bastante confianza en que el servidor está sano
  Como las actualizaciones son atómicas, si algo se rompe y no quieres atenderlo en ese momento, solo aprietas el botón de rollback en Cockpit y lo ves después cuando tengas tiempo
- Básicamente estás apostando a que lo que hospedas no va a vivir más que el ciclo de actualización
  Cuando finalmente llegue el upgrade, hay muchas probabilidades de que sea bastante doloroso
  Creo que es mejor dar saltos de versión más pequeños y más frecuentes, en vez de un salto enorme cuando ya todo cambió tras muchos años
- Si quieres algo completamente gratis, o tienes muchas máquinas, Alma y Rocky sí encajan
  Si no te molesta registrarte con Red Hat, también está RHEL, que da acceso gratis a actualizaciones para hasta 10 máquinas por cuenta registrada
  RHEL es sin duda la más estable entre las distros principales, y Alma y Rocky son esencialmente clones downstream de RHEL
Yo también estoy en ese mismo barco
Tengo dos servidores viejos que dejé abandonados “demasiado” tiempo, y ahora me da miedo tocarlos para actualizarlos
Pero viendo el show que están armando las distros Linux con lo de verificación/comprobación de edad, hasta estoy pensando en irme por completo
También probé Artix, pero se rompió tras reiniciar la semana pasada, y parece que algo había salido mal en una actualización anterior del kernel, así que hasta tuve que sacar un ISO de rescate
Por eso a ese equipo lo cambié a Devuan, aunque todavía no tengo un veredicto
No tengo grandes quejas, pero sigue en fase de burn-in
En la laptop corro Arch, pero la comunidad me parece un poco hostil por el tema de la censura, así que cuando tenga un fin de semana libre pienso formatearla e instalar otra cosa
No quiero drama político en mi software
Curiosamente, esta fue la primera vez que compré una laptop nueva y jamás arranqué Windows; instalé Linux directamente y todo “simplemente funcionó”
Justo ahora que estaba emocionado por usar Linux a fondo, me da tristeza ver que los grandes jugadores acepten etapas de erosión de privacidad como IA por todos lados, verificación/comprobación de edad y telemetría activada por defecto
Con todo eso, mi respuesta es simplemente “nope”
- Una vez dejé un servidor Ubuntu sin tocar durante 10 años y luego lo actualicé en 20 minutos sin dolor
  Ese servidor sigue corriendo hoy en el LTS más reciente
  Ni siquiera sé si empezó en Ubuntu 4 o 6, pero todo fue bastante bien
  Tal vez actualizar lentamente ayudó a evitar el sufrimiento de los early adopters
  Hoy uso mucho más Debian
  Con tantos ataques a la cadena de suministro, Debian Stable es una verdadera joya, y aunque haya algunos paquetes que necesites manejar aparte por requerir versiones más nuevas, me gusta ese espíritu de ingeniería sobria y anticuada
- Creo que estás mal encaminado con lo de verificación/comprobación de edad
- Que algo se rompa tras reiniciar por una actualización del kernel anterior suele ser más un problema de Arch/Artix
  Ambas van muy rápido detrás de lo más nuevo, y la estabilidad no siempre es la prioridad máxima
  Pero eso no significa que una rolling release siempre tenga que entregar la versión más nueva de todo
  Llevo unos meses usando Void Linux: es rolling release, pero usa kernel LTS y permite elegir mainline también, y sus mantenedores se enfocan más en versiones estables de apps que en actualizaciones rápidas
- Mis servidores/VM suelen correr FreeBSD o Alpine
  También tengo algo de Debian donde hace falta, por ejemplo en Proxmox, VPS que no soportan Alpine o equipos del trabajo
  También tengo algunos sistemas de prueba corriendo Chimera, pero no pienso depender mucho de eso hasta que salga una versión estable
  Y también ando experimentando un poco con AerynOS
- Ojalá el ciclo de soporte de FreeBSD fuera más largo
  La vida útil de soporte por release es de menos de un año, así que si se te pasa la ventana de actualización, después actualizar se vuelve más difícil que en otras distros como Debian Stable
Me pasé a Debian y Ubuntu para servidores, pero cuando era más joven, a mediados de los 2000, estaba obsesionado con FreeBSD
En realidad pasaba más tiempo configurando y ajustando cosas que haciendo trabajo útil
En esa época era difícil encontrar servidores dedicados o VPS que ofrecieran la familia BSD, y creo que terminé instalándome en lugares como Panix.com
Antes de eso, también recuerdo que una empresa llamada 15MinuteServers, que creo que estaba en el antiguo NAC de Nueva Jersey, ofrecía BSD
Ya solo estoy divagando por nostalgia
- Hoy instalarlo es bastante fácil con mis proveedores
  Uso FreeBSD en Hetzner y OVH, y antes también probé Vultr
- OVH tiene una plantilla de FreeBSD
  Y la mayoría de los proveedores de VM/VPS KVM permiten acceso a consola y montar ISOs propias, así que puedes instalar lo que quieras
Que fastfetch reporte más memoria usada de la real probablemente se deba a ZFS ARC
Igual que la page cache en Linux, se puede recuperar en cualquier momento, y distintas herramientas la etiquetan de forma diferente: https://www.linuxatemyram.com/
Recuerdo que cuando alguien me explicó Docker por primera vez, respondí: “ah, ¿te refieres a jails?”
Como explica el artículo, no son exactamente lo mismo
kqueue también fue una gran victoria
De verdad, gracias a los desarrolladores de FreeBSD
Operé mi primera empresa durante 15 años sobre FreeBSD, y el uptime y la resiliencia fueron increíbles
Yo también tengo un servidor Ubuntu 16.04 que me da miedo actualizar
Ahora mismo lleva 1281 días de uptime, y a estas alturas hasta me da pena reiniciarlo
- Puedes copiar el sistema de archivos a otra máquina con dd y luego arrancarlo en un emulador como qemu para hacer un ensayo general
  Solo ten cuidado si hay algo configurado para arrancar automáticamente y conectarse hacia afuera
- No entiendo qué te da miedo exactamente
  ¿No tienes respaldos?
  En sistemas Debian/Ubuntu puedes configurar con bastante facilidad actualizaciones automáticas y reinicios regulares, y el mantenimiento manual queda reducido a upgrades de versión grandes
- Mi servidor más viejo está en 8.04

Migré el blog a FreeBSD después de mantenerlo 10 años en Ubuntu 16.04

Contexto de la migración

Por qué elegir FreeBSD

Instalación de FreeBSD e incorporación de Bastille

Red y estructura de reverse proxy

Configuración de Caddy y de los Jails por sitio

Despliegue del sitio y del blog

Benchmarks y pruebas de carga

Pruebas regionales con VPS de Vultr

Cambio final y lecciones clave

Lecturas relacionadas

1 comentarios

Comentarios en Hacker News