Instalación de Oracle Linux 9: Ksplice, UEK y una línea base limpia para servidores

El modelo mental: OL9, UEK, RHCK y Ksplice

Oracle Linux 9 es una distribución compatible con RHEL con dos líneas de kernel que puedes ejecutar:

• RHCK (Red Hat Compatible Kernel): sigue de cerca las expectativas ABI del kernel de RHEL.
• UEK (Unbreakable Enterprise Kernel): el kernel de Oracle, generalmente más reciente, con características y mejoras de rendimiento orientadas a cargas empresariales.

Ninguna de las dos es “siempre correcta”. UEK suele ser una buena elección por defecto para despliegues OL, especialmente donde Oracle lo espera (bases de datos, I/O intensivo de almacenamiento/red, ciertos controladores). RHCK puede ser la opción conservadora cuando necesitas compatibilidad máxima con módulos de kernel de terceros validados para la línea de RHEL, o cuando las herramientas de cumplimiento de tu organización asumen versiones del kernel de RHEL.

Ksplice es parcheo en vivo: aplicar ciertos parches de kernel sin reiniciar. En el mundo real, no elimina la necesidad de reinicios para siempre. Cambia el calendario de reinicios de “cada vez que hay una CVE del kernel” a “cuando lo planees”. Eso marca una gran diferencia si alguna vez intentaste coordinar reinicios en clústeres con estado, middleware delicado o la paciencia de ejecutivos.

Una cita que vale la pena colgar sobre tu rack: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. No es una cita SRE, pero da en el clavo para la planificación operativa.

Aquí está la actitud base: elige la línea de kernel con intención, verifica que arrancaste lo que crees que arrancaste, haz que las actualizaciones sean predecibles y mantén la deriva baja. Tus incidentes futuros seguirán ocurriendo, pero serán sobre bugs reales, no sobre ambigüedad auto infligida.

Broma #1: Si no estandarizas tu línea base, cada servidor se convierte en un copo de nieve único. Y los copos de nieve se derriten bajo presión.

Datos y contexto interesantes (porque la historia se filtra en tu incidente)

• Oracle Linux comenzó como una reconstrucción de las fuentes de RHEL; el ADN “compatible pero con opciones” explica por qué RHCK existe junto a UEK.
• Ksplice fue originalmente una startup (finales de los 2000) centrada en actualizaciones de kernel sin reinicio; Oracle la adquirió y la integró en su oferta empresarial.
• UEK se ha movido con frecuencia más rápido que la corriente del kernel de RHEL, lo cual puede importar para habilitación de hardware en plataformas más nuevas.
• La estabilidad ABI estilo RHEL es un objetivo de diseño; los proveedores de terceros con frecuencia prueban contra esa expectativa, por eso RHCK sigue siendo relevante.
• El parcheo en vivo no cubre “todos los parches”: algunos cambios de kernel son demasiado invasivos; aún necesitas ventanas de mantenimiento para ciertas clases de actualizaciones.
• Realidades de Secure Boot: puede estar habilitado y aún no protegerte si tu proceso operativo permite módulos sin firmar o controles débiles de la cadena de arranque.
• La modularidad de DNF y la proliferación de repos se convirtieron en un problema práctico de operaciones en la era RHEL 8+; la higiene de repos ahora forma parte de la “instalación”.
• El dominio de systemd (desde mediados de los 2010 en la mayoría de distros) significa que el comportamiento de servicios, los logs de arranque y las fallas de dependencias son mayormente un problema de systemd ahora, no de “scripts init”.

Una línea base de servidor limpia que resiste operaciones reales

Objetivos de la línea base (los que importan a las 3 a.m.)

• Estado de arranque determinista: siempre sabes qué kernel estás ejecutando y por qué.
• Actualizaciones predecibles: las correcciones de seguridad fluyen; los cambios rompientes no se infiltran sin aviso.
• Baja deriva: los hosts se parecen lo suficiente como para que un runbook funcione.
• Observable: logs, sincronización de tiempo y señales de recursos son fiables.
• Recuperable: puedes revertir o al menos detener el hundimiento cuando algo huele mal.

Componentes de la línea base

Para la mayoría de entornos, quiero que esto se configure temprano:

• UEK o RHCK elegido intencionalmente, con el otro eliminado o al menos no por defecto.
• Ksplice habilitado y monitorizado si tienes la suscripción/entitlement y la necesidad operativa.
• Política de repos: solo repos necesarios habilitados; nada de repos “testing” en producción.
• Actualizaciones de seguridad automáticas (o al menos notificaciones automáticas), con una ventana de mantenimiento con responsable humano para reinicios.
• Sincronización de tiempo vía chrony; la deriva de tiempo arruina las líneas de tiempo de incidentes y la autenticación.
• Política de firewall que coincida con la exposición real de servicios, no “abrir y rezar”.
• SELinux en modo enforcing a menos que puedas defender la excepción con evidencia.
• Crash kernel (kdump) habilitado para sistemas donde fallos de kernel serían costosos de rastrear.
• Comprobaciones de sanidad de almacenamiento: scheduler correcto, opciones de montaje correctas, nada de “pareció más rápido” sin medición.

