Instalación de AlmaLinux 10: Linux empresarial con una ruta de actualización limpia

Por qué AlmaLinux 10 (y qué estás eligiendo realmente)

AlmaLinux es una distribución Enterprise Linux orientada a ser compatible con el ecosistema RHEL. En lenguaje de operaciones claro: obtienes las convenciones de empaquetado, comportamientos de systemd, valores por defecto de SELinux y la memoria operativa del administrador que las empresas estandarizan. Eso importa más que el logotipo.

El valor real de AlmaLinux 10 no es “gratis”. Es la previsibilidad. Flujo de arranque predecible (UEFI), postura de seguridad predecible (SELinux activado), herramientas de actualización predecibles (DNF), y patrones de ciclo de vida predecibles (las actualizaciones mayores son eventos, las menores son mantenimiento).

Pero la compatibilidad tiene dos caras. Si lo instalas como una distro de hobby—sistema de archivos gigante único, sin pensar en /var, sin plan para UEFI, sin línea base—entonces cada incidente “menor” se convierte en un deporte de contacto total.

Aquí va la postura opinativa: instala AlmaLinux 10 como si esperases operarlo durante 5–10 años. Si no puedes comprometerte a eso, ponlo en un contenedor, o elige algo que estés dispuesto a reconstruir con frecuencia.

Datos interesantes y contexto histórico (para no repetir la historia)

• Los clones de Enterprise Linux solían ser “instalar y olvidar”. Luego los cambios en la política upstream convirtieron la “estrategia de clonado” en un asunto de junta directiva, no en un hobby de nerds.
• UEFI se convirtió en la historia de arranque por defecto porque el arranque BIOS es básicamente una pieza de museo que aún alimenta tu sistema de nómina.
• SELinux pasó de “desactivarlo” a “nos salvó”. Las herramientas modernas de política y mejores valores por defecto hicieron que el modo enforce sea nuevamente la línea base sensata.
• DNF reemplazó a YUM para arreglar la resolución de dependencias y problemas de rendimiento; el comando “yum” hoy es mayormente pegamento de compatibilidad.
• systemd ganó porque la gestión consistente de servicios vence a mil scripts init artesanales, especialmente durante las caídas.
• OpenSSH endureció sus valores por defecto con el tiempo (algoritmos, expectativas sobre login root). Las viejas configuraciones de “permitir todo” se vuelven bloqueadores de actualizaciones.
• XFS se volvió el sistema de archivos empresarial por defecto por rendimiento en volúmenes grandes y consistencia; ext4 sigue siendo válido, pero los valores por defecto importan.
• Kickstart y las instalaciones PXE se volvieron la manera adulta de construir flotas porque “operaciones por clic” no escala ni audita.

Una idea para pegar en tu monitor tomada del mundo de la fiabilidad: La esperanza no es una estrategia — atribuida al General Gordon R. Sullivan. En operaciones, “recordaremos los pasos de instalación” es esperanza con pasos adicionales.

Broma #1: Si tu única copia de seguridad es “podemos reinstalar”, felicitaciones—has inventado recuperación ante desastres por buenas vibras.

Decisiones que importan antes de hacer clic en “Begin Installation”

1) UEFI + Secure Boot: decide deliberadamente

UEFI debería ser tu predeterminado a menos que estés atrapado en hardware legado. Para Secure Boot, sé honesto: ¿lo necesitas por cumplimiento o porque realmente gestionas la integridad de la cadena de arranque? Si lo activas, debes mantener aburrida tu historia de kernel/módulos—no permitir controladores firmados aleatoriamente después.

Consejo operativo: elige Secure Boot si tu equipo de plataforma puede soportarlo de forma consistente. Las flotas mixtas donde algunos nodos usan Secure Boot y otros no tienden a producir caídas de “funciona en mi host”.

2) Diseño de almacenamiento: en realidad estás diseñando dominios de falla

Tus elecciones de particionado en el momento de la instalación determinan qué se llena primero, qué puede ser instantaneado (snapshot) y qué bloquea las actualizaciones. La caída clásica en producción es que / o /var llegan al 100% a las 3 a.m. porque los logs, capas de contenedores o un spool descontrolado crecieron sin freno.

Opinión: separa /var si el sistema va a ejecutar bases de datos, contenedores, runners de CI o cualquier cosa que sea “charlatana”. Coloca /var/log por separado sólo cuando tengas una razón real y monitoreo para acompañarlo. Si no, creas un segundo modo de falla: “/var/log está lleno y nada registra”.

