Instalación de Rocky Linux 10: compatible con RHEL sin el dolor de la suscripción

Lo que realmente estás construyendo (y lo que no)

Rocky Linux 10 es la jugada de “quiero el comportamiento de RHEL sin la burocracia de RHEL”. Si has pasado tiempo con Linux empresarial,
ya sabes por qué importa: tus proveedores certifican contra una plataforma, tus auditores esperan ciertos controles,
y tus runbooks operativos asumen systemd, SELinux, nombres de paquetes predecibles y una ventana de soporte larga.

Pero aclaremos el trato:

• Obtienes userland y comportamiento de kernel compatibles con RHEL, una pila de empaquetado familiar (dnf/rpm) y valores predeterminados empresariales.
• No obtienes contratos de soporte del proveedor por defecto, integraciones de gestión propietarias o repos bloqueados por suscripción.
• Debes obligatoriamente realizar tu propia validación básica: modo de arranque, esquema de disco, actualizaciones, sincronización horaria, registros y postura de seguridad.

Si tu entorno necesita soporte oficial del proveedor por razones regulatorias o contractuales, cómpralo donde importe.
Si tu entorno necesita “funcionar igual, parchear igual y no sorprendernos”, Rocky es una opción sólida.

Una verdad operativa: la mayoría de las interrupciones no son causadas por bugs exóticos del kernel. Son causadas por suposiciones—sobre almacenamiento,
sobre orden de arranque, sobre el estado de los repos, sobre “la endureceremos después”. Rocky Linux no evita esas suposiciones. Tú sí.

Datos interesantes y contexto histórico

Estos no son puntos para la noche de trivia. Ayudan a explicar por qué existe Rocky y por qué se comporta como lo hace.

1. Los clones de RHEL son un patrón recurrente. El ecosistema lleva tiempo con reconstrucciones de Linux empresarial para capturar compatibilidad con RHEL sin fricciones de licencia directa.
2. CentOS solía ser el “RHEL gratuito” por defecto. Durante años, muchas organizaciones estandarizaron en CentOS para flotas de servidores porque seguía de cerca a RHEL.
3. CentOS Stream cambió expectativas. Cuando Stream se convirtió en el foco, pasó de “reconstrucción downstream” a una vista previa continua de lo que podría llegar a RHEL.
4. Rocky Linux se creó en respuesta a ese cambio. Un amplio segmento de la industria necesitaba de nuevo una plataforma estable y downstream-compatible.
5. El “contrato del Linux empresarial” es social tanto como técnico. Estabilidad significa pocas sorpresas: expectativas de ABI, cadencia del kernel y valores conservadores.
6. dnf reemplazó a yum por una razón. Resolución de dependencias, modularidad y mejoras de rendimiento no fueron cosméticas; abordaron años de dolor en el parcheo de flotas.
7. SELinux no es opcional en entornos serios. Es una de las grandes razones por las que los sistemas “tipo RHEL” se pueden desplegar a escala sin convertir cada servicio en una rareza personalizada.
8. systemd estandarizó el comportamiento de servicios entre distribuciones. Lo ames o lo odies, hizo que la supervisión de servicios, el registro y la gestión de dependencias fuera más consistente.
9. UEFI + GPT es ya la realidad por defecto. Si aún diseñas como si todo fuera BIOS+MBR, estás construyendo bombas de tiempo para plataformas modernas de servidores.

Decisiones previas que previenen cortes

1) Decide: UEFI o BIOS heredado (y no mezcles estilos)

Si el hardware es remotamente moderno, usa UEFI. No es una cuestión de moda; es sobre una gestión de arranque coherente,
mejor soporte de GPT y menos misterios de “¿por qué desapareció el cargador de arranque tras una actualización de firmware?”.

Mezclar modos de arranque del medio de instalación (instalar en legacy BIOS en un host y en UEFI en otro) crea deriva operativa.
La deriva genera confusión, y la confusión genera tickets a las 03:00.

2) Decide: esquema de almacenamiento por dominio de falla, no por hábito

Tu plan de almacenamiento debería responder a dos preguntas:

• ¿Qué falla? Disco, controlador, nodo, rack, volumen en la nube, humano.
• ¿Qué se rompe cuando falla? Arranque, sistema raíz, registros, base de datos, imágenes de contenedores.

Guía simple que aguanta en producción:

• Fiabilidad de arranque: Mantén /boot simple. Si haces RAID, asegúrate de que tu gestor de arranque lo soporte sin problemas.
• Control operativo: Pon /var en su propio volumen lógico si la máquina va a registrar mucho o ejecutar contenedores. Las tormentas de logs no deben llenar root.
• Barandillas de seguridad: Si no puedes permitirte tiempo de inactividad, usa redundancia (RAID hardware o mdraid) para discos de sistema; no finjas que los snapshots en nube son RAID.
• Rendimiento: Separa los caminos de escritura intensiva (bases de datos, aplicaciones con journal intenso) del resto. Si no puedes, al menos monitoriza I/O y planifica capacidad.

