Instalación RHEL 10: la lista de comprobación empresarial que desearías haber tenido antes

Hechos rápidos y contexto (por qué las instalaciones RHEL se ven así)

• Anaconda es el instalador de RHEL, y existe desde finales de los 90. Su trabajo es aburrido: ser predecible en hardware pésimo.
• Kickstart no es un lujo; es cómo las empresas convirtieron servidores “copos de nieve” en ganado mucho antes de que la nube lo pusiera de moda.
• systemd se convirtió en el valor por defecto en RHEL 7. Por eso servicios, registros y diagnósticos de arranque ahora viven en un único universo scriptable.
• XFS se volvió el sistema de archivos por defecto en RHEL 7 por buenas razones: escala, madurez y rendimiento sensato con árboles de directorios grandes.
• SELinux lleva décadas en RHEL. Muchas brechas no ocurren porque SELinux sea mágico, sino porque es molesto de eludir en silencio.
• UEFI desplazó al BIOS como estándar moderno de arranque; tus fallos de arranque cada vez se parecen más a “variables EFI” y “estado de Secure Boot”, no a brujería MBR.
• chrony reemplazó a daemons NTP más antiguos porque las redes modernas necesitan convergencia más rápida y mejor manejo de laptops/VM que suspenden o se desvían.
• LUKS2 es el formato moderno de cifrado de disco en Linux. No es solo para laptops; es para data centers donde perder discos es una pesadilla de cumplimiento.
• cgroups v2 (el modelo moderno de control de recursos en Linux) cambia cómo se comportan límites de CPU/memoria; importa si ejecutas pilas de contenedores o cuotas estrictas.

Ninguno de estos hechos es trivia. Explican por qué “simplemente pasar por el instalador” es una trampa. RHEL está diseñado para operaciones repetibles a escala.
Si no instalas como si fueras a operar, te estás ofreciendo para un futuro informe de incidentes.

Decisiones que debes tomar antes de arrancar el instalador

1) ¿Qué estás construyendo: servidor mascota, nodo de flota o sistema regulado?

Si es un nodo de flota, necesitas automatización (Kickstart), almacenamiento estandarizado y red predecible. Si es regulado, necesitas cifrado, ajustes de auditoría,
y una pista de papel. Si es una “caja utilitaria” única, está bien—solo no finjas que no se convertirá en producción.

2) Firmware y modo de arranque: ¿UEFI o legacy?

Elige UEFI a menos que tengas una razón de compatibilidad sólida para no hacerlo. Las instalaciones Legacy BIOS aún son posibles, pero el soporte del proveedor y las futuras actualizaciones
cada vez asumirán más UEFI. Además: la política de Secure Boot debe ser una decisión consciente, no una sorpresa.

3) Diseño de disco: ¿LVM, particiones simples o algo personalizado?

Para instalaciones RHEL empresariales, la elección sensata por defecto es GPT + UEFI + LVM sobre XFS, con LUKS opcional.
LVM te da flexibilidad operativa: redimensionar, añadir volúmenes, separar rutas con mucho escrito.

Evita esquemas de particionado heroicos que “optimizan el rendimiento” a mano a menos que puedas defenderlos durante un incidente.
Tu yo futuro no recordará por qué /var obtuvo 12.7 GiB.

4) Cifrado: ¿lo necesitas y puedes desbloquearlo a escala?

El cifrado de disco es fácil. El cifrado con arranque desatendido, manos remotas y una custodia de claves rota no lo es.
Si habilitas LUKS, decide el mecanismo de desbloqueo: frase local (manual), cifrado ligado a la red (cuando aplique), o un método amigable con la orquestación.

5) Identidad de red: nombres de host, DNS, NTP y plan IP

Elige nombres de host que reflejen función y entorno. Decide si usarás DHCP, IPs estáticas o reservas DHCP. Define resolutores DNS y dominios de búsqueda.
Decide fuentes NTP y si necesitas servidores de tiempo internos.

6) Estrategia de actualizaciones: “lo último”, fijado o por etapas?

En empresas reales, haces actualizaciones por etapas. No dejas que una instalación nueva descargue lo más reciente en el momento de la instalación y llames eso reproducible.
Decide: versión base de la imagen, estrategia de snapshot de repositorios, y cómo aplicas erratas de seguridad.

7) Autenticación: usuarios locales, LDAP/IdM o SSO?