3) Elección de sistema de archivos: elige al ganador aburrido

XFS es una gran opción por defecto para volúmenes de servidor. Ext4 también está bien, particularmente para particiones de arranque/root pequeñas. Si quieres ZFS, estás eligiendo un modelo de ciclo de vida y herramientas distinto; puede ser fantástico, pero no finjas que es “igual que XFS”.

4) Sincronización horaria y DNS: no improvises

El tiempo y el DNS son los dos servicios que todos asumen que están bien—hasta que Kerberos falla, los certificados TLS parecen “aún no válidos”, o tu gestor de paquetes no puede resolver repositorios. Asegura que NTP/chrony y la configuración del resolvedor formen parte de la línea base post-instalación.

5) Identidad y acceso: los usuarios locales son un olor

En empresas, los usuarios administradores locales se acumulan como polvo. Usa autenticación centralizada (SSSD/LDAP/Kerberos) cuando corresponda, y conserva una cuenta local de emergencia con acceso controlado. Si estás en entornos pequeños, mantenlo simple: al menos exige claves SSH, desactiva la autenticación por contraseña y registra todo.

6) Ruta de actualización: plánificala ahora, no después

Una “ruta de actualización limpia” es mitad política, mitad arquitectura:

• Política: despliegues por etapas, repositorios fijados y ventanas de cambio que incluyan tiempo para revertir.
• Arquitectura: gestión de configuración, scripts de bootstrap idempotentes y separación de datos del OS cuando sea factible.

Si el estado de tu aplicación vive dentro de /usr/local con archivos editados a mano y binarios misteriosos, ninguna distro podrá salvarte. AlmaLinux no arreglará tu relación con el desorden.

Rutas de instalación: ISO, Kickstart e imágenes doradas

Instalación interactiva desde ISO (buena para el primer nodo, mala para flotas)

Usa el instalador interactivo para validar compatibilidad de hardware, supuestos de almacenamiento y nombres de NIC. Luego para. No construyas diez servidores haciendo clic en las mismas pantallas diez veces y confiando en tu memoria.

Kickstart (la opción adulta)

Kickstart te da instalaciones versionables y revisables. Eso significa:

• Particionado y selección de paquetes auditable.
• Nombres de red y servicios base predecibles.
• Un camino hacia provisión por PXE y reconstrucciones sin intervención.

Cuando llegue el inevitable “necesitamos reconstruir el nodo 14 ahora mismo”, Kickstart convierte el pánico en una rutina.

Imágenes doradas (usar con cuidado)

Las imágenes doradas son excelentes para nubes e hipervisores, pero pueden hornear problemas: machine IDs obsoletos, claves SSH host duplicadas y artefactos extraños de udev/red. Si vas por esta ruta, necesitas un paso de inicialización en el primer arranque que restablezca la identidad y vuelva a sellar secretos correctamente.

Diseños de almacenamiento que sobreviven auditorías y caídas

Diseño base para servidores de propósito general (recomendado)

Para una VM típica o servidor bare-metal que ejecute algunos servicios:

• /boot (ext4): pequeño, estable.
• /boot/efi (vfat): partición del sistema UEFI.
• / (XFS): OS y binarios.
• /var (XFS): logs, caches, spools, contenedores.
• /home opcional (XFS): si los humanos realmente inician sesión (intenta no hacerlo).

LVM encima de RAID (hardware o mdadm) te da flexibilidad: ampliar sistemas de archivos, añadir un nuevo LV para /var/lib/containers o esculpir espacio para datos de aplicaciones sin reinstalar.

Hosts de contenedores (no los trates como “solo servidores”)

Si el host ejecuta Podman/Docker o componentes de Kubernetes, planifica la amplificación de escrituras en almacenamiento. Da a /var mayor margen o separa /var/lib/containers en su propio LV. Si no lo haces, el runtime de contenedores eventualmente devorará tu OS.

Hosts de base de datos (separa OS y datos)

Para bases de datos, separa agresivamente OS y datos. Coloca los datos de la base en sus propios volúmenes con opciones de montaje claras, colas de I/O separadas si es posible y monitoreo. Mantén / y /var limpios para que las actualizaciones del OS y los logs no compitan con la carga principal.

Encriptación: LUKS es una decisión de política

La encriptación de disco es genial—hasta que necesitas reiniciar un servidor desatendido a las 2 a.m. Elige LUKS cuando también tengas un plan para desbloqueo remoto, acceso a consola y runbooks operacionales. “Teclearemos la frase de paso cuando se reinicie” no es un plan si el servidor está a 1.300 km.