3) Decide: LVM o “particiones simples”

Usa LVM para casi todos los servidores. Hace que el redimensionamiento sea sensato, soporta snapshots (con matices) y te da un límite de abstracción controlado.
Las particiones simples están bien para appliances inmutables, pero la mayoría de los servidores “temporales” viven años.

4) Decide: elección de sistema de archivos (XFS vs ext4) con intención

XFS es un predeterminado común en entorno empresarial por buenas razones: escalable, robusto y bien soportado. ext4 también está perfectamente bien.
Elige uno y estandariza, a menos que tengas una razón de carga de trabajo para desviarte.

5) Decide: plan de red (estática, reservas DHCP o dinámica)

Los servidores que ejecutan servicios de producción deben tener direccionamiento predecible. Puede ser configuración estática o reservas DHCP,
pero “obtendrá cualquier IP” no es un plan.

6) Decide: cómo parchearás (y cómo revertirás)

Parchear no es un evento; es una canalización. Decide ahora:

• ¿Actualizas automáticamente (dnf-automatic) o haces lotes y apruebas?
• ¿Cuál es tu política de actualización de kernel?
• ¿Haces snapshot de discos de VM antes de parchear? ¿Tienes un método de rollback probado?

Broma #1 (corta, relevante): Trata el parcheo como el uso del hilo dental—todos están de acuerdo en que es bueno, y la mayoría de las interrupciones ocurren porque alguien “pensó en empezar mañana”.

Guía de instalación: UEFI, almacenamiento y valores sensatos

Step 0: verifica el medio de instalación y el modo de arranque

Antes de hacer clic en “Instalar”, confirma que has arrancado como pretendes (UEFI vs legacy). En muchos servidores, el menú de arranque
mostrará dos entradas para la misma ISO USB—elige la UEFI a menos que tengas una razón para no hacerlo.

Step 1: elige un conjunto de paquetes mínimo salvo que necesites GUI

Para servidores, elige una instalación mínima. Cada paquete extra es:
otra actualización,
otra posible vulnerabilidad,
otro momento de “¿por qué este servicio escucha en un puerto que no conocíamos?”.

Step 2: zona horaria, localización y teclado (las armas silenciosas)

Configura la zona horaria correctamente y habilita la sincronización de tiempo más tarde. Certificados, Kerberos, correlación de logs y líneas temporales de incidentes dependen de relojes que no mientan.

Step 3: particionado de disco que no te perseguirá

Si instalas en una VM de un solo disco, el esquema seguro más simple es:

• Partición del sistema UEFI (ESP), pequeña
• /boot, pequeña
• PV LVM para el resto
• Volúmenes lógicos para /, /var y swap (el tamaño de swap depende de la carga; no lo hagas por costumbre)

Si instalas en servidores físicos con dos discos de sistema, tienes dos enfoques comunes:

• RAID1 hardware para discos de sistema: lo más sencillo operativamente; el controlador se convierte en una dependencia.
• RAID1 software (mdraid): transparente y portable entre controladores; debes tener cuidado con la ubicación del cargador de arranque/UEFI.

Step 4: red y nombre de host

Pon un nombre de host real. Si tu convención de nombres es un desastre, arregla la convención, no los hostnames después del despliegue.
Los nombres de host aparecen en logs, monitorización, certificados y en la mente de las personas.

Step 5: creación de usuario y SSH

Crea un usuario administrador no root. Permite SSH con claves. Mantén SSH por contraseña deshabilitado salvo que tengas una necesidad específica, y aun así,
constriñe su uso mediante política de red y MFA cuando sea posible.

Step 6: SELinux debe estar Enforcing

Mantén SELinux en Enforcing. Si lo deshabilitas “solo por ahora”, lo olvidarás y la máquina se convertirá en un caso especial.
Los casos especiales son donde los pagers van a reproducirse.

Step 7: validación del primer arranque

Después del primer arranque, no instales de inmediato tu pila de aplicaciones. Valida el sistema base: modo de arranque, salud del disco,
configuración de repos, actualizaciones, sincronización de tiempo y registro.

Post-instalación: actualizaciones, repos, línea base de seguridad y higiene de servicios

Repos: mantenlo aburrido e intencional

El Linux empresarial vive y muere por la disciplina de repositorios. Quieres:
un conjunto conocido de repos,
paquetes consistentes entre hosts,
y un comportamiento de actualización predecible.