Si vas a usar identidad centralizada (común), plánificalo ahora. Cambia políticas sudo, acceso SSH, expectativas de auditoría y flujo de trabajo de respuesta a incidentes.

Broma #1: Instalar RHEL sin decidir almacenamiento e identidad por adelantado es como comprar una caja fuerte y dejar la llave bajo el felpudo.

Listas de comprobación / plan paso a paso (pre, instalación, post)

Lista previa a la instalación (haz esto antes de tocar Anaconda)

• Confirma especificaciones de hardware/VM: CPU, RAM, modelo de disco, tipo de controlador y NICs. Obtén los nombres reales de dispositivo que verás en Linux.
• Confirma ajustes de firmware: UEFI activado, modo RAID vs HBA/JBOD, política de Secure Boot, extensiones de virtualización si aplica.
• Elige diseño de almacenamiento: particiones, LVM, puntos de montaje, tipos de sistema de archivos y plan de cifrado.
• Define configuración de red: VLANs, MTU, bonding/teaming, rutas estáticas, DNS y fuentes de tiempo.
• Decide repositorios post-instalación y método de actualización (y si la máquina puede alcanzarlos en tiempo de instalación).
• Prepara automatización: archivo Kickstart, o al menos una hoja de construcción escrita que puedas seguir exactamente.
• Registra la línea base: hostname previsto, IP, etiqueta serial/activo, propietario, entorno y propósito.

Lista del instalador (elecciones que penalizan después)

• Verifica que estás instalando en el modo de arranque previsto (UEFI vs legacy) antes de particionar.
• Configura la zona horaria correcta y habilita sincronización de tiempo (o al menos plánficalo para después de la instalación).
• Elige conjuntos de paquetes mínimos; añade lo que necesites de forma intencional.
• No desactives SELinux para “hacer que funcione”. Arregla la política o las etiquetas.
• Establece la política de contraseñas de root y crea un usuario admin con sudo. Prefiere SSH basado en claves.
• Asegura que los discos objetivo correctos están seleccionados. Verifica tres veces en servidores multi-disco.

Lista post-instalación (el primer arranque es donde empieza la instalación real)

• Actualiza al nivel de parches de tu línea base (por etapas, controlado).
• Endurece SSH: claves, usuarios/grupos permitidos, deshabilita autenticación por contraseña cuando sea posible.
• Confirma que SELinux está en modo enforcing; corrige etiquetas erróneas desde imágenes/scripts personalizados.
• Configura zonas del firewall y aperturas de servicios explícitas.
• Configura registro persistente y envío remoto de logs si es necesario.
• Valida almacenamiento: opciones de sistema de archivos, fstab correcto, salud de LVM y expectativas del scheduler de IO.
• Valida sincronización de tiempo y resolución de nombres. Un DNS roto se hará pasar por “lentitud aleatoria”.
• Linea base de rendimiento: CPU steal (VMs), latencia de IO y rendimiento de red. Captura métricas iniciales.
• Registra en tu plano de gestión (Satellite, repos internos, config mgmt) y marca la build como inmutable.

Tareas prácticas (comandos, salidas, qué significa, qué decides)

Estas son las comprobaciones “recorre la máquina” que espero en un nuevo sistema RHEL 10 antes de confiarle algo que tenga paginador conectado.
Cada tarea incluye: comando, salida de ejemplo, qué significa y qué decisión tomas.

Task 1: Confirmar versión del SO y procedencia de la instalación

cr0x@server:~$ cat /etc/redhat-release
Red Hat Enterprise Linux release 10.0 (Plow)

Qué significa: Estás en la versión mayor/minor esperada (y no en una imagen antigua “reutilizada”).

Decisión: Si la release no es la prevista, detente. No “actualices después” como plan de recuperación para una base mal instalada.

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

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

Qué significa: El sistema arrancó en modo UEFI. Eso afecta particionado, configuración de GRUB y ciertos flujos de recuperación.

Decisión: Si esperabas UEFI pero obtuviste Legacy, reinstala ahora. Flotas mixtas hacen las operaciones frágiles.

Task 3: Inspeccionar dispositivos de bloque e identificar el disco de arranque real

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        MODEL          SIZE TYPE FSTYPE      MOUNTPOINTS
sda         PERC H755      1.8T  disk
├─sda1                    600M  part vfat        /boot/efi
├─sda2                      1G  part xfs         /boot
└─sda3                    1.8T  part LVM2_member
  ├─rhel-root               80G lvm  xfs         /
  ├─rhel-var                50G lvm  xfs         /var
  ├─rhel-tmp                 8G lvm  xfs         /tmp
  └─rhel-home               10G lvm  xfs         /home