Tareas prácticas: comandos, salidas y las decisiones que impulsan

Estos son los chequeos que ejecuto después de una instalación de AlmaLinux 10. Cada uno responde a una pregunta que importa durante una actualización o una caída.

Tarea 1: Verificar la versión del OS y línea de kernel

cr0x@server:~$ cat /etc/os-release
NAME="AlmaLinux"
VERSION="10.0 (Purple Lion)"
ID="almalinux"
ID_LIKE="rhel fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)"

Qué significa: Confirma que estás en la versión mayor y platform ID esperados.

Decisión: Si esto no dice el10, detente y arregla tu imagen/repositorio. No “actualices más tarde”.

Tarea 2: Confirmar modo de arranque UEFI (o no)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Qué significa: UEFI está activo si ese directorio existe.

Decisión: Si esperabas UEFI y obtuviste BIOS, arréglalo ahora. Los modos de arranque mixtos complican la estandarización, Secure Boot y los flujos de recuperación.

Tarea 3: Comprobar estado de Secure Boot

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Qué significa: Secure Boot está activado.

Decisión: Si está activado, trata a los módulos de kernel de terceros y drivers fuera del árbol como cambios controlados. Si está desactivado pero la política lo exige, arréglalo antes de incorporar a producción.

Tarea 4: Inspeccionar el diseño de discos y sistemas de archivos

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda       476G disk
├─sda1    600M part vfat   /boot/efi
├─sda2      1G part ext4   /boot
└─sda3  474.4G part LVM2_member
  ├─almalv-root  60G lvm   xfs    /
  ├─almalv-var  120G lvm   xfs    /var
  └─almalv-home  20G lvm   xfs    /home

Qué significa: Confirma partición UEFI, /boot separado y diseño basado en LVM.

Decisión: Si /var es pequeño en un host de servicio, arréglalo ahora (redimensiona LVs) antes de que logs/contenedores lo llenen y conviertan tu próxima actualización en una situación de rehenes.

Tarea 5: Validar que fstab sea sensato (sin montajes de red sorpresa al arranque)

cr0x@server:~$ cat /etc/fstab
UUID=3E2A-1C0B  /boot/efi  vfat  umask=0077,shortname=winnt  0  2
UUID=7b3e6dd4-0f3e-4a4c-9b0d-5a5f0a8a5f17  /boot  ext4  defaults  1  2
/dev/mapper/almalv-root  /     xfs   defaults  0  0
/dev/mapper/almalv-var   /var  xfs   defaults  0  0

Qué significa: Los montajes críticos de arranque son locales y sencillos.

Decisión: Si ves montajes NFS/CIFS sin nofail y timeouts apropiados, estás invitando a colgamientos de arranque tras el primer tropiezo de red.

Tarea 6: Comprobar nombres de NIC y estado de enlace (la predictibilidad importa)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens192           UP             00:50:56:aa:bb:cc

Qué significa: Nombre de interfaz y estado. UP significa enlace activo.

Decisión: Si los nombres difieren entre hardware/plantillas de VM idénticas, arregla tu aprovisionamiento o reglas de udev. “¿Cuál NIC es prod?” no es un juego divertido durante una caída.

Tarea 7: Confirmar IP, ruta y DNS con NetworkManager

cr0x@server:~$ nmcli -g GENERAL.DEVICE,GENERAL.STATE,IP4.ADDRESS,IP4.GATEWAY,IP4.DNS device show ens192
ens192:100 (connected)
10.20.30.40/24
10.20.30.1
10.20.30.10

Qué significa: El dispositivo está conectado, tiene IP, gateway y DNS.

Decisión: Si el DNS está mal, arréglalo antes de depurar “dnf está roto”. Casi siempre es DNS.

Tarea 8: Verificar sincronización horaria (TLS y auth dependen de ella)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-05 13:18:19 UTC
           Universal time: Tue 2026-02-05 13:18:19 UTC
                 RTC time: Tue 2026-02-05 13:18:19
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: Reloj sincronizado y NTP activo.

Decisión: Si System clock synchronized es no, arregla chrony antes de tocar certificados, Kerberos o sistemas distribuidos.

Tarea 9: Comprobar modo SELinux y denegaciones recientes

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ ausearch -m avc -ts recent | tail -n 5
----
time->Tue Feb  5 13:10:41 2026
type=AVC msg=audit(1738761041.223:412): avc:  denied  { name_connect } for  pid=1240 comm="nginx" dest=5432 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket permissive=0