No habilites repos de terceros al azar en servidores de producción porque un blog lo dijo. Si necesitas paquetes adicionales, toma una decisión consciente:
mirroréalos, pínalos y prueba las actualizaciones en un entorno de staging que se parezca a producción.

Actualizaciones: parchea temprano y luego con regularidad

Tu primera acción real después de instalar debe ser actualizar, luego reiniciar si cambió el kernel o bibliotecas críticas.
Esto establece la línea base y evita el mito de “está corriendo desde el día de la instalación”.

Línea base de seguridad: SSH, firewalld y política SELinux

Configura SSH con claves, bloquea el inicio de sesión root, mantiene firewalld activo y usa SELinux como fue pensado:
como una capa de seguridad que limita la radio de impacto.

Registro: conserva los logs, no te ahogues en ellos

Configura persistencia de journald si la necesitas, reenvía logs a almacenamiento central y limita la retención local para que el host no
haga un self-DoS llenando el disco.

Cita (idea parafraseada)

Idea parafraseada: todo falla eventualmente; la resiliencia viene de diseñar para la falla, no de esperar que no ocurra.
— Werner Vogels (liderazgo orientado a la fiabilidad, parafraseado)

Tareas prácticas: comandos, significado de salidas y decisiones (12+)

Estos son los chequeos que realmente ejecuto después de instalar un sistema compatible con RHEL. Cada uno termina con una decisión,
porque los comandos sin decisiones son solo arte performativo.

Task 1: Confirma versión del SO e identidad de la plataforma

cr0x@server:~$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="10.0 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.0 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="rocky"

Qué significa: Estás en Rocky 10 y anuncia compatibilidad con la familia RHEL.

Decisión: Si PLATFORM_ID no es EL10, detente y confirma que no instalaste la ISO equivocada o un derivado que no quieres.

Task 2: Verifica modo de arranque (UEFI vs legacy)

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

Qué significa: La presencia del directorio de firmware EFI indica arranque en UEFI.

Decisión: Si esperabas UEFI y obtuviste BIOS, reinstala correctamente ahora. No lo “arregles después”. Después es caro.

Task 3: Inspecciona dispositivos de bloque y mapa de particiones

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda        200G disk
├─sda1     600M part vfat   /boot/efi
├─sda2       1G part xfs    /boot
└─sda3   198.4G part LVM2_member
  ├─rl-root   40G lvm  xfs  /
  ├─rl-var    80G lvm  xfs  /var
  └─rl-swap    8G lvm  swap [SWAP]

Qué significa: Tienes un layout limpio UEFI + /boot + LVM, y /var está aislado.

Decisión: Si /var no está separado en un host con muchos logs (contenedores, bases de datos, runners CI), considera reconstruir antes de que lleguen los datos.

Task 4: Comprueba uso de sistemas de archivos y la trampa “/var llenó root”

cr0x@server:~$ df -hT
Filesystem           Type   Size  Used Avail Use% Mounted on
/dev/mapper/rl-root  xfs     40G  2.3G   38G   6% /
/dev/mapper/rl-var   xfs     80G  5.1G   75G   7% /var
/dev/sda2            xfs    960M  220M  740M  23% /boot
/dev/sda1            vfat   599M  6.2M  593M   2% /boot/efi

Qué significa: Espacio libre saludable en los puntos de montaje importantes.

Decisión: Si root es pequeño y /var no está separado, estás a un pico de logs de tener un sistema de archivos raíz de solo lectura.

Task 5: Confirma corrección de fstab (el arranque importa más que la estética)

cr0x@server:~$ cat /etc/fstab
UUID=2f6c4d9b-4c1e-4ed6-a57b-3e1e6e2a9b0a /                       xfs     defaults        0 0
UUID=fa1b70d8-5b0c-4b98-8e12-7c0d8f8195a2 /var                    xfs     defaults        0 0
UUID=8d8a7d9f-9b02-4d5e-9f21-3d65d7f6e4bc /boot                   xfs     defaults        0 0
UUID=0A1B-2C3D                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/rl-swap                       none                    swap    defaults        0 0

Qué significa: Montajes basados en UUID reducen sorpresas si cambian los nombres de dispositivo.

Decisión: Si ves rutas de dispositivo como /dev/sda3 para montajes críticos en servidores físicos, cámbialas a UUIDs ahora.

Task 6: Verifica estado de repos y evita “paquetes misteriosos”

cr0x@server:~$ dnf repolist
repo id                         repo name
appstream                       Rocky Linux 10 - AppStream
baseos                          Rocky Linux 10 - BaseOS
extras                          Rocky Linux 10 - Extras

Qué significa: Tienes los repos centrales habilitados. Eso suele ser lo que quieres en el día uno.

Decisión: Si ves repos extra que no aprobaste, desactívalos antes de instalar nada. Reproducibilidad gana a novedad.

