• 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 funcionan las operaciones de Patch Manager
<a name="patch-manager-patching-operations"></a>

Esta sección proporciona detalles técnicos que explican cómo Patch Manager, una herramienta de AWS Systems Manager, determina cuáles son las revisiones que deben instalarse y el modo en que lo hace en cada sistema operativo compatible. En el caso de los sistemas operativos Linux, también proporciona información sobre cómo especificar un repositorio de origen en una base de referencia de revisiones personalizada para revisiones distintas de las predeterminadas configuradas en un nodo administrado. En esta sección se proporciona también información detallada acerca de cómo funcionan las reglas de líneas de base de revisiones en diversas distribuciones del sistema operativo Linux.

**nota**  
La información en los siguientes temas se aplica independientemente del método o el tipo de configuración que utilice para las operaciones de aplicación de revisiones:  
Una política de revisiones configurada en Quick Setup
Una opción de administración de host configurada en Quick Setup
Una ventana de mantenimiento para ejecutar una revisión `Scan` o una tarea `Install`
Una operación **Patch Now** (Aplicar revisión ahora) bajo demanda

**Topics**
+ [Cómo se calculan las fechas de lanzamiento y actualización de los paquetes](patch-manager-release-dates.md)
+ [Cómo se seleccionan los parches de seguridad](patch-manager-selecting-patches.md)
+ [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md)
+ [Cómo se instalan los parches](patch-manager-installing-patches.md)
+ [Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux](patch-manager-linux-rules.md)
+ [Diferencias en la operación de revisiones entre Linux y Windows Server](patch-manager-windows-and-linux-differences.md)

# Cómo se calculan las fechas de lanzamiento y actualización de los paquetes
<a name="patch-manager-release-dates"></a>

**importante**  
La información de esta página se aplica a los sistemas operativos (SO) Amazon Linux 2 y Amazon Linux 2023 para las instancias de Amazon Elastic Compute Cloud (Amazon EC2). Amazon Web Services crea y mantiene los paquetes para estos tipos de sistemas operativos. La forma en que los fabricantes de otros sistemas operativos administran sus paquetes y repositorios afecta a la forma en que se calculan sus fechas de lanzamiento y actualización. Para sistemas operativos distintos de Amazon Linux 2 y Amazon Linux 2023, como Red Hat Enterprise Linux, consulte la documentación del fabricante para obtener información sobre cómo se actualizan y mantienen sus paquetes.

En la configuración de las [líneas de base de revisiones personalizadas](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) que cree, para la mayoría de los tipos de sistemas operativos, puede especificar que la instalación de las revisiones se apruebe automáticamente después de un número de días determinado. AWS proporciona varias líneas de base de revisiones predefinidas que incluyen fechas de aprobación automática de 7 días.

Un *tiempo de espera hasta la aprobación automática* es el número de días que se debe esperar después de que se haya lanzado la revisión y antes de que se apruebe automáticamente para aplicarla. Por ejemplo, se crea una regla mediante la clasificación de `CriticalUpdates` y se configura para establecer un tiempo de espera hasta la aprobación automática de 7 días. Como resultado, una nueva revisión crítica con una fecha de lanzamiento o una fecha de última actualización datada del 7 de julio se aprueba automáticamente el 14 de julio.

Para evitar resultados inesperados en el tiempo de espera hasta la aprobación automática en Amazon Linux 2 y Amazon Linux 2023, es importante entender cómo se calculan sus fechas de lanzamiento y actualización.

**nota**  
Si un repositorio de Amazon Linux 2 o Amazon Linux 2023 no proporciona información sobre la fecha de publicación de los paquetes, Patch Manager utiliza el tiempo de compilación como la fecha de las especificaciones de aprobación automática. Si no se puede determinar el tiempo de compilación del paquete, Patch Manager utiliza una fecha predeterminada del 1 de enero de 1970. Esto resulta en que Patch Manager omita cualquier especificación de fecha de aprobación automática en las líneas base de revisiones que estén configuradas para aprobar revisiones en cualquier fecha posterior al 1 de enero de 1970.

En la mayoría de los casos, el tiempo de espera hasta la aprobación automática para instalar las revisiones se calcula a partir de un valor de `Updated Date` en `updateinfo.xml`, no un valor de `Release Date`. Los siguientes son detalles importantes sobre estos cálculos de fechas: 
+ La `Release Date` es la fecha en que se lanza un *aviso*. Esto no significa que el paquete esté necesariamente disponible en los repositorios asociados. 
+ La `Update Date` es la fecha más reciente en que se actualizó el aviso. La actualización de un aviso puede representar algo tan pequeño como la actualización de un texto o descripción. Esto no significa que el paquete se lanzó ese día o que esté necesariamente disponible en los repositorios asociados. 

  Esto significa que un paquete puede tener un valor de `Update Date` del 7 de julio, pero no podrá instalarse hasta, por ejemplo, el 13 de julio. Supongamos que, en este caso, una línea de base de revisiones que especifica un tiempo de espera de 7 días hasta la aprobación automática se ejecuta en una operación `Install` el 14 de julio. Dado que el valor de `Update Date` es 7 días antes de la fecha de ejecución, las revisiones y actualizaciones del paquete se instalan el 14 de julio. La instalación se realiza a pesar de que solo ha pasado 1 día desde que el paquete se puede instalar.
+ Un paquete que contenga revisiones del sistema operativo o aplicación se puede actualizar más de una vez después del lanzamiento inicial.
+ Se puede lanzar un paquete en los repositorios administrados por AWS, y más tarde revertirse si se identifican problemas relacionados con él.

En algunas operaciones de aplicación de revisiones, es posible que estos factores no sean importantes. Por ejemplo, si una línea de base de revisiones está configurada para instalar una revisión con valores de gravedad de `Low` y `Medium`, además de una clasificación de `Recommended`, cualquier tiempo de espera hasta la aprobación automática podría tener poco impacto en las operaciones.

Sin embargo, en los casos de revisiones críticas o de gravedad alta cuya programación sea más importante, puede ser conveniente tener un mayor control sobre cuándo deben instalarse. El método recomendado para hacerlo es utilizar repositorios de origen de revisiones alternativos en lugar de los predeterminados para las operaciones de aplicación de revisiones en un 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. Para obtener más información, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).

# Cómo se seleccionan los parches de seguridad
<a name="patch-manager-selecting-patches"></a>

Patch Manager, una herramienta de AWS Systems Manager, se centra principalmente en instalar actualizaciones relacionadas con la seguridad de los sistemas operativos en los nodos administrados. De forma predeterminada, Patch Manager no instala todos los parches disponibles, sino un conjunto de parches más reducido centrado en la seguridad.

Patch Manager no reemplaza de forma predeterminada un paquete que se haya marcado como obsoleto en un repositorio de paquetes con ningún paquete de reemplazo con un nombre diferente, a menos que este reemplazo sea necesario para la instalación de otra actualización de paquete. En cambio, para los comandos que actualizan un paquete, Patch Manager solo informa las actualizaciones que faltan para el paquete que está instalado, pero obsoleto y las instala. Esto se debe a que la sustitución de un paquete obsoleto suele requerir la desinstalación de un paquete existente y la instalación de uno de reemplazo. Reemplazar el paquete obsoleto podría introducir cambios importantes o funcionalidades adicionales que no se habían previsto.