Opinión: si no estás listo para ejecutar SELinux en modo enforcing, no estás listo para servicios expuestos a internet. “Solo interno” no es un campo de fuerza; es un rumor.

Tareas prácticas: comandos, señales esperadas y decisiones

Estas son comprobaciones reales que puedes pegar en un terminal. Cada tarea incluye lo que significa la salida y qué decisión debes tomar en función de ella. Hazlas en orden en una instalación OL9 fresca y luego incorpora los resultados en la automatización.

Tarea 1: Confirmar la versión del SO y la identidad de la línea base

cr0x@server:~$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="9.4"
ID="ol"
ID_LIKE="fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Oracle Linux Server 9.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:9:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 9"
ORACLE_BUGZILLA_PRODUCT_VERSION=9.4

Significado: Confirma que realmente estás en Oracle Linux 9.x, no en una plantilla parecida. PLATFORM_ID y CPE_NAME muestran la familia EL9.

Decisión: Registra la versión en CMDB/inventario de activos; alinea los destinos de repos y la política de parches con la misma línea menor en la flota cuando sea posible.

Tarea 2: Comprobar qué kernel estás ejecutando actualmente

cr0x@server:~$ uname -r
5.15.0-201.135.6.el9uek.x86_64

Significado: el9uek en la cadena de release indica UEK. Si ves .el9.x86_64 sin uek, ese es RHCK.

Decisión: Si esto no coincide con tu estándar, detente y arréglalo ahora. El plan de “lo limpiaremos después” es cómo deriva una flota.

Tarea 3: Confirmar qué kernel está establecido por defecto para el próximo arranque

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.135.6.el9uek.x86_64

Significado: Esto es lo que GRUB arrancará por defecto, no lo que estés ejecutando hoy.

Decisión: Si el kernel por defecto difiere de uname -r, estás a un reinicio de una sorpresa. Alinearlos.

Tarea 4: Listar kernels instalados (detectar instalaciones de doble línea)

cr0x@server:~$ rpm -qa | egrep '^kernel|^kernel-uek' | sort
kernel-5.14.0-427.13.1.el9_4.x86_64
kernel-core-5.14.0-427.13.1.el9_4.x86_64
kernel-modules-5.14.0-427.13.1.el9_4.x86_64
kernel-uek-5.15.0-201.135.6.el9uek.x86_64
kernel-uek-core-5.15.0-201.135.6.el9uek.x86_64
kernel-uek-modules-5.15.0-201.135.6.el9uek.x86_64

Significado: Tienes instalado tanto RHCK como UEK. Esto es común después de migraciones o instalaciones “por si acaso”.

Decisión: Elige una línea como estándar. Si mantienes ambas, documenta por qué y asegúrate de que el kernel por defecto sea explícito. Si no, elimina la línea no usada para reducir confusión.

Tarea 5: Verificar repositorios habilitados (higiene de repos)

cr0x@server:~$ sudo dnf repolist --enabled
repo id                                   repo name
ol9_baseos_latest                         Oracle Linux 9 BaseOS Latest (x86_64)
ol9_appstream                             Oracle Linux 9 Application Stream (x86_64)
ol9_uek_latest                            Latest Unbreakable Enterprise Kernel Release 7 for Oracle Linux 9 (x86_64)
ol9_ksplice                               Ksplice for Oracle Linux 9 (x86_64)

Significado: Estas son las fuentes de la verdad para paquetes y kernels. Repos extra son cómo accidentalmente importas rarezas.

Decisión: Deshabilita cualquier cosa que no puedas explicar. Si no tienes entitlement para Ksplice, no dejes el repo medio configurado.

Tarea 6: Comprobar postura de actualizaciones de paquetes (qué está pendiente)

cr0x@server:~$ sudo dnf -q check-update
kernel-uek.x86_64                  5.15.0-201.138.1.el9uek        ol9_uek_latest
openssl-libs.x86_64                1:3.0.7-29.el9_4               ol9_baseos_latest

Significado: Las actualizaciones pendientes incluyen un kernel y librerías de usuario. Esto es normal.

Decisión: Decide si aplicas inmediatamente (build nuevo) o lo escalonas. Si Ksplice está habilitado, la actualización del kernel se convierte en una decisión de “parchear en vivo primero, reiniciar después”.

Tarea 7: Confirmar estado de Secure Boot (no adivines)

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

Significado: Secure Boot está activado a nivel de firmware. Si está desactivado, puede que aún estés bien—pero es una decisión de política, no un encogimiento de hombros por defecto.

Decisión: Si tu postura de cumplimiento espera Secure Boot, arréglalo temprano. Activarlo más tarde puede romper flujos de trabajo con controladores no firmados.

Tarea 8: Comprobar modo SELinux (realidad de la línea base de seguridad)

cr0x@server:~$ getenforce
Enforcing

Significado: SELinux está activo y aplicando políticas. Permissive es “modo auditoría”; disabled es “me gusta vivir peligroso”.