Task 7: Revisa actualizaciones y entiende la radio de impacto

cr0x@server:~$ dnf check-update
Last metadata expiration check: 0:12:31 ago on Tue 06 Feb 2026 10:14:20 AM UTC.
kernel.x86_64                     6.12.0-1.el10_0                 baseos
openssl-libs.x86_64               3.2.2-4.el10_0                  baseos
systemd.x86_64                    256.7-2.el10_0                  baseos

Qué significa: Hay actualizaciones pendientes de kernel, OpenSSL y systemd—esto no es una categoría de “quizá más tarde”.

Decisión: Parchea ahora en una ventana de mantenimiento; planifica un reinicio si se actualizan kernel/systemd. Si este host forma parte de un clúster, haz un rollout por fases.

Task 8: Aplica actualizaciones y captura lo que cambió

cr0x@server:~$ sudo dnf -y update
Dependencies resolved.
================================================================================
 Package           Arch   Version                 Repository               Size
================================================================================
Upgrading:
 kernel            x86_64 6.12.0-1.el10_0         baseos                  12 M
 openssl-libs      x86_64 3.2.2-4.el10_0          baseos                 2.4 M
 systemd           x86_64 256.7-2.el10_0          baseos                 4.1 M

Transaction Summary
================================================================================
Upgrade  3 Packages

Complete!

Qué significa: Actualizaste componentes centrales.

Decisión: Reinicia pronto. No dejes un kernel nuevo instalado pero no en ejecución; eso crea la ilusión de “está parcheado”.

Task 9: Valida estado de SELinux (y no negocies con él)

cr0x@server:~$ getenforce
Enforcing

Qué significa: SELinux está haciendo su trabajo.

Decisión: Si está Permissive o Disabled, arréglalo ahora a menos que tengas una excepción documentada con controles compensatorios.

Task 10: Confirma estado del cortafuegos y puertos abiertos intencionalmente

cr0x@server:~$ sudo firewall-cmd --state
running

cr0x@server:~$ sudo firewall-cmd --list-services
ssh

Qué significa: firewalld está en ejecución y solo SSH está permitido por la definición de servicios.

Decisión: Si ves servicios de amplio acceso que no reconoces, elimínalos. “Lo restringiremos después” es cómo los puertos de prueba se convierten en características de producción.

Task 11: Comprueba sincronización horaria (porque los logs deben coincidir)

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

Qué significa: El reloj del sistema está sincronizado, el servicio NTP está activo.

Decisión: Si la sincronización es “no”, arréglalo antes de unir a dominios, emitir certificados o depurar cualquier cosa distribuida.

Task 12: Verifica configuración de red y resolución DNS

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens192           UP             10.40.12.34/24 fe80::250:56ff:feaa:bbcc/64

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.40.12.10
       DNS Servers: 10.40.12.10 10.40.12.11
        DNS Domain: corp.example

Qué significa: Tienes una dirección y el DNS está apuntando a algo intencional.

Decisión: Si el DNS apunta a un resolvedor aleatorio o no resuelve zonas internas, arréglalo ahora—las instalaciones de paquetes y el descubrimiento de servicios fallarán de maneras creativas.

Task 13: Confirma servicios del sistema y detecta escuchas accidentales

cr0x@server:~$ systemctl --failed
0 loaded units listed.

cr0x@server:~$ ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=991,fd=3))
LISTEN 0      4096   127.0.0.1:323       0.0.0.0:*     users:(("chronyd",pid=812,fd=5))

Qué significa: Nada falló; solo puertos esperados están abiertos.

Decisión: Si ves listeners inesperados, identifica el paquete y deshabilita el servicio antes de que sea titular de un informe de incidente.

Task 14: Valida salud del almacenamiento (la exposición hardware varía)

cr0x@server:~$ sudo dmesg -T | grep -E "I/O error|blk_update_request|reset|nvme|ata" | tail -n 8
[Tue Feb  6 10:21:22 2026] nvme nvme0: pci function 0000:5e:00.0
[Tue Feb  6 10:21:22 2026] nvme nvme0: 4/0/0 default/read/poll queues
[Tue Feb  6 10:21:22 2026] nvme0n1: p1 p2 p3

Qué significa: No hay errores de almacenamiento obvios; el dispositivo se enumeró correctamente.

Decisión: Si ves resets o errores de I/O aquí durante el día de instalación, reemplaza hardware o arregla firmware antes de confiar datos importantes a este host.

Task 15: Higiene de kernel y reinicio (evita “parcheado pero no reiniciado”)

cr0x@server:~$ uname -r
6.12.0-1.el10_0.x86_64

cr0x@server:~$ sudo dnf -q repoquery --installed --latest-limit=1 kernel
kernel-6.12.0-1.el10_0.x86_64