Qué significa: SELinux está en enforcing; una denegación AVC muestra que nginx intentó conectar al puerto de Postgres.

Decisión: No desactives SELinux. Decide si el servicio debe hablar a ese puerto y aplica el booleano/etiquetado correcto. Si la conexión es legítima, arreglas la política; si no, arreglas la arquitectura.

Tarea 10: Confirmar estado del firewall y servicios abiertos

cr0x@server:~$ systemctl is-active firewalld
active

cr0x@server:~$ firewall-cmd --list-all
public (active)
  target: default
  interfaces: ens192
  services: ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Qué significa: El firewall está activo; sólo el servicio SSH está abierto en la zona public.

Decisión: Si tu host expone puertos aleatorios, ciérralos ahora. Si tu app necesita puertos, ábrelos explícitamente y documenta como código.

Tarea 11: Comprobar configuración de repos y actualizar metadata

cr0x@server:~$ dnf repolist
repo id                              repo name
almalinux-baseos                     AlmaLinux 10 - BaseOS
almalinux-appstream                  AlmaLinux 10 - AppStream
almalinux-crb                        AlmaLinux 10 - CRB

cr0x@server:~$ dnf -q check-update || true
kernel.x86_64  6.11.0-12.el10  almalinux-baseos
openssl.x86_64 3.2.2-4.el10    almalinux-baseos

Qué significa: Los repos están habilitados; hay actualizaciones disponibles.

Decisión: Si faltan repos o aparecen repos de terceros inesperados, detente. La seguridad de la actualización comienza con higiene de repos.

Tarea 12: Inspeccionar servicios habilitados (reducir sorpresas en el arranque)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled | head -n 15
UNIT FILE                          STATE   PRESET
chronyd.service                     enabled enabled
firewalld.service                   enabled enabled
sshd.service                        enabled enabled
tuned.service                       enabled enabled
NetworkManager.service              enabled enabled

Qué significa: Servicios centrales habilitados; puedes ver qué iniciará en el arranque.

Decisión: Deshabilita lo que no necesites. Cada daemon habilitado es tanto una superficie de ataque como una futura interacción de actualización.

Tarea 13: Validar postura de endurecimiento SSH

cr0x@server:~$ sshd -T | egrep 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Qué significa: Autenticación por contraseña y login root están deshabilitados; las claves están habilitadas.

Decisión: Si la autenticación por contraseña está habilitada en hosts accesibles por internet, arréglalo antes de convertirte en un nodo de botnet ajeno.

Tarea 14: Comprobar indicadores de salud del disco (NVMe/SATA)

cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.0-12.el10] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Qué significa: El dispositivo reporta salud PASSED (no perfecto, pero un comienzo).

Decisión: Si SMART está fallando o no disponible, decide si necesitas herramientas del proveedor, comprobaciones del controlador RAID o reemplazo proactivo. No esperes el teatro de “sistema de archivos en solo lectura”.

Tarea 15: Confirmar persistencia de journald y expectativas de volumen de logs

cr0x@server:~$ grep -E '^(Storage|SystemMaxUse|RuntimeMaxUse)=' /etc/systemd/journald.conf
Storage=persistent
SystemMaxUse=1G
RuntimeMaxUse=200M

Qué significa: Los logs persisten tras reinicio, con límites.

Decisión: Si journald no tiene límites en discos pequeños, capéalo. Si necesitas retención larga, envía logs fuera del host; no los atesores localmente como souvenirs.

Tarea 16: Medir rendimiento de arranque y encontrar unidades lentas

cr0x@server:~$ systemd-analyze
Startup finished in 3.212s (kernel) + 9.844s (userspace) = 13.056s
graphical.target reached after 9.801s in userspace

cr0x@server:~$ systemd-analyze blame | head
4.812s NetworkManager-wait-online.service
1.905s firewalld.service
1.102s chronyd.service

Qué significa: Señala servicios que enlentecen el arranque, a menudo “wait-online”.

Decisión: Si NetworkManager-wait-online domina y no lo necesitas, desactívalo. Un arranque más rápido significa recuperación y parcheo más rápidos.

Tarea 17: Comprobar CPU/memoria y presión (línea base para comparaciones posteriores)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\):|Thread|Core|Socket'
CPU(s):                               4
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Core(s) per socket:                   2
Socket(s):                            1

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       0.9Gi       5.9Gi       0.0Gi       0.9Gi       6.6Gi
Swap:          4.0Gi         0B       4.0Gi

Qué significa: Establece cómo es “normal” en una instalación limpia.