Decisión: Mantén enforcing a menos que tengas una incompatibilidad conocida. Si algo falla, escribe una política local o ajusta contextos; no lo apagues sin más.

Tarea 9: Validar sincronización de tiempo (las líneas de tiempo de incidentes dependen de esto)

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

Significado: El reloj está sincronizado, NTP está activo y usas UTC (bien). Si synchronized: no, tus logs te harán quedar mal.

Decisión: Si no está sincronizado, repara chrony antes de hacer cualquier otra cosa. Depurar con tiempo incorrecto es autolesión.

Tarea 10: Confirmar identidad de red y DNS (básico, pero rompe todo)

cr0x@server:~$ hostnamectl
 Static hostname: ol9-db-01
       Icon name: computer-server
         Chassis: server
      Machine ID: 2f9b2c9d0d6a4d4a8c1d3b0d3b2c4a11
         Boot ID: 8a42f5d7e7f747a0a5f01d72bbf05d61
Operating System: Oracle Linux Server 9.4
          Kernel: Linux 5.15.0-201.135.6.el9uek.x86_64
    Architecture: x86-64

Significado: El nombre del host está configurado; el kernel mostrado coincide con tu expectativa. Nombres de host descoordinados causan colisiones de monitoreo y dolor con certificados.

Decisión: Estandariza patrones de hostname; asegura que DNS forward/reverse sea correcto para todo lo que vaya a usar TLS o sistemas tipo Kerberos.

Tarea 11: Ver qué está escuchando (detectar exposición accidental)

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

Significado: Solo SSH está abierto al mundo; chrony es local. Si ves servicios aleatorios en 0.0.0.0, tu “instalación mínima” no fue tal.

Decisión: Si un servicio escucha y no lo pediste, desactívalo. Servicios abiertos por defecto son una decisión de carrera limitante.

Tarea 12: Estado del firewall y reglas reales

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

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

Significado: El firewall está en ejecución y solo SSH está permitido en la zona pública.

Decisión: Mantén esto cerrado. Abre puertos como parte del despliegue de la aplicación, no como parte de la “instalación del servidor”.

Tarea 13: Comprobar diseño de almacenamiento y opciones de montaje (evitar errores accidentales)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
NAME        TYPE   SIZE FSTYPE MOUNTPOINTS
sda         disk   200G
├─sda1      part   600M vfat   /boot/efi
├─sda2      part     1G xfs    /boot
└─sda3      part 198.4G LVM2_member
  ├─ol-root lvm     80G xfs    /
  ├─ol-var  lvm     60G xfs    /var
  └─ol-home lvm   58.4G xfs    /home

Significado: Separar /var suele ser una ventaja para logs, caches de paquetes y bases de datos que requieren espacio. LVM te da opciones de redimensionamiento cuando la realidad aparece.

Decisión: Para servidores que ejecutan servicios con estado, divide /var (y a menudo /var/log) deliberadamente. Si dejas todo en /, documenta tu plan de crecimiento.

Tarea 14: Comprobar scheduler de I/O y ajustes de cola (no optimices a ciegas)

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

Significado: El scheduler actual es mq-deadline. En discos SSD modernos virtualizados esto suele estar bien; en ciertos arrays, none también puede ser apropiado.

Decisión: No cambies schedulers porque un blog te lo dijo. Cámbialo solo con una prueba de carga medida y un plan de reversión.

Tarea 15: Confirmar swap y postura de presión de memoria

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       2.1Gi        26Gi       128Mi       3.0Gi        28Gi
Swap:          4.0Gi          0B       4.0Gi

Significado: Hay swap y no está siendo usado; bien. No tener swap no es “optimización de rendimiento”, es jugar con el OOM killer.

Decisión: Mantén swap para la mayoría de servidores de propósito general; hazlo de tamaño sensato. Para sistemas de bases de datos especializados, decide deliberadamente y prueba modos de fallo.

Tarea 16: Auditar errores de arranque rápidamente (no esperes al ticket)

cr0x@server:~$ sudo journalctl -b -p warning --no-pager | tail -n 20
Feb 05 10:01:18 ol9-db-01 kernel: ACPI: \_SB_.PLTF.C000: Failed to evaluate _DSM (0x1001)
Feb 05 10:01:20 ol9-db-01 systemd[1]: Failed to start Crash recovery kernel arming.
Feb 05 10:01:20 ol9-db-01 systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE

Significado: El arranque tiene advertencias; kdump falló. Eso no es necesariamente fatal, pero es una desviación de la línea base.

Decisión: Arregla kdump si necesitas volcados de kernel; de lo contrario desactívalo intencionalmente para que no genere ruido que oculte fallos reales de arranque.

Ksplice en OL9: lo que realmente necesitas

Ksplice es palanca operativa. Pero solo si lo tratas como un sistema, no como una casilla para marcar.

Para qué sirve Ksplice

• Reducir la cantidad de reinicios de emergencia por CVE del kernel.
• Comprar tiempo para coordinar ventanas de mantenimiento.
• Mantener servicios sensibles a la disponibilidad estables mientras sigues parchando.

Para qué no es Ksplice