Qué significa: El kernel en ejecución coincide con el último kernel instalado.

Decisión: Si estos no coinciden después de una actualización, programa un reinicio y regístralo. “Lo actualizamos” no cuenta hasta que se está ejecutando.

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición equivocada

Una compañía mediana migró una flota de servicios internos desde un CentOS envejecido a una reconstrucción compatible con RHEL.
Trataron la instalación del SO como una formalidad y se centraron en el despliegue de aplicaciones.
La suposición era simple: “El espacio en disco es espacio en disco. Los valores por defecto están bien.”

La pila de aplicaciones estaba muy basada en contenedores. Los logs eran ruidosos pero manejables—hasta que se dejó activado un flag de depuración en un servicio.
En pocas horas, /var se infló. En su instalación de “los valores por defecto están bien”, /var vivía en el filesystem raíz.
Root alcanzó 100% y el sistema empezó a fallar de maneras que parecían no relacionadas: inicios de sesión SSH colgaban, unidades systemd agotaban tiempo
y el nodo dejó de aceptar nuevas descargas de contenedores.

El on-call inicialmente persiguió CPU y red. Los gráficos eran ruidosos; el disco estaba gritando en silencio.
Eventualmente alguien ejecutó df, vio root lleno y borró logs. El host se recuperó—más o menos.
Luego disfrutaron de la secuela: descargas parciales corruptas y un runtime de contenedores que necesitó reinicio.

La solución no fue “decir a los desarrolladores que logeen menos” (aunque sí, también eso). La solución real fue un layout de almacenamiento que asumiera fallas:
separar /var, limitar la retención de journald y enviar logs fuera del host. El incidente terminó siendo una lección de instalación,
no una lección de aplicación, lo cual es un tipo especial de molesto.

Microhistoria 2: La optimización que salió mal

Otra organización tenía un mandato de rendimiento: builds CI más rápidos, descargas de artefactos más rápidas, todo más veloz.
Alguien propuso una “optimización”: montar el workspace de build en un único filesystem grande, sin volúmenes separados,
y afinar para throughput. También deshabilitaron SELinux porque “está ralentizando operaciones de archivos”.

El CI se volvió un poco más rápido. Luego se volvió raro. Aparecieron anomalías de permisos, pero solo bajo carga.
Algunos builds fallaron con errores de sistema de archivos; los reintentos tuvieron éxito. Los equipos culparon a la herramienta de CI, a la red,
y una vez, brevemente, a la luna.

La causa raíz fue un cóctel: afinaciones agresivas más un workspace que generaba gran churn de metadatos,
combinado con una canalización de logs que ocasionalmente generaba picos de escritura. Sin aislamiento entre /, /var
y el workspace de build, el peor día de una carga de trabajo se convirtió en el peor día de todos.
Deshabilitar SELinux no “arregló el rendimiento”; solo quitó una barrera, y la revisión de seguridad eventual los obligó
a reactivarlo bajo presión—durante una ventana de lanzamiento de fin de trimestre. Fue… una elección.

Deshicieron la “optimización”: volúmenes lógicos separados, valores sensatos de planificación I/O, SELinux Enforcing,
y un enfoque medido para el tuning con benchmarks que reflejaban la realidad.
Los tiempos de build fueron ligeramente más lentos que la configuración “más rápida”, pero la tasa de fallos cayó drásticamente.
En operaciones de producción, lo más rápido rara vez es lo mejor.

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

Un equipo cercano a finanzas ejecutaba sistemas tipo Rocky para servicios internos.
Su práctica era dolorosamente aburrida: cada instalación seguía una checklist, cada host tenía el mismo particionado,
los repos estaban fijados y las actualizaciones se probaban a través de un anillo canario.
No era glamoroso. Era efectivo.

Una mañana, un lote de hosts empezó a no arrancar tras una actualización de firmware realizada por otro equipo.
El modo de fallo varió por modelo de hardware. Algunos sistemas cayeron en un prompt de arranque; otros no encontraban la entrada EFI.
Aquí es donde normalmente ves pánico y gente “arreglando” cosas a mano en la consola.

Se recuperaron rápido porque su disciplina de instalación les daba un estado predecible:
UEFI en todas partes, tamaños de ESP consistentes, configuración de cargador consistente y una forma estándar de verificar y reconstruir entradas EFI.
Pudieron comparar un host roto con uno conocido bueno y aplicar los mismos pasos de recuperación sin conjeturas.

El resultado no fue una noche heroica. Fue un incidente tranquilo con un postmortem limpio.
El mejor cumplido que operaciones puede ganarse es: “Eso fue aburrido.” Broma #2 (corta, relevante): La infraestructura aburrida es como un cinturón de seguridad—solo la notas cuando no la tienes.

