Antes de parchear una flota RHEL con Satellite, comprueba tres cosas: que cada host esté registrado en un entorno de vista de contenido, que los repositorios estén sincronizados y que el host admita ejecución remota. Con eso, Satellite calcula qué errata son aplicables e instalables, y se aplican por interfaz web o con hammer. AAP se suma después: toma los hosts de Satellite como inventario y orquesta lo que rodea al parche. Esta lista resume qué revisar en cada punto según la documentación de Red Hat Satellite 6.18 y Ansible Automation Platform 2.6.
Las piezas que intervienen
| Pieza | Para qué sirve en el parcheo |
|---|---|
| Repositorios sincronizados | Traen a Satellite las últimas errata de Red Hat. |
| Vista de contenido y entorno de ciclo de vida | Fijan qué errata puede instalar cada host. |
| Ejecución remota | Lanza el trabajo de instalación en los hosts. |
| Inventario de AAP con credencial de Satellite | Da a AAP la lista de hosts que gestiona Satellite. |
Antes de nada, mira el ciclo de vida de Satellite: la política es N-2, donde N es la última versión menor, y solo se da soporte a N-2 mientras esa versión siga soportada. Un parcheo ordenado empieza por saber en qué versión de Satellite estás.
1. Requisitos de cada host
Según la documentación de Satellite 6.18, antes de instalar errata se debe cumplir lo siguiente:
- Los repositorios de Satellite Server están sincronizados con las últimas errata de Red Hat.
- El host está registrado en un entorno de vista de contenido.
- El host está configurado para ejecución remota.
- Las errata son instalables: solo se pueden instalar las que están en el entorno de vista de contenido del host.
Los hosts necesitan además el conjunto de paquetes Red Hat Satellite Client 6, que incluye katello-host-tools y sus dependencias, según las buenas prácticas de parcheo.
2. Errata aplicables frente a instalables
En la interfaz web, la tarjeta de errata de cada host (Hosts > All Hosts, pestaña Overview) distingue dos listas. Applicable muestra las errata que afectan a paquetes instalados; Installable muestra las aplicables que están disponibles en el entorno de vista de contenido del host. Se pueden filtrar por avisos de seguridad, correcciones de errores y mejoras.
Por línea de comandos, la documentación usa:
hammer erratum list --organization "Mi_Organizacion"
El comando admite --errata-restrict-applicable y --errata-restrict-installable para filtrar la salida.
Si una erratum es aplicable pero no instalable, la documentación indica que hay que actualizar la vista de contenido de forma incremental y promoverla al entorno de ciclo de vida del host. Después, la erratum pasa a ser instalable. Revisa cuántas errata están en esa situación antes de planificar la ventana: es la diferencia entre lo que afecta a tus hosts y lo que de verdad puedes instalar.
3. Cómo se instalan
La documentación de Satellite 6.18 describe dos caminos. Por la interfaz web: Content > Content Types > Errata, elegir la erratum, seleccionar los hosts en la pestaña Content Hosts y pulsar Apply to Hosts y luego Confirm. El resultado se comprueba en Monitor > Jobs, donde el último trabajo Install errata debe haber terminado bien en todos los hosts.
Por hammer, con ejecución remota, la documentación muestra este ejemplo:
hammer job-invocation create \
--feature katello_errata_install \
--inputs errata=ID_ERRATUM_1,ID_ERRATUM_2 \
--search-query "name = host.example.com"
Para actuar sobre una colección de hosts, la consulta es "host_collection = Nombre_Coleccion". Para todos los hosts donde una erratum es aplicable, "applicable_errata = ID_ERRATUM". Para seguir el resultado, hammer task list y hammer task progress --id ID_TAREA.
4. Parchear en lotes
La guía de Red Hat recomienda, para acciones masivas, agrupar los hosts por versión mayor del sistema operativo y elegir la opción «via remote execution – customize first», que permite decidir cuándo se aplican los parches. También señala que no se pueden aplicar errata a paquetes que no estén en los repositorios de Satellite ni en los entornos de vista de contenido del host.
Antes de la primera ventana, decide el orden de los lotes, quién valida cada uno y qué condición detiene el siguiente.
5. Conectar AAP a Satellite
En AAP 2.6 existe el tipo de credencial Red Hat Satellite 6, que permite sincronizar el inventario con Satellite. Pide la URL de Satellite, un usuario y una contraseña. Con esa credencial se crea una fuente de inventario y se sincroniza, de modo que AAP conoce los mismos hosts que Satellite.
Revisa qué usuario de Satellite usa esa credencial y qué permisos tiene: solo necesita leer el inventario que AAP va a gestionar.
6. Qué añade AAP al parcheo
Satellite ya instala errata por ejecución remota. AAP puede encargarse de lo que rodea al parche, como las comprobaciones previas y posteriores, si las defines en una plantilla de trabajo o un flujo de trabajo. Antes de automatizarlas, escribe qué comprobarías a mano en cada host antes y después del parche: esa lista es el punto de partida de la plantilla.
Dónde puede ayudar una revisión
Si quieres un orden de prioridades para tu flota, la revisión de ciclo de vida de RHEL y AAP cubre versiones, fechas de soporte, estado del parcheo y playbooks.