• Una garantía de que nunca volverás a reiniciar.
• Un reemplazo para actualizar librerías de usuario (OpenSSL, glibc, etc.).
• Una varita mágica para kernels rotos, controladores malos o problemas de firmware.

Comprobaciones centrales para estar listo con Ksplice

Tarea 17: Verificar que la herramienta ksplice esté instalada

cr0x@server:~$ rpm -q ksplice-uptrack
ksplice-uptrack-1.0.2-14.el9.x86_64

Significado: El paquete existe. Si no está instalado, no estás parcheando en vivo nada.

Decisión: Si piensas usar Ksplice, instala la herramienta como parte de la imagen base; no dependas de pasos manuales post-instalación.

Tarea 18: Comprobar estado del servicio ksplice

cr0x@server:~$ sudo systemctl status uptrack.service --no-pager
● uptrack.service - Ksplice Uptrack service
     Loaded: loaded (/usr/lib/systemd/system/uptrack.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-02-05 10:05:12 UTC; 6min ago
   Main PID: 1523 (uptrack)
     Tasks: 3
     Memory: 12.4M
        CPU: 0.220s
     CGroup: /system.slice/uptrack.service
             └─1523 /usr/sbin/uptrack -d

Significado: El servicio está en ejecución. Nota el estado “enabled”; quieres que sea persistente tras reinicios.

Decisión: Si está inactivo, verifica entitlements y configuración. Si no quieres Ksplice, desactívalo y elimínalo—agentes medio configurados crean falsa confianza.

Tarea 19: Listar actualizaciones Ksplice aplicadas y disponibles

cr0x@server:~$ sudo uptrack-show --available
Effective kernel version is 5.15.0-201.135.6.el9uek.x86_64
Updates available:
[0t9s] CVE-2025-12345: Fix for kernel issue in netfilter
[1a2b] CVE-2025-23456: Fix for kernel issue in io_uring

Significado: Ksplice ve tu kernel efectivo y tiene parches en vivo disponibles.

Decisión: Si no hay nada disponible, eso puede estar bien. Si existen actualizaciones y estás en una ventana de parcheo, aplícalas. Si Ksplice no puede determinar el kernel efectivo, probablemente tengas una desalineación de kernel o un estado no soportado.

Tarea 20: Aplicar actualizaciones Ksplice (cuando la política lo permita)

cr0x@server:~$ sudo uptrack-upgrade -y
Installing [0t9s]... ok
Installing [1a2b]... ok
Your kernel is fully up to date.

Significado: Parches en vivo aplicados con éxito.

Decisión: Registra el evento de parcheo (ticket/CMDB). Si los parches fallan, no sigas reintentando a ciegas—captura logs y considera una actualización normal de kernel + reinicio.

Tarea 21: Confirmar el estado de requerimiento de reinicio (Ksplice no cancela la física)

cr0x@server:~$ sudo dnf -q needs-restarting -r || true
No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Significado: Desde la vista del gestor de paquetes, no necesitas reinicio por cambios de userland. Esto no significa que nunca reinicies, pero reduce la urgencia.

Decisión: Usa esto para justificar posponer reinicios a ventanas programadas, no para evitarlos eternamente. Aún quieres reinicios periódicos para firmware/controladores, actualizaciones de kernel más allá de parches en vivo y la higiene general.

Selección de UEK e higiene de arranque

Los errores en la línea de kernel son costosos porque aparecen tarde: un controlador se comporta distinto, el rendimiento cambia, o un módulo de terceros se niega a cargarse tras un reinicio.

Elige un estándar: UEK por defecto, salvo que tengas una razón de compatibilidad

Mi defecto en ambientes Oracle Linux es UEK para cargas de servidor típicas salvo que:

• Dependas de un módulo de kernel de terceros certificado solo para la línea de kernel de RHEL.
• Tengas un requisito regulatorio o de proveedor que haga referencia explícita al stream de kernel compatible de RHEL.
• Quieres minimizar diferencias entre flotas OL y RHEL.

Tarea 22: Instalar paquetes de kernel UEK (si aún no están presentes)

cr0x@server:~$ sudo dnf install -y kernel-uek
Last metadata expiration check: 0:18:10 ago on Tue 05 Feb 2026 09:54:21 AM UTC.
Dependencies resolved.
====================================================================
 Package                Arch       Version                         Repo            Size
====================================================================
Installing:
 kernel-uek              x86_64     5.15.0-201.138.1.el9uek         ol9_uek_latest  17 M

Transaction Summary
====================================================================
Install  1 Package

Complete!

Significado: Kernel UEK instalado. Aún debes asegurarte de que sea la entrada por defecto de arranque.

Decisión: Si es un sistema de producción, programa un reinicio para validar que el nuevo kernel arranca correctamente antes de marcar la build como “golden”.

Tarea 23: Establecer el kernel por defecto explícitamente

cr0x@server:~$ sudo grubby --set-default /boot/vmlinuz-5.15.0-201.138.1.el9uek.x86_64

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.138.1.el9uek.x86_64

Significado: El próximo arranque irá a la imagen UEK deseada.

Decisión: Fíjalo. No confíes en el comportamiento “gana el más reciente” de GRUB cuando hay múltiples familias de kernel instaladas.

Tarea 24: Eliminar la familia de kernel no usada (opcional, pero reduce confusión)

cr0x@server:~$ sudo dnf remove -y 'kernel*5.14.0*' 'kernel-core*5.14.0*' 'kernel-modules*5.14.0*'
Dependencies resolved.
====================================================================
 Package                Arch   Version                    Repository    Size
====================================================================
Removing:
 kernel                  x86_64 5.14.0-427.13.1.el9_4      @System      0
 kernel-core             x86_64 5.14.0-427.13.1.el9_4      @System     25 M
 kernel-modules          x86_64 5.14.0-427.13.1.el9_4      @System     34 M

Transaction Summary
====================================================================
Remove  3 Packages

Complete!

Significado: Se eliminaron paquetes RHCK (en este ejemplo). Aún tienes UEK instalado.

Decisión: Si este host debe soportar ambas (raro), mantenlas pero documenta la razón y asegura que el kernel por defecto se gestione vía gestión de configuración.

Estrategia de actualizaciones: seguridad, estabilidad y control de cambios

Actualizar no es un comando. Es una política con herramientas asociadas.

Actualizaciones de seguridad: hazlas rutinarias

Si no puedes automatizar actualizaciones de seguridad, al menos automatiza la visibilidad. Los humanos son programadores poco fiables.

Tarea 25: Ver avisos de seguridad para actualizaciones pendientes

cr0x@server:~$ sudo dnf updateinfo list --security
OLSA-2026-0001 Important/Sec.  openssl-libs-1:3.0.7-29.el9_4.x86_64
OLSA-2026-0002 Moderate/Sec.   curl-7.76.1-29.el9_4.x86_64

Significado: Existen avisos de seguridad para paquetes específicos.

Decisión: Si estos paquetes están en tu ruta de ejecución (usualmente lo están), planifica parcharlos. Para sistemas expuestos a internet, “Important” no es opcional.

Tarea 26: Aplicar actualizaciones con una postura conservadora

cr0x@server:~$ sudo dnf upgrade -y
Dependencies resolved.
====================================================================
 Package             Arch   Version                      Repo               Size
====================================================================
Upgrading:
 openssl-libs         x86_64 1:3.0.7-29.el9_4             ol9_baseos_latest  1.5 M

Transaction Summary
====================================================================
Upgrade  1 Package

Complete!

Significado: Paquete de userland actualizado. El kernel puede permanecer pendiente según tu enfoque.

Decisión: Después de las actualizaciones, ejecuta needs-restarting para decidir si reiniciar servicios o reiniciar el sistema.

Tarea 27: Identificar servicios que necesitan reinicio por librerías actualizadas

cr0x@server:~$ sudo dnf needs-restarting || true
sshd : 1032
chronyd : 980

Significado: Estos procesos están ejecutando librerías antiguas mapeadas; deberían reiniciarse para aplicar completamente las actualizaciones.

Decisión: Reinicia servicios en orden controlado. Para SSH, ten cuidado: mantén una sesión activa abierta al reiniciar para evitar quedarte fuera.

Tarea 28: Bloquear fuentes de paquetes y evitar habilitaciones accidentales de repos

cr0x@server:~$ sudo dnf config-manager --set-disabled ol9_developer_EPEL
Error: No matching repo to modify: ol9_developer_EPEL.

Significado: El repo no está presente; bien. Si estuviera presente y habilitado, querrías desactivarlo en producción.

Decisión: Gestiona explícitamente los repos habilitados en la automatización. “No estaba habilitado en mi máquina” no es un control.

Tres microhistorias corporativas desde el terreno

Incidente causado por una suposición equivocada: “UEK está instalado, así que debemos estar ejecutándolo”

En una empresa mediana, un equipo estandarizó en Oracle Linux para una flota de servidores de aplicaciones. El documento base decía “instalar UEK” y la canalización de builds hizo exactamente eso. En algún punto de la cadena de reinicios, sin embargo, el kernel por defecto siguió siendo RHCK porque la imagen originalmente provenía de una plantilla que tenía RHCK primero en el orden de GRUB.

Durante meses nada pareció roto. El monitoreo estaba en verde. El rendimiento estaba bien. Luego, un reinicio de mantenimiento afectó a un subconjunto de nodos y de pronto una característica de una NIC de terceros se comportó de forma distinta. El síntoma fue feo: caídas de paquetes esporádicas bajo carga y retransmisiones que parecían “red” pero olían a “kernel”. El equipo persiguió puertos de switch, culpó al cableado y abrió tickets con el proveedor. El tiempo desapareció.

La solución fue vergonzosamente simple: confirma el kernel en ejecución, confirma el kernel por defecto, y luego alinéalos. La lección no fue “UEK malo” ni “RHCK malo”. Fue que instalar un paquete no es lo mismo que arrancarlo. Cualquier línea base que no verifique el estado de arranque es un cuento para dormir.

Después, añadieron dos comprobaciones a la aceptación de builds: uname -r debe coincidir con la línea prevista, y grubby --default-kernel debe coincidir con uname -r. Tomó minutos. Les ahorró días después.

Optimización que salió mal: “Deshabilitemos swap para reducir latencia”

Otra organización ejecutaba servicios de baja latencia y decidió que el swap era el enemigo. Alguien leyó un hilo de rendimiento y tomó la conclusión personalmente. El swap fue eliminado de la línea base. Los servidores se sintieron “más ágiles” en un benchmark estrecho, así que el cambio pareció justificado.

Luego vino la fuga lenta: un servicio Java con un bug de crecimiento de memoria que normalmente habría empujado algunas páginas frías al swap bajo presión. Sin swap, la presión de memoria pasó de “ligeramente degradada” a “OOM instantáneo”. El kernel empezó a matar procesos. No siempre al obvio—a veces mataba el sidecar o un agente de logging primero, lo que hizo el incidente más difícil de interpretar.

La peor parte fue el modo de fallo. No fue degradación gradual. Fue un bucle caótico de crashes que parecía un bug de aplicación (lo era) pero se comportó como inestabilidad de infraestructura (se convirtió en eso). Reintrodujeron swap con un tamaño sensato, ajustaron límites de memoria y usaron cgroups para contener a los peores. La “optimización” había reducido un tipo de latencia e incrementado mucho el tiempo medio hasta la recuperación.

Broma #2: Deshabilitar swap para “mejorar rendimiento” es como quitar la rueda de repuesto para “reducir peso”. Técnicamente cierto hasta que la carretera se pone interesante.

Práctica aburrida pero correcta que salvó el día: “Mantener /var separado y monitorizarlo”

En un entorno regulado, el equipo de seguridad exigió logging de auditoría muy verboso. El equipo de ops hizo algo profundamente poco sexy: separaron /var en su propio volumen lógico, añadieron alertas sobre espacio libre y mantuvieron la rotación de logs ajustada. Nadie aplaudió. Nadie escribió un post en un blog al respecto.

Una mañana, un proveedor de autenticación upstream tuvo fallos intermitentes. Las aplicaciones empezaron a reintentar, y las tormentas de reintentos amplificaron el volumen de logs. En muchos sistemas, ese tipo de evento llena el filesystem raíz y se obtienen fallos en cascada: el gestor de paquetes falla, servicios no pueden escribir estado, los inicios SSH fallan, y la recuperación se vuelve una aventura de manos remotas.

Aquí, la raíz se mantuvo sana. Solo se vio afectado /var, saltaron alertas temprano, y el equipo tuvo margen de maniobra: limitaron reintentos, aumentaron la rotación temporalmente y limpiaron el crecimiento. El incidente dolió, pero no se convirtió en una caída total del sistema. El mejor trabajo de ops parece que nada pasó.

Guión de diagnóstico rápido

Esta es la secuencia para “entrar en la sala en llamas”. Asume OL9, pero la mayoría de pasos son universales. El objetivo es encontrar el cuello de botella rápido: CPU, memoria, disco, red, o “el kernel no es lo que crees”.

Primero: confirma que estás en el kernel que crees

cr0x@server:~$ uname -r
5.15.0-201.135.6.el9uek.x86_64

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.135.6.el9uek.x86_64

Señal: La descoincidencia significa que estás a un reinicio de un nuevo modo de fallo. Además, algunas anomalías de rendimiento se correlacionan con diferencias de línea de kernel.

Decisión: Si está desalineado, trátalo como deriva de configuración y arréglalo antes de afinar más.

Segundo: identifica la presión de recursos en 60 segundos

cr0x@server:~$ uptime
 10:19:52 up  2:31,  2 users,  load average: 7.22, 6.91, 6.80

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
 3  0      0 26800000 120000 2100000  0    0     2     7  120  240  3  1 95  1  0
 8  2      0  900000 110000 2200000  0    0  8000 12000 1400 2200  5  3 55 37  0

Señal: Alto wa (iowait) sugiere latencia o saturación de almacenamiento. Alto r con bajo idle sugiere contención de CPU. Swap in/out sugiere presión de memoria.

Decisión: Elige la clase de cuello de botella probable y profundiza allí, no en todas partes.

Tercero: si iowait es alto, pruébalo con estadísticas por dispositivo

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-201.135.6.el9uek.x86_64 (ol9-db-01)  02/05/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.20    0.00    3.10   34.50    0.00   56.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
sda              65.0   5200.0     0.0    0.0   18.5     80.0    110.0  14500.0     2.0    1.8   35.2    131.8    5.3   92.0

Señal: Alto await, alto %util y creciente aqu-sz = el almacenamiento es el cuello de botella.

Decisión: Revisa el backend de almacenamiento, la profundidad de cola, vecinos ruidosos, el sistema de archivos y los patrones de I/O de la aplicación antes de tocar ajustes de CPU.

Cuarto: si CPU está alta, encuentra a los principales responsables y sus llamadas al sistema

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 2412 java            380  22.1
 1530 node             95   3.2
  980 chronyd           2   0.1

Señal: Un proceso dominando significa que puedes enfocarte. Muchos procesos usando un poco sugiere contención o efecto de manada.

Decisión: Para ofensores únicos, revisa el perfilado a nivel de aplicación y límites. Para manadas, revisa tormentas de conexión, bucles de reintento y contención de locks.

Quinto: si “parece red”, valida descartes y errores

cr0x@server:~$ ip -s link show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0       0       0       0

Señal: Existen descartes o errores; no es prueba de causa raíz pero sí una pista. En entornos virtualizados, los descartes pueden deberse a congestión en el host.

Decisión: Si los descartes son no nulos y están creciendo, correlaciona con la carga y revisa métricas de vSwitch/host; no reescribas inmediatamente parámetros de TCP.

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

1) “Ksplice está instalado pero nada se parchea”