Manual de diagnóstico rápido

Cuando una instalación fresca de Rocky Linux 10 “se siente lenta”, “no se actualiza” o “no puede alcanzar cosas”, no divagues.
El triage es una secuencia. Tu objetivo es identificar la clase de cuello de botella en minutos.

Primero: identifica el dominio de falla (arranque, red, almacenamiento, CPU/memoria, repos)

• Problemas de arranque: atascado en el cargador, modo de emergencia, raíz ausente, fallos de fsck.
• Problemas de red: fallos DNS, no alcanzar repos, sin ruta por defecto, pérdida intermitente de paquetes.
• Problemas de almacenamiento: iowait alta, errores en el journal, filesystems llenos, resets de dispositivo.
• Problemas de cómputo: load average alto, OOM kills, procesos desbocados.
• Problemas de repos/paquetes: conflictos de dependencias, timeouts de metadata, errores GPG.

Segundo: ejecuta los tres discriminadores más rápidos

1) Espacio en disco y sanidad de inodos

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   40G  2.3G   38G   6% /
/dev/mapper/rl-var    80G  5.1G   75G   7% /var

Interpretación: Si cualquier filesystem crítico está por encima de ~90%, trátalo como causa del incidente hasta demostrar lo contrario.

Decisión: Libera espacio, expande LV o limita logs antes de hacer otra cosa.

2) DNS y ruta por defecto

cr0x@server:~$ ip route
default via 10.40.12.1 dev ens192 proto static metric 100
10.40.12.0/24 dev ens192 proto kernel scope link src 10.40.12.34 metric 100

cr0x@server:~$ getent hosts mirrors.rockylinux.org
203.0.113.20   mirrors.rockylinux.org

Interpretación: Si la búsqueda DNS falla, las operaciones de repo y muchas cosas “aleatorias” fallan.

Decisión: Arregla DNS/ruteo antes de culpar a dnf o al SO.

3) iowait y principales culpables

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
 1  0      0 312544  42152 812344    0    0   120   220  310  640  6  3 89  2  0
 0  1      0 309812  42152 812512    0    0   320  5400  290  610  4  2 65 29  0
 0  1      0 310120  42160 812600    0    0   280  5100  300  620  5  2 63 30  0
 0  0      0 311004  42160 812900    0    0   140   260  305  635  5  2 90  3  0
 1  0      0 310888  42168 812930    0    0   150   240  320  650  6  3 88  3  0

Interpretación: wa (iowait) en picos sugiere contención de almacenamiento o problemas del dispositivo.

Decisión: Si iowait está alto, deja de afinar CPU. Investiga discos, colas y servicios con escrituras intensas.

Tercero: profundiza una capa según lo que encontraste

• Si falla el arranque: revisa el journal del arranque previo, verifica /etc/fstab, comprueba entradas EFI.
• Si dnf falla: verifica repos, DNS, reloj y claves GPG; inspecciona el texto de error de dnf como adulto.
• Si el rendimiento es malo: identifica si es CPU, presión de memoria o latencia de almacenamiento; no adivines.

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

1) “dnf update se agota”

Síntomas: Cannot download repomd.xml, metadata lenta, fallos intermitentes.

Causa raíz: Configuración DNS incorrecta, problemas de proxy o ruta por defecto rota.

Solución: Valida ruteo y DNS; confirma sincronización horaria; luego reintenta.

cr0x@server:~$ curl -I -m 5 https://mirrors.rockylinux.org
HTTP/2 200
date: Tue, 06 Feb 2026 10:45:12 GMT
content-type: text/html

Decisión: Si curl no puede alcanzarlo, dnf tampoco. Arregla la ruta de red primero.

2) “Después del reinicio, entra en modo de emergencia”

Síntomas: shell de emergencia systemd, mensaje sobre fallo al montar un filesystem.

Causa raíz: Entrada incorrecta en /etc/fstab, UUID equivocado, disco ausente o carrera con montajes de red.

Solución: Usa systemctl status y los mensajes del journal para identificar la unidad de montaje, luego corrige fstab.

cr0x@server:~$ systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
  var.mount      loaded failed failed /var

Decisión: Si es un montaje local, corrige UUIDs. Si es un montaje de red, añade dependencias adecuadas o nofail con timeouts sensatos.

3) “SSH funciona, pero todo lo demás no conecta”

Síntomas: Puedes SSH, pero HTTPS saliente falla o servicios internos no son alcanzables.

Causa raíz: Falta de ruta por defecto, máscara de subred errónea o firewall bloqueando salidas (menos común).

Solución: Inspecciona rutas y configuración de interfaz, confirma accesibilidad de la puerta de enlace.