Decisión: Si la memoria ya está justa en un host nuevo, no despliegues cargas hambrientas de memoria y luego te sorprendas.

Tarea 18: Comprobar planificador de I/O y opciones de montaje (rendimiento y latencia)

cr0x@server:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber bfq none

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS / /var
/ xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota
/var xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

Qué significa: Muestra el planificador y opciones de montaje que afectan latencia y rendimiento.

Decisión: No “tunes” opciones de montaje al azar. Captura la línea base primero; cambia una cosa; mide; revierte si empeora.

Guion de diagnóstico rápido (encuentra el cuello de botella en minutos)

Esta es la secuencia de “estoy de guardia y algo se siente lento”. El objetivo es identificar si estás limitado por CPU, memoria, I/O, red o bloqueado por una dependencia (DNS, auth, backend de almacenamiento).

Primero: confirma que el síntoma es real y local

• ¿La aplicación está lenta para todos o solo desde un segmento de red?
• ¿El host está lento para todos los comandos o solo para la app?
• ¿Cambió algo (deploy, parche, config) en la última hora?

Segundo: comprueba saturación de recursos con herramientas sencillas

cr0x@server:~$ uptime
 13:22:11 up 10 days,  3:41,  1 user,  load average: 6.12, 5.98, 5.44

Interpretación: Un load average por encima del conteo de CPUs sugiere contención de CPU o crecimiento de la cola ejecutable (también podría ser I/O bloqueado que contribuye al load).

Decisión: Si el load es alto, comprueba inmediatamente uso de CPU vs iowait y la cola de ejecución.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  1      0 412112  90124 982112    0    0   120   450  580  900 25 10 45 20  0
 6  2      0 401980  90124 982400    0    0   110   980  600  950 22 11 42 25  0

Interpretación: r son procesos ejecutables, b son bloqueados, wa es iowait. Aquí, el iowait es significativo y hay procesos bloqueados.

Decisión: Trátalo como probable cuello de botella de almacenamiento. Pasa a comprobaciones de latencia de disco antes de ajustar hilos de la app.

Tercero: diferencia latencia de disco vs sistema de archivos lleno vs presión de memoria

cr0x@server:~$ df -hT / /var
Filesystem            Type  Size  Used Avail Use% Mounted on
/dev/mapper/almalv-root xfs    60G   18G   42G  31% /
/dev/mapper/almalv-var  xfs   120G  118G  2.0G  99% /var

Interpretación: /var está efectivamente lleno. Eso puede causar escrituras lentas, servicios fallidos y comportamiento extraño del gestor de paquetes.

Decisión: Detén la hemorragia: rota logs, limpia caches o amplia el LV. No “reinicies todo” y esperes lo mejor.

cr0x@server:~$ dmesg -T | tail -n 8
[Tue Feb  5 13:18:02 2026] XFS (dm-1): log I/O error -5
[Tue Feb  5 13:18:02 2026] XFS (dm-1): Filesystem has been shut down due to log error (0x2).

Interpretación: Si ves cierres del sistema de archivos, el problema no es tu app. Es almacenamiento o errores de dispositivo subyacente.

Decisión: Escala a storage/hardware inmediatamente. Protege los datos. Remonta como solo lectura si hace falta y planea una recuperación controlada.

Cuarto: valida red y DNS (porque siempre están en la lista de sospechosos)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.10
       DNS Servers: 10.20.30.10 10.20.30.11

Interpretación: Confirma la configuración de resolvedor y el servidor DNS activo.

Decisión: Si los servidores DNS están mal o inalcanzables, arréglalos antes de culpar a DNF, SSSD o la app.

Quinto: comprueba estado de servicios y logs con intención

cr0x@server:~$ systemctl --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● app.service    loaded failed failed Example Application

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Interpretación: Una unidad fallida es explícita; no adivines.

Decisión: Ve a journalctl -u app.service -b, arregla la causa raíz y luego reinicia. No reinicies como herramienta de diagnóstico a menos que disfrutes perder evidencia.

Tres micro-historias del mundo corporativo (porque alguien ya cometió tu error)

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa ligada a finanzas movió una flota de servicios internos a “Linux compatible con RHEL” para estandarizar parches. Se construyó una nueva imagen basada en AlmaLinux rápido, se aprobó rápido y se desplegó rápido. La suposición crítica: “El particionado por defecto del instalador está bien; es una distro empresarial”.