Síntomas: uptrack-show muestra errores, servicio no ejecutándose o nunca aparecen actualizaciones.

Causa raíz: Falta de entitlement del repo, agente no habilitado, o ejecución de una línea/versión de kernel no soportada para el canal Ksplice configurado.

Solución: Verifica que dnf repolist --enabled incluya el repo de Ksplice, asegura systemctl enable --now uptrack.service, y confirma que uname -r coincida con la línea UEK/RHCK esperada para el soporte de Ksplice.

2) “Después del reinicio, el kernel cambió inesperadamente”

Síntomas: El sistema reinicia y ahora los controladores/rendimiento difieren; uname -r muestra una familia distinta.

Causa raíz: Entrada por defecto de GRUB no establecida; ambas familias de kernel instaladas; actualizaciones instalaron un kernel más nuevo de la otra familia.

Solución: Usa grubby --default-kernel y grubby --set-default para fijar; elimina paquetes de kernel no usados o gestiona GRUB explícitamente en la gestión de configuración.

3) “DNF trae versiones inesperadas”

Síntomas: Una actualización rutinaria trae paquetes que no esperabas; las cadenas de dependencias se ven raras.

Causa raíz: Repos extra habilitados (a menudo developer/testing), o streams modulares descoordinados entre hosts.

Solución: Impone listas blancas de repos, audita con dnf repolist --enabled, y estandariza streams modulares si los usas.