cr0x@server:~$ ping -c 2 10.40.12.1
PING 10.40.12.1 (10.40.12.1) 56(84) bytes of data.
64 bytes from 10.40.12.1: icmp_seq=1 ttl=64 time=0.388 ms
64 bytes from 10.40.12.1: icmp_seq=2 ttl=64 time=0.402 ms

--- 10.40.12.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Decisión: Si no puedes alcanzar la puerta de enlace, deja de culpar al DNS y arregla L2/L3 primero.

4) “SELinux bloquea mi servicio; lo desactivé”

Síntomas: Servicio falla al iniciar, denegaciones AVC en logs, alguien cambia SELinux a permissive/disabled.

Causa raíz: Archivos mal etiquetados, puertos no estándar o servicio configurado fuera de rutas esperadas.

Solución: Lee la denegación, etiqueta correctamente, permite el tipo de puerto donde proceda y mantén SELinux enforcing.

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
----
type=AVC msg=audit(1738839012.412:911): avc:  denied  { name_connect } for  pid=1420 comm="nginx" dest=8080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket

Decisión: Si es una conexión legítima, configura puertos/etiquetas; si es comportamiento inesperado, trátalo como hallazgo de seguridad.

5) “El sistema es lento bajo carga; CPU parece bien”

Síntomas: Picos de latencia, load average elevado, CPU en idle alto, usuarios se quejan.

Causa raíz: Latencia de almacenamiento e iowait, a menudo por picos de logs, thrash de swap o discos sobrecargados.

Solución: Identifica procesos con I/O alto, comprueba salud de dispositivos, separa cargas y ajusta logging.

cr0x@server:~$ iostat -x 1 3
Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              5.0  90.0   80.0  7200.0  28.50   1.10  99.0

Decisión: Si %util se acerca al 100% y await sube, estás limitado por almacenamiento. Añade IOPS, reduce escrituras o rediseña el layout.

6) “Se nos acabó el espacio pero df dice que hay”

Síntomas: Fallan escrituras, pero df -h muestra espacio libre.

Causa raíz: Agotamiento de inodos (raro en XFS, más plausible en ext4) o archivos borrados pero abiertos.

Solución: Revisa uso de inodos y archivos borrados pero abiertos; reinicia servicios ofensores si es necesario.

cr0x@server:~$ df -i
Filesystem            Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/rl-var    524288  81234  443054   16% /var

cr0x@server:~$ sudo lsof +L1 | head
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
rsyslogd 901 root    5w   REG  253,1  1048576     0  123 /var/log/messages (deleted)

Decisión: Si encuentras archivos grandes borrados pero abiertos, reinicia ese servicio en una ventana controlada para liberar espacio.

Listas de verificación / plan paso a paso

Checklist A: “Necesito una instalación confiable de Rocky Linux 10”

1. Confirma ajustes de firmware del hardware: UEFI habilitado, política de secure boot consistente con tu organización.
2. Arranca el instalador en el modo previsto (entrada UEFI, no legacy).
3. Elige un conjunto de paquetes mínimo salvo que se requiera GUI.
4. Configura hostname, zona horaria y plan de direccionamiento de red.
5. Esquema de almacenamiento:
   • ESP + /boot + LVM
   • Separar /var para sistemas con muchos logs/contenedores
   • Redundancia para discos de sistema (RAID1 hardware o mdraid) si el downtime importa
6. Crea un usuario administrador no root; configura claves SSH.
7. Mantén SELinux Enforcing.
8. Primer arranque: verifica release del SO, modo de arranque, layout de discos y montajes de filesystems.
9. Habilita y valida sincronización horaria.
10. Valida repos; desactiva todo lo no aprobado.
11. Parchea completamente; reinicia; confirma que el kernel en ejecución coincide con el instalado.
12. Confirma que el cortafuegos está en ejecución; abre solo servicios/puertos necesarios.

Checklist B: “Estandarizar instalaciones en una flota”

1. Escribe un layout de almacenamiento gold (nombres LVM, puntos de montaje, tamaños, tipos de filesystem).
2. Define política de repos: cuáles repos, si se espejan y cómo fluyen las actualizaciones (dev → staging → prod).
3. Decide servicios base: chronyd activado, firewalld activado, sshd endurecido, demonios innecesarios apagados.
4. Codifica la configuración con automatización (Kickstart + gestión de configuración). Las instalaciones manuales no escalan; solo se multiplican.
5. Crea verificaciones de validación: modo de arranque, SELinux, sincronización horaria, puertos abiertos, umbrales de uso de disco.
6. Define procedimiento de emergencia: acceso por consola, procedimiento de arranque de rescate y cómo recuperar entradas EFI.

Checklist C: “Antes de desplegar una app”