Estuvo bien para una VM tranquila. No estuvo bien para un nodo API ocupado que escribe logs, mantiene caché de paquetes y ejecuta un runtime de contenedores. En semanas, /var se llenó durante un día de pico. La app empezó a lanzar timeouts y el equipo de soporte persiguió problemas de red fantasma porque CPU y red se veían normales. Mientras tanto, journald empezó a descartar mensajes porque el espacio en disco escaseaba, y los logs más útiles desaparecieron justo cuando todos los necesitaban.

El postmortem fue incómodo porque nadie había hecho nada “malo” en el sentido habitual. El OS se instaló. El servicio arrancó. Existía monitoreo. La falla real fue asumir que el layout por defecto coincidía con la carga de trabajo.

La solución no fue heroica: reconstruyeron los nodos con un /var separado y más grande, aplicaron límites a journald y enviaron logs fuera del host. También añadieron una prueba de soak en preproducción que generaba intencionalmente volumen de logs y churn de capas de contenedores. Una vez que /var se mantuvo sano durante una semana de abuso sintético, volvieron a confiar en la imagen.

Micro-historia 2: La optimización que salió mal

Otra organización tenía un servicio sensible a latencia y un ingeniero con sano temor a los context switches. “Optimizó” deshabilitando unos servicios por defecto y ajustando valores de kernel/sysctl basados en un blog. También deshabilitó tuned porque “cambia cosas” y fijó el gobernador de CPU manualmente en un snippet de configuración.

En pruebas sintéticas rindió más rápido. Luego llegó una ventana de mantenimiento real. Después de una actualización y reinicio, el tiempo de arranque aumentó enormemente y el servicio inició de forma inconsistente entre nodos. Algunos nodos esperaron eternamente la red; otros arrancaron temprano, sufrieron timeouts DNS y fallaron. Un nodo estuvo bien. La flota no lo estuvo. El tuning había derivado porque la imagen dorada se actualizó en sitio y distintos equipos “arreglaron” nodos a mano.

Lo alarmante: la ganancia de rendimiento no era el problema. El problema fue la no reproducibilidad. Durante la recuperación no pudieron saber qué cambios estaban en qué nodo. La respuesta al incidente se volvió arqueología.

La corrección final fue aburrida: revertir sysctls desconocidos, reactivar servicios base y aplicar tuning de rendimiento vía perfiles versionados con puertas de medición explícitas. Aún afinan, pero solo con plan de avance/reversión y con gestión de configuración imponiendo homogeneidad.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa minorista ejecutaba AlmaLinux en sistemas de borde que ocasionalmente perdían conectividad de red. Nada sofisticado: algunos servicios locales, una cola y sincronización periódica. Su equipo de plataforma insistía en dos cosas que a nadie le encantaban: una lista de verificación de línea base estricta y simulacros rutinarios de reconstrucción usando Kickstart.

Un día un problema de firmware del controlador de almacenamiento empezó a causar errores de I/O intermitentes. Un par de nodos pasaron a solo lectura. El equipo de aplicación, con razón, quería “solo reiniciar” y seguir vendiendo. Pero el equipo de plataforma tenía una rutina practicada: capturar logs, marcar el nodo fuera de rotación, reconstruir en hardware conocido bueno y restaurar servicio desde la cola.

Como la instalación del OS era reproducible, no perdieron tiempo preguntándose en qué estado estaba la caja. Como las particiones eran consistentes, sus scripts de recolección de logs funcionaron. Como SELinux se aplicaba en todas partes, no tuvieron la deriva de seguridad de “funciona en nodo A pero no en nodo B”. La caída se contuvo, no se celebró.

Ese día nadie recibió crédito por ser ingenioso. La empresa recibió crédito por seguir abierta. Ese es el trabajo.

Broma #2: Lo único más permanente que una solución temporal es el ticket que dice “eliminar después”.

Errores comunes: síntoma → causa raíz → solución

1) DNF está lento o falla con timeouts

Síntoma: dnf makecache se cuelga o la descarga de metadata de repos falla por timeout.

Causa raíz: Misconfiguración de DNS, problemas de proxy o problemas de MTU/ruta. Menos a menudo: selección de mirror rota.

Solución: Confirma resolvedor y enrutamiento (nmcli, resolvectl), prueba resolución de nombres, valida ajustes de proxy en /etc/dnf/dnf.conf y en el entorno. Si estás en una VLAN con MTU extraña, prueba con ping -M do y ajusta.

2) El sistema no arranca después de activar Secure Boot

Síntoma: El arranque falla tras instalar drivers de terceros o módulos de kernel personalizados.

Causa raíz: Módulos sin firmar bloqueados por la política de Secure Boot.