4) “Reiniciar ssh me dejó fuera”

Síntomas: Reiniciaste sshd durante el parcheo y perdiste conectividad.

Causa raíz: Mala configuración de firewall, error en la configuración de sshd, o estabas conectado a través de un bastión frágil sin alternativa.

Solución: Valida la configuración con sshd -t antes de reiniciar, mantén una segunda sesión abierta, y usa acceso por consola para cambios críticos.

5) “Alto iowait después de ‘tuning’ de almacenamiento”

Síntomas: Picos de latencia; apps lentas; iostat muestra alto await.

Causa raíz: Cambio de scheduler de I/O o ajustes de cola sin considerar el backend de almacenamiento o la virtualización; opciones de filesystem/mount desalineadas.

Solución: Revierte el tuning; vuelve al scheduler por defecto; mide con cargas representativas; coordina con el equipo de almacenamiento sobre profundidad de cola y comportamiento del array.

6) “Los logs desaparecieron o el sistema se congeló por disco lleno”

Síntomas: Servicios fallan, gestor de paquetes falla, kernel reporta errores de escritura.

Causa raíz: Filesystem raíz lleno por logs o datos de aplicación; falta de alertas sobre crecimiento.

Solución: Separa /var (y a veces /var/log), habilita rotación agresiva de logs, monitorea la utilización de filesystems y limita logs de aplicaciones que se descontrolen.