Qué significa: Puedes ver la EFI System Partition, /boot separado y un PV LVM que aloja volúmenes lógicos.

Decisión: Valida que los puntos de montaje coinciden con la intención. Si /var no está separado en sistemas con muchos logs, considera arreglarlo pronto (migrar después es doloroso).

Task 4: Comprobar tipos de sistema de archivos y opciones (perfiles de rendimiento y seguridad)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS / /var /tmp /home
/ /dev/mapper/rhel-root xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k
/var /dev/mapper/rhel-var xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k
/tmp /dev/mapper/rhel-tmp xfs rw,nosuid,nodev,noexec,relatime,seclabel
/home /dev/mapper/rhel-home xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k

Qué significa: /tmp está endurecido (nosuid,nodev,noexec). XFS está en uso. Las etiquetas SELinux están habilitadas.

Decisión: Mantén /tmp endurecido salvo que realmente un toolchain de compilación necesite exec en /tmp—mejor arregla ese toolchain en lugar de debilitar el SO.

Task 5: Validar salud de LVM y espacio libre para crecimiento

cr0x@server:~$ vgs
  VG   #PV #LV #SN Attr   VSize  VFree
  rhel   1   4   0 wz--n-  1.79t  1.64t

Qué significa: Mucho espacio libre en el VG. Bien: puedes ampliar /var o añadir volúmenes específicos de la app sin pedir ticket al Teatro del Equipo de Almacenamiento.

Decisión: Si VFree es pequeño, dimensionaste volúmenes demasiado grandes u olvidaste el crecimiento futuro. Arréglalo ahora, antes de que existan datos.

Task 6: Confirmar estado de cifrado (LUKS) donde sea requerido

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS
sda      disk
├─sda1   part vfat        /boot/efi
├─sda2   part xfs         /boot
└─sda3   part crypto_LUKS
  └─luks-2b3c...  crypt LVM2_member
    └─rhel-root   lvm   xfs         /

Qué significa: El PV raíz está dentro de un contenedor LUKS. Eso es cifrado en reposo real, no “cerramos la puerta del datacenter”.

Decisión: Valida que tienes un proceso de desbloqueo funcional (consola local, KVM remoto o método aprobado por la empresa). Si no, has construido una futura indisponibilidad.

Task 7: Comprobar kernel, parámetros de arranque y estado de microcódigo

cr0x@server:~$ uname -r
6.12.0-xx.el10.x86_64

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-xx.el10.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto rhgb quiet

Qué significa: Estás en una línea de kernel conocida; cmdline muestra crashkernel habilitado (útil para kdump).

Decisión: Si ejecutas cargas sensibles a latencia, considera si “quiet/rhgb” pertenece en producción (yo suelo quitarlos en servidores para ver los logs de arranque).

Task 8: Confirmar enforcement de SELinux

cr0x@server:~$ getenforce
Enforcing

Qué significa: SELinux está haciendo su trabajo: enforcing, no solo registrando.

Decisión: Si está Permissive/Disabled, arréglalo antes de que lleguen las apps. Si no, tu “base de seguridad” es un memo, no un control.

Task 9: Confirmar estado del firewall y qué está realmente expuesto

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

cr0x@server:~$ sudo firewall-cmd --get-active-zones
public
  interfaces: ens192

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

Qué significa: Firewalld está activo; solo el servicio SSH está permitido en la zona public.

Decisión: No abras puertos “temporalmente” y lo olvides. Si un servicio es necesario, defínelo explícitamente por zona y guárdalo en la automatización.

Task 10: Validar DNS y comportamiento del resolvedor (fallos rápidos vencen misterios lentos)

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

Qué significa: systemd-resolved está gestionando DNS; tienes dos resolutores; hay un dominio de búsqueda establecido.

Decisión: Si se requiere DNSSEC o DNS dividido, plánficalo ahora. Si los resolutores no son alcanzables, arréglalo antes de culpar “a la red”.

Task 11: Validar sincronización de tiempo (la autenticación y sistemas distribuidos dependen de ella)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A140035 (10.20.0.53)
Stratum         : 3
Ref time (UTC)  : Mon Feb 05 12:10:28 2026
System time     : 0.000123456 seconds fast of NTP time
Last offset     : -0.000045678 seconds
RMS offset      : 0.000210000 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Qué significa: Chrony está sincronizado, pequeño offset, estrato estable. Esto evita fallos TLS, rarezas de Kerberos y dolores de correlación de logs.

