

• El panel de AWS Systems Manager CloudWatch dejará de estar disponible después del 30 de abril de 2026. Los clientes pueden seguir utilizando la consola de Amazon CloudWatch para ver, crear y administrar sus paneles de Amazon CloudWatch, tal y como lo hacen actualmente. Para obtener más información, consulte la [documentación del panel de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

# Cómo especificar un repositorio de origen de parches alternativo (Linux)
<a name="patch-manager-alternative-source-repository"></a>

Cuando se utilizan los repositorios predeterminados configurados en un nodo administrado para operaciones de aplicación de revisiones, Patch Manager, una herramienta 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 los parches de seguridad](patch-manager-selecting-patches.md).

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 los nodos administrados de Ubuntu Server 25.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](#patch-manager-alternative-source-repository-examples) más adelante en este tema.

Para obtener más información sobre las bases de referencia de parches predeterminadas y personalizadas, consulte [Líneas de base de revisiones personalizadas y predefinidas](patch-manager-predefined-and-custom-patch-baselines.md).

**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 para Linux](patch-manager-create-a-patch-baseline-for-linux.md).

**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](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).

**Topics**
+ [Consideraciones importantes para repositorios alternativos](#alt-source-repository-important)
+ [Ejemplos de uso de repositorios de origen de parches alternativos](#patch-manager-alternative-source-repository-examples)

## Consideraciones importantes para repositorios alternativos
<a name="alt-source-repository-important"></a>

Tenga en cuenta los siguientes puntos a la hora de planificar su estrategia de aplicación de parches con repositorios de parches alternativos.

**Aplicar verificaciones de actualización de repositorios (YUM y DNF)**  
La configuración predeterminada de un administrador de paquetes en una distribución de Linux podría estar configurada para omitir un repositorio de paquetes inalcanzable sin errores si no puede establecerse la conexión con el repositorio. Para hacer cumplir las actualizaciones del repositorio, agregue `skip_if_unavailable=False` a la configuración del repositorio.

Para obtener más información acerca de la opción `skip_if_available`, consulte [Conectividad con la fuente de revisiones](patch-manager-prerequisites.md#source-connectivity).

**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 2 o Red Hat Enterprise Linux, 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 archivo `updateinfo.xml` no 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 **Clasificación**, **Gravedad** y **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
<a name="patch-manager-alternative-source-repository-examples"></a>

**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 Personal Package Archives Ubuntu Server**  
Los nodos administrados de Ubuntu Server ejecutan software que se distribuye a través de [Personal Package Archives (PPA) para Ubuntu](https://launchpad.net/ubuntu/+ppas). En este caso, debe crear una base de referencia de revisiones que especifica un repositorio de PPA que ha configurado en el nodo administrado como repositorio de origen para la operación de aplicación de revisiones. A continuación, utilice Run Command para ejecutar el documento de base de referencia de revisiones en los nodos.

**Ejemplo 3: aplicaciones corporativas internas en versiones de Amazon Linux compatibles**  
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. 