7) “Secure Boot habilitado, pero módulos del kernel no cargan”

Síntomas: Controladores/módulos no cargan tras habilitar Secure Boot; dmesg muestra problemas de firma.

Causa raíz: Módulos de terceros sin firmar y un proceso operativo que nunca gestionó el firmado/inscripción de claves MOK.

Solución: O firma los módulos correctamente y gestiona las claves MOK, o mantén Secure Boot apagado por política—no funcionen en un estado intermedio indefinido.

Listas de verificación / plan paso a paso

Imagen gold baseline (haz esto una vez, automatiza para siempre)

1. Instala OL9 minimal donde corresponda; evita grupos de paquetes extra salvo que los necesites.
2. Configura hostname, DNS y zona horaria (usa UTC salvo razón legal en contrario).
3. Elige la línea de kernel:
   • UEK para flotas Oracle Linux típicas.
   • RHCK si un proveedor lo exige o necesitas alineación estrecha con RHEL.
4. Fija el kernel por defecto con grubby; elimina la otra familia de kernel si no la necesitas.
5. Habilita solo repos requeridos; verifica con dnf repolist --enabled.
6. Activa SELinux en modo enforcing; arregla problemas de política en lugar de desactivar.
7. Configura chrony y verifica sincronización de tiempo.
8. Configura firewall: permite solo lo requerido; valida con ss y firewall-cmd.
9. Particiona con sensatez: separa /var para la mayoría de roles de servidor; asegúrate de un plan de crecimiento.
10. Decide sobre Ksplice:
    • Si lo usas, instala agente, habilita servicio y valida la aplicación de parches.
    • Si no lo usas, no finjas—elimina paquetes y deshabilita repos.