Solución: Usa drivers firmados y soportados por el proveedor; inscribe claves si realmente gestionas tu propio firmado; de lo contrario desactiva Secure Boot solo si la política lo permite. No mezcles “cadena de arranque estricta” con “módulos DKMS aleatorios”.

3) Servicios fallan misteriosamente después de la instalación

Síntoma: El servicio arranca bien en un nodo y falla en otro con “permission denied” incluso como root.

Causa raíz: Denegaciones SELinux, archivos con etiquetas incorrectas o contextos erróneos tras copia manual de archivos.

Solución: Inspecciona denegaciones AVC, restaura contextos (restorecon), aplica etiquetas correctas y usa booleans donde corresponda. Desactivar SELinux no es una solución; es una rendición.

4) El arranque tarda una eternidad, especialmente en hosts en red

Síntoma: Tiempo de arranque largo; systemd-analyze blame muestra wait-online.

Causa raíz: NetworkManager-wait-online esperando conectividad en entornos donde no es necesario (o donde DHCP es inestable).

Solución: Desactiva wait-online cuando la carga no lo requiere al arranque, o corrige la dependencia de red. No enmascares problemas de red con esperas infinitas.

5) El disco se llena durante la operación normal

Síntoma: /var llega al 100%, los servicios se caen, los logs se detienen, DNF falla.

Causa raíz: /var subdimensionado, logs sin límite, crecimiento de capas de contenedores, directorios spool desbocados.

Solución: Redimensiona LVs, limita journald, configura logrotate, separa almacenamiento de contenedores y define alertas de monitoreo para uso de espacio e inodos.

6) Después de una actualización, la app no puede enlazar a puerto o conectar saliente

Síntoma: Permission denied al bind/connect incluso con la configuración correcta de la app.

Causa raíz: Etiquetado de puertos SELinux o reglas de firewall no alineadas con la app.

Solución: Comprueba la zona/puertos/servicios de firewalld, verifica tipos de puerto SELinux y aplica soluciones dirigidas. Evita reglas de “abrir todo” que se vuelvan pasivos permanentes.

7) Claves de host o identidad de máquina duplicadas en VMs clonadas

Síntoma: Advertencias SSH sobre cambios de clave de host; el monitoreo muestra múltiples nodos con la misma ID.

Causa raíz: Imagen dorada clonada sin regenerar machine-id y claves host SSH.

Solución: Usa cloud-init o scripts de primer arranque para resetear identidad, regenerar claves y asegurar hostnames únicos y reservas DHCP donde sea necesario.

Listas de verificación / plan paso a paso

Paso a paso: instalación AlmaLinux 10 de grado empresarial (servidor único)

1. Decide modo de arranque: Usa UEFI a menos que tengas una razón documentada para no hacerlo. Decide la política de Secure Boot por adelantado.
2. Decide diseño de almacenamiento: Planea /var separado para hosts de servicio. Usa LVM para flexibilidad. Elige XFS para la mayoría de cargas.
3. Configura hostname y red: Configura IP estática donde proceda; asegura DNS y NTP correctos.
4. Paquetes mínimos: Instala solo lo necesario. Menos paquetes significan menos CVEs y menos conflictos de actualización.
5. Crea acceso administrativo: Usa claves SSH. Desactiva login root por SSH. Crea una ruta de emergencia auditada.
6. Mantén SELinux en enforcing: Arregla problemas de política propiamente en vez de apagarlo.
7. Habilita firewall: Abre solo los puertos necesarios, de forma explícita.
8. Actualiza de inmediato: Parcha al estado menor actual antes de incorporar a producción.
9. Captura la línea base: Guarda salidas de comandos clave (repolist, diseño de montaje, servicios habilitados, sincronización horaria).
10. Registra en monitoreo: Espacio disco/inodos, CPU, memoria, carga y estado de servicios como mínimo.
11. Documenta plan de actualización: ¿Cuál es tu reversión? ¿Snapshot? ¿Reconstrucción? ¿Dónde se almacenan los datos?
12. Prueba un reinicio: Verifica arranque, red, servicios y disponibilidad de la aplicación después del reinicio.

Checklist: qué significa una “ruta de actualización limpia” en la práctica