Decisión: Si Leap status no es Normal o los offsets son grandes, arregla la accesibilidad NTP o reglas de firewall. No “ignore el desvío de tiempo”.

Task 12: Confirmar persistencia de journald (registros que sobreviven reinicios)

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

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 312.0M in the file system.

Qué significa: Los logs persisten tras el reinicio y tienen un tope. Has elegido conservar evidencia sin permitir que los logs devoren el filesystem raíz.

Decisión: Si Storage es volatile, cámbialo. Si SystemMaxUse es ilimitado, pon un tope y envía logs fuera del host si necesitas retención.

Task 13: Comprobar recursos básicos del sistema (presión de memoria, sanity del swap)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.2Gi        28Gi       120Mi       1.8Gi        29Gi
Swap:          8.0Gi          0B       8.0Gi

Qué significa: Mucho margen; swap existe y no está en uso aún.

Decisión: Para muchas cargas de servidor, algo de swap sigue siendo valioso como red de seguridad. Evita políticas “swapoff en todas partes” a menos que entiendas el modo de fallo.

Task 14: Validar stack de IO y detectar latencia obvia antes de que lleguen las apps

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-xx.el10.x86_64 (server)  02/05/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          1.20    0.00    0.55    0.10    0.00   98.15

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
dm-0             0.20    1.50     8.0    64.0      64.0     0.01    2.10    1.90    2.13   0.25   0.04

Qué significa: Await bajo y baja utilización; el disco no es actualmente el cuello de botella.

Decisión: Si await se dispara a decenas/centenas de ms con carga ligera, detente e investiga el controlador de almacenamiento, multipath o el rendimiento del SAN subyacente.

Task 15: Confirmar canales de actualización y qué se parcheará realmente

cr0x@server:~$ sudo dnf repolist
repo id                              repo name
rhel-10-baseos                       RHEL 10 BaseOS (Staged)
rhel-10-appstream                    RHEL 10 AppStream (Staged)
rhel-10-extras                       RHEL 10 Extras (Staged)

Qué significa: Los repos están configurados y probablemente apuntan a tu espejo/snapshot por etapas.

Decisión: Si los repos apuntan a fuentes aleatorias o faltan, arréglalo ahora. El comportamiento de actualización es parte de tu postura de seguridad.

Task 16: Confirmar kdump configurado (no te importará hasta que realmente te importe)

cr0x@server:~$ systemctl is-enabled kdump
enabled

cr0x@server:~$ sudo kdumpctl status
Kdump is operational

Qué significa: Si el kernel hace panic, puedes capturar un volcado de crash para diagnóstico real.

Decisión: En sistemas críticos, mantiene kdump. En VMs pequeñas, puedes optar por deshabilitarlo para recuperar RAM—documenta esa elección.

Almacenamiento y sistemas de archivos: diseños que sobreviven al mundo real

El diseño por defecto en el que confío (y por qué)

En servidores empresariales de propósito general, me gusta:
/ (root) dimensionado para OS y herramientas, /var separado para logs y estado mutable,
/tmp separado y endurecido, y volúmenes dedicados opcionales para bases de datos o sistemas de colas.
Usa XFS a menos que tengas una razón específica y validada para no hacerlo.

El objetivo operativo no es la elegancia. Es controlar el radio de impacto. Cuando una app se descontrola y escribe logs infinitos, /var se llena—no /.
Cuando un proceso de build abusa de /tmp, no puede crear por accidente un área de staging ejecutable.

Particionado y LVM: elige flexibilidad sobre profecía

La gente sobre-particiona porque quiere prevenir incidentes de disco lleno. Eso es noble, y suele causar incidentes de disco lleno.
El enfoque correcto es separar puntos de montaje de alto riesgo más espacio libre en LVM para crecimiento controlado.

Dicho de otro modo: no puedes predecir qué directorio crecerá. Puedes predecir cuáles hacen daño cuando lo hacen.

Particiones de arranque UEFI: mantenlas aburridas

Para UEFI: necesitas una EFI System Partition (vfat) montada en /boot/efi. Manténla de tamaño estándar (cientos de MB).
Mantén /boot separado (XFS está bien) si usas LUKS para root—porque el arranque de root cifrado necesita claridad.