1. Espacio: verifica cabeza de espacio para / y /var; establece políticas de retención.
2. Identidad: verifica hostname, DNS y sincronización horaria.
3. Seguridad: SELinux Enforcing; claves SSH; política de firewall presente.
4. Actualizaciones: parcheado, reiniciado y estable.
5. Observabilidad: confirma persistencia del journal si se necesita y que el reenvío de logs esté operativo.

Preguntas frecuentes

1) ¿Es Rocky Linux 10 “lo mismo que RHEL”?

Es compatible con RHEL en las cosas que importan para la mayoría de cargas: ecosistema de paquetes, comportamiento y valores empresariales.
No es el mismo producto y no viene con el mismo contrato de soporte del proveedor por defecto.

2) ¿Debo instalar una GUI en servidores?

No, salvo que tengas una razón operativa fuerte. Los servidores sin interfaz son más fáciles de parchear, menor superficie de ataque,
menos dependencias, menos sorpresas. Usa herramientas de gestión remota y UI web donde proceda.

3) ¿XFS o ext4 para Rocky Linux 10?

XFS es una buena opción por defecto para uso general en servidores y escala bien. ext4 también es fiable. Estandariza en uno salvo que una carga requiera algo específico.
La mayor ganancia es la disciplina en particionado, no la religión del filesystem.

4) ¿Necesito swap?

Usualmente sí, pero dimensiona según la carga. El swap no es una característica de rendimiento; es una red de seguridad.
En sistemas con memoria justa puede prevenir un crash inmediato mientras diagnosticas. En cargas sensibles a latencia, puedes limitarlo y confiar en un dimensionamiento de memoria correcto.
No asignes ciegamente “2x RAM” en 2026.

5) ¿Debo desactivar SELinux si causa problemas?

No. Arregla la política o el etiquetado. Desactivar SELinux cambia una conveniencia a corto plazo por fragilidad y riesgo a largo plazo.
Si absolutamentе necesitas ponerlo en permissive para depurar, documéntalo y crea un ticket con seguimiento real.

6) ¿Cómo mantener consistencia de instalaciones entre entornos?

Usa Kickstart para la instalación del SO y gestión de configuración para el estado (usuarios, SSH, sysctl, servicios, config de la app).
Luego valida con chequeos automatizados. Los humanos son geniales en juicios y malos en precisión repetitiva.

7) ¿Cuál es el layout de disco correcto para hosts de contenedores?

Separa /var (y a veces /var/lib dependiendo del runtime) para que imágenes, capas y logs no llenen root.
Planifica la amplificación de escritura. Monitoriza IOPS, no solo capacidad. Si puedes poner el almacenamiento de contenedores en discos separados, hazlo.

8) ¿Cómo sé si estoy limitado por CPU o por almacenamiento?

Revisa vmstat para iowait y cola de ejecución, luego mira iostat -x para saturación de dispositivos.
Alto uso de CPU con iowait bajo sugiere bound por CPU; iowait alto y %util de disco alto sugiere bound por almacenamiento.

9) ¿Puedo unir Rocky Linux 10 a un directorio corporativo?

Sí. Aplican los prerrequisitos habituales: DNS correcto, sincronización horaria correcta y un hostname consistente.
Las uniones a directorio fallan más por relojes y DNS que por el SO.

10) ¿Qué es lo primero que automatizo después de instalar?

Validación de la línea base y flujo de parcheo. Si automatizas solo una cosa, automatiza la parte que previene la deriva de configuración:
repos, actualizaciones, estado SELinux, reglas de firewall, sincronización horaria y política de logs.

Conclusión: próximos pasos prácticos

Rocky Linux 10 te da la forma operativa compatible con RHEL en la que muchas organizaciones confían, sin atarte el proceso básico
de parcheo de una flota a un flujo de suscripción. Ese es el valor. El riesgo es pensar que la instalación está “terminada” cuando el instalador lo dice.

Próximos pasos que rinden inmediatamente:

1. Estandariza modo de arranque y layout de disco (UEFI + GPT, separar /var para hosts ruidosos, LVM casi en todas partes).
2. Bloquea repos y convierte las actualizaciones en una canalización predecible (canary → despliegue por fases).
3. Mantén SELinux Enforcing y aprende a leer las denegaciones en lugar de rendirte.
4. Valida tras cada instalación usando las tareas prácticas arriba; conviértelas en chequeos automatizados.
5. Adopta el manual de diagnóstico rápido para que tu equipo deje de adivinar y empiece a aislar cuellos de botella con rapidez.

Si haces esas cinco cosas, Rocky Linux 10 se convierte exactamente en lo que querías: un SO estable con forma empresarial que se diluye en el fondo
y te deja preocuparte por las partes de producción que realmente son interesantes. Como los usuarios.