Este comportamiento es coherente con el comando `update-minimal` de YUM y DNF, que se centra en las actualizaciones de seguridad más que en las mejoras de características. Para obtener más información, consulte [Cómo se instalan los parches](patch-manager-installing-patches.md).

**nota**  
Cuando utiliza el parámetro `ApproveUntilDate` o el parámetro `ApproveAfterDays` en una regla de líneas de base de revisiones, Patch Manager evalúa las fechas de lanzamiento de la revisión mediante la hora universal coordinada (UTC).   
Por ejemplo, en el caso de `ApproveUntilDate`, si especifica una fecha como `2025-11-16`, las revisiones publicadas entre `2025-11-16T00:00:00Z` y se `2025-11-16T23:59:59Z` aprobarán.   
Tenga en cuenta que las fechas de lanzamiento de las revisiones que muestran los administradores de paquetes nativos de los nodos administrados pueden mostrar diferentes horas según la zona horaria local del sistema, pero Patch Manager siempre utiliza la fecha y hora UTC para los cálculos de aprobación. Esto garantiza la coherencia con las fechas de lanzamiento de las revisiones publicadas en los sitios web oficiales de asesoramiento de seguridad.

Para los tipos de sistemas operativos basados en Linux que informan de un nivel de gravedad de las revisiones, Patch Manager utiliza el nivel de gravedad notificado por el editor de software para el aviso de actualización o la revisión individual. Patch Manager no deriva los niveles de gravedad de orígenes de terceros, como el [Sistema de puntuación de vulnerabilidades comunes](https://www.first.org/cvss/) (CVSS), ni de las métricas publicadas por la [Base de datos nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).

**nota**  
En todos los sistemas basados en Linux compatibles con Patch Manager, es posible elegir un repositorio de origen distinto configurado para el nodo administrado, normalmente para instalar actualizaciones no relacionadas con la seguridad. Para obtener más información, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).

Elija entre las siguientes pestañas para obtener información acerca de cómo Patch Manager selecciona parches de seguridad para el sistema operativo.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

Los repositorios preconfigurados se administran de forma diferente en Amazon Linux 2 que en Amazon Linux 2023.

En Amazon Linux 2, el servicio de línea de base de revisiones de Systems Manager utiliza repositorios preconfigurados en los nodos administrados. Normalmente, hay dos repositorios preconfigurados (repos) en un nodo:

**En Amazon Linux 2**
+ **ID del repositorio**: `amzn2-core/2/architecture`

  **Nombre del repositorio**: `Amazon Linux 2 core repository`
+ **ID del repositorio**: `amzn2extra-docker/2/architecture`

  **Nombre del repositorio**: `Amazon Extras repo for docker`

**nota**  
El valor *arquitectura* puede ser x86\$164 o aarch64 (para procesadores Graviton).

Cuando crea una instancia de Amazon Linux 2023 (AL2023), esta contiene las actualizaciones que estaban disponibles en la versión de AL2023 y la AMI específica que seleccionó. Su instancia AL2023 no recibe de manera automática las actualizaciones de seguridad críticas e importantes adicionales en el momento del lanzamiento. En cambio, con la característica de *actualizaciones deterministas a través de repositorios versionados* compatibles con AL2023, que está activada de forma predeterminada, puede aplicar las actualizaciones según una programación que se adapte a sus necesidades específicas. Para obtener información, consulte [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) en la *Guía del usuario de Amazon Linux 2023*. 

En AL2023, el repositorio preconfigurado es el siguiente:
+ **ID del repositorio**: `amazonlinux`

  **Nombre del repositorio**: repositorio de Amazon Linux 2023

En Amazon Linux 2023 (versión preliminar), los repositorios preconfigurados están vinculados a *las versiones bloqueadas* de las actualizaciones de paquetes. Cuando se lanzan nuevos Amazon Machine Images (AMIs) para AL2023, se bloquean en una versión específica. Para las actualizaciones de revisiones, Patch Manager recupera la última versión bloqueada del repositorio de actualizaciones de revisiones y, a continuación, actualiza los paquetes en el nodo administrado en función del contenido de esa versión bloqueada.

**Administradores de paquetes**  
Los nodos administrados de Amazon Linux 2 utilizan Yum como administrador de paquetes. Amazon Linux 2023 utiliza DNF como el administrador de paquetes. 

Ambos administradores de paquetes utilizan el concepto de un *aviso de actualización* como un archivo llamado `updateinfo.xml`. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. considera todos los paquetes que se encuentran en un aviso de actualización como paquetes de seguridad Patch Manager. A los paquetes individuales no se les asignan clasificaciones ni niveles de gravedad. Por este motivo, Patch Manager asigna los atributos de un aviso de actualización a los paquetes relacionados.

**nota**  
Si selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear una línea de base de revisiones**, los paquetes que no estén clasificados en un archivo `updateinfo.xml` (o un paquete que contenga un archivo sin los valores de Clasificación, Gravedad y Fecha con el formato correcto) se podrán incluir en la lista de revisiones filtrada con anterioridad. Sin embargo, para poder aplicar un parche, este debe seguir cumpliendo las reglas de base de referencia de parches especificadas por el usuario.  
Para obtener más información sobre la opción **Incluir actualizaciones no relacionadas con la seguridad**, consulte [Cómo se instalan los parches](patch-manager-installing-patches.md) y [Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux](patch-manager-linux-rules.md).

------
#### [  CentOS Stream ]

En CentOS Stream, el servicio de base de referencia de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. En la siguiente lista, se muestran ejemplos para una Amazon Machine Image (AMI) de CentOS 9.2 ficticia:
+ **ID del repositorio**: `example-centos-9.2-base`

  **Nombre del repositorio**: `Example CentOS-9.2 - Base`
+ **ID del repositorio**: `example-centos-9.2-extras` 

  **Nombre del repositorio**: `Example CentOS-9.2 - Extras`
+ **ID del repositorio**: `example-centos-9.2-updates`

  **Nombre del repositorio**: `Example CentOS-9.2 - Updates`
+ **ID del repositorio**: `example-centos-9.x-examplerepo`

  **Nombre del repositorio**: `Example CentOS-9.x – Example Repo Packages`

**nota**  
Todas las actualizaciones se descargan desde los repositorios remotos configurados en el nodo administrado. Por lo tanto, el nodo debe tener acceso saliente a Internet para conectarse a los repositorios y que puedan implementarse las revisiones.

Los nodos de CentOS Stream utilizan DNF como administrador de paquetes. El administrador de paquetes utiliza el concepto de un aviso de actualización. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. 

Sin embargo, los repositorios predeterminados de CentOS Stream no se configuran con un aviso de actualización. Esto significa que Patch Manager no detecta paquetes en repositorios de CentOS Stream predeterminados. Para permitir que Patch Manager procese paquetes no incluidos en avisos de actualización, debe activar la marca `EnableNonSecurity` en las reglas de base de referencia de los parches.

**nota**  
Los avisos de actualización de CentOS Stream son compatibles. Los repositorios con avisos de actualización se pueden descargar tras el lanzamiento.

------
#### [ Servidor Debian ]

En Debian Server, el servicio de base de referencia de parches de Systems Manager utiliza repositorios (repos) preconfigurados en la instancia. Estos repositorios preconfigurados se utilizan para obtener una lista actualizada de actualizaciones de paquetes disponibles. Por este motivo, Systems Manager realiza el equivalente a un comando `sudo apt-get update`. 