Cifrado: hazlo real, hazlo operable

Cifrar datos en reposo suele ser un requisito de política. La trampa es construir un sistema que no pueda reiniciarse desatendido tras mantenimiento de energía,
porque alguien dejó la frase de desbloqueo en una hoja de cálculo y luego la rotó.

Si usas LUKS, decide:

• Dónde viven las claves y quién puede recuperarlas durante un incidente.
• Qué ocurre cuando el host se mueve, reemplaza o restaura desde backup.
• Si existe acceso a consola remota durante el arranque (para desbloqueo manual).

Swap: aburrido, pasado de moda, aún útil

Swap no es una característica de rendimiento. Es una moldeadora de modos de fallo. Una pequeña cantidad de swap puede mantener un sistema con vida el tiempo suficiente para avisarte,
enviar logs y recuperarse con gracia en lugar de que procesos se maten de forma aleatoria.

Opciones de montaje: seguridad y comportamiento, no folclore

Usa nodev,nosuid,noexec donde tenga sentido (p. ej., /tmp). Usa noatime solo si entiendes los efectos secundarios;
relatime suele ser suficiente y es el valor por defecto. Evita tunear basado en cargo cult de internet.

Base de seguridad: SELinux, firewall, criptografía y la realidad de SSH

SELinux: enforcing es la línea base, no la aspiración

SELinux se lleva la culpa por fallos que solo expone. Cuando una app intenta escribir en el directorio equivocado o enlazar al puerto incorrecto,
SELinux dice “no” y lo detectas temprano. Eso es una característica.

Si necesitas depurar, usa herramientas dirigidas: revisa logs de audit, confirma contextos y aplica cambios mínimos de política.
“Desactivar SELinux” es la versión sysadmin de “quitar el detector de humo porque hace ruido”.

Firewall: denegar por defecto con intención explícita

En servidores, quiero firewalld corriendo con servicios mínimos expuestos. Si necesitas abrir puertos, hazlo deliberadamente y regístralo en la automatización.
No es paranoia; es reducir tu superficie de escaneo.

SSH: claves, acceso restringido y sin usuarios misteriosos

Usa autenticación por claves para acceso admin cuando sea posible. Deshabilita login de root por SSH. Limita quién puede entrar por SSH (AllowUsers o AllowGroups).
Para break-glass, usa una ruta auditada y documéntala.

Políticas de criptografía: no pelees con la plataforma

RHEL tiene gestión de política criptográfica a nivel de sistema. Eso es bueno: mantiene ajustes TLS consistentes entre consumidores de OpenSSL.
No dejes que scripts de instalación de aplicaciones aleatorias debiliten políticas criptográficas para “hacer que un cliente viejo se conecte”.
Arregla el cliente, o aisla ese sistema legado hasta que pueda reemplazarse.

Cita (idea parafraseada) de Werner Vogels: “You build it, you run it” — la fiabilidad mejora cuando los constructores asumen las consecuencias operativas.

Registro y observabilidad: conserva la evidencia

journald persistente es no negociable para depuración en producción

Si journald es volátil, los logs desaparecen al reinicio—el momento exacto tras actualizaciones de kernel, eventos de energía o “cambiamos una cosa pequeña”.
Persiste el journal, ponle un tope en disco y envía logs importantes fuera del host si cumplimiento o respuesta a incidentes exige retención.

Aislamiento del volumen de logs: /var como barrera de seguridad

Separar /var es una práctica clásica y aburrida porque funciona. Contiene el desorden: cachés de paquetes, logs, spools y estado.
Cuando /var se llena, el SO a menudo puede seguir funcionando lo suficiente para arreglarlo. Cuando / se llena, todo se vuelve emocionante.

Linea base de métricas: toma un snapshot cuando todo está sano

El mejor momento para capturar métricas base de rendimiento es justo después de la instalación, antes de que cambie la carga.
Captura: CPU idle/steal, latencia de IO, rendimiento de red y presión de memoria. Más adelante, cuando alguien diga “está más lento”, tendrás una referencia.

Broma #2: Los logs son como los backups—todos los valoran después de darse cuenta de que no los tienen.

Redes: DNS, tiempo, MTU, bonding y “por qué va lento”

DNS: la causa raíz de la mitad de tus incidentes “intermitentes”

