Cómo especificar un repositorio de origen de parches alternativo (Linux)
Cuando se utilizan los repositorios predeterminados configurados en un nodo administrado para operaciones de aplicación de revisiones, Patch Manager, una capacidad de AWS Systems Manager, busca o instala las revisiones relacionadas con la seguridad. Este es el comportamiento predeterminado de Patch Manager. Para obtener información completa acerca de cómo Patch Manager selecciona e instala los parches de seguridad, consulte Cómo se seleccionan las revisiones de seguridad.
Sin embargo, en los sistemas Linux, también puede utilizar Patch Manager para instalar revisiones que no estén relacionadas con la seguridad o que se encuentren en un repositorio de origen diferente del configurado de forma predeterminada en el nodo administrado. Puede especificar repositorios de origen de parches alternativos al crear una base de referencia de parches personalizada. En cada base de referencia de parches personalizada, es posible especificar configuraciones de origen de parches para un máximo de 20 versiones de un sistema operativo Linux compatible.
Por ejemplo, supongamos que su flota de Ubuntu Server incluye nodos administrados de Ubuntu Server 14.04 y Ubuntu Server 16.04. En este caso, puede especificar repositorios alternativos para cada versión en la misma base de referencia de parches personalizada. Para cada versión, es necesario proporcionar un nombre y especificar el tipo de versión del sistema operativo (producto), así como proporcionar una configuración de repositorio. También es posible especificar un único repositorio de origen alternativo que se aplique a todas las versiones de un sistema operativo compatible.
nota
La ejecución de una base de referencia de revisiones personalizada que especifica repositorios de revisiones alternativos para un nodo administrado no los convierte en los nuevos repositorios predeterminados del sistema operativo. Una vez completada la operación de aplicación de revisiones, los repositorios previamente configurados como valores predeterminados del sistema operativo del nodo siguen siendo los predeterminados.
Para obtener una lista de escenarios de ejemplo del uso de esta opción, consulte Ejemplos de uso de repositorios de origen de parches alternativos más adelante en este tema.
Para obtener más información sobre las bases de referencia de parches predeterminadas y personalizadas, consulte Acerca de las líneas de base de revisiones personalizadas y predefinidas.
Ejemplo: uso de la consola
Para especificar repositorios de origen de parches alternativos al trabajar en la consola de Systems Manager, utilice la sección Patch sources (Orígenes de parches) de la página Create patch baseline (Crear una base de referencia de parches). Para obtener información sobre el uso de las opciones de Orígenes de parches, consulte Creación de una línea de base de revisiones personalizada (Linux).
Ejemplos: uso de la AWS CLI
Para ver un ejemplo de cómo usar la opción --sources con la AWS Command Line Interface (AWS CLI), consulte Creación de una base de referencia de parches con repositorios personalizados para distintas versiones del sistema operativo.
Temas
Consideraciones importantes para repositorios alternativos
Tenga en cuenta los siguientes puntos a la hora de planificar su estrategia de aplicación de parches con repositorios de parches alternativos.
Solo se utilizan los repositorios especificados para la aplicación de parches
Especificar repositorios alternativos no significa especificar repositorios adicionales. Puede elegir especificar repositorios distintos de los configurados como valores predeterminados en un nodo administrado. Sin embargo, también debe especificar los repositorios predeterminados como parte de la configuración de origen de parches alternativos si desea que sus actualizaciones se apliquen.
Por ejemplo, en los nodos administrados de Amazon Linux 2, los repositorios predeterminados son amzn2-core y amzn2extra-docker. Si desea incluir el repositorio Extra Packages for Enterprise Linux (EPEL) en sus operaciones de aplicación de parches, debe especificar los tres repositorios como repositorios alternativos.
nota
La ejecución de una base de referencia de revisiones personalizada que especifica repositorios de revisiones alternativos para un nodo administrado no los convierte en los nuevos repositorios predeterminados del sistema operativo. Una vez completada la operación de aplicación de revisiones, los repositorios previamente configurados como valores predeterminados del sistema operativo del nodo siguen siendo los predeterminados.
El comportamiento de aplicación de parches para las distribuciones basadas en YUM depende del manifiesto updateinfo.xml.
Al especificar repositorios de revisión alternativos para las distribuciones basadas en YUM, como Amazon Linux 1 o Amazon Linux 2, Red Hat Enterprise Linux o CentOS, el comportamiento de las revisiones depende de si el repositorio incluye un manifiesto de actualización en forma de un archivo updateinfo.xml con formato completo y correcto. Este archivo especifica la fecha de lanzamiento, clasificaciones y gravedad de los distintos paquetes. Cualquiera de los siguientes afectarán al comportamiento de aplicación de parches:
-
Si filtra por Classification (Clasificación) y Severity (Gravedad), pero no están especificados en
updateinfo.xml, el paquete no se incluirá el filtro. Esto también significa que los paquetes sin un archivoupdateinfo.xmlno se incluyen en la aplicación de parches. -
Si filtra por ApprovalAfterDays, pero la fecha de lanzamiento del paquete no está en formato de fecha de inicio Unix (o no tiene fecha de lanzamiento especificada), el paquete no se incluirá en el filtro.
-
Existe una excepción cuando selecciona la casilla de verificación Incluir actualizaciones no relacionadas con la seguridad en la página Crear línea de base de revisiones. En este caso, los paquetes sin un archivo
updateinfo.xml(o que contengan este archivo sin valores de Classification [Clasificación], Severity [Gravedad] y Date [Fecha] con el formato adecuado) se incluirán en la lista de revisiones previamente filtrada. (Deben seguir cumpliendo los otros requisitos de reglas de base de referencia de los parches para instalarse).
Ejemplos de uso de repositorios de origen de parches alternativos
Ejemplo 1: actualizaciones que no son de seguridad para Ubuntu Server
Ya está utilizando Patch Manager para instalar revisiones de seguridad en una flota de nodos administrados de Ubuntu Server mediante la base de referencia de revisiones predefinida proporcionada por AWS, AWS-UbuntuDefaultPatchBaseline. Puede crear una nueva base de referencia de parches basada en esta base predeterminada, pero especifica en las reglas de aprobación que también desea instalar las actualizaciones que no son de seguridad y que forman parte de la distribución predeterminada. Cuando esta base de referencia de revisiones se ejecuta en los nodos, se aplican tanto las revisiones de seguridad como las que no lo son. También puede elegir aprobar los parches que no son de seguridad en las excepciones de parches especificadas para una base de referencia.
Ejemplo 2: Personal Package Archives (PPA) para Ubuntu Server Personal Package Archives
Los nodos administrados de Ubuntu Server ejecutan software que se distribuye a través de Personal Package Archives (PPA) para Ubuntu
Ejemplo 3: aplicaciones corporativas internas en Amazon Linux
Necesita ejecutar algunas aplicaciones necesarias para el cumplimiento normativo del sector en los nodos administrados de Amazon Linux. Puede configurar un repositorio para estas aplicaciones en los nodos, utilizar YUM para instalar inicialmente las aplicaciones y, a continuación, actualizar o crear una nueva base de referencia de revisiones para incluir este nuevo repositorio corporativo. Una vez hecho esto, puede utilizar Run Command para ejecutar el documento AWS-RunPatchBaseline con la opción Scan para comprobar si el paquete corporativo aparece entre los paquetes instalados y está actualizado en el nodo administrado. Si no está actualizado, puede ejecutar el documento de nuevo con la opción Install para actualizar las aplicaciones.