• Construcción reproducible: Kickstart o pipeline de imágenes. Nada de copos hechos a mano.
• Gestión de configuración: Ansible/Salt/Puppet/etc. Aunque sea pequeño, ten algo.
• Control de repos: Repos conocidos únicamente; repos de terceros revisados y fijados.
• Separación de datos: Los datos de la app no se mezclan con archivos del OS. Backups y restores probados.
• Ensayos de actualización: Prueba en un nodo de staging representativo con patrones de tráfico reales cuando sea posible.
• Historia de reversión: Snapshot de VM, snapshot LVM (con precaución) o reconstrucción + restauración. Elige uno y practica.
• Observabilidad: Logs enviados fuera del host, métricas retenidas y dashboards conocidos por las personas que serán alertadas.

Checklist: endurecimiento post-instalación que no rompa a tu yo futuro

• Deshabilitar auth por contraseña SSH; exigir claves.
• Deshabilitar login root directo por SSH; usar sudo.
• Establecer límites en journald; verificar logrotate donde aplique.
• Habilitar y configurar zonas de firewalld correctamente.
• Confirmar chrony/NTP funcionando; usar UTC salvo razón fuerte en contra.
• Mantener SELinux en enforcing; tratar denegaciones como señales, no como molestias.
• Eliminar paquetes/servicios no usados; menos es menos.

Preguntas frecuentes

1) ¿Debería elegir AlmaLinux 10 para nuevos sistemas de producción?

Si quieres convenciones Enterprise Linux y un ecosistema estable, sí. La ganancia operacional viene de la compatibilidad y la previsibilidad, no de la novedad.

2) ¿Es una “instalación mínima” realmente mejor?

Por lo general sí. Menos paquetes reducen la exposición a seguridad e interacciones en actualizaciones. Instala lo necesario y deja que la gestión de configuración agregue el resto.

3) ¿Cuál es el mejor sistema de archivos para servidores AlmaLinux 10?

XFS es el predeterminado seguro para la mayoría de sistemas de archivos de servidor. Ext4 está bien para /boot y roots pequeñas. Elige ZFS solo si también eliges su modelo operacional.

4) ¿Necesito LVM?

Si operas sistemas reales: sí, la mayoría de las veces. LVM permite redimensionar y arreglar el layout sin reinstalar. Sin él, apuestas a que nunca te equivocarás sobre uso de disco.

5) ¿Debería separar /var?

Para hosts de servicio, sí. Especialmente con contenedores, CI, logging intenso o caché de paquetes. Mantener /var aislado evita que una carga ruidosa inutilice el OS.

6) ¿Vale la pena Secure Boot?

Vale la pena cuando puedes soportarlo de forma consistente y tu entorno valora la integridad de arranque. Si usas rutinariamente módulos fuera del árbol, Secure Boot puede convertirse en un impuesto de mantenimiento recurrente.

7) ¿Cómo aseguro una ruta limpia de actualización mayor?

Haz que las reconstrucciones sean fáciles. Controla repos. Mantén la configuración declarativa. Separa datos. Entonces las actualizaciones serán eventos planeados en lugar de rituales desesperados.

8) SELinux está bloqueando mi app. ¿Cuál es la solución correcta?

Encuentra la denegación, decide si el acceso es legítimo y aplica cambios dirigidos (booleans, contextos correctos, puertos permitidos). Apagar SELinux arregla el síntoma borrando la barrera.

9) ¿Qué revisar primero cuando “el servidor está lento”?

uptime y vmstat. Quieres saber si estás atascado por CPU, I/O o memoria antes de tocar la aplicación.

10) ¿Puedo confiar en imágenes doradas en lugar de Kickstart?

Puedes, pero solo si tienes un proceso de primer arranque que resetea identidad y mantienes el pipeline de imágenes disciplinado. Si no, clonarás los errores de ayer a escala.

Conclusión: próximos pasos prácticos

Si quieres que AlmaLinux 10 se sienta “empresarial”, instálalo como planeas convivir con él. La mayoría del dolor viene del crecimiento no planificado: logs, contenedores, caches y cambios humanos que nunca vuelven a la automatización.

Haz esto a continuación:

1. Elige un diseño de almacenamiento con una estrategia real para /var y escríbelo.
2. Decide la política UEFI + Secure Boot a nivel de flota, no host por host.
3. Convierte tu mejor instalación interactiva en un Kickstart y reconstruye un nodo desde cero para probar que funciona.
4. Captura una línea base con el conjunto de comandos arriba y guárdala con la configuración del sistema.
5. Ejecuta una falla simulada: llena /var en staging, observa qué se rompe y arréglalo antes de que producción lo haga por ti.

Cuando lleguen las actualizaciones, aún tendrás trabajo. Pero será el tipo de trabajo que termina a tiempo, no el tipo que termina con un postmortem y un nuevo respeto por el espacio en disco.