Resolutores mal configurados causan arranques de aplicaciones lentos, timeouts aleatorios de API y failovers confusos.
Valida resolución directa e inversa donde sea necesario. Sabe si systemd-resolved está en uso y cómo se integra con tu tooling.

Sincronización de tiempo: la dependencia silenciosa

El desvío de tiempo rompe TLS, autenticación, tracing distribuido y tu capacidad para correlacionar logs entre sistemas.
Chrony debe estar configurado y verificado. No aceptes “probablemente está bien”.

MTU y VLANs: una clásica trampa de rendimiento

Jumbo frames pueden ayudar en algunos entornos, y también pueden crear pérdida de paquetes en hoyos negros si el camino no los soporta end-to-end.
Si pones MTU 9000, valídalo en switches, hypervisors y NICs. Si no, tendrás fallos parciales y extraños.

Bonding/teaming: la redundancia requiere pruebas

No declares victoria porque ambos enlaces muestran “UP”. Prueba la conmutación por error. Desconecta un cable (o deshabilita una vNIC) y verifica que el host mantiene conectividad.
También verifica que la configuración del switch coincida con el modo de bonding.

Guión de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando un host RHEL 10 recién instalado está “lento”, no empieces por reinstalar. Empieza por aislar el dominio del cuello de botella:
CPU, memoria, disco, red o configuración/identidad. Esta secuencia encuentra el 80% de los problemas rápido.

Primero: ¿el sistema está fundamentalmente sano?

• Revisa errores de arranque: journalctl -b -p err
• Revisa carga básica: uptime, top o htop
• Revisa discos llenos: df -h, df -i

Segundo: ¿es CPU/planificación de VM?

• Busca steal de CPU (VMs): mpstat -P ALL 1 5 (steal %)
• Revisa throttling: systemd-cgtop para presión de cgroups

Tercero: ¿es latencia de IO?

• Mide: iostat -xz 1 5 (await, %util)
• Encuentra ofensores: pidstat -d 1, iotop si está disponible
• Valida multipath/SAN: multipath -ll (si se usa)

Cuarto: ¿es la red (o DNS fingiendo ser red)?

• Latencia DNS: resolvectl query your-service y revisa tiempos
• Pérdida de paquetes: ping -c 20 gateway
• Rendimiento: ss -s (salud de sockets), ip -s link (drops/errores)

Quinto: ¿es fricción por políticas/configuración?

• Denegaciones SELinux: ausearch -m avc -ts recent
• Bloqueos del firewall: firewall-cmd --list-all más logs de servicio
• Desvío de tiempo/TLS: chronyc tracking, errores de certificados en logs de apps

El truco es disciplina. No persigas cinco hipótesis a la vez. Escoge un dominio, demuestra que es culpable o inocente, y luego avanza.

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

1) Síntoma: Timeouts aleatorios hacia servicios internos

Causa raíz: Configuración incorrecta del resolutor DNS, dominio de búsqueda faltante o confusión con systemd-resolved stub.

Solución: Valida resolvectl status, asegura que los resolutores son alcanzables, establece dominio/búsqueda correctos y prueba consultas explícitamente.

2) Síntoma: Reinicio tras actualizaciones y ahora el sistema no arranca

Causa raíz: Modo de arranque incorrecto (instaló Legacy, esperaba UEFI), o la partición EFI no se creó/montó correctamente.

Solución: Confirma UEFI con /sys/firmware/efi. Si está mal, reinstala en el modo correcto. Si falta la partición EFI, repara el bootloader desde medios de rescate.

3) Síntoma: Los logs desaparecen después del reinicio

Causa raíz: journald configurado con almacenamiento volátil (por defecto en algunas builds mínimas), o /var/log no persistente en una canalización de imágenes.

Solución: Establece Storage=persistent en journald.conf, crea /var/log/journal y limita uso con SystemMaxUse.

4) Síntoma: “Disco lleno” deja fuera todo el host

Causa raíz: Filesystem raíz único; /var y / son lo mismo; tormenta de logs llena /. A veces agotamiento de inodos.

Solución: Separa /var; monitoriza df -i; limita journals; usa logrotate; envía logs fuera del host.

5) Síntoma: La aplicación no puede enlazar a un puerto o escribir en un directorio

Causa raíz: SELinux niega por contexto incorrecto o boolean faltante; o firewall bloquea conexiones entrantes.

Solución: Revisa denegaciones AVC con ausearch, corrige contextos con restorecon, ajusta booleans necesarios y abre puertos del firewall intencionalmente.