11. Aplica actualizaciones y luego decide: reiniciar servicios vs reiniciar el sistema. Usa needs-restarting.
12. Reinicia una vez durante la validación de la build para asegurar que vuelve correctamente con el kernel previsto.
13. Captura el “estado conocido bueno”: kernel, repos habilitados, módulos cargados, puertos en escucha, diseño de filesystem.

Operaciones recurrentes (ritmo semanal)

• Ejecuta visibilidad de actualizaciones de seguridad (dnf updateinfo list --security).
• Aplica actualizaciones de userland regularmente; reinicia servicios afectados deliberadamente.
• Aplica actualizaciones Ksplice cuando estén disponibles (si la política lo permite).
• Programa reinicios periódicos (mensual/trimestral) incluso con parcheo en vivo.
• Audita la deriva: familia de kernel, lista de repos, servicios del firewall, modo SELinux.

Comprobaciones de saneamiento antes de la ventana de mantenimiento (por host)

• uname -r y grubby --default-kernel coinciden.
• dnf check-update revisado; kernel y librerías críticas anotadas.
• dnf needs-restarting revisado después de actualizaciones.
• Acceso por consola verificado para sitios remotos.
• Backups/snapshots validados para sistemas con estado.

Preguntas frecuentes

1) ¿Debo usar UEK o RHCK en Oracle Linux 9?

Por defecto usa UEK para la mayoría de flotas Oracle Linux, especialmente si ejecutas cargas Oracle o quieres características de kernel más recientes. Usa RHCK cuando un proveedor de terceros certifique solo contra la línea de kernel compatible con RHEL o tu organización demande alineación estricta con el kernel de RHEL.

2) ¿Puedo instalar ambos UEK y RHCK “por si acaso”?

Puedes, pero te compras confusión. Si mantienes ambos, debes fijar el kernel por defecto y verificarlo continuamente. Si no, reiniciarás en una familia de kernel distinta y lo llamarás “aleatorio”.

3) ¿Ksplice elimina todos los reinicios?

No. Reduce la presión de reinicio urgente por muchas CVE de kernel, pero aún necesitas reinicios para ciertos cambios de kernel, actualizaciones de firmware, cambios de controladores y la higiene del ciclo de vida general.

4) ¿Por qué importa grubby --default-kernel si uname -r se ve correcto?

Porque uname -r es “lo que arrancaste”, mientras que grubby es “lo que arrancarás”. A los incidentes les encanta la brecha entre esas dos frases.

5) ¿Debo habilitar actualizaciones automáticas en servidores OL9?

Habilita actualizaciones automáticas de seguridad solo si tienes una historia de rollback probada y entiendes tus requisitos de control de cambios. Como mínimo, automatiza el reporte de avisos de seguridad y mantén ventanas de mantenimiento frecuentes.

6) ¿Cuál es el conjunto mínimo de repos que debo mantener habilitado?

Típicamente BaseOS y AppStream, más UEK si lo ejecutas, más Ksplice si tienes entitlement y lo usas. Cualquier otro debe justificarse por una necesidad de paquete específica y revisarse periódicamente.

7) ¿Es realista SELinux enforcing en producción?

Sí. La mayoría de servicios estándar funcionan bien por defecto. Cuando surjan problemas, corrige contextos o escribe políticas dirigidas. Desactivar SELinux porque un demonio personalizado se quejó es la forma más rápida de obtener incidentes “misteriosos” después.

8) ¿Qué diseño de filesystem recomiendas para un servidor de propósito general?

UEFI + /boot separado, LVM para flexibilidad, /var separado para contención de crecimiento y logs. Para logging intensivo o bases de datos, considera separar /var/log o ubicar datos en volúmenes dedicados.

9) ¿Cómo sé si debo preocuparme por Secure Boot?

Si estás en entornos regulados o te importa la integridad de la cadena de arranque, es un control robusto. Si requieres módulos de kernel de terceros, planifica el firmado de módulos y la inscripción de claves MOK primero, o Secure Boot será una sorpresa de outage.

Próximos pasos que puedes hacer esta semana

1. Elige tu estándar de kernel (UEK o RHCK) y escríbelo en un lugar que importe: canalización de builds + política.
2. Añade dos comprobaciones de aceptación a cada build de host: uname -r coincide con el estándar, y grubby --default-kernel coincide con uname -r.
3. Decide sobre Ksplice con intención. Si lo usas, monitorízalo y demuestra que parchea. Si no, elimínalo y deja de fingir.
4. Haz las actualizaciones predecibles: constriñe repos, estandariza la cadencia de parches y usa needs-restarting para evitar reinicios aleatorios.
5. Ejecuta el playbook de diagnóstico rápido en un host sano y captura el “normal”. Esa línea base hace que futuras anomalías sean obvias.

Si no haces nada más: aplica higiene del arranque del kernel y de repos. La mayoría de problemas de producción “misteriosos” son simplemente decisiones no documentadas que finalmente cobran interés.