A continuación, los paquetes se filtran desde los repositorios `debian-security codename`. Esto significa que en cada versión de Debian Server, Patch Manager solo identifica las actualizaciones que son parte del repositorio asociado para esta versión, como se muestra a continuación:
+  Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`

------
#### [ Oracle Linux ]

En Oracle Linux, el servicio de base de referencia de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. Normalmente, hay dos repositorios preconfigurados en un nodo.

**Oracle Linux 7**:
+ **ID del repositorio**: `ol7_UEKR5/x86_64`

  **Nombre del repositorio**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **ID del repositorio**: `ol7_latest/x86_64`

  **Nombre del repositorio**: `Oracle Linux 7Server Latest (x86_64)` 

**Oracle Linux 8**:
+ **ID del repositorio**: `ol8_baseos_latest` 

  **Nombre del repositorio**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **ID del repositorio**: `ol8_appstream`

  **Nombre del repositorio**: `Oracle Linux 8 Application Stream (x86_64)` 
+ **ID del repositorio**: `ol8_UEKR6`

  **Nombre del repositorio**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`

**Oracle Linux 9**:
+ **ID del repositorio**: `ol9_baseos_latest` 

  **Nombre del repositorio**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **ID del repositorio**: `ol9_appstream`

  **Nombre del repositorio**: `Oracle Linux 9 Application Stream Packages(x86_64)` 
+ **ID del repositorio**: `ol9_UEKR7`

  **Nombre del repositorio**: `Oracle Linux UEK Release 7 (x86_64)`

**nota**  
Todas las actualizaciones se descargan desde los repositorios remotos configurados en el nodo administrado. Por lo tanto, el nodo debe tener acceso saliente a Internet para conectarse a los repositorios y que puedan implementarse las revisiones.

Oracle Linux Los nodos administrados de utilizan Yum como administrador de paquetes y Yum utiliza el concepto de aviso de actualización como un archivo denominado `updateinfo.xml`. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. A los paquetes individuales no se les asignan clasificaciones ni niveles de gravedad. Por este motivo, Patch Manager asigna los atributos de un aviso de actualización a los paquetes relacionados e instala los paquetes en función de los filtros de clasificación especificados en la base de referencia de parches.

**nota**  
Si selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear una línea de base de revisiones**, los paquetes que no estén clasificados en un archivo `updateinfo.xml` (o un paquete que contenga un archivo sin los valores de Clasificación, Gravedad y Fecha con el formato correcto) se podrán incluir en la lista de revisiones filtrada con anterioridad. Sin embargo, para poder aplicar un parche, este debe seguir cumpliendo las reglas de base de referencia de parches especificadas por el usuario.

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

En AlmaLinux, Red Hat Enterprise Linux y Rocky Linux, el servicio de línea de base de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. Normalmente, hay tres repositorios preconfigurados en un nodo.

Todas las actualizaciones se descargan desde los repositorios remotos configurados en el nodo administrado. Por lo tanto, el nodo debe tener acceso saliente a Internet para conectarse a los repositorios y que puedan implementarse las revisiones.

**nota**  
Si selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear una línea de base de revisiones**, los paquetes que no estén clasificados en un archivo `updateinfo.xml` (o un paquete que contenga un archivo sin los valores de Clasificación, Gravedad y Fecha con el formato correcto) se podrán incluir en la lista de revisiones filtrada con anterioridad. Sin embargo, para poder aplicar un parche, este debe seguir cumpliendo las reglas de base de referencia de parches especificadas por el usuario.

Los nodos administrados de Red Hat Enterprise Linux 7 utilizan YUM como administrador de paquetes. Los nodos administrados de AlmaLinux, Red Hat Enterprise Linux 8 y Rocky Linux utilizan DNF como gestor de paquetes. Ambos administradores de paquetes utilizan el concepto de un aviso de actualización como un archivo llamado `updateinfo.xml`. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. A los paquetes individuales no se les asignan clasificaciones ni niveles de gravedad. Por este motivo, Patch Manager asigna los atributos de un aviso de actualización a los paquetes relacionados e instala los paquetes en función de los filtros de clasificación especificados en la base de referencia de parches.

RHEL 7  
Los siguientes ID de repositorio están asociados con RHUI 2. RHUI 3 se lanzó en diciembre de 2019 y supuso la introducción de un esquema de nomenclatura diferente para los ID de repositorio de Yum. En función de la AMI RHEL-7 desde la que cree los nodos administrados, es posible que tenga que actualizar los comandos. Para obtener más información, consulte [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971) en el *Portal del cliente de Red Hat*.
+ **ID del repositorio**: `rhui-REGION-client-config-server-7/x86_64`

  **Nombre del repositorio**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **ID del repositorio**: `rhui-REGION-rhel-server-releases/7Server/x86_64`

  **Nombre del repositorio**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **ID del repositorio**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`

  **Nombre del repositorio**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`