6) Síntoma: La red está “up” pero transferencias grandes se quedan o son inestables

Causa raíz: Desajuste de MTU (jumbo frames no soportados end-to-end) o mala configuración de bonding.

Solución: Valida MTU a través del camino; prueba con pings usando el bit DF; confirma que la configuración del switch coincide con el modo de bonding; prueba failover.

7) Síntoma: El rendimiento es terrible solo en VMs

Causa raíz: Steal de CPU por overcommit, contención de almacenamiento en datastores compartidos o faltan optimizaciones virtio.

Solución: Mide steal con mpstat, revisa latencia de IO con iostat, coordina con el equipo de virtualización para colocación de recursos y tiering de almacenamiento.

8) Síntoma: El host no puede autenticarse con servicios corporativos

Causa raíz: Desvío de tiempo, hostname incorrecto o expectativas de DNS inverso en entornos tipo Kerberos.

Solución: Arregla la sincronización de tiempo primero; asegura hostname/FQDN correcto; valida DNS directo/inverso; luego reintenta el enrolamiento.

Tres micro-historias corporativas (qué realmente sale mal)

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

Un equipo desplegó una nueva piscina de jump hosts basados en RHEL 10 para acceso de producción. Habían hecho “lo normal”: parchearon, endurecieron SSH, firewalld en ejecución.
El acceso parecía bien en pruebas ligeras. Luego la rotación on-call empezó a usar los hosts durante un incidente real.

Las sesiones se colgaban 20–40 segundos cuando los ingenieros ejecutaban comandos que tocaban hostnames internos. Después de eso, todo “ponía al día”.
La primera suposición fue congestión de red. La segunda fue una herramienta bastión rota. La tercera fue “DNS de RHEL 10 es raro”.

La causa raíz fue dolorosamente simple: la instalación asumió que el dominio de búsqueda corporativo sería provisto por DHCP en todas partes. En ese entorno no lo era.
Muchos hostnames eran no calificados en scripts y hábitos de shell. Así que cada lookup probaba sufijos equivocados, alcanzaba timeouts y finalmente resolvía.

La solución fue igualmente simple: configurar explícitamente dominio de búsqueda y lista de resolutores, validar con resolvectl y añadir una comprobación básica de latencia DNS al pipeline de build.
La lección no fue “DHCP es malo”. La lección fue “las suposiciones son configuración que olvidaste escribir”.

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

Un grupo de infraestructura quería builds más rápidas para runners CI en RHEL 10. Alguien propuso deshabilitar journald persistente porque “escribir en disco es lento” y
“no necesitamos logs en runners efímeros”. Se presentó como optimización de rendimiento y ahorro de almacenamiento. Se integró.

Dos semanas después, un subconjunto de runners empezó a fallar builds intermitentemente. Las fallas no eran consistentes—a veces instalaciones de paquetes fallaban,
otras veces descargas de red morían, otras pruebas hacían timeout. Lo único consistente era que reiniciar un runner “lo arreglaba” por un rato.

Resultó que había un problema real subyacente: una interacción driver/firmware de la NIC en un lote de hardware que causaba flap de enlace ocasional.
Journald habría mostrado una línea temporal clara de eventos link down/up, renovaciones DHCP y reinicios de servicios. Pero journald era volátil y las máquinas se reiniciaron
durante remediaciones automáticas. Así que la evidencia evaporó.

Volvieron a habilitar journald persistente con un tope de disco ajustado, añadieron envío remoto de logs para eventos críticos, y el tiempo de debug se desplomó de días a horas.
La “optimización” no ahorró IO significativo. Salvó la ilusión de IO mientras costaba observabilidad, que suele ser lo más caro de perder.

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

Un clúster de aplicaciones con relación a finanzas corría en RHEL con requisitos estrictos de auditoría. El estándar de build parecía casi cómicamente conservador:
/var separado, swap presente, kdump habilitado, SELinux enforcing, firewall mínimo, journald persistente con topes y un layout LVM estandarizado con mucho espacio libre en VG.
Nadie lo amaba. Todos lo toleraban.

Durante un trimestre ocupado, un componente de terceros se volvió rogue y empezó a registrar salida de debug verbosa en /var/log a alta velocidad tras un pequeño cambio de configuración.
En horas, /var llegó al 100% de uso. En muchos sistemas, eso significa fallo total del host y una noche larga.

Aquí, el host se mantuvo arriba. El filesystem root tenía espacio. SSH seguía funcionando. systemd seguía funcionando. El monitoring seguía funcionando.
El ingeniero on-call se conectó, confirmó /var lleno, rotó y truncó los logs ofensores y reinició el componente bajo una configuración corregida.

El postmortem no fue glamouroso. El estándar de build no recibió aplausos. Pero evitó una caída que habría cascado en trabajos batch perdidos e informes retrasados.
La práctica aburrida—separar /var y capar logs—hizo exactamente lo que las prácticas aburridas deben hacer: reducir el tamaño de los desastres.

Preguntas frecuentes

1) ¿Debo usar instalación GUI o mínima para servidores RHEL 10?

Mínima, a menos que tengas una razón fuerte. Menos paquetes significa menos CVEs, menos churn de parches y menos dependencias raras.
Siempre puedes añadir herramientas después; quitar una pila GUI más tarde rara vez vale la pena la limpieza.

2) ¿XFS es siempre el sistema de archivos correcto?

Para la mayoría de casos de servidor empresariales, sí. XFS escala bien y se comporta de forma predecible bajo carga. Si necesitas una característica específica (como patrones de archivos pequeños o snapshots),
justifícala con pruebas y planes de soporte operativo, no con opiniones.

3) ¿Realmente necesito un /var separado?

Si el sistema ejecutará cualquier cosa que registre, haga spool, cache o almacene estado mutable (es decir: casi todo), sí.
Separar /var es un seguro barato contra tormentas de logs y cachés desbocadas que sacan al OS.

4) ¿Debo cifrar discos raíz en servidores?

Si tienes requisitos regulatorios o de riesgo, sí. Si no, sigue siendo recomendable para sistemas con datos sensibles.
Pero hazlo solo si puedes operarlo: desbloqueo, rotación de claves y recuperación deben diseñarse, no improvisarse.

5) ¿Puedo desactivar SELinux para agilizar despliegues?

Puedes, pero no deberías. Desactivar SELinux tiende a ocultar malas configuraciones hasta después, cuando el radio de impacto es mayor.
Usa modo permissive brevemente para diagnóstico si es necesario, luego vuelve a enforcing con etiquetas/política adecuadas.

6) ¿Cuál es la base para endurecer SSH sin romper la automatización?

Usa auth por claves, deshabilita login root y restringe usuarios/grupos permitidos. Mantén una ruta break-glass, pero hazla auditable.
Si la automatización necesita acceso, usa cuentas de servicio dedicadas con reglas sudo acotadas—no claves compartidas.

7) ¿Cómo debo manejar actualizaciones en sistemas recién instalados?

Alinealas con tus repos por etapas y ventanas de parcheo. No dejes que instalaciones nuevas tiren paquetes arbitrarios desde donde sea.
Estandariza en una línea base conocida y avanza en olas controladas.

8) ¿Qué revisar primero cuando “la red está lenta”?

DNS y MTU. Valida latencia y configuración del resolutor, luego revisa drops/errores en las interfaces.
Después, mira path MTU si fallan transferencias grandes. Muchas quejas de “red lenta” son demoras en resolución de nombres.

9) ¿Necesito kdump en todos los servidores?

En sistemas críticos, sí. En VMs pequeñas con presupuesto de RAM ajustado, quizá no.
Hazlo una decisión deliberada: o lo mantienes para diagnosabilidad o lo deshabilitas y aceptas menor visibilidad de crashes.

Próximos pasos que puedes hacer hoy

Si quieres que tus instalaciones RHEL 10 dejen de ser artefactos de “funciona en mi máquina” y empiecen a ser activos de producción, haz tres cosas:
estandariza decisiones, automatiza la construcción y valida con una comprobación de salud repetible.

1. Escribe tu línea base: modo de arranque, diseño de almacenamiento, postura de cifrado, DNS/NTP, postura SELinux/firewall y estrategia de actualizaciones.
2. Conviértelo en automatización: Kickstart más gestión post-instalación. Si no puedes reconstruirlo, no lo posees.
3. Ejecuta la sección de tareas como checklist de gating: trata los fallos como tests fallidos, no como “lo arreglaremos tras el go-live”.
4. Añade el guión de diagnóstico rápido a los docs on-call: el mejor momento para enseñar debugging es antes del incidente, no durante.

Producción no es donde demuestras que tus clics al instalador funcionan. Es donde demuestras que tus valores por defecto son buenos. Hazlos bien.