AlmaLinux 8, RHEL 8 y Rocky Linux 8  
+ **ID del repositorio**: `rhel-8-appstream-rhui-rpms`

  **Nombre del repositorio**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID del repositorio**: `rhel-8-baseos-rhui-rpms`

  **Nombre del repositorio**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID del repositorio**: `rhui-client-config-server-8`

  **Nombre del repositorio**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`

AlmaLinux 9, RHEL 9 y Rocky Linux 9  
+ **ID del repositorio**: `rhel-9-appstream-rhui-rpms`

  **Nombre del repositorio**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID del repositorio**: `rhel-9-baseos-rhui-rpms`

  **Nombre del repositorio**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID del repositorio**: `rhui-client-config-server-9`

  **Nombre del repositorio**: `Red Hat Enterprise Linux 9 Client Configuration`

------
#### [ SLES ]

En los nodos administrados de SUSE Linux Enterprise Server (SLES), la biblioteca ZYPP obtiene la lista de revisiones disponibles (una colección de paquetes) de las siguientes ubicaciones:
+ Lista de repositorios: `etc/zypp/repos.d/*`
+ Información de paquetes: `/var/cache/zypp/raw/*`

SLESLos nodos administrados de utilizan Zypper como administrador de paquetes, y Zypper utiliza el concepto de revisión. Un parche es una simple colección de paquetes que corrigen un problema concreto. Patch Manager se ocupa de todos los paquetes que se referencian en un parche como relacionados con la seguridad. Dado que a los paquetes individuales no se les asignan clasificaciones ni gravedad, Patch Manager les asigna los atributos del parche al que pertenecen.

------
#### [ Servidor Ubuntu ]

En Ubuntu Server, el servicio de base de referencia de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. Estos repositorios preconfigurados se utilizan para obtener una lista actualizada de actualizaciones de paquetes disponibles. Por este motivo, Systems Manager realiza el equivalente a un comando `sudo apt-get update`. 

A continuación, los paquetes se filtran desde los repositorios `codename-security`, cuyo nombre de código es único para la versión de lanzamiento, como `trusty` para Ubuntu Server 14. Patch Manager identifica únicamente las actualizaciones que forman parte de estos repositorios: 
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)

------
#### [ Windows Server ]

En los sistemas operativos Microsoft Windows, Patch Manager recupera una lista de las actualizaciones disponibles que Microsoft publica a través de los servicios de Microsoft Update y que están disponibles de manera automática para Windows Server Update Services (WSUS).

**nota**  
Patch Manager solo pone a disposición parches para versiones del sistema operativo Windows Server que son compatibles con Patch Manager. Por ejemplo, Patch Manager no se puede utilizar para aplicar parches a Windows RT.

Patch Manager monitorea continuamente las nuevas actualizaciones en cada Región de AWS. La lista de las actualizaciones de Windows disponibles se actualiza en cada región al menos una vez al día. Cuando la información sobre parches de Microsoft se procesa, Patch Manager elimina las actualizaciones que se han sustituido por actualizaciones posteriores de su lista de parches. Por lo tanto, solo se muestra la última actualización y, en su caso, están disponibles para su instalación. Por ejemplo, si `KB4012214` sustituye a `KB3135456`, solo `KB4012214` estará disponible como una actualización en Patch Manager.

Del mismo modo, solo Patch Manager puede instalar las revisiones que estén disponibles en el nodo gestionado durante la operación de aplicación de revisiones. De forma predeterminada, en Windows Server 2019 y Windows Server 2022 se eliminan las actualizaciones que se sustituyen por actualizaciones posteriores. Como resultado, si utiliza el parámetro `ApproveUntilDate` en la línea de base de revisiones Windows Server, pero la fecha seleccionada en el parámetro `ApproveUntilDate` es *anterior* a la fecha del último parche, se produce la siguiente situación:
+ La revisión sustituida se elimina del nodo y, por lo tanto, no se puede instalar con Patch Manager.
+ La última revisión de reemplazo está presente en el nodo, pero aún no se ha aprobado su instalación en la fecha especificada por el parámetro `ApproveUntilDate`. 

Esto significa que el nodo gestionado es compatible con las operaciones de Systems Manager, aunque es posible que no se haya instalado una revisión crítica del mes anterior. Esta misma situación puede ocurrir cuando se utiliza el parámetro `ApproveAfterDays`. Debido al comportamiento de las revisiones sustituidas por Microsoft, es posible establecer un número (generalmente superior a 30 días) para que las revisiones para Windows Server no se instalen nunca si la última revisión disponible de Microsoft se publica antes de que hayan transcurrido los días en `ApproveAfterDays`. Tenga en cuenta que este comportamiento del sistema no se aplica si ha modificado la configuración con objetos de políticas globales (GPO) de Windows para que la versión sustituida esté disponible en los nodos administrados.

**nota**  
En algunos casos, Microsoft lanza parches para las aplicaciones que no especifican una hora ni una fecha de actualización. En estos casos, se suministra una fecha y hora actualizadas de `01/01/1970` de forma predeterminada.

------

# 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. 

# Cómo se instalan los parches
<a name="patch-manager-installing-patches"></a>

Patch Manager, una herramienta de AWS Systems Manager, utiliza el administrador de paquetes integrado en el sistema operativo para instalar actualizaciones en los nodos administrados. Por ejemplo, utiliza la API de Windows Update en Windows Server y `DNF` en Amazon Linux 2023. Patch Manager respeta las configuraciones de los repositorios y administradores de paquetes existentes en los nodos, e incluye ajustes como el estado del repositorio, las URL duplicadas, la verificación de GPG y opciones como `skip_if_unavailable`.

Patch Manager no instala un paquete nuevo que sustituya a un paquete obsoleto que esté instalado actualmente. (Excepciones: el paquete nuevo es una dependencia de otro paquete que se está actualizando o el paquete nuevo tiene el mismo nombre que el paquete obsoleto). En su lugar, Patch Manager informa sobre las actualizaciones disponibles para los paquetes instalados y las instala. Este enfoque ayuda a evitar cambios inesperados en la funcionalidad del sistema que pueden producirse cuando un paquete reemplaza a otro.

Si necesita desinstalar un paquete que ha quedado obsoleto e instalar un paquete que lo sustituya, puede que necesite utilizar un script personalizado o utilizar comandos del administrador de paquetes fuera de las operaciones estándar del Patch Manager.

Elija entre las siguientes pestañas para obtener información acerca de cómo Patch Manager instala parches en un sistema operativo.

------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]

En los nodos administrados de Amazon Linux 2 y Amazon Linux 2023, el flujo de trabajo de instalación de revisiones es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. Si hay varias versiones de un parche aprobadas, se aplica la última.

1. La API de actualización de YUM (Amazon Linux, 2) o la API de actualización de DNF (Amazon Linux 2023) se aplica a las revisiones aprobadas de la siguiente manera:
   + Para las líneas de base de revisiones predeterminadas y proporcionadas por AWS, solo se aplican las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad). Esto se debe a que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** no está seleccionada. Las líneas de base predefinidas equivalen a una línea de base personalizada con lo siguiente:
     + La casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** no está seleccionada
     + Una lista de GRAVEDAD de `[Critical, Important]`
     + Una lista de CLASIFICACIÓN de `[Security, Bugfix]`

     En Amazon Linux 2, el comando yum equivalente para este flujo de trabajo es el siguiente:

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     En Amazon Linux 2023, el comando dnf equivalente para este flujo de trabajo es el siguiente:

     ```
     sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```

     Si la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** está seleccionada, se aplican las revisiones que están en `updateinfo.xml` y no las que están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).

     En Amazon Linux 2, si se selecciona una línea de base con **Incluir actualizaciones no relacionadas con la seguridad** y tiene una lista de gravedad de `[Critical, Important]` y una lista de clasificación de `[Security, Bugfix]`, el comando yum equivalente es el siguiente:

     ```
     sudo yum update --security --sec-severity=Critical,Important --bugfix -y
     ```

     En Amazon Linux 2023, el comando dnf equivalente es el siguiente:

     ```
     sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
     ```
**nota**  
Los paquetes nuevos que sustituyen a los ya obsoletos con nombres diferentes se instalan si ejecuta estos comandos `yum` o `dnf` fuera del Patch Manager. Sin embargo, *no* se instalan mediante las operaciones equivalentes del Patch Manager.

**Detalles adicionales sobre los parches para Amazon Linux 2023**  
Asistencia para el nivel de gravedad “None”  
Amazon Linux 2023 también admite el nivel de gravedad de revisiones `None`, el cual reconoce el administrador de paquetes DNF.   
Asistencia para el nivel de gravedad “Medium”  
Para Amazon Linux 2023, un nivel de gravedad de revisiones `Medium` equivale a un nivel de gravedad `Moderate` que podría definirse en algunos repositorios externos. Si incluye `Medium` revisiones de gravedad en la línea de base de revisiones, también se instalarán en las instancias `Moderate` revisiones de gravedad de revisiones externas.  
Cuando consulta los datos de cumplimiento mediante la acción [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) de la API, el filtrado para el nivel de gravedad `Medium` informa revisiones con niveles de gravedad tanto `Medium` como `Moderate`.  
Manejo transitivo de dependencias para Amazon Linux 2023  
En el caso de Amazon Linux 2023, Patch Manager puede instalar versiones de dependencias transitivas distintas a las que instalan los comandos de `dnf` equivalentes. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).   
Por ejemplo, `dnf upgrade-minimal --security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las **últimas versiones disponibles de las mismas dependencias transitivas.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**nota**  
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. En esos casos, la operación de aplicación de revisiones correspondiente se lleva a cabo sin instalar las actualizaciones del repositorio y finaliza de manera satisfactoria. 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).

------
#### [ CentOS Stream ]

En los nodos administrados CentOS Stream, el flujo de trabajo de instalación de revisiones es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

   Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. Si hay varias versiones de un parche aprobadas, se aplica la última.

1. La actualización de DNF en CentOS Stream se aplica a las revisiones aprobadas.
**nota**  
En el caso de CentOS Stream, Patch Manager podría instalar versiones de dependencias transitivas diferentes a las que instalan los comandos equivalentes de `dnf`. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).   
Por ejemplo, `dnf upgrade-minimal ‐‐security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las *últimas* versiones disponibles de las mismas dependencias transitivas.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Servidor Debian ]

En las instancias de Debian Server, el flujo de trabajo de instalación de parches es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado. 
**nota**  
Como no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Debian Server, las opciones de aprobación automática no son compatibles con este sistema operativo.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
**nota**  
En Debian Server, las versiones candidatas a revisiones se limitan a las revisiones incluidas en `debian-security`.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. La biblioteca de APT se utiliza para actualizar paquetes.
**nota**  
Patch Manager no admite el uso de la opción `Pin-Priority` de APT para asignar prioridades a los paquetes. Patch Manager agrega las actualizaciones disponibles de todos los repositorios habilitados y selecciona la actualización más reciente que coincide con la línea de base de cada paquete instalado.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ macOS ]

En los nodos administrados macOS, el flujo de trabajo de instalación de revisiones es el siguiente:

1. La lista de propiedades `/Library/Receipts/InstallHistory.plist` es un registro de software que se ha instalado y actualizado mediante los administradores de paquetes `softwareupdate` y `installer`. Mediante la herramienta de línea de comandos `pkgutil` (para `installer`) y el administrador de paquetes `softwareupdate`, se ejecutan comandos de la CLI para analizar esta lista. 

   Para `installer`, la respuesta a los comandos de la CLI incluye detalles de `package name`, `version`, `volume`, `location` y `install-time`, pero Patch Manager solo utiliza `package name` y `version`.

   Para `softwareupdate`, la respuesta a los comandos de la CLI incluye el nombre del paquete (`display name`), `version` y `date`, pero Patch Manager utiliza únicamente el nombre del paquete y la versión.

   Para Brew y Brew Cask, Homebrew no admite que sus comandos se ejecuten con el usuario raíz. Como resultado, Patch Manager consulta y ejecuta los comandos de Homebrew como propietario del directorio de Homebrew o como usuario válido perteneciente al grupo de propietarios de ese directorio. Los comandos se asemejan a `softwareupdate` y `installer`, y se ejecutan a través de un subproceso de Python para recopilar los datos de los paquetes, y el resultado se analiza con el objetivo de identificar los nombres y las versiones de los paquetes.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. Si hay varias versiones de un parche aprobadas, se aplica la última.

1. Invoque la CLI del paquete correspondiente en el nodo administrado para procesar las revisiones aprobadas de la siguiente manera:
**nota**  
`installer` carece de la funcionalidad para buscar e instalar actualizaciones. Por lo tanto, para `installer`, Patch Manager solo notifica qué paquetes están instalados. Como resultado, los paquetes `installer` nunca se notifican como `Missing`.
   + Para las líneas de base de revisiones predeterminadas proporcionadas por AWS y las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *no* está seleccionada, solo se aplican las actualizaciones de seguridad.
   + Para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *sí* está seleccionada, se aplican tanto las actualizaciones de seguridad como las que no están relacionadas con la seguridad.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Oracle Linux ]

En los nodos administrados Oracle Linux, el flujo de trabajo de instalación de revisiones es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. Si hay varias versiones de un parche aprobadas, se aplica la última.

1. En los nodos administrados de la versión 7, la API de actualización de YUM se aplica a las revisiones aprobadas como se indica a continuación:
   + Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *no* está seleccionada, solo se aplican las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad).

     El comando yum equivalente para este flujo de trabajo es:

     ```
     sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
     ```
   + Para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *sí* está seleccionada, se aplican las revisiones que están en `updateinfo.xml` y las que no están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).

     El comando yum equivalente para este flujo de trabajo es:

     ```
     sudo yum update --security --bugfix -y
     ```

     En los nodos administrados de las versiones 8 y 9, la API de actualización de DNF se aplica a las revisiones aprobadas como se indica a continuación:
     + Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *no* está seleccionada, solo se aplican las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad).

       El comando yum equivalente para este flujo de trabajo es:

       ```
       sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
       ```
**nota**  
En el caso de Oracle Linux, Patch Manager puede instalar versiones de dependencias transitivas distintas a las que instalan los comandos de `dnf` equivalentes. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).   
Por ejemplo, `dnf upgrade-minimal --security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las *últimas* versiones disponibles de las mismas dependencias transitivas.
     + Para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *sí* está seleccionada, se aplican las revisiones que están en `updateinfo.xml` y las que no están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).

       El comando yum equivalente para este flujo de trabajo es:

       ```
       sudo dnf upgrade --security --bugfix
       ```
**nota**  
Los paquetes nuevos que sustituyen a los ya obsoletos con nombres diferentes se instalan si ejecuta estos comandos `yum` o `dnf` fuera del Patch Manager. Sin embargo, *no* se instalan mediante las operaciones equivalentes del Patch Manager.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**nota**  
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. En esos casos, la operación de aplicación de revisiones correspondiente se lleva a cabo sin instalar las actualizaciones del repositorio y finaliza de manera satisfactoria. 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).

------
#### [ AlmaLinux, RHEL, and Rocky Linux  ]

En los nodos administrados de AlmaLinux, Red Hat Enterprise Linux y Rocky Linux, el flujo de trabajo de instalación de revisión es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. Si hay varias versiones de un parche aprobadas, se aplica la última.

1. La API de actualización de YUM (en RHEL 7) o la API de actualización de DNF (en AlmaLinux 8 y 9, RHEL 8, 9 y 10, y Rocky Linux 8 y 9) se aplica a las revisiones aprobadas de acuerdo con las siguientes reglas:

    

**Situación 1: se excluyen las actualizaciones no relacionadas con la seguridad**
   + **Se aplica a**: líneas de base de revisiones predeterminadas y predefinidas proporcionadas por AWS y líneas de base de revisiones personalizadas.
   + Casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad**: *no* está seleccionada.
   + **Revisiones aplicadas**: las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad) se aplican *únicamente* si coinciden con la configuración de la línea de base de revisiones y se encuentran en los repositorios configurados.

     En algunos casos, es posible que una revisión especificada en `updateinfo.xml` ya no esté disponible en un repositorio configurado. Los repositorios configurados suelen tener solo la última versión de una revisión, que es una recopilación acumulativa de todas las actualizaciones anteriores, pero es posible que la última versión no cumpla con las reglas de la línea de base de revisiones y se omita en la operación de aplicación de revisiones.
   + **Comandos**: en RHEL 7, el comando yum equivalente para este flujo de trabajo es: 

     ```
     sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
     ```

     En AlmaLinux, RHEL 8 y Rocky Linux, los comandos dnf equivalentes para este flujo de trabajo son los siguientes:

     ```
     sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
     sudo dnf update-minimal --sec-severity=Important --bugfix -y
     ```
**nota**  
En el caso de AlmaLinux, RHEL, y Rocky LinuxRocky Linux, es posible que Patch Manager instale versiones de dependencias transitivas distintas a las que instalan los comandos de `dnf` equivalentes. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).   
Por ejemplo, `dnf upgrade-minimal --security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las *últimas* versiones disponibles de las mismas dependencias transitivas.

**Situación 2: se incluyen actualizaciones no relacionadas con la seguridad**
   + **Se aplica a**: líneas de base de revisiones personalizadas.
   + Casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad**: está seleccionada.
   + **Revisiones aplicadas**: se aplican las revisiones incluidas en `updateinfo.xml` *y* las que no están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).
   + **Comandos**: en RHEL 7, el comando yum equivalente para este flujo de trabajo es:

     ```
     sudo yum update --security --bugfix -y
     ```

     En AlmaLinux 8 y 9, RHEL 8 y 9 y Rocky Linux 8 y 9, el comando dnf equivalente para este flujo de trabajo es el siguiente:

     ```
     sudo dnf update --security --bugfix -y
     ```
**nota**  
Los paquetes nuevos que sustituyen a los ya obsoletos con nombres diferentes se instalan si ejecuta estos comandos `yum` o `dnf` fuera del Patch Manager. Sin embargo, *no* se instalan mediante las operaciones equivalentes del Patch Manager.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

**nota**  
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. En esos casos, la operación de aplicación de revisiones correspondiente se lleva a cabo sin instalar las actualizaciones del repositorio y finaliza de manera satisfactoria. 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).

------
#### [ SLES ]

En los nodos administrados de SUSE Linux Enterprise Server (SLES), el flujo de trabajo de instalación de revisiones es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. Si hay varias versiones de un parche aprobadas, se aplica la última.

1. La API de actualización de Zypper se aplica a los parches aprobados.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Servidor Ubuntu ]

En los nodos administrados Ubuntu Server, el flujo de trabajo de instalación de revisiones es el siguiente:

1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.

1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante. 

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado. 
**nota**  
Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. 

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
**nota**  
Para cada versión de Ubuntu Server, las versiones candidatas a parches se limitan a los parches que forman parte del repositorio asociado a esa versión, como se muestra a continuación:  
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.

1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.

1. La biblioteca de APT se utiliza para actualizar paquetes.
**nota**  
Patch Manager no admite el uso de la opción `Pin-Priority` de APT para asignar prioridades a los paquetes. Patch Manager agrega las actualizaciones disponibles de todos los repositorios habilitados y selecciona la actualización más reciente que coincide con la línea de base de cada paquete instalado.

1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).

------
#### [ Windows Server ]

Cuando se realiza una operación de aplicación de revisiones en un nodo administrado de Windows Server, este solicita una instantánea de la base de referencia de revisiones adecuada a Systems Manager. Esta instantánea contiene la lista de todas las actualizaciones disponibles en la base de referencia de parches que se aprobaron para su implementación. Esta lista de actualizaciones se envía a la API de Windows Update, que determina qué actualizaciones son aplicables al nodo administrado y se instala cuando sea necesario. Windows solo permite instalar la versión más reciente disponible de una KB. Patch Manager instala la última versión de una KB cuando esta, o cualquier versión anterior de la KB, coincide con la línea de base de revisiones aplicada. Si se instalan las actualizaciones, el nodo administrado se reinicia después, tantas veces como sea necesario para completar todas las revisiones necesarias. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)). El resumen de la operación de aplicación de parches se puede encontrar en la salida de la solicitud de Run Command. Puede encontrar más registros en el nodo administrado de la carpeta `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`.

Como la API de Windows Update se utiliza para descargar e instalar KB, se respetan todos los ajustes de la política de grupos de Windows Update. No se necesitan ajustes de la política de grupos para utilizar Patch Manager, pero se aplicará la configuración que haya definido, por ejemplo, dirigir nodos administrados a un servidor Windows Server Update Services (WSUS).

**nota**  
De forma predeterminada, Windows descarga todos los KB del sitio de Windows Update de Microsoft porque Patch Manager utiliza la API de Windows Update para impulsar la descarga e instalar los parches. Como resultado, el nodo administrado debe poder acceder al sitio de Microsoft Windows Update; si no, la aplicación de revisiones no se realizará correctamente. De forma alternativa, puede configurar un servidor WSUS para que funcione como un repositorio de KB y configurar los nodos administrados para que se dirijan al servidor WSUS mediante las políticas de grupo.  
Patch Manager puede hacer referencia a los ID de KB al crear líneas de base de revisiones personalizadas para Windows Server, por ejemplo, cuando se incluye una lista de **revisiones aprobadas** o una lista de **revisiones rechazadas** en la configuración de línea de base. Patch Manager solo instala las actualizaciones a las que se les asigna un ID de KB en Microsoft Windows Update o en un servidor WSUS. Las actualizaciones que carecen de un ID de KB no se incluyen en las operaciones de aplicación de revisiones.   
Para obtener información sobre la creación de líneas de base de revisiones personalizadas, consulte los temas siguientes:  
 [Cómo crear una línea de base de revisiones personalizada para Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
 [Creación de una línea de base de revisiones de revisiones (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Formatos de nombre de paquete para sistemas operativos Windows](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)

------

# Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux
<a name="patch-manager-linux-rules"></a>

Las reglas de una base de referencia de parches para distribuciones de Linux funcionan de forma diferente en función del tipo de distribución. A diferencia de actualizaciones de revisiones en los nodos administrados de Windows Server, las reglas se evalúan en cada nodo para tener en cuenta los repositorios configurados en la instancia. Patch Manager, una herramienta de AWS Systems Manager, utiliza el administrador de paquetes nativo para impulsar la instalación de revisiones aprobadas por la línea de base de revisiones.

Para los tipos de sistemas operativos basados en Linux que informan de un nivel de gravedad de las revisiones, Patch Manager utiliza el nivel de gravedad notificado por el editor de software para el aviso de actualización o la revisión individual. Patch Manager no deriva los niveles de gravedad de orígenes de terceros, como el [Sistema de puntuación de vulnerabilidades comunes](https://www.first.org/cvss/) (CVSS), ni de métricas publicadas por la [Base de datos nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).

**Topics**
+ [Funcionamiento de las reglas de línea de base de revisiones en Amazon Linux 2 y Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Funcionamiento de las reglas de líneas de base de revisiones en CentOS Stream](#linux-rules-centos)
+ [Funcionamiento de las reglas de líneas de base de revisiones en Debian Server](#linux-rules-debian)
+ [Funcionamiento de las reglas de líneas de base de revisiones en macOS](#linux-rules-macos)
+ [Funcionamiento de las reglas de líneas de base de revisiones en Oracle Linux](#linux-rules-oracle)
+ [Funcionamiento de las reglas de líneas de base de revisiones en AlmaLinux, RHEL y Rocky Linux](#linux-rules-rhel)
+ [Funcionamiento de las reglas de líneas de base de revisiones en SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Funcionamiento de las reglas de líneas de base de revisiones en Ubuntu Server](#linux-rules-ubuntu)

## Funcionamiento de las reglas de línea de base de revisiones en Amazon Linux 2 y Amazon Linux 2023
<a name="linux-rules-amazon-linux"></a>

**nota**  
Amazon Linux 2023 (AL2023) usa repositorios versionados que se pueden bloquear en una versión específica mediante una o más configuraciones del sistema. Para todas las operaciones de aplicación de parches en las instancias de EC2 de AL2023, Patch Manager usa las versiones más recientes del repositorio, independientemente de la configuración del sistema. Para obtener información, consulte [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) en la *Guía del usuario de Amazon Linux 2023*.

En Amazon Linux 2 y Amazon Linux 2023, el procedimiento de selección de revisiones es el siguiente:

1. En el nodo administrado, la biblioteca YUM (Amazon Linux 2) o la biblioteca DNF (Amazon Linux 2023) accede al archivo `updateinfo.xml` de cada repositorio configurado. 

   Si no encuentra el archivo `updateinfo.xml`, la instalación de las revisiones variará en función de la configuración de la opción **Incluir actualizaciones no relacionadas con la seguridad** y **Aprobación automática**. Por ejemplo, si se permiten las actualizaciones no relacionadas con la seguridad, se instalarán en el momento en que se realice la aprobación automática.

1. Cada aviso de actualización de `updateinfo.xml` incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.  
**Atributos de aviso de actualización**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.

1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

## Funcionamiento de las reglas de líneas de base de revisiones en CentOS Stream
<a name="linux-rules-centos"></a>

Los repositorios predeterminados de CentOS Stream no incluyen un archivo `updateinfo.xml`. Sin embargo, los repositorios personalizados que se cree o se utilicen pueden incluir este archivo. En este tema, las referencias a `updateinfo.xml` se aplicarán únicamente a estos repositorios personalizados.

En las instancias de CentOS Stream, el proceso de selección de parches es el siguiente:

1. En el nodo administrado, la biblioteca DNF accede al archivo `updateinfo.xml`, si existe en un repositorio personalizado, correspondiente a cada uno de los repositorios configurados.

   Si no encuentra el archivo `updateinfo.xml`, el cual incluye los repositorios predeterminados, la instalación de los parches variará según la configuración de la opción **Incluir actualizaciones no relacionadas con la seguridad** y **Aprobación automática**. Por ejemplo, si se permiten las actualizaciones no relacionadas con la seguridad, se instalarán en el momento en que se realice la aprobación automática.

1. Si `updateinfo.xml` está presente, cada aviso de actualización en el archivo incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.  
**Atributos de aviso de actualización**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

1. En todos los casos, el producto del nodo administrado se determina según el SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.

1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

## Funcionamiento de las reglas de líneas de base de revisiones en Debian Server
<a name="linux-rules-debian"></a>

En Debian Server, el servicio de línea de base de revisiones permite filtrar en los campos *Prioridad* y *Sección*. Estos campos suelen estar presentes para todos los paquetes de Debian Server. Para determinar si un parche se ha seleccionado mediante la base de referencia de parches, Patch Manager hace lo siguiente:

1. En sistemas Debian Server, el equivalente de `sudo apt-get update` es ejecutar para actualizar la lista de paquetes disponibles. Los repositorios no están configurados y los datos se obtienen de los repositorios configurados en una lista de `sources`.

1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).

1. Después, se aplican las listas de [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) y [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches).
**nota**  
Como no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Debian Server, las opciones de aprobación automática no son compatibles con este sistema operativo.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. En este caso, en Debian Server, las versiones candidatas a revisiones se limitan a las revisiones incluidas en los siguientes repositorios:

   Estos repositorios se denominan de la siguiente manera:
   + Debian Server 11: `debian-security bullseye`
   + Debian Server 12: `debian-security bookworm`

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

   Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

Para ver el contenido de los campos *Priority* y *Section *, ejecute el siguiente comando `aptitude`: 

**nota**  
Es posible que necesite instalar por primera vez Aptitude en sistemas Debian Server.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

En la respuesta a este comando, todos los paquetes actualizables se notifican en este formato: 

```
name, priority, section, archive, candidate version
```

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

## Funcionamiento de las reglas de líneas de base de revisiones en macOS
<a name="linux-rules-macos"></a>

En las instancias de macOS, el proceso de selección de parches es el siguiente:

1. En el nodo administrado, Patch Manager accede al contenido analizado del archivo `InstallHistory.plist` e identifica los nombres y las versiones de los paquetes. 

   Para obtener más detalles acerca del proceso de análisis, consulte la pestaña **macOS** en [Cómo se instalan los parches](patch-manager-installing-patches.md).

1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.

1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

## Funcionamiento de las reglas de líneas de base de revisiones en Oracle Linux
<a name="linux-rules-oracle"></a>

En las instancias de Oracle Linux, el proceso de selección de parches es el siguiente:

1. En el nodo administrado, la biblioteca YUM accede al archivo `updateinfo.xml` de cada repositorio configurado.
**nota**  
El archivo `updateinfo.xml` podría no estar disponible si Oracle no administra el repositorio. Si no encuentra el archivo `updateinfo.xml`, la instalación de las revisiones variará en función de la configuración de la opción **Incluir actualizaciones no relacionadas con la seguridad** y **Aprobación automática**. Por ejemplo, si se permiten las actualizaciones no relacionadas con la seguridad, se instalarán en el momento en que se realice la aprobación automática.

1. Cada aviso de actualización de `updateinfo.xml` incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.  
**Atributos de aviso de actualización**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.

1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

## Funcionamiento de las reglas de líneas de base de revisiones en AlmaLinux, RHEL y Rocky Linux
<a name="linux-rules-rhel"></a>

En AlmaLinux, Red Hat Enterprise Linux (RHEL) y Rocky Linux, el proceso de selección de revisiones es el siguiente:

1. En el nodo administrado, la biblioteca YUM (RHEL 7) o la biblioteca DNF (AlmaLinux 8 y 9, RHEL 8, 9 y 10, y Rocky Linux 8 y 9) accede al archivo `updateinfo.xml` de cada repositorio configurado.
**nota**  
El archivo `updateinfo.xml` podría no estar disponible si Red Hat no administra el repositorio. Si no se encuentra `updateinfo.xml`; no se aplica ningún parche.

1. Cada aviso de actualización de `updateinfo.xml` incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.  
**Atributos de aviso de actualización**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

   Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.

1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

## Funcionamiento de las reglas de líneas de base de revisiones en SUSE Linux Enterprise Server
<a name="linux-rules-sles"></a>

En SLES, cada parche incluye los siguientes atributos que denotan las propiedades de los paquetes del parche:
+ **Category**: Corresponde al valor del atributo clave **Classification** en el tipo de datos [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la línea de base de revisiones. Denota el tipo de parche incluido en el aviso de actualización.

  Puede consultar la lista de valores admitidos mediante el comando **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** de la AWS CLI o la operación **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** de la API. También puede consultar la lista en el área **Approval rules** (Reglas de aprobación) de la página **Create patch baseline** (Crear una base de referencia de parches) o **Edit patch baseline** (Editar una base de referencia de parches) de la consola de Systems Manager.
+ **Gravedad**: corresponde al valor del atributo clave **Gravedad** en el tipo de datos [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la línea de base de revisiones. Denota la gravedad de los parches.

  Puede consultar la lista de valores admitidos mediante el comando **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** de la AWS CLI o la operación **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** de la API. También puede consultar la lista en el área **Approval rules** (Reglas de aprobación) de la página **Create patch baseline** (Crear una base de referencia de parches) o **Edit patch baseline** (Editar una base de referencia de parches) de la consola de Systems Manager.

El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave **Product** del tipo de datos [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la línea de base de revisiones. 

En cada parche, la base de referencia de parches se usa como filtro, de modo que solo se incluyen en la actualización los paquetes cualificados. Si varios paquetes son aplicables después de la aplicación de la definición de bases de referencia de parches, se usa la más reciente. 

Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

## Funcionamiento de las reglas de líneas de base de revisiones en Ubuntu Server
<a name="linux-rules-ubuntu"></a>

En Ubuntu Server, el servicio de línea de base de revisiones permite filtrar en los campos *Prioridad* y *Sección*. Estos campos suelen estar presentes para todos los paquetes de Ubuntu Server. Para determinar si un parche se ha seleccionado mediante la base de referencia de parches, Patch Manager hace lo siguiente:

1. En sistemas Ubuntu Server, el equivalente de `sudo apt-get update` es ejecutar para actualizar la lista de paquetes disponibles. Los repositorios no están configurados y los datos se obtienen de los repositorios configurados en una lista de `sources`.

1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).

1. Después, se aplican las listas de [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) y [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches).
**nota**  
Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.

   Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.

   Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. En este caso, en Ubuntu Server, las versiones candidatas a revisiones se limitan a las revisiones incluidas en los siguientes repositorios:
   + Ubuntu Server 16.04 LTS: `xenial-security`
   + Ubuntu Server 18.04 LTS: `bionic-security`
   + Ubuntu Server 20.04 LTS: `focal-security`
   + Ubuntu Server 22.04 LTS (`jammy-security`)
   + Ubuntu Server 24.04 LTS (`noble-security`)
   + Ubuntu Server 25.04 (`plucky-security`)

   Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.

   Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).

Para ver el contenido de los campos *Priority* y *Section *, ejecute el siguiente comando `aptitude`: 

**nota**  
Es posible que necesite instalar por primera vez Aptitude en sistemas Ubuntu Server 16.

```
aptitude search -F '%p %P %s %t %V#' '~U'
```

En la respuesta a este comando, todos los paquetes actualizables se notifican en este formato: 

```
name, priority, section, archive, candidate version
```

Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).

# Diferencias en la operación de revisiones entre Linux y Windows Server
<a name="patch-manager-windows-and-linux-differences"></a>

En este tema se describen las principales diferencias entre la aplicación de revisiones de Linux y Windows Server en Patch Manager, una herramienta de AWS Systems Manager.

**nota**  
Para aplicar revisiones a los nodos administrados de Linux, los nodos deben ejecutar la versión de SSM Agent 2.0.834.0 o posterior.  
Cada vez que se agregan herramientas nuevas a Systems Manager o se actualizan las herramientas existentes, se lanza una versión actualizada de SSM Agent. No utilizar la versión más reciente del agente puede impedir que el nodo administrado utilice diversas herramientas y características de Systems Manager. Por este motivo, se recomienda automatizar el proceso de mantener SSM Agent actualizado en los equipos. Para obtener más información, consulte [Automatización de las actualizaciones de SSM Agent](ssm-agent-automatic-updates.md). Suscríbase a la página [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) en GitHub para recibir notificaciones sobre las actualizaciones de SSM Agent.

## Diferencia 1: evaluación de parches
<a name="patch-evaluation_diff"></a>

Patch Manager utiliza procesos diferentes en los nodos administrados por Windows y los nodos administrados por Linux con el fin de evaluar qué revisiones deben incluirse. 

**Linux**  
En la aplicación de revisiones de Linux, Systems Manager evalúa las reglas de bases de referencia de revisiones y la lista de las revisiones aprobadas y rechazadas en *cada* nodo administrado. Systems Manager debe evaluar la aplicación de revisiones en cada nodo debido a que el servicio recupera la lista de actualizaciones y revisiones conocidas a partir de los repositorios configurados en el nodo administrado.

**Windows**  
En la aplicación de parches de Windows, Systems Manager evalúa las reglas de base de referencia de parches y la lista de los parches aprobados y rechazados *directamente en el servicio*. Puede hacerlo porque los parches de Windows se obtienen de un único repositorio (Windows Update).

## Diferencia 2: parches `Not Applicable`
<a name="not-applicable-diff"></a>

Debido a la gran cantidad de paquetes disponibles para los sistemas operativos Linux, Systems Manager no informa los detalles sobre parches en el estado *Not Applicable* (No aplicable). Un parche `Not Applicable` es, por ejemplo, un parche del software Apache cuando la instancia no tiene instalado dicho servicio. Systems Manager informa la cantidad de revisiones `Not Applicable` en el resumen, pero si llama a la API [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) para un nodo administrado, los datos devueltos no incluyen revisiones cuyo estado sea `Not Applicable`. Este comportamiento es diferente en Windows.

## Diferencia 3: compatibilidad con documentos SSM
<a name="document-support-diff"></a>

El documento `AWS-ApplyPatchBaseline` de Systems Manager (documento de SSM) no admite nodos administrados de Linux. Para aplicar bases de referencia de revisiones a nodos administrados de Linux, macOS y Windows Server, el documento de SSM recomendado es `AWS-RunPatchBaseline`. Para obtener más información, consulte [Documentos de comando de SSM para la aplicación de revisiones a nodos administrados](patch-manager-ssm-documents.md) y [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).

## Diferencia 4: parches de aplicación
<a name="application-patches-diff"></a>

Patch Manager se centra principalmente en aplicar parches a sistemas operativos. Sin embargo, también puede utilizar Patch Manager para aplicar revisiones a algunas aplicaciones de los nodos administrados.

**Linux**  
En los sistemas operativos Linux, Patch Manager utiliza los repositorios configurados para actualizaciones y no distingue entre sistemas operativos y parches de aplicaciones. Puede utilizar Patch Manager para definir de qué repositorios obtendrá actualizaciones. Para obtener más información, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).

**Windows**  
En nodos administrados de Windows Server, puede aplicar reglas de aprobación, así como excepciones de revisiones *aprobadas* o *rechazadas*, para las aplicaciones publicadas por Microsoft, como Microsoft Word 2016 o Microsoft Exchange Server 2016. Para obtener más información, consulte [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).

## Diferencia 5: opciones de listas de revisiones rechazadas en líneas de base de revisiones personalizadas
<a name="rejected-patches-diff"></a>

Al crear una línea de base de revisiones personalizada, puede especificar una o más revisiones para una lista de **revisiones rechazadas**. En el caso de los nodos gestionados por Linux, también puede optar por permitir su instalación si son dependencias de otra revisión permitida por la línea de base.

Windows Server, sin embargo, no admite el concepto de dependencias de revisiones. Puede agregar una revisión a la lista de **revisiones rechazadas** en una línea de base personalizada para Windows Server, pero el resultado depende de (1) si la revisión rechazada ya está instalada o no en un nodo gestionado y (2) de la opción que elija para la **acción de revisiones rechazadas**.

Consulte la siguiente tabla para obtener más información sobre las opciones de revisiones rechazadas en Windows Server.


| Estado de la instalación | Opción: “Permitir como dependencia” | Opción: “Bloque” | 
| --- | --- | --- | 
| La revisión ya está instalada | Estado registrado: INSTALLED\$1OTHER | Estado registrado: INSTALLED\$1REJECTED | 
| La revisión no está instalada | Revisión omitida | Revisión omitida | 

Cada revisión para Windows Server que Microsoft lanza normalmente contiene toda la información necesaria para que la instalación se realice correctamente. Sin embargo, en ocasiones, es posible que se requiera un paquete de requisitos previos, que debe instalarse manualmente. Patch Manager no proporciona información acerca de estos requisitos previos. Para obtener información relacionada, consulte [Solución de problemas de actualización de Windows](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting) en el sitio web de